以下、Q と A を分けて書きますね
■ Q1.
> ・前提としまして、例えば4ノードのvSANクラスタ(VMは全てFTT1ミラー)の
> 1台で何らかの障害が発生してそのホストのVMにはアクセスできなく
> なった場合、ミラーリングしているもう1つのVMへの書き込み差分を
> 別の正常なホストのとある領域へコピーし続けるというような動きになる理解でよいでしょうか？
▼ A1.
持続性コンポーネント自体は最小 3Node で 1台ダウンした際も、Witness が置かれているホストに一先ず差分書き込みの持続性コンポーネントを保存します。
これにより、最悪もう 1 台の 仮想マシンのデータが置かれた ESXi ホストがダウンして VM 自体が強制終了されても、最初にダウンした ESXi が復旧し、Witness に置かれた差分の持続性コンポーネントと復旧した ESXi に格納されていたデータを合成して、VM が強制終了する直前までのデータが再構成され、VM がより新しい状態で HA により再起動します。
■ Q2.
> ・上記の理解で正しい場合、リシンクが実行される前に
> 障害ホストが復旧した場合は、増分のみのデータをアクセス不可だった
> VMにマージする動きになって、マージ後増分データは削除される・・・
▼A2.
その理解で合っています。
■ Q3.
> 逆に60分経ってリシンクが実行された場合は正常なVMからまるまるフルコピーが実行され、3ノードの構成で
> VMの冗長性が完全に確保された後は書き込み差分の領域は削除される動きになる、という理解でよいでしょうか？
▼ A3.
再構成が開始されている場合も、再構成完了前に落ちていた ESXi が復旧した場合、
このまま再構成を継続するか、復旧した ESXi の元データに差分をマージしたほうが早いか計算され、
より早く復旧する方で再構成が行われます。
再構成が完了している場合は復旧した ESXi の対象 VM の VMDK と持続性コンポーネントは削除されます。
■ Q4.
> その場合、この機能自体が無かった昔はリシンクが実行される前に障害ホストが復旧した場合でも
> 再度フル同期が走っていたのでしょうか？
> (そうでないと今回の機能で増分のみの同期になったので復旧性が向上しましたと言えない気がしまして・・・)
▼ A4.
この時の動きが A3 で説明した「より早く再構成が完了する方を自動で選ぶ」仕組みになり、
従来からあった再構成の仕組みに持続性コンポーネントコンポーネントが加わりより柔軟に対応できるようになった感じです。
■ Q5.
> ・仮にFTT1(ミラー)のVM両方に障害が発生してユーザからそのVMにアクセス
> できない場合などはこの機能も停止する、という理解でよいでしょうか？
▼ A5.
持続性コンポーネント、データの再構成のどちらも書き込み IO があり、アクセスできるデータのどちらかが活きていることが前提なので、
FTT1 RAID1 構成時に2重障害で両データにアクセスできなくなった場合はどちらも停止して、停止した ESXi が復旧したら VM への IO も復旧します。
