***** 注意 *******
こちらの記事で紹介するvSANで発生するスプリットブレイン（仮想マシンの二重起動）は
HCI アプライアンスやReady Nodeを問わず、vSAN環境で確認される事象ですが、vSANのバグではありません。
あくまでもvSAN環境の設定に依存する問題です。
こちらの記事ではvSAN環境で稀に起こりうる、仮想マシンの二重起動（スプリットブレイン）について紹介します。
なお、本記事では特に言及がない限りスプリットブレイン ＝ 仮想マシンの二重起動を示す用語として扱います。
vSAN環境におけるスプリットブレインの可能性については、以下のVMware Japanのブログでも紹介されているものになります。
VMware Virtual SAN 利用時の vSphere HA 設定に関するベストプラクティス - Japan Cloud Infrastructure Blog - VMware Blogs
本記事では、実際にどういう状況でスプリットブレインが起こるのかを、事象の再現を通じて紹介し、発生の仕組みについて説明します。
スプリットブレインの発生の仕組み
上記のVmware Japanのブログでも示唆されている通り、ハートビートデータストアがない状況でネットワークパーティションに相当する障害が発生した場合、スプリットブレインになる可能性があります。
ネットワークパーティションとは
VMware徹底入門 第4版 では、ネットワークパーティションの発生条件は以下のフローチャートでわかりやすく示されています
Image may be NSFW.
Clik here to view.
つまり、vSphere HAのハートビートが途絶え、かつハートビートデータストアのハートビートファイルがロックされており、かつ隔離アドレスへのPing疎通がある場合にネットワークパーティションとなります。
ネットワークパーティションの場合、障害ホストは自分自身が仮想マシンを稼働させるに足る状況である（データストアへアクセス可能、ネットワークへのアクセスも可能）と判断するため、仮想マシンを停止しません。
一方でパーティションされたホスト以外のホストは、ハートビートファイル経由で、パーティションされたホストの存在が確認できるため、パーティションされたホストで稼働する仮想マシンを起動しようとはしません。
Heartbeat Datastoreがない場合のネットワークパーティション
では、ハートビートデータストアがない状況（アクセスできないのではなく、設定されていない）の場合、上記のフローチャートはどのようになるのでしょうか。
ハートビートデータストアがない状況ではハートビートファイルの確認ができませんので、隔離アドレスへのPingによって、ネットワークパーティションか、隔離状態かが決まります。
この場合、実際にデータストアへのアクセスがない場合でも、隔離アドレスへのPingが通るとネットワークパーティションと判定されるため、仮想マシンを停止ししません。
データストアにアクセス不可であるにもかかわらず仮想マシンが停止しないため、パーティションされたホスト上で仮想マシンが稼働し続けることになります。
一方で、パーティションされたホスト以外のホストからは、ハートビートデータストアがないためパーティションされたホストの状態が確認できません。そのため、仮想マシンを起動しようとします。
健全なホストは当然ながらデータストアへのアクセスがありますので問題なく仮想マシンを起動できます。
その結果、パーティションされた側と健全なホストの両方で同じ仮想マシンが起動することになります。（＝ スプリットブレイン）
パーティションされた側の仮想マシンはDiskへのアクセスがない状態ですので、まともにOSが動作できませんがメモリ上に展開されているプログラムは生きており、仮想マシンとしてもMAC アドレスを持っているため、MACアドレスやIPアドレスの重複が発生する可能性があります。
vSAN環境でスプリットブレインが起こりうる条件
vSAN環境の場合、デフォルト設定のまま使用してしまうと、スプリットブレインが起こりうる条件を満たしている場合があります。
すなわち、
- ハートビートデータストアがない
- データストアにアクセスできない状態でも、隔離アドレスにPingが通る
という状況です。
vSANデータストアはハートビートデータストアとして利用できない制限があるため、外部データストアがなければハートビートデータストアの設定ができませんが
vSAN環境の場合、HCIとして導入されるとvSANデータストア以外に共有の外部ストレージがなく、ハートビートデータストアがない状況もあり得ます。
また、vSAN Clusterの場合、vSphere HAのハートビートはvSAN ネットワークを流れることになりますが、隔離アドレスのデフォルトは管理ネットワークのデフォルトゲートウェイになるため、vSANネットワークのみが切断（＝vSphere HAのハートビート停止、およびvSANデータストアへのアクセス不可）された場合でも隔離アドレスへはPingが通ります。
したがって、vSAN ClusterでvSANデータストア以外の共有ストレージがなく、かつ隔離アドレスをデフォルトから変更していない環境ではスプリットブレインが起こりうる、ということになります。
スプリットブレインをラボで再現する
※絶対に本番環境で実施しないでください。実施による損害についての責任は負いません
再現方法概要
再現方法は簡単です。まずは必須の設定以外はすべてデフォルトでvSAN Clusterを構成します。
その状態でスイッチ側で、vSAN vmkernel portが使用するポートのうち一つを選んでvSAN用VLANの設定を消します。
こうすることで、ESXi側で対象のUplinkポートがLinkup状態のためUplinkポートのFailoverをしません。
かつ、vSAN疎通が失われることでvSphere HAのハートビート疎通と、vSANデータストアへのアクセスが両方失われます。
この状況でも管理ネットワークは影響がありませんので隔離アドレス（デフォルトゲートウェイ）へのPingは通ります。
再現事前準備
- 必須設定以外すべてデフォルトでvSAN Clusterを構成する
- vSAN Cluster内のホストのうち、パーティションされるホストを任意に選ぶ
- DRSを無効にする
- １で選んだホスト上に、検証用のVMのみを配置する（VCSA/PSCなど重要なVMは使用せず、安全な場所に配置しておく）
- 検証用VMを起動する
- 検証用VMがほかのホストでも稼働できることを確認する（vMotionのCompatibilityの検証を利用）
- ハートビートデータストアがないことを確認する
- １で選んだホストのvSAN vmkernel portが使用するポートをスイッチ側で特定する
スプリットブレインを再現
事前準備が完了したら、後はスイッチ側で対象ポートのvSAN VLANを無効にするだけです。
無効にしてほどなくすると検証用VMが１で選んだホスト上で稼働しつつ、ほかのホスト上でも起動されていることが確認できると思います。
Host Clientでログインすると二つのホストで同時に同じVMが起動していることが確認できるはずです。
vCenterはどちらかのインベントリからVMを削除しようとしますが、両方とも稼働状態のためエラーになります。
この状態はVLAN設定を復旧させた後も継続します。
スプリットブレインを終了させるためには手動で仮想マシンを停止するしかありません。
スプリットブレインを防ぐためには
スプリットブレインを防ぐ方法はいくつもあります。
ハートビートデータストアを構築する
ハートビートデータストアがあれば、上記のスプリットブレインは発生しません。
この方法では、パーティションされたホストの存在をほかのホストが認識することができるため、仮想マシンが2重で起動されることはなくオリジナルのホストでのみ稼働し続けます。
ただし、パーティションされたホストはvSANデータストアへのアクセスがありませんので対象の仮想マシンのOSはまともに動作できません。
ハートビートではストアはFC-SAN接続でなくとも、iSCSIでもNFSでも構いませんがせっかくのHCIなのに外部ストレージ必須になってしまうのはちょっと、、、という意見もあるかもしれません。
隔離アドレスを変更する
隔離アドレスをデフォルトである、管理ネットワークのデフォルトゲートウェイから、vSANネットワーク上のInterfaceに設定することでvSANレベルの障害とvSphere HAレベルの障害の粒度がより一致する形になるため、スプリットブレインを防ぐことができます。
この方法では、vSANネットワークの切断がホスト隔離状態になりますので、仮想マシンが停止しHAによりほかのホストで起動することになります。
しかし、この方法ではvSAN VLAN内にPing疎通可能なネットワークデバイスが必要になります。
TORスイッチの持つ仮想インターフェース機能などを利用できれば問題ないです。
vSphere HA Component Protectionを利用する
この方法は使用できません。特にラボで検証などもしていませんが予期せぬ挙動となる可能性がありますので避けてください。
スプリットブレインを防ぐ手段にはなりませんが注意のために記載しました。
このことはVmware docに記載されております。
Other vSphere HA Interoperability Issues
VMCP does not detect or respond to accessibility issues for files located on Virtual Volume datastores. If a virtual machine's configuration and VMDK files are located only on Virtual Volume datastores, they are not protected by VMCP.
Clik here to view.