お世話になります。

ご認識通り、Nutanixで、Redundancy Factor2で構成されている場合、2ノード縮退時は、2ノードの中でRF2で2ノードの中でデーター冗長が行われます。ただし、さらに1ノードの障害には耐えられない形となります。では、3ノード構成のクラスターで1ノード障害時に、データーを内部で再冗長化するかというと、2ノードになった状態でも仮想マシンは、稼動し続けることができるため、2ノードで稼働中に、さらに2台のノードのうち1台のホスト上でディスク障害が発生した場合などでもデータロストを起こさないようにするメリットがあります。

3ノードのうちに1ノードの障害が発生した場合、故障したノードを早めに復旧することが重要ですが、クラスター全体のサービスを停止せずデーターを保護しながら稼動し続けるという観点では、2ノードでのデーター冗長化がメリットのある機能だと思います。

ローカリティ(性能向上)もデータ冗長性（可用性）の復活も同時に行われます。

Redundancy Factor＝2 が設定されている場合で環境に変化（障害など）が起きた場合には、データのコピーが2つある状態に向けたアクティビティが行われます。

3ノードクラスタで1ノードに障害が発生し、2ノードのクラスタになった場合でもデータの冗長性の復元を行います。（2ノード内で2コピーを作るため、結果として2ノードそれぞれで、同じデータを保持することになります。）

リビルドが完了すれば追加障害にも耐えられる状態になりますが、3→2ノードでキャパシティの1/3が失われてしまっている状態なので、大きなクラスタに比べると不安がのこります。いずれにしてもノードを早急に修理して3ノードに復帰させるのが良いでしょう。

@Shadowhat  @TetsuoMiyoshi 

早速のご回答ありがとうございます。
たびたび申し訳ありませんが、追加で確認をさせてください。

さらに2台のノードのうち1台のホスト上でディスク障害が発生した場合などでもデータロストを起こさないようにするメリットがあります。

つまり、3ノード構成における1ノード障害時（リビルド完了済み）の状態では以下の認識で正しいでしょうか？
①追加のディスク障害が発生した場合でもIOを継続できる

②追加のノード障害が発生した場合は、Redundancy Factorを超える障害であるためアクセス不可となる

③②の後で、いずれかのノードが復旧すればアクセスが復旧するが、いずれのノードも復旧できない場合はデータロスになる（もしくはディスクが無事ならばAHV/CVMの再構成で復旧可能？）

① YES (ディスクレベルでのリビルドが発生し、あるべき状態へ復元を行います)

② アクセス不可ではありませんが、あるべき状態（2コピーを作る）が復元できないため、システムを停止させて、ノードの復旧を行うべきです。

③ 最後に残された1ノード内にデータ自体は残るため、復旧可能です。

@TetsuoMiyoshi 

ご返信ありがとうございます。

②についてですが、私の説明の問題かもしれませんが、ラボ機で確認する限り、3ノード構成における1ノード障害時（リビルド完了済み）の状態で追加のノード障害が発生した場合、残る１ノードのPrism Elementにもアクセスができず、仮想マシンも止まっているように見受けられました。CassandraやZookeeperの観点で整合性が取れない状態であるための挙動ではないかと考えております。

③についてですが、KBなどで復旧の手順が紹介されていたりしますでしょうか？

Q: ②追加のノード障害が発生した場合は、Redundancy Factorを超える障害であるためアクセス不可となる

A: ② アクセス不可ではありませんが、あるべき状態（2コピーを作る）が復元できないため、システムを停止させて、ノードの復旧を行うべきです。

に関して念のため行間を補足しておきますと、1ノードになった時点でデータ破壊を防ぐためにストレージI/Oを担うサービスが止まりますので、(ストレージに対する)アクセス不可にはなりますね。ただ、生きてるノードのVMはONのままなので、ゲストOS内のメモリキャッシュで処理できちゃうような一部のサービスは動き続ける可能性はありますが、ディスクI/Oはできない状態では何かしらの処理に支障が出るので、VMはシャットダウンした方がいい、という話ですね。

@smzksts 

補足のご説明ありがとうございます。正しく理解することができました。