vSAN -- メンテナンス -- 複数ホストの再起動 / クラスタ全シャットダウン -- 利用不可のデータが発生するリスク

Products

• VMware vSAN

Issue/Introduction

Symptoms:

免責事項：これは英文の記事「A simultaneous reboot of all hosts in the vSAN cluster may result in data unavailability after a single failure (60424)」の日本語訳です。記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。 vSAN クラスタでクラスタレベルのメンテナンスを実行するときに、再起動の後に「アクション不要のメンテナンス モード」機能を使用すると、クラスタの起動中に障害が発生した場合、メンテナンス後にデータが使用できなくなることがあります。 注: メンテナンスモードのオプション「アクション不要」は 6.0 では「データの移行なし」、 6.5 および 6.7 では「データを退避しない」オプションのことを指します。 問題/障害の例： - （複数）ディスク障害 - その他のハードウェアの問題 - ネットワーク障害等の理由により（複数）ホストがクラスタに参加できない 本事象は次の場合は発生しません。 - 「アクション不要」以外のメンテナンスモードの使用 - 「ローリング再起動」を実施することによる vSAN ホストの再起動（vSAN ホストをメンテナンスモードに移行した後） 注： この方法でクラスタ全体をメンテナンスする前に、vCenter Server を含めすべての仮想マシンを正常にパワーオフする必要があります。もし vCenter Server が vSAN Cluster 外で動作していて電源をオフに出来ない場合は vSphere HA を無効化し DRS を手動へ設定してください。

Environment

VMware vSAN 6.7.x
VMware vSAN 6.6.x
VMware vSAN 7.0.x
VMware vSAN 6.0.x
VMware vSAN 6.5.x
VMware vSAN 6.2.x
VMware vSAN 6.x
VMware vSAN 6.1.x
VMware vSAN 8.0.x

Cause

複数の vSAN ホストを "アクション不要" オプションでメンテナンスモードに移行し、すべての vSAN ホストを同時に再起動した結果、同じ vSAN オブジェクト（= 仮想マシンデータ）の複数の vSAN コンポーネントに "Stale" というフラグが立てられる場合があります。
上述の障害や接続の問題が発生した場合、この vSAN オブジェクトは "Stale" から正常な状態に戻ることができず、利用不可になる可能性があります。
その結果、一部の仮想マシンデータが利用不可状態になる可能性があります。（= 例: 仮想ディスクがオンラインにならない。）

Resolution

一般: 発生リスクを下げるために:
vSAN ホストをメンテナンスモードに移行し、すべての仮想マシンをシャットダウンする前に：

- すべての仮想マシンがストレージポリシーに準拠していることを確認し、正常な状態で完全にデータの冗長性が確保されていることをご確認ください。
確認方法については下記マニュアルをご参照ください。（マニュアルのページにてインストールされているビルドを選択してください。）
https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.storage.doc/GUID-133B65D0-CE10-45E7-BFA5-74CAD19E0DFD.html

- お使いの vSAN 環境が正常な状態であり、ハードウェア障害が発生していないことをご確認ください。
この点については、例えば vSAN 健全性チェックを実行する等の方法で確認できます。
vSAN 健全性チェックの実行方法については下記マニュアルをご参照ください。（マニュアルのページにてインストールされているビルドを選択してください）
https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.vsan-monitoring.doc/GUID-9504EECF-5946-49FB-86C6-8A4F977F5FC3.html

問題を回避するために:
vSAN ホスト 6.7 Update 3 （およびそれ以降）の場合のみ:
組み込みツールを使用することができます。
詳細は Using a built-in tool to perform simultaneous reboot of all hosts in the vSAN cluster (70650) の記事をご参照ください。

問題が発生した場合:
vSAN ホストの再起動後に上述の問題が発生した場合:
影響を受けた vSAN オブジェクトは VMware サポートによってリカバリできる場合があります。

将来のvSANリリースでの恒久的なソリューションの実装：
完全なソリューションは VMware vSAN エンジニアリングによって調査されており、将来のリリースで実装される予定です。

Workaround:

vSAN ホストをメンテナンスモードに移行し、再起動を行う前に以下の手順を実施します。

始める前に:
- すべての仮想マシンがストレージポリシーに準拠していることを確認し、正常な状態で完全にデータの冗長性が確保されていることをご確認ください。
確認方法については下記マニュアルをご参照ください。（マニュアルのページにてインストールされているビルドを選択してください。）
https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.storage.doc/GUID-133B65D0-CE10-45E7-BFA5-74CAD19E0DFD.html

- お使いの vSAN 環境が正常な状態であり、ハードウェア障害が発生していないことをご確認ください。
この点については、例えば vSAN 健全性チェックを実行する等の方法で確認できます。
vSAN 健全性チェックの実行方法については下記マニュアルをご参照ください。（マニュアルのページにてインストールされているビルドを選択してください）
https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.vsan-monitoring.doc/GUID-9504EECF-5946-49FB-86C6-8A4F977F5FC3.html

vSAN ホスト 6.7 Update 3 （およびそれ以降）の場合:
上述の問題を回避するために、組み込みツールを使用することができます。
詳細は Using a built-in tool to perform simultaneous reboot of all hosts in the vSAN cluster (70650) の記事をご参照ください。
https://kb.vmware.com/s/article/70650

vSAN ホスト 6.7 Update 3 未満の場合:


パート1:
注:
以下の手順は vSAN クラスタ配下のすべてのホストを同時に再起動する前に実施する必要があります。
これらのステップを完了するために、ESXi ホストをメンテナンスモードに移行する必要はありません。

1. クラスタ内のすべてのホストが NTP 時刻と同期していることを確認します。
Configuring Network Time Protocol (NTP) on an ESXi host using the vSphere Client (57147) を参照してください。

注：この回避策を機能させるには、すべてのホストが NTP 時刻と同期していることがとても重要です。


2.) この記事に添付されているスクリプト（pre_reboot.sh および post_reboot.sh）を vSAN ホストにダウンロードします。
ホスト再起動後にもスクリプトが利用できるよう、スクリプトを vSAN データストア以外の永続ストレージに配置してください。
もし vSAN データストア以外に永続ストレージがない場合は、ホストに再アップロードできるよう、スクリプトに簡単にアクセスできるようにします。
SSH/Putty 経由で以下のコマンドを実行して、スクリプトを実行するために必要な権限を与えてください（実行前に"$"を削除してください）。

$ chmod +x pre_reboot.sh
$ chmod +x post_reboot.sh


3.) "esxcli vsan network list" コマンドの出力を保存し、vSAN ネットワーク構成のバックアップを作成します。
ファイルを vSAN データストア以外の永続ストレージに配置します。
出力を txt ファイルに保存する方法の例：
esxcli vsan network list > vsan_network_list_backup.txt

通常クラスタの出力例:
次の例では、"vmk0" が vSAN によって使用される VmkNic インターフェースであり、そのトラフィックタイプは "vsan" です。
注: 構成によっては、vSAN 用に構成された VmkNic インターフェイスが複数存在する場合があります。

[root@sc-rdops-vm06-dhcp-174-97:~] esxcli vsan network list
Interface
   VmkNic Name: vmk0
   IP Protocol: IP
   Interface UUID: e162115c-a0ed-26ab-fff3-02000ca1a627
   Agent Group Multicast Address: 224.2.3.4
   Agent Group IPv6 Multicast Address: ff19::2:3:4
   Agent Group Multicast Port: 23451
   Master Group Multicast Address: 224.1.2.3
   Master Group IPv6 Multicast Address: ff19::1:2:3
   Master Group Multicast Port: 12345
   Host Unicast Channel Bound Port: 12321
   Multicast TTL: 5
   Traffic Type: vsan


ストレッチクラスタの出力例:
上記出力に加え、監視ホストではないホスト上で下記出力が確認できる場合があります。
監視用ホストとの通信のために構成された専用 VmkNic:
"vmk1" は監視用ホストとの通信のための VmkNic です。 (= トラフィックタイプ: witness)

Interface

VmkNic Name: vmk1
IP Protocol: IP
Interface UUID: b2b43659-9ccf-018e-fcb8-a0369fdefe94
Agent Group Multicast Address: 224.2.3.4
Agent Group IPv6 Multicast Address: ff19::2:3:4
Agent Group Multicast Port: 23451
Master Group Multicast Address: 224.1.2.3
Master Group IPv6 Multicast Address: ff19::1:2:3
Master Group Multicast Port: 12345
Host Unicast Channel Bound Port: 12321
Multicast TTL: 5
Traffic Type: witness


4.) 手順 3 に基づいて:
次の手順を実行して pre_reboot.sh ファイルを変更し、上記の手順 3 で見つかった関連するすべての VmkNic 上で vSAN トラフィックを無効にします。
vmknic ごとに、pre_reboot.sh ファイルに次のコマンドを追加します。
esxcli vsan network ip remove -i <VMkNic Name>

例:
手順 3 で示された構成例では、pre_reboot.sh スクリプトに次のコマンドを追加する必要があります。
esxcli vsan network ip remove -i vmk0
esxcli vsan network ip remove -i vmk1


5.) 手順 3 に基づいて:
次の手順を実行して post_reboot.sh ファイルを変更し、上記の手順 3 で見つかった関連するすべての VmkNic 上で vSAN トラフィックを再度有効にします。
VmkNic ごとに、post_reboot.sh ファイルに次のコマンドを追加します。
esxcli vsan network ip add -i <VMkNic Name> -T=<Traffic Type>

例:
手順 3 で示された構成例では、post_reboot.sh スクリプトに次のコマンドを追加する必要があります。
esxcli vsan network ip add -i vmk0 -T=vsan
esxcli vsan network ip add -i vmk1 -T=witness


6.）関連するクラスターのすべての vSAN ホストで "pre_reboot.sh" スクリプトを正確に同時に実行する CRON ジョブを作成します。
注: すべての vSAN ホストがスクリプトを同時に実行することのできる将来の時間を選択してください。

6.1) 現在の Crontab ファイルのバックアップを作成します:
Crontab ファイル: /var/spool/cron/crontabs/root
上記ファイルを vSAN データストアではない場所にコピーします。
例:
cp /var/spool/cron/crontabs/root /vmfs/volumes/datastore1/root_crontab.BKP

6.2) 現在の Crontab ファイルを編集します:
Crontab ファイル: /var/spool/cron/crontabs/root
以下のコマンドを実行してファイルをオープンします: vi /var/spool/cron/crontabs/root

このファイルの末尾に cron ジョブを追加します。
例:
注: Crontab ファイルで使用する形式は、次のとおりです。
#min hour day mon dow command
"pre_reboot.sh" を 12 月 15 日 20:30 (UTC) にすべてのホスト上で同時に実行する場合は、
各 vSAN ホストに次の行を追加する必要があります。

30   20   15  12  *   /vmfs/volumes/datastore/pre_reboot.sh

6.3) 下記2点のコマンドを実行し、現在 vSAN ホスト上で稼働する CROND デーモンの再起動を行います。（実行前に "$" を削除してください。）
$ kill -HUP $(cat /var/run/crond.pid)
$ /usr/lib/vmware/busybox/bin/busybox crond


7.) 手順2〜6 を次の vSAN ホストで繰り返します。


8.) すべてのホストで CRON ジョブが実行されたら（例: 12月15日 20:30 UTC）、すべてのホスト上で以下のコマンドを実行し、ノードの状態が「マスター」であることを確認します。
esxcli vsan cluster get | grep "Local Node State"


9.) 各 ESXi ホストで次のコマンドを実行し、「アクション不要」モードですべての vSAN ホストをメンテナンスモードに移行することを続行します。（実行前に "$" を削除してください。）
$ esxcli system maintenanceMode set -e true -m noAction


10.) すべての vSAN ホストの再起動を続行します。



パート2:

注:
すべての vSAN ホストが再起動から戻ったら（オンラインに戻ったら）、vSAN クラスタ内のすべてのホストで以下の手順を実行する必要があります。

11.) すべての vSAN ホスト上で以下のコマンドを実行し、ノードの状態が "MASTER" であることを確認します。
esxcli vsan cluster get | grep "Local Node State"


12.) 各 vSAN ホスト上で以下のコマンドを実行し、すべての vSAN ディスクが "true" と表示されることを確認します。
esxcli vsan storage list | grep "In CMMDS"
   In CMMDS: true
   In CMMDS: true
   In CMMDS: true
   In CMMDS: true

"false" のディスクエントリが見つかった場合、そのホストはまだ関連ディスクの初期化を行なっているか、ディスクの問題が起きている可能性があります。
例えば vSAN 健全性チェックを実行することでディスクの問題を確認することができます。
確認方法については下記マニュアルをご参照ください。（マニュアルのページにてインストールされているビルドを選択してください。）
https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.vsan-monitoring.doc/GUID-9504EECF-5946-49FB-86C6-8A4F977F5FC3.html


13.) すべての vSAN ホスト上で以下のコマンドを実行し、メンテナンスモードを終了します。（実行前に "$" を削除してください。）
$ esxcli system maintenanceMode set -e false


14.) すべてのホスト上で以下のコマンドを実行し、メンテナンスモードが解除されていることを確認します。
esxcli vsan cluster get | grep "Maintenance Mode State"
   Maintenance Mode State: OFF

15.) 各 vSAN ホスト上で、再起動前に "post_reboot.sh" に加えられた変更が失われていないこと（= 手順5. で追加した内容が含まれていること）を確認してください。

16.) VmkNik インターフェース上の vSAN トラフィックを再有効化するために、"post_reboot.sh" スクリプトを実行する CRON ジョブを作成します。
注: すべての vSAN ホストがスクリプトを同時に実行することのできる将来の時間を選択してください。

16.1) 現在の Crontab ファイルのバックアップを作成します:
Crontab ファイル: /var/spool/cron/crontabs/root
上記ファイルを vSAN データストアではない場所にコピーします。
例:
cp /var/spool/cron/crontabs/root /vmfs/volumes/datastore1/root_crontab_Post_Reboot.BKP2

16.2) 現在の Crontab ファイルを編集します:
Crontab ファイル: /var/spool/cron/crontabs/root
以下のコマンドを実行してファイルをオープンします: vi /var/spool/cron/crontabs/root
パート1 - 6.2 で追加したエントリを削除します。
このファイルの末尾に新しい cron ジョブを追加します。
例:
注: Crontab ファイルで使用する形式は、次のとおりです。
#min hour day mon dow command
"post_reboot.sh" を 12 月 15 日 21:00 (UTC) にすべてのホスト上で同時に実行する場合は、
各 vSAN ホストに次の行を追加する必要があります。

00   21   15  12  *   /vmfs/volumes/datastore/post_reboot.sh

16.3) 下記2点のコマンドを実行し、現在 vSAN ホスト上で稼働する CROND デーモンの再起動を行います。（実行前に "$" を削除してください。）
$ kill -HUP $(cat /var/run/crond.pid)
$ /usr/lib/vmware/busybox/bin/busybox crond


17.) すべてのホストで CRON ジョブが実行されたら（例: 12月15日 20:30 UTC）、
すべてのオブジェクトが健全であること（= アクセス不可のオブジェクトがないこと）を確認します。
そのためには、下記コマンドの出力が空である必要があります。
cmmds-tool find -f python | grep -C5 CONFIG_STATUS | grep content | grep -v "state....7\|state....15"


18) 現在の Crontab ファイルを編集します:
Crontab ファイル: /var/spool/cron/crontabs/root
以下のコマンドを実行してファイルをオープンします: vi /var/spool/cron/crontabs/root
パート2 - 16.2 で追加したエントリを削除します。


19.) 下記2点のコマンドを実行し、現在 vSAN ホスト上で稼働する CROND デーモンの再起動を行います。（実行前に "$" を削除してください。）
$ kill -HUP $(cat /var/run/crond.pid)
$ /usr/lib/vmware/busybox/bin/busybox crond

Additional Information

Impact/Risks:
上記のように、複数の vSAN ホストを同時に「アクション不要」モードでメンテナンスモードに移行し、続いて複数の vSAN ホストを同時に再起動しようとすると、データが利用できない状態となるリスクが高まります。