この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。

これは未公開の文書です SUSE® Storage 1.12 (Dev).

RWXボリュームのファストフェールオーバー（実験的）

リリース1.7.0では、ノードが失敗した際のReadWriteManyボリュームのダウンタイムを最小限に抑える機能が追加されました。 この機能が有効になると、LonghornはボリュームをエクスポートするNFSサーバーポッドの状態を監視するためにリースベースのメカニズムを使用し、応答しなくなった場合には迅速に別のノードに移動します。 NFSサーバーの動作に関する詳細はRWXボリュームを参照してください。

この機能を有効にするには、RWXボリュームファストフェールオーバーを「true」に設定します。 設定が変更された後、既存のRWXボリュームはこの機能を使用するために再起動する必要があります。 これは、ワークロードをゼロにスケールダウンし、その後再度スケールアップすることで行います。 新しいボリュームは作成時に設定を取得し、適切に構成されます。

機能が有効になっている場合、ポッドが作成または再作成されると、Longhornは同じ名前の関連するリースオブジェクトを`longhorn-system`ネームスペースに作成します。 NFSサーバーポッドは、生命の証拠としてリースを更新し続けます。 更新が停止した場合、Longhornは別のノードに新しいNFSサーバーポッドを作成し、ワークロードを再接続する手続きを行います。これは、古いノードがKubernetesによって`Not Ready`としてマークされる前に行われます。

監視と迅速な反応を追加するだけでなく、この機能はクライアント再接続のために短縮された猶予期間を使用するようにNFSサーバーの設定を変更します。

設定が「false」に戻された場合、リースチェックは無効になり、ポッドの移動は既存のボリュームに対してもノード障害のための通常のKubernetesルールを使用します。 次回サーバーポッドが再起動されると、通常の猶予期間の設定に戻ります。

詳細については、 https://github.com/longhorn/longhorn/issues/6205.を参照してください。

稀な状況では、フェールオーバーがデッドロック状態になる可能性があります。これは、フェールオーバー処理中の状態により既にブロックされている回復アクションが、さらにNFSサーバーポッドの作成を妨げる場合に発生します。 その場合、フェールオーバーに1分または2分以上かかる場合は、関連するリースオブジェクトを削除するのが回避策です。 これにより状態がクリアされ、新しいリースが置き換えられたサーバーポッドと共に作成されます。 例えば、スタックされたボリュームの名前が`pvc-2ce4e82e-7ccc-46c0-90a8-a141501fbf93`であり、機能が有効になっている場合、同じ名前のリースが存在します。 関連するリースオブジェクトを削除するには:

kubectl -n longhorn-system delete lease pvc-2ce4e82e-7ccc-46c0-90a8-a141501fbf93

例えば、 https://github.com/longhorn/longhorn/issues/9093.を参照してください。

リソース消費とシステムパフォーマンスへの影響

Longhornチームは、RWXボリュームがリソース消費とシステムパフォーマンスに与える影響を調査しました。60のRWXボリュームを使用して完了したベンチマーク研究は、_RWXボリュームのファストフェールオーバー_機能を有効にすると、以下の結果が得られることを示しています：

  • Kubernetes APIサーバー（kube-apiserver）へのリクエストが増加

  • kube-apiserverからetcdへのリモートプロシージャコール（RPC）が増加

  • CPUとメモリ使用量のわずかな増加

Environment:

  • *Setup (設定):*1つのコントロールノード + 3つのワーカーノード（v1.27.15+rke2r1）

  • *ワークロード:*60のデプロイメントと60のRWXボリューム（`soft`マウント付き）

テスト結果:

メトリック ファストフェールオーバー無効 ファストフェールオーバー有効 差異

APIリクエストレート（kube-apiserver）

37.5 req/s

59 req/s

+57.3%

RPCレート（kube-apiserverからetcd）

37 ops/s

57 ops/s

+54.1%

メモリ使用量

低いピーク/最小値

高いピーク/最小値

ファストフェールオーバーが有効な場合の使用量の増加

Longhorn ManagerのCPU/RAM使用量

405 MB / 0.1 CPU

417 MB / 0.13 CPU

+3% RAM / +30% CPU

シェアマネージャーのCPU/RAM使用量

2.2 GB / 0.235 CPU

2.25 GB / 0.26 CPU

+2.3% RAM / +10.6% CPU

詳細なスクリーンショットとさらなる文脈については、 関連する問題の議論を参照してください。