"HCI" はじめました。

vSAN担当小佐野舞です。VMwareのHCIを広めるため日々活動していきます。

vSAN 7 Update 3 詳細編② 2ノードクラスタにおける可用性の向上 その2

みなさま、こんにちは。

この記事は久しぶりに出社した曲面ディスプレイで書き始めてみました。

広角で撮るとより違和感です。

f:id:vmwarekkHCI:20220127165224p:plain

 

前回はこちら

vSAN 7 Update 3 詳細編① 2ノードクラスタにおける可用性の向上 その1

 

2ノードvSAN クラスタユースケースとして、拠点やエッジが挙げられます。

データセンタではなく、そこで収集、実行すべきアプリケーションを稼働させる基盤として、末端だから可用性は低くて良い、そんなことはありません。

だからこそ、2ホストの2重障害*にも耐えられる、Nested フォルトドメイン!!!

 

*ホスト2台の障害ではありません。

ホスト1台+異なるホストのストレージデバイス障害

各ホストの同時ストレージデバイス障害

などの2つの同時障害という意味となります。

詳しく説明していきますね。

 

通常の2ノードクラスタの場合の障害時の挙動の復習です。

まず、各ホストにデータがミラーリングされていることから、1ホストの障害でも仮想マシンを継続稼働させることが可能です。

(通常のvSAN 構成と同様のFTT=1 ミラーリングはホスト1台の障害を許容します)

 

障害のパターンとして2つ例に挙げます。

  1. ストレージデバイス障害
    各ホスト単一ディスクグループの場合:ホスト障害と同様の挙動となります。
    各ホストに複数ディスクグループがある場合:障害が発生している同一ホスト内の異なるディスクグループに空き容量があれば、再同期が行われます。
  2. ホスト障害
    下の図で詳しく説明していきます。

f:id:vmwarekkHCI:20220127164727p:plain

ストレージポリシー

サイトの耐障害性 なし

許容する障害の数 1 (ミラーリング)

ホスト#1で稼働している仮想マシンのVMDKはホスト#1、ホスト#2の両方に書き込まれます。

 

f:id:vmwarekkHCI:20220127164746p:plain

ホスト#1に障害発生!

ホスト#1上で稼働している仮想マシンは電源断の状態となり、ローカルデバイスに保管されているVMDKに対してもアクセスできなくなります。

ホスト#2で稼働している仮想マシンについては影響なく稼働し続けます。

 

f:id:vmwarekkHCI:20220127164706p:plain

ホスト#1上で稼働していた仮想マシンはHAによりホスト#2上で起動します。

HAによる再起動、です。

もちろんホスト#2で稼働していた仮想マシンはそのまま動き続けます。

 

 

では、Nested フォルトドメインが有効な場合の障害時の挙動を見ていきましょう。

f:id:vmwarekkHCI:20220127110955p:plain

ストレージポリシー

サイトの耐障害性 ホストミラーリング(2ノード)

許容する障害の数 1 (ミラーリング)

 

障害のパターンとして3つ例に挙げます。

いずれもホスト#1上の仮想マシンは稼働し続けるシナリオです。

  1. ストレージデバイス障害
  2. ホスト障害
  3. ホスト障害とストレージデバイス障害

 

1.ストレージデバイス障害

f:id:vmwarekkHCI:20220201170018p:plain

ホスト#2のストレージデバイス障害が発生した場合、そのストレージデバイスに配置されているVMDKにアクセスできなくなります。

キャッシュデバイスの障害の場合はディスクグループ全体にアクセスできなくなります。

ホスト#1、ホスト#2上の仮想マシンは稼働し続けます。

 

 

2.ホスト障害

f:id:vmwarekkHCI:20220201160054p:plain

ホスト#2のホスト障害が発生した場合、ホスト#2のVMDKにはアクセスできなくなります。

ホストミラーリングされていることによって、ホスト#1上の仮想マシンは稼働し続けます。

ホスト#2上で稼働していた仮想マシンは自動的にホスト#1で再起動されます。

 

 

3.ホスト障害とストレージデバイス障害

f:id:vmwarekkHCI:20220201170226p:plain

ホスト#2の障害とホスト#1のストレージデバイス障害が同時に発生した

同時ではなくても

ホスト#2のメンテナンス中にホスト#1のストレージデバイス障害が発生してしまった!

という場合。

Nested フォルトドメインで同一ホストの異なるディスクグループにもVMDKがあるため、ホスト#1上の仮想マシンは稼働し続けます。

ホスト#2上で稼働していた仮想マシンは自動的にホスト#1で再起動されます。

 

 

必要容量はホストミラーリングで2倍、さらにNested フォルトドメイン(ホスト内保護)により2倍となります。

仮想マシン1台 VMDK 40GBの場合:

ホストミラーリング 40GB x2 = 80GB

ホスト内保護    80GB x 2 = 160GB

ざっくりこのような試算になります。

 

2ホストだからこそ。

障害時/メンテナンス時の可用性を高める必要性がある場合にはこのNested フォルトドメインを活用いただくことで、安心安全の2ノードvSAN を構成いただけます。

そのためには倍の容量が必要となります。

強固な保護のために支払うのは倍の容量、ということですね...

ただですね、このNested フォルトドメインの設定はストレージポリシーで定義します。

ホストミラーリングかつホスト内保護を行うか、ホストミラーリングのみを行うか、選べます!

ストレッチクラスタ のローカル保護/サイト保護でも同様ですが、どの仮想マシンを重点的に保護するか、必要に応じて設定できることがvSAN の強みですね!

 

 

 

ということで久しぶりに2ノードについて書いたら長くなってしまいました。

その他のU3アップデートについてもまとめていきたいと思ってますので、引き続きよろしくお願いします!