VMware Global Community
yomura
Contributor
Contributor
Jump to solution

vSAN クラスタのシャットダウン手順

VMware vSphere 7.0からvSANクラスタのシャットダウン手順が色々やることが増えたようです。

※確認したドキュメント

 vSAN クラスタのシャットダウンと再起動

シャットダウンを自動化したいのですが、以下をvCenter REST APIか、bashで実施することは可能でしょうか。

・[監視] タブをクリックし、 [vSAN] > [オブジェクトの再同期]

・DRSとHAのオフ

※SDKは使わずに実現したいです。

1 Solution

Accepted Solutions
kawaman
Leadership
Leadership
Jump to solution

yomura さん

シャットダウン順序についてですが、vCSA が vSAN クラスタ上で動いている場合は、
その他の VM の停止後に、vCSA もシャットダウンします。

その後に、いずれかの ESXi ホストにて KB 70650 の手順に沿って reboot_helper.py を実行します。

>   (3) クラスタ メンバーの更新を無効→ ( vSAN クラスタのシャットダウンと再起動 ではvCenterで実行するような記載に見えるけど、各ESXiで実施 )

上にについては恐らく実施は不要です。

esxcfg-advcfg -s 1 /VSAN/IgnoreClusterMemberListUpdates

等のコマンドの必要性は確認取れ次第に追記します。

また、Docs 上の記載は誤記ですね。恐らく vCSA から SSH で各ESXi にログインして、と書きたかったか単純に間違えたかと思われます。

纏めると、基本は KB 70650 の手順で

  (1) vCSA以外の仮想マシンをすべて落とす

  (2) vCSA が vSAN クラスタ上にいる場合はシャットダウンする

  (3) reboot_helper.py prepareの実行

  (3) クラスタ メンバーの更新を無効→ ( vSAN クラスタのシャットダウンと再起動 ではvCenterで実行するような記載に見えるけど、各ESXiで実施 )

  (4) vCSAを落とす

  (4) "データ移行なし"でメンテナンスモードにする ( 各ESXiで実施 )

  (5) ESXiを落とす

となります。

>  ■疑問 1.

vCSA のシャットダウン順序については、上記の通り vSAN クラスタ上にいる場合は reboot_helper の前にシャットダウンします。

vSAN クラスタ上になく、いつでもシャットダウンできる場合は vSAN クラスタシャットダウン後でも問題ないです。

>  ■疑問 2.

DRS 無効にするメリットについては、例えば順に VM をシャットダウンしていった際に、

負荷の偏りが検知され今まさに順にシャットダウンしている最中なのに別の残っている vMotion が始まってしまったり、

起動時に順に起動している時にシャットダウン時とは別のホストで起動したり、全 VM 起動中に vMotion が始まったり、

という余計な影響をなくすという事もあると私は考えます。

どこで動いても問題ない場合は気にしなくても良いかと思います。

※ vCSA やその他管理 VM がなるべく若番の ESXi にいて欲しい時など、移動してしまうと困る時は DRS 無効にした方が無難です。

これも DRS グループ、アフィニティルールで任意の VM とホストをマッピングしておくことで気にする事はありません。

私自身は vCSA on vSAN クラスタの構成の場合は、全シャットダウン・全起動の際に vCSA がどこにあるか探しやすいように、

ESXi ホスト 1 ~ 2 に優先的に管理 VM が配置されるように should のルールで管理 VM と ホストをグループで紐づけています。

View solution in original post

15 Replies
gowatana
Leadership
Leadership
Jump to solution

モデレーターより: 日本語での投稿のため、VMware vSAN フォーラムから移動いたしました。

Reply
0 Kudos
yomura
Contributor
Contributor
Jump to solution

コミュニティを使うのが始めてて、よくわかっておらず、ご迷惑をおかけしました。

移動してくださり、ありがとうございます。

Reply
0 Kudos
gowatana
Leadership
Leadership
Jump to solution

こんにちは。

vSAN クラスタのシャットダウンの際に、下記を手動実行することは稀かなと思いました。

・[監視] タブをクリックし、 [vSAN] > [オブジェクトの再同期]

vSAN クラスタを停止する準備としては、自動化の際も、下記の KB にある reboot_helper.py を実行するとよいと思います。

Using a built-in tool to perform simultaneous reboot of all hosts in the vSAN cluster (70650)

https://kb.vmware.com/s/article/70650

※Related Versions に、vSAN 7.0 も含まれています。

つぎに DRS と HA についてですが、

vSAN クラスタ停止の前段での、全 VM のシャットダウンと、

ESXi のメンテナンスモード移行によって、実際には動作しなくなるはずです。

CLI や API から設定変更するのは難しそうということもありますが、

vCenter を停止する場合などは手順が複雑化するので、

あえてオフにしなくてもよいのではないかと考えられるのですが、いかがでしょうか?

ちなみに vSphere 7.0 時点の REST API では、クラスタについては情報取得(GET)のみができそうです。

https://developer.vmware.com/docs/vsphere-automation/latest/vcenter/vcenter/cluster/

以上です。参考になりますでしょうか。

yomura
Contributor
Contributor
Jump to solution

KB70650で記載されている「reboot_helper.py」は、再起動/停止時に単一障害によってデータが利用不可となる以下KB60424の手順簡略化のためのスクリプトと理解しており、KB60424の中にvSANのオブジェクトを再同期するような記載はないので、再同期は必要と考えておりました。

A simultaneous reboot or shutdown of all hosts in the vSAN cluster may result in data unavailability after a single failure (60424)

https://kb.vmware.com/s/article/60424?lang=en_us

そもそもオブジェクトの再同期とは、何なのかと以下を見ても、詳細は理解できておりませんが、

ざっくりvSANストレージ内のデータ不整合をなくすものなのかなぁと考えております。

vSAN クラスタの再同期について

DRSとHAについては、私もgowatana​​さんが記載してくださったとおりの認識をしておりました、

7.0から正式な手順として加わっていたため、実施する方法を考えておりました。

なぜ、DRSとHAのオフが必要かわかりますでしょうか。

KB60424に記載されている以下が理由なのでしょうか。

------------------------------

注: vCenter Serverを含め、この方法でクラスター全体のメンテナンスを行う前に、すべてのVMの電源を適切に切断する必要があります。vCenter ServerがvSANクラスター外で実行されていて電源をオフにできない場合は、vSphere HAを無効にし、vSphere DRSを手動でvSANクラスターに設定してください。

------------------------------

vSANクラスター外のvCenter Serverが生きていた場合、メンテナンスモードにしたタイミングなどでHAやDRSが動作してしまうのかご存知でしょうか。

vSANクラスター上のVMが落ちていれば、vCenter ServerがvSANクラスター内なのかクラスター外なのかは関係ないと考えておりました。

REST APIを調べてくださり、ありがとうございます。

gowatana​さんが記載していただいたとおり、Getしかないんです・・・

PowerCLIで実施する方法は見つけているのですが、HAとDRSが必要という話になるのであれば、RESTかbashでやりたく・・・

Reply
0 Kudos
kawaman
Leadership
Leadership
Jump to solution

yomura さん

※ vSAN 7.0 の公式 Docs の手順について、KB との差異を念のため開発側にも確認をしておりますので情報得られたら別途コメント追記します。

「オブジェクトの再同期」については、シャットダウン前に「再同期する」ではなく、

再同期中のオブジェクトが無いか、[監視] > [オブジェクトの再同期] にて確認をするという意味になります。

何等か作業前に障害が発生しており、冗長性を失ったオブジェクトが再同期中であったり、
RAID1 → RAID5 にストレージポリシーを付け替えてデータが移行中であったり、
間違って「全データ移行」でメンテナンスモードに入れてしまいデータが移動中のホストがあるのに、
その他のホストをシャットダウンしてしまうとデータにアクセスできなくなってしまうのでそれを防ぐためです。

基本は gowatana さんに記載頂いた reboot_helper.py をいずれか1台のホストで実行していただく事で、

次回起動時に、いずれかのホストが起動できなかった場合や隔離されてしまった場合においてもデータ順序のずれなく認識できますので

reboot_helper.py を前提で計画頂く事で問題ありません。

DRS や HA の無効化については以前よりお作法として実施する事が多かった手順です。

背景としては仮想マシンが別のホストに付け変わってしまう事を防いだり(メンテナンスモードに正しく入れている限り起こりませんが)、

HA が有効になっていると ESXi ホスト単体で VM の自動停止・起動を有効にしていても動作しないので自動起動を利用する場合は HA を無効にする必要があります(これもメンテナンスモードに入れている以上元々動作しないのでここで気にする必要はない)。

メンテナンスモードに正しく入っていない状態の ESXi ホストをシャットダウンしてしまった際、
HA が有効だと障害と検知され別のホストに仮想マシンのインベントリが付け変わる可能性があるので、それを防ぐ意味が強いです。


DRS を無効にするとリソースプールスナップショットが取得できてないとリソースプールが復元できない事態にもなるので、

通常は「無効」ではなく「手動」などに設定変更するのが多いかなと思います。

ご参考まで

Reply
0 Kudos
yomura
Contributor
Contributor
Jump to solution

kawamanさん

オブジェクトの再同期は「再同期する」ではなく、「再同期中のオブジェクトを確認する」という行為だったのですね。

また、再同期中になるケースがどんな時か教えてくださり、誠にありがとうございます。

vSAN クラスタを停止する準備としては、reboot_helper.py を実行するで良いと理解しました。

教えていただいたことから考えると、vSANクラスタのシャットダウン手順は

以下(1)~(6)の順に行うと良いのかなと考えましたが、いかがでしょうか。

■vSANクラスタのシャットダウン手順

  (1) vCSA以外の仮想マシンをすべて落とす

  (2) reboot_helper.py prepareの実行

  (3) クラスタ メンバーの更新を無効→ ( vSAN クラスタのシャットダウンと再起動 ではvCenterで実行するような記載に見えるけど、各ESXiで実施 )

  (4) vCSAを落とす

  (5) メンテナンスモードにする ( 各ESXiで実施 )

  (6) ESXiを落とす

  ※上記(5)を必ず実行する&ESXi ホスト単体で VM の自動停止・起動の設定をしていないのであれば、上記 (3)の前にHAのオフは不要

■疑問

 1. 上記(4)のvCSAは上記(1)のタイミングで落としてはいけないかどうかご存知でしょうか。

     上記(3)の情報をvCSAが把握しないといけないなどあれば、上記(4)のタイミングになろうかと思いますが。

 2. DRSについては、vSANクラスタをシャットダウンする直前と起動時で同じESXi上にVMが居てほしい場合は

       DRSを手動にしておいた方が良いが、起動時にどこのESXiで起動しても良いのであればDRSも手動にする

       必要なしと考えておりますが、その他にDRSを手動にしておく必要性をご存知でしょうか。

■疑問2に対する私の考え

    そもそも、ある仮想マシンはどこのESXi上で起動されては困るという話や、仮想マシンAと仮想マシンBは

    同一ホストで動かしたくないという話であれば、アフィニティルールか非アフィニティルールで制御すべき

    ことなのかと考えております。

Reply
0 Kudos
kawaman
Leadership
Leadership
Jump to solution

yomura さん

シャットダウン順序についてですが、vCSA が vSAN クラスタ上で動いている場合は、
その他の VM の停止後に、vCSA もシャットダウンします。

その後に、いずれかの ESXi ホストにて KB 70650 の手順に沿って reboot_helper.py を実行します。

>   (3) クラスタ メンバーの更新を無効→ ( vSAN クラスタのシャットダウンと再起動 ではvCenterで実行するような記載に見えるけど、各ESXiで実施 )

上にについては恐らく実施は不要です。

esxcfg-advcfg -s 1 /VSAN/IgnoreClusterMemberListUpdates

等のコマンドの必要性は確認取れ次第に追記します。

また、Docs 上の記載は誤記ですね。恐らく vCSA から SSH で各ESXi にログインして、と書きたかったか単純に間違えたかと思われます。

纏めると、基本は KB 70650 の手順で

  (1) vCSA以外の仮想マシンをすべて落とす

  (2) vCSA が vSAN クラスタ上にいる場合はシャットダウンする

  (3) reboot_helper.py prepareの実行

  (3) クラスタ メンバーの更新を無効→ ( vSAN クラスタのシャットダウンと再起動 ではvCenterで実行するような記載に見えるけど、各ESXiで実施 )

  (4) vCSAを落とす

  (4) "データ移行なし"でメンテナンスモードにする ( 各ESXiで実施 )

  (5) ESXiを落とす

となります。

>  ■疑問 1.

vCSA のシャットダウン順序については、上記の通り vSAN クラスタ上にいる場合は reboot_helper の前にシャットダウンします。

vSAN クラスタ上になく、いつでもシャットダウンできる場合は vSAN クラスタシャットダウン後でも問題ないです。

>  ■疑問 2.

DRS 無効にするメリットについては、例えば順に VM をシャットダウンしていった際に、

負荷の偏りが検知され今まさに順にシャットダウンしている最中なのに別の残っている vMotion が始まってしまったり、

起動時に順に起動している時にシャットダウン時とは別のホストで起動したり、全 VM 起動中に vMotion が始まったり、

という余計な影響をなくすという事もあると私は考えます。

どこで動いても問題ない場合は気にしなくても良いかと思います。

※ vCSA やその他管理 VM がなるべく若番の ESXi にいて欲しい時など、移動してしまうと困る時は DRS 無効にした方が無難です。

これも DRS グループ、アフィニティルールで任意の VM とホストをマッピングしておくことで気にする事はありません。

私自身は vCSA on vSAN クラスタの構成の場合は、全シャットダウン・全起動の際に vCSA がどこにあるか探しやすいように、

ESXi ホスト 1 ~ 2 に優先的に管理 VM が配置されるように should のルールで管理 VM と ホストをグループで紐づけています。

yomura
Contributor
Contributor
Jump to solution

kawamanさん

回答が遅くなり申し訳ありません。

> 上にについては恐らく実施は不要です。

> esxcfg-advcfg -s 1 /VSAN/IgnoreClusterMemberListUpdates

> 等のコマンドの必要性は確認取れ次第に追記します。

> また、Docs 上の記載は誤記ですね。恐らく vCSA から SSH で各ESXi にログインして、と書きたかったか単純に間違えたかと思われます。

こちらについて、何かわかりましたら、またご連絡いただけると幸いです。

仮想マシンが起動時にどこに移動していても良い場合は、以下手順と理解しました。

  (1) vCSA以外の仮想マシンをすべて落とす

  (2) vCSA が vSAN クラスタ上にいる場合はシャットダウンする

  (3) reboot_helper.py prepareの実行

  (4) "データ移行なし"でメンテナンスモードにする ( 各ESXiで実施 )

  (5) ESXiを落とす

Reply
0 Kudos
yomura
Contributor
Contributor
Jump to solution

立て続けに申し訳ありません。

このコミュニティの運用ルールがわからず、

7番目のkawamanさんの回答に「正解」を押したのですが、質問者が押すものという理解で合っていますでしょうか。

Reply
0 Kudos
gowatana
Leadership
Leadership
Jump to solution

こんにちは。

「正解」は、質問者が押すもので合っています。

下記にフォーラムの利用方法をまとめてありますので、ご参考としていただければと思います。

【最初にお読みください】VMTN Japanese フォーラムの利用方法

以上です。引き続きよろしくお願いいたします。

yomura
Contributor
Contributor
Jump to solution

gowataさん

こんにちは!

大変助かります!!!

ありがとうございます。

Reply
0 Kudos
kawaman
Leadership
Leadership
Jump to solution

シャットダウン手順についてはご認識の通りで問題ありません。

ドキュメントの内容の追加情報については確認中のため、追ってコメント追記したいと思います。

Reply
0 Kudos
kawaman
Leadership
Leadership
Jump to solution

開発側の人の意見も確認できました。

やはり reboot_helper.py を利用する KB 70650 (Link) を正としてくださいとの事でした。

yomura
Contributor
Contributor
Jump to solution

kawamanさん

ご確認くださりありがとうございます。

---------------------------------------------------------------

> 上にについては恐らく実施は不要です。

> esxcfg-advcfg -s 1 /VSAN/IgnoreClusterMemberListUpdates

> 等のコマンドの必要性は確認取れ次第に追記します。

---------------------------------------------------------------

>開発側の人の意見も確認できました。

>やはり reboot_helper.py を利用する KB 70650 (Link) を正としてくださいとの事でした。

ご確認してくださったのは、

「esxcfg-advcfg -s 1 /VSAN/IgnoreClusterMemberListUpdates」が不要かどうかという点で良いでしょうか。

KB 70650の中に

「esxcfg-advcfg -s 1 /VSAN/IgnoreClusterMemberListUpdates」を実行する記載がないので、

実行する必要はなく、以下(1)から順に(5)まで実施するのがvSANクラスタのシャットダウン手順と

理解しました。

  (1) vCSA以外の仮想マシンをすべて落とす

  (2) vCSA が vSAN クラスタ上にいる場合はシャットダウンする

  (3) reboot_helper.py prepareの実行

  (4) "データ移行なし"でメンテナンスモードにする ( 各ESXiで実施 )

  (5) ESXiを落とす

Reply
0 Kudos
kawaman
Leadership
Leadership
Jump to solution

はい、以下のご認識の通りです

「esxcfg-advcfg -s 1 /VSAN/IgnoreClusterMemberListUpdates」を実行する記載がないので、

実行する必要はなく、以下(1)から順に(5)まで実施するのがvSANクラスタのシャットダウン手順と

理解しました。

​よろしくお願い致します。

Reply
0 Kudos