**** 留意事項 *****
こちらのブログの内容はDECN（Dell EMC Community Network）に投稿されたブログの再掲です。
DECNが近い将来に廃止となるためこちらに移行させていただいております。
内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。
本記事は以下の記事の続きです。前提条件や用語の確認などがありますので、前回記事を読んでいない方はご一読ください。
本記事では前回記事で説明した対処法の一つである、
① 仮想マシンをGuestOS側からShutdownし、ESXiの再起動完了後に再度起動させる（ダウンタイム30分～数時間）
について説明します。
実施方法
- 仮想マシンのダウンタイムの調整が完了したら、対象ESXi上の仮想マシンをすべてGuestOS側からShutdownしてください。
- 具体的なShutdown手順や対象の仮想マシンを管理している担当者もしくは構築ベンダやOSベンダにご相談ください。
- 安全にShutdownできないVMがある場合は、強制的に落とすしかありません。その場合はGuestOSのファイルシステムが破損する可能性があります。
- 対象ESXi上のすべての仮想マシンをShutdownし終わったら、ESXiのサポート（VxRailの場合はDell EMC）の指示通りにESXiを再起動します。
- vSANを利用している場合、かならずvSANデータオブジェクトがすべて健全であることを確認してください。（後述）
- 障害の内容や状況に応じて再起動の手順が異なる場合がありますが、たいていの場合はvSANデータオブジェクトの健全性を確認してからNodeの強制リセット（iDRAC or BMC）のパターンで問題ないです。
- ESXiの再起動が完了したらvCenterから正しく認識されている（応答なし状態ではない）ことをvSphere Web Clientから確認し、Shutdownした仮想マシンを起動してください。
- 最後にvSANヘルスチェックとVxRail ManagerのDiagnostic（VxRailの場合）を実施して健全性を確認してください。
- こちらのヘルスチェック手順をご参考にしてください
- エラーや警告があった場合はサポートにご連絡ください。
この方法のメリット・デメリット
メリット
- 比較的簡単
- vCenterやPSCの配置に依存しない
- 対象のESXi上にvCenterやPSCがいた場合、それらはShutdownされるが本手順では関係ない
デメリット
- 最低でも15分くらいはダウンタイムが発生する
- 万が一ESXiが起動してこなかった場合は数十分～数時間のダウンタイムが発生する場合がある。
- とりいそぎ他のESXiで起動する必要があるため
この方法の使いどころ
以下の場合にお勧めです。
- 仮想化環境の操作にあまり慣れてない
- 手順をシンプルにしてオペレーションミスを防ぎたい
- メンテナンスウインドウをとしてダウンタイムを5～8時間程度確保できる
（補足）vSANデータオブジェクトの健全性を確認
vSAN環境では仮想マシンが使用するデータはCluster内の各ESXiが分散して保有することで冗長性を確保しています。
もしvSANデータオブジェクトが健全でない（＝冗長性が確保されていない）状態でESXiを再起動してしまうと、データにアクセスできなくなる仮想マシンが出てくる可能性があります。
なのでESXiの（強制）再起動前に必ずvSANデータオブジェクトの健全性を確認しましょう。
確認方法はvSphere WebClientにログインして以下の画面を開いてください。
右上の再テストボタンも押してください。
赤線を引いたVirtual SAN オブジェクトの健全性がパスしていれば問題ありません。
画面下部ですべてのobjectがhealthyであることを確認してください。
また失敗となっているネットワーク、物理ディスク、クラスタは”応答なし”状態のESXiがある場合は必ずでますのでこの段階では無視してください。
以上です。次回は、
② 仮想マシンをGuestOS側からShutdownし、即座に別のESXiで起動（ダウンタイム数分～数十分）
について説明します。