Longhorn、エンタープライズレベルのクラウドネイティブコンテナ分散ストレージ - 高可用性

[[419475]]

目次

• データの局所性
• デフォルトのグローバル設定の変更
• Longhorn UI を使用して単一ボリュームのデータの場所を変更する
• StorageClass を使用して単一ボリュームのデータ局所性を設定する
• データ局所性設定
• ボリュームのデータ局所性を設定する方法
• 誤って切り離されたボリュームの回復
• Longhorn でのノード障害の処理
  • ボリュームアタッチメントリカバリポリシー
  • ボリュームアタッチメントリカバリポリシーなし（Kubernetes のデフォルト）
  • ボリューム アタッチメント回復ポリシーの待機 (Longhorn のデフォルト)
  • ボリュームアタッチメントリカバリポリシー即時
  • Kubernetes ノードに障害が発生するとどうなりますか?
  • ノード障害時の Longhorn ポッド削除戦略
  • 障害が発生した Kubernetes ノードが回復すると何が起こりますか?

データの局所性

データ ローカリティ設定は、次の状況で有効にすることを目的としています。可能な場合は常に、Longhorn ボリュームの少なくとも 1 つのレプリカを、そのボリュームを使用するポッドと同じノードにスケジュールする必要があります。ローカル コピーを持つという特性を、データ ローカリティを持つと呼びます。

たとえば、ローカル コピーがあるとボリュームの可用性が向上するため、クラスターのネットワーク接続が不十分な場合にデータのローカリティが役立ちます。

データ ローカリティは、ボリューム レベルではなくアプリケーション レベルで高可用性が実現されるデータベースなどの分散アプリケーションにも役立ちます。この場合、ポッドごとに必要なボリュームは 1 つだけなので、各ボリュームは、それを使用するポッドと同じノードにスケジュールする必要があります。さらに、ボリューム スケジューリングのデフォルトの Longhorn 動作により、分散アプリケーションに問題が発生する可能性があります。問題は、ポッドに 2 つのレプリカがあり、各ポッド レプリカにボリュームがある場合、Longhorn はこれらのボリュームに同じデータがあることを認識できず、同じノードにスケジュールすべきではないということです。したがって、Longhorn は同じノード上で同一のレプリカをスケジュールすることができ、ワークロードの高可用性の提供を妨げる可能性があります。

データ ローカリティが無効になっている場合、Longhorn ボリュームはクラスター内の任意のノード上のレプリカによってバックアップされ、クラスター内の任意のノードで実行されているポッドによってアクセスされます。

データ局所性設定

Longhorn は現在、次の 2 つのデータ ローカリティ設定をサポートしています。

• 無効。これはデフォルトのオプションです。アタッチされたボリューム (ワークロード) と同じノード上にレプリカが存在する場合と存在しない場合があります。
• ベストエフォート。このオプションは、Longhorn に、接続されたボリューム (ワークロード) と同じノード上にレプリカを保持するように指示します。 Longhorn は、ディスク容量不足、ディスク ラベルの互換性がないなどの環境上の制約により、接続されたボリューム (ワークロード) に対してレプリカをローカルに保持できない場合でも、ボリュームを停止しません。

ボリュームのデータ局所性を設定する方法

Longhorn ボリュームのデータ ローカリティを設定するには、次の 3 つの方法があります。

デフォルトのグローバル設定の変更

Longhorn UI 設定で、データ ローカリティのグローバル デフォルトを変更できます。グローバル設定は、レプリカ数などのデフォルトとしてのみ使用されます。既存のボリュームの設定は変更されません。 (データのローカリティ) を指定せずにボリュームを作成すると、Longhorn はグローバル デフォルト設定を使用してボリュームのデータ ローカリティを決定します。

Longhorn UI を使用して単一ボリュームのデータの場所を変更する

ボリュームを作成するときに、Longhorn UI を使用してデータのローカリティを設定できます。ボリュームの詳細ページでボリュームを作成した後、データのローカリティ設定を変更することもできます。

StorageClass を使用して単一ボリュームのデータ局所性を設定する

Longhorn は、データ ローカリティ設定を StorageClass のパラメータとして公開します。指定されたデータ ローカリティ設定を使用して StorageClass を作成し、その StorageClass を使用して PVC を作成できます。たとえば、次の YAML ファイルは、Longhorn CSI ドライバーにデータ ローカリティをベスト エフォートに設定するように指示する StorageClass を定義します。

種類: ストレージクラス
APIバージョン: storage.k8s.io/v1
メタデータ:
名前: ハイパーコンバージド
プロビジョナー: driver.longhorn.io
ボリューム拡張を許可する: true  
パラメータ:
  レプリカ数: "2"  
  データ局所性: 「ベストエフォート」  
  staleReplicaTimeout: "2880" # 48 時間（分）
  バックアップから: ""  

誤って切り離されたボリュームの回復

Kubernetes のアップグレード、Docker の再起動、またはネットワークの切断中に予期しないデタッチが発生すると、ポッドがコントローラー (デプロイメント、ステートフルセット、デーモンセットなど) によって管理されている場合、Longhorn はワークロード ポッドを自動的に削除します。ポッドを削除すると、そのコントローラーがポッドを再起動し、Kubernetes がボリュームの再接続と再マウントを処理します。

Longhorn でワークロード ポッドを自動的に削除したくない場合は、Longhorn UI 設定の「ボリュームが予期せず切断されたときにワークロード ポッドを自動的に削除する」で設定できます。

コントローラーのない Pod の場合、Longhorn はそれらを削除しません。Longhorn がそれらを削除した場合、誰もそれらを再起動しないからです。誤って切断されたボリュームを回復するには、コントローラーなしでポッドを手動で削除して再作成する必要があります。

Longhorn でのノード障害の処理

Kubernetes ノードに障害が発生するとどうなりますか?

このセクションは、ノード障害時に何が起こるか、および回復時に何が起こるかをユーザーに通知することを目的としています。

1 分後、kubectl get nodes は障害が発生したノードについて NotReady を報告します。

約 5 分後、NotReady ノード上のすべての Pod のステータスが Unknown または NodeLost に変わります。

StatefulSet には安定した ID があるため、Kubernetes はユーザーに代わってポッドの削除を強制しません。 StatefulSet を強制的に削除する方法については、Kubernetes の公式ドキュメントを参照してください。

デプロイメントには安定した ID はありませんが、Read-Write-Once ストレージの場合、2 つのノードに同時に接続できないため、Kubernetes によって作成された新しいポッドは、失われたノードにある古いポッドに RWO ボリュームがまだ接続されているため、起動に失敗します。

どちらの場合も、Kubernetes は失われたノード上のポッドを自動的に削除し (ポッドの削除タイムスタンプを設定)、古いボリュームを使用して新しいボリュームを再作成しようとします。削除されたポッドは Terminating 状態のままになり、接続されたボリュームを解放/再利用できないため、管理 (admin) またはストレージ (storage) ソフトウェアからの介入がない場合、新しいポッドは ContainerCreating 状態のままになります。

ノード障害時の Longhorn ポッド削除戦略

Longhorn には、ダウンしたノード上の StatefulSet/Deployment の終了したポッドをユーザーが自動的に強制削除できるようにするオプションが用意されています。強制削除後、Kubernetes は Longhorn ボリュームをデタッチし、新しいノードで代替ポッドを開始します。

設定オプションの詳細については、Longhorn UI の [設定] タブまたは [設定リファレンス] の [ノードがダウンしたときのポッド削除ポリシー] を参照してください。

ボリュームアタッチメントリカバリポリシー

ポッドを強制的に削除することにした場合 (手動または Longhorn の助けを借りて)、Kubernetes はポッドに関連付けられた VolumeAttachment オブジェクトを削除するのに約 6 分かかり、最後に失われたノードからボリュームを切り離して、新しいポッドで使用できるようにします。

この 6 分間は Kubernetes にハードコードされており、失われたノード上のポッドが強制的に削除されると、関連付けられたボリュームは適切にアンマウントされません。 Kubernetes は、この固定タイムアウトを待機して、VolumeAttachment オブジェクトを直接クリーンアップします。

この問題に対処するために、3 つの異なるボリューム アタッチメント回復戦略を提供します。

ボリュームアタッチメントリカバリ戦略なし（Kubernetes のデフォルト）

Longhorn は、障害が発生したノードからボリューム アタッチメントを回復しません。これは、Kubernetes のデフォルトの動作と一致しています。ユーザーは終了したポッドを強制的に削除する必要があります。その時点で、Longhorn は障害が発生したノードからボリューム アタッチメントを回復します。これにより、要求されたボリュームが利用可能な場合、保留中の交換ポッドが正しく起動できるようになります。

ボリューム アタッチメント回復ポリシーの待機 (Longhorn のデフォルト)

Longhorn は、終了するすべてのポッドの削除猶予期間が経過するまで、ボリューム アタッチメントの復元を待機します。この時点でノード kubelet は Pod を削除する必要があり、Pod はまだ使用可能であるため、障害が発生したノード Kubelet は Pod を削除できないと結論付けることができます。この時点で、Longhorn は障害が発生したノードからボリューム アタッチメントを回復します。これにより、要求されたボリュームが利用可能な場合、保留中の交換ポッドが正しく起動できるようになります。

ボリュームアタッチメントリカバリポリシー即時

Longhorn は、保留中の交換ポッドが利用可能である限り、障害が発生したノードからボリューム アタッチメントを回復します。これにより、要求されたボリュームが利用可能な場合、保留中の交換ポッドが正しく起動できるようになります。

障害が発生した Kubernetes ノードが回復すると何が起こりますか?

障害発生後 5 ～ 6 分以内にノードがオンラインに戻ると、Kubernetes はポッドを再起動し、ボリュームの再アタッチや VolumeAttachment のクリーンアップを行わずにボリュームをアンマウントして再マウントします。

ノードがクラッシュするとボリューム エンジンがシャットダウンされるため、デバイスがノード上に存在しなくなるため、この直接再マウントは機能しません。

この場合、Longhorn はボリュームをデタッチして再アタッチし、ボリューム エンジンを回復して、ポッドがボリュームを安全に再マウント/再利用できるようにします。

障害発生後 5 ～ 6 分以内にノードがオンラインに戻らない場合、Kubernetes はポッド排除メカニズムに基づいてすべての到達不能なポッドを削除しようとし、これらのポッドは終了状態になります。詳細については、ポッドの削除タイムアウトを参照してください。

その後、障害が発生したノードが回復すると、Kubernetes は終了したポッドを再起動し、ボリュームをデタッチし、古い VolumeAttachment がクリーンアップされるのを待ってから、ボリュームを再アタッチして再マウントし、再利用します。通常、これらの手順には 1 ～ 7 分かかります。

この場合、デタッチと再アタッチの操作は Kubernetes リカバリ プロセスにすでに含まれています。したがって、追加のアクションは必要なく、上記の手順を実行すると Longhorn ボリュームが使用できるようになります。

上記のすべてのリカバリ シナリオでは、Longhorn は Kubernetes の関連付けを通じてこれらの手順を自動的に処理します。