本日は以前ご紹介した物理サーバを安全に停止するときのメンテナンスモードの続きを投稿していきます。
- メンテナンスモードの3種類の呼び方がが変わりました
- メンテナンスモードが実行できないとき、どうする？
まずひとつめ。
変わった、というよりはわかりやすくなったといった方が良いかもしれません。
メンテナンスモードのvSAN データ移行オプションとして3種類あります。
- すべてのデータを他のホストに退避する(全データの移行)
- 他のホストからデータにアクセスできることを確認する(=アクセシビリティの確保)
- データを退避しない
メンテナンスモードする対象のホストが何をするのか、vSAN として内部に保管しているデータをどうするのか、を選択します。
そして各オプションの下にこのオプションを選択したことによってどのような影響があるか注釈が出るようになっています。
操作を実行するために必要な容量を使用できるかどうか。
移動するデータのサイズ。
準拠しなくなるオブジェクトの数。
アクセスできなくなるオブジェクトの数。
ふたつめ。メンテナンスモードに入れない！とき、どうする？です。
もちろん、その原因を探します。
3種類ほど経験したので
1つ目は、他ホストもメンテナンスモードに移行中だったとき。
他のホストからデータにアクセスできることを確認する(=アクセシビリティの確保)
特にクラスタに参加している台数が少ない構成の場合、うっかりで起こります。
3ホスト構成で、1ホストメンテナンスモードに移行済み、忘れていてもう1ホストしてしまうことがありました。
本番環境ではなかなかないと思いますが、同時操作には注意です。
2つ目は、クラスタをシャットダウンしようと全台メンテナンスモードにしたいとき。
メンテナンスモードのオプションを指定し忘れて、デフォルト(初期値)の他のホストからデータにアクセスできることを確認する(=アクセシビリティの確保)のまま進んでしまうと他のホストからアクセスできない台数になった時点でメンテナンスモードの移行に失敗します。
これ！よくお客様から聞かれます。
コマンドラインでのメンテナンスモード移行も、vSAN オプションを忘れずに！
3つ目は、ホストの台数がコンポーネントが配置されている台数が一致していて、全データの移行をしようとしたとき。
ミラーリングのFTT1であれば3ホスト、イレイジャーコーディングのRAID5のFTT1であれば4ホスト、ミラーリングのFTT2であれば5ホストといったように必要な最小台数が異なります。
PoCでさまざまな仮想マシンのストレージポリシーを作成した時、イレイジャーコーディングとミラーリングが混在しているとうっかり台数を忘れてしまうことがありました。
どんなときもメンテナンスモードがなぜ失敗したのかは慌てずタスク/イベントでご確認ください！
一般的なエラーとなっていても、失敗した原因については中に書いてあります。
