オブジェクト修復タイマーの無効化は強く非推奨ですが、設定できる最大値は 4,294,967,295 なのである程度大きな値を入れておけばノード障害時やノードの停止時などの修復は行われません。
当然その状態が長く続いたまま別のノードが停止した場合などは VM の停止、データロストのリスクが伴います。
オブジェクトの修復を「手動で実行したい意図」である場合、故障を認識した後にオブジェクト修復タイマーの値を小さく設定しデータの修復をさせる必要があります。
ノードのメンテナンスで長時間停止する必要がある時など、その間だけオブジェクト修復タイマーを調整する運用が一般的なので、無効化は避けてください。
また、HDD や SSD が明示的に壊れた事を検知した場合(Absent ではなく Degraded)は、オブジェクト修復タイマーの設定とは関係なく修復が即時開始されます。
「vSANリバランスを自動的に実行させないため」に関しては、オブジェクト修復タイマーではなく「自動リバランス」を無効にしておくだけで済みます。
但し、こちらも各ドライブの容量が 80% を超えた場合は、「自動リバランス」が無効であっても空いている他のドライブにリバランスが開始されます。
修復とリバランスは別物です。
修復はポリシーを満たさない VM のデータを再構成するための機能で、
例えば RAID1 の片方のデータが ESXi ホストの停止によりアクセスできなくなった際に、残ったもう一つのデータを別のホストに「コピー」して RAID1 を再構成する動きをとります。
リバランスはポリシーを満たしている正常のなデータに対して、ドライブの使用率と閾値に応じてデータを「移動」し、利用率を均等にする機能です。
HA 発生後の動きとしては、オブジェクト復旧タイマー60分で設定されている場合は60分後に、ポリシーに準拠していない VM データの再構成が始まります。
その後、停止していた ESXi ホストが復旧した際は、そのホスト内のデータと、正常に稼働していたホスト内のデータが比べられ、停止していたホスト内の古い不要なデータは削除されます。
その結果、復旧したホストのドライブ使用率は低下するので、ここで自動リバランスが有効になっていれば、他のホストからデータが再配置されクラスタ全体でのドライブ利用率が均等になる様に調整されます。
オブジェクト修復タイマーの無効化は強く非推奨ですが、設定できる最大値は 4,294,967,295 なのである程度大きな値を入れておけばノード障害時やノードの停止時などの修復は行われません。
当然その状態が長く続いたまま別のノードが停止した場合などは VM の停止、データロストのリスクが伴います。
オブジェクトの修復を「手動で実行したい意図」である場合、故障を認識した後にオブジェクト修復タイマーの値を小さく設定しデータの修復をさせる必要があります。
ノードのメンテナンスで長時間停止する必要がある時など、その間だけオブジェクト修復タイマーを調整する運用が一般的なので、無効化は避けてください。
また、HDD や SSD が明示的に壊れた事を検知した場合(Absent ではなく Degraded)は、オブジェクト修復タイマーの設定とは関係なく修復が即時開始されます。
「vSANリバランスを自動的に実行させないため」に関しては、オブジェクト修復タイマーではなく「自動リバランス」を無効にしておくだけで済みます。
但し、こちらも各ドライブの容量が 80% を超えた場合は、「自動リバランス」が無効であっても空いている他のドライブにリバランスが開始されます。
kawamanさん
ありがとうございます!非推奨なのですね、承知しました。
ご教示頂いた内容において、
オブジェクト復旧タイマー60分、「自動リバランス」が無効である場合、1Node障害が起きた時に、
HA発生後、残ったNodeの各ドライブ容量が 80% を超えない場合は、「自動リバランス」が無効なので、60分後もリバランスが実行されない
HA発生後、残ったNodeの各ドライブ容量が 80% を超えた場合は、60分後にリバランスが実行される
と認識しているのですが、相違ありますでしょうか。
修復とリバランスは別物です。
修復はポリシーを満たさない VM のデータを再構成するための機能で、
例えば RAID1 の片方のデータが ESXi ホストの停止によりアクセスできなくなった際に、残ったもう一つのデータを別のホストに「コピー」して RAID1 を再構成する動きをとります。
リバランスはポリシーを満たしている正常のなデータに対して、ドライブの使用率と閾値に応じてデータを「移動」し、利用率を均等にする機能です。
HA 発生後の動きとしては、オブジェクト復旧タイマー60分で設定されている場合は60分後に、ポリシーに準拠していない VM データの再構成が始まります。
その後、停止していた ESXi ホストが復旧した際は、そのホスト内のデータと、正常に稼働していたホスト内のデータが比べられ、停止していたホスト内の古い不要なデータは削除されます。
その結果、復旧したホストのドライブ使用率は低下するので、ここで自動リバランスが有効になっていれば、他のホストからデータが再配置されクラスタ全体でのドライブ利用率が均等になる様に調整されます。
なるほど、、
すみません。復旧とリバランスを混同していたため齟齬が起きていることを把握しました。
ご教示頂きありがとうございます。
60分後に復旧(RAID再構築)時に、仮想マシンへのIOPSの低下等、挙動影響は大きいでしょうか。
もちろん仮想マシンの数や使用済みリソース、障害発生したNode数に依存するかと存じますが、
vSphere7.0からは、比較的早く復旧処理が完了している感覚でおります。
また、vSANリバランス発生時は、クラスタ全体でのドライブ調整が走るため、VMへのIOPSが著しく低下することが確認できており、
自動実行を避けたいのでオフに設定しております。
少し前の QA でリバランスやリビルド時の負荷について回答していますので、参照先としてご紹介します。
比較的新しいバージョンでは Adaptive Resync などが適切に働きフロントエンドには IO 影響が極力発生しないような調整が入りますが、
キャパシティドライブが HDD の場合や、SATA SSD の場合、Resync がどの程度の量、範囲で起きるかにもよりますが同時並列で起こる Resync IO を受け止める Queue Depth が少ないために IO のボトルネックとなる可能性があります。
そうした懸念がある場合は、リバランスは手動運用にして決まったメンテナンス時間に実行するなどの運用が良い場合はあります。