vSAN

VSAN Cormac Blog 〜 管理クラスタを含んだVSANデータストアの復旧シナリオ〜

〜管理クラスタを含んだVSANデータストアの復旧シナリオ〜
こちらのポストでは、管理クラスタが含まれているVSANデータストアに障害が発生した際の復旧方法についてご紹介させて頂きます。
我々のLabにあるサーバの一台で興味深い事象が発生しました。4ノードのクラスタの1台のホストで、そのホスト上のストレージがVSANデータストアとして利用出来なくなるというトラブルです。VSANには自動復旧させる機能が実装されているので、障害が発生した際には可能な限り多くのVMを再保護しようとします。しかしVSANデータストアの容量が限界になった時に発報されるWarningを無視したことによって、VSANデータストアを失う羽目になりました。このVSAN環境は私たちの管理クラスタとしての機能も含まれていて、vCenter Server、DNS/AD及び、VDPやView等の他のアプリケーションも配置されています。
こちらがその際に出力されたWarningです。
注:ホスト障害を対処する為に十分な容量がないことを示しています – 全てのVMを再保護する為には、120%の利用可能なストレージ容量が必要。(今後、この警告を無視してはいけない)
limits-failure
掻い摘んでお話しますと、容量を増やして当初のVSANの問題は解消され、次に仮想マシンを起動させる必要がありました。vCenterサーバやDNS/ADサーバなどの仮想マシンのvmware.logを調査することによって、仮想ディスクが容量不足になっていることを確認できました。もちろん、その仮想マシンがディスクを使い果たした時にはサスペンドされますが、これはデータストア上の仮想マシンの通常の動きであり、VSANに限ったお話ではありません。

その時点でvCenterにアクセスすることが出来ませんでしたので、このメッセージに対してどのように対応すればいいのかを検討し、CLIコマンドである、”vim-cmd”コマンドを実行してみることにしました。AD/DNSサーバ(dc01.rainpole.com)から始めてみます。最初にVM idが必要になりますので、ESXi上に配置されているVM idを以下のコマンドで確認します。

次に、以下のコマンドでVMにメッセージが表示されていないか確認します。

次のコマンドで、出力されているメッセージを対処します。注:メッセージ id 6034178に対して、”0″(0. button.retry (Retry) [default])を実行。問題なく処理できたことが確認出来ます。

引続き、メッセージが残されているか確認してみます。もしメッセージが表示された場合は新しいメッセージidを使い、もう一度同じコマンドを実行する必要があります。注:必要に応じて何回か繰り返します

全てのメッセージに対処し、最終的にはメッセージが出力されなくなります(”No message.”)。次は同様の方法でvCenterサーバを起動させます。vCenterサーバが起動したら各種クライアントから接続し、未解決の問題に対応します。

原文:Recovering from a full VSAN datastore scenario
VMware Storage and Availability Business Unitの シニアスタッフエンジニアCormac Horganの個人ブログを翻訳したものになります。VSANの詳細に関しては弊社マニュアル 、KBをご確認ください。また本記事は VSAN 6.2ベースに記載しております。予めご了承ください