今月は1日1回くらい、さまざまな ネステッド vSAN 6.7 U1 を構成してみようと思います。
昨日はこちら。
ネステッド vSAN 6.7 U1 を楽しむ。2018-12-01
2日目は、vSAN の最小構成とされる 3ノード クラスタを構成します。
- ESXi は 3ノード
- ハイブリッド（SSD + HDD）ディスクグループ
- ディスクグループは各ノードで 1つずつ
- 重複排除・圧縮 は無効のまま
- フォールト ドメインはデフォルト構成のまま
- vCenter は vSAN 外部に配置
vSAN ではデフォルト（の仮想マシンストレージポリシー）だと、
データは、3ノード（コンポーネント x 2 と 監視 x 1）に分散配置されます。
下記は昨日の 4ノード vSAN ですが、VM「vm01」の 3オブジェクト
VM Home（.vmxファイルなど）、Hard Disk 1（VMDK ファイル）、SWAP オブジェクト
がそれぞれ 3ノードに分散されている様子がわかります。
3ノード vSAN だと、1ノードで障害が発生した場合でも
データの可用性がある（データを読み書きできる）のですが、
ノード障害中はリビルドができないため、その間に 2台目のノード障害があると
悲しいことになってしまいます。
4ノード vSAN の、1ノード障害。（昨日の vSAN にて）
4ノード以上の vSAN であれば、1ノードの障害が発生した場合でも
デフォルトで 60分後にデータがリビルドされます。
ためしに、1ノードで疑似障害を発生させてみます。
ネストの外側から、ESXi VM をパワーオフします。
このときのポイントは下記です。
- VM のデータが配置されているノードを選択する。
- VM が起動しているノードは選択しない。
（VM が稼働継続する様子が見られるように）
少し待って vSphere Client を更新すると、1ノード障害の様子が確認できます。
今回は「192.168.1.32」という ESXi を強制停止したので、
そのノード（ホスト）に配置されているデータに問題が発生します。
VM が起動しているノードを停止したわけではないので
「vm01」は、そのまま稼働継続できています。
監視 → vSAN → 健全性
でもアラートが表示されます。
障害直後は「可用性が低下（再構築なし）- 遅延タイマー」に計上されています。
これは、過剰なデータ移動を避けるように「オブジェクト修復タイマー」で指定されている
時間「60分間」は、リビルドを待機するためです。
これは、「オブジェクトの再同期」画面でもわかります。
VM が １つだけなのに「～ 遅延タイマー」が 3件 となっているのは、
この VM が 3つの vSAN オブジェクトを持っているためです。
60分以上経過すると自動的に正常なノードでリビルドされ、データが健全な状態になります。
「vm01」のオブジェクトがすべて健全になりました。
障害ノード「192.168.1.32」に配置されていたコンポーネントが、
正常ノード「192.168.1.31」にリビルドされています。
3ノード vSAN の、1ノード障害。
一方、3ノード vSAN でノード障害が発生した場合には、
障害ノードを復旧するまでリビルドができません。
3ノード vSAN を構築しました。
そして疑似障害を発生させるため、ネストの外側から ESXi VM をパワーオフします。
3ノード vSAN でも、4ノードの場合と同様に VM は稼働継続したまま、
障害ノードのデータにはアクセスができなくなります。
そしてリビルドの遅延タイマーを待ちます。
しかし、60分以上経過しても、正常ノードの台数が不足したままなので
リビルドはされません。
「可用性が低下（再構築なし）- 遅延タイマー」はゼロ件になり、
「可用性が低下（再構築なし）」が 3件になります。
障害ノードを何とか復旧するまで、不安な状態となります。
当然ながら、障害ノードを復旧すると自動的にデータは健全な状態になります。
そのため、vSAN は 4ノード以上にしておくと、
1ノード障害時にも落ち着いて復旧作業をすることができます。
つづく。