|
この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。 |
|
これは未公開の文書です SUSE® Storage 1.12 (Dev). |
オフラインレプリカ再構築
v1.9.0以降、SUSE Storageはオフラインレプリカ再構築をサポートしています。この機能により、ボリュームが切り離されている間に劣化したボリュームが自動的にレプリカを再構築できます。
グローバル設定 offline-replica-rebuilding
-
有効にすると、SUSE Storageは対象のボリュームに対して自動的にオフライン再構築を開始します。
-
このグローバル設定の詳細については、settingsを参照してください。
ボリュームごとのオーバーライド
-
各ボリュームに対してグローバル`offline-replica-rebuilding`設定を個別にオーバーライドできます。これは、SUSE Storage UIを通じて、またはボリュームカスタムリソースを編集することで行えます。`kubectl`を使用するには、次のコマンドを実行し、`spec.offlineRebuilding`フィールドを変更してください:
kubectl -n longhorn-system edit volume <volume-name>`<volume-name>`を特定のボリュームの名前に置き換えてください。
-
ボリュームごとの`spec.offlineRebuilding`フィールドが`enabled`または`disabled`に設定されている場合、この設定はグローバル設定よりも優先されます。`spec.offlineRebuilding`のデフォルト値は`ignored`です。
以下の表は、グローバル設定とボリュームごとの設定がどのように相互作用するかを示しています:
グローバル設定 ( |
ボリュームごとの設定 ( |
オフライン再構築が有効 |
|
|
はい |
|
|
いいえ |
|
|
はい |
|
|
はい |
|
|
いいえ |
|
|
いいえ |
再構築処理
-
オフラインレプリカ再構築がトリガーされると、SUSE Storageはフロントエンドをアクティブにせずにボリュームを接続し、欠落しているレプリカを再構築し、再構築プロセスが完了した後にボリュームを切り離します。
-
このプロセスは、関連するワークロードがスケールアップし、ボリュームを必要とする場合に中断される可能性があります。
再構築は開始されていないか、キャンセルされました
オフライン再構築が開始されると、再構築条件が満たされない場合、劣化したボリュームが接続状態に留まることがあります。これを防ぐために、必要な条件が満たされない場合、オフライン再構築は開始されないか、キャンセルされます。
-
利点:
-
再構築が完了しない場合でも、ボリュームが接続状態に留まらないことを保証します。
-
無駄な再構築の試行を防ぎます。
-
不必要なボリュームの接続と切断のサイクルを減らします。
-
リソースの可用性に基づいて、予測可能な再構築動作を提供します。
-
-
必要な条件:必要な条件が満たされると、劣化したボリュームのオフライン再構築が自動的に開始されます。これらの条件には次のものが含まれます:
-
再利用可能な失敗したレプリカが存在するか、
-
ディスク候補が存在すること:
-
ディスクをホストしているノードのインスタンスマネージャーが準備完了である必要があります。
-
ディスクを含むノードがスケジュール可能であること。
-
ディスク自体はスケジュール可能です。
-
-
オフライン再構築が開始される前に
オフライン再構築が有効になっているとき、SUSE Storageが開始すべきかどうかを決定します。
-
SUSE Storageが劣化した切り離されたボリュームを検出します。
-
システムは再構築を開始する前に、必要な条件が満たされているかどうかを検証します。
-
条件が満たされると、再構築が進行します。そうでなければ、ボリュームは切り離されたままです。
-
ノードが追加されたり、準備が整ったり、スケジュール可能になったりすると、必要な条件が再評価されます。
オフライン再構築中
SUSE Storageは、進行中に再構築プロセスをキャンセルすべきかどうかを判断します。
-
SUSE Storageは、オフライン再構築が開始され、ボリュームが接続されているときのボリュームの状態を検出します。
-
ボリュームの`Scheduled`条件の状態が`False`になると、オフライン再構築はキャンセルされ、ボリュームは切り離されます。
-
再度必要な条件が満たされると、オフライン再構築が再開されます。そうでなければ、ボリュームは切り離されたままです。
例
-
成功したオフライン再構築:
-
ボリュームは、3つのレプリカを持つ3ワーカーノードクラスターで作成されます。
-
オフライン再構築が有効になっています。
-
ボリュームは切り離され、その後ボリュームのレプリカが削除されます。
-
オフライン再構築が始まり、ボリュームが接続されます。
-
再構築が完了した後、ボリュームは切り離されます。
-
-
オフライン再構築は有効になっていても開始されません:
-
ボリュームは、3つのレプリカを持つ3ワーカーノード(A、B、C)クラスターで作成されます。
-
オフライン再構築が有効になっています。
-
ワーカーノードAはスケジュール不可です。
-
ワーカーノードAのボリュームレプリカが削除されます。
-
スケジュール可能なワーカーノードが2つしか存在しないため、オフライン再構築は開始されません。
-
-
オフライン再構築中にワーカーノードが排出されます:
-
ボリュームは、3つのレプリカを持つ3ワーカーノード(A、B、C)クラスターで作成されます。
-
オフライン再構築が有効になっています。
-
ボリュームは切り離され、その後、ワーカーノードA上のボリュームレプリカが削除されます。
-
オフライン再構築が始まり、ボリュームがワーカーノードA上のレプリカを再構築するために接続されます。
-
ワーカーノードAは排出され、スケジュールできなくなり、ワーカーノードA上のボリュームレプリカが削除されます。
-
ボリュームは、ボリュームの`Scheduled`条件ステータスが`False`になるまで接続されたままです。
-
ボリュームは、ワーカーノードAがスケジュール可能になるか、新しいスケジュール可能なノードが追加されるまで切り離されます。
-