2017年12月25日月曜日

コレで大丈夫、vSANクラスタの正しいシャットダウン(オレ流の運用にご注意を!!)

このBlogvExpert Adventarに参加しています。


〜“ほんのちょっと”な、vSANのお作法を正しく知って欲しい〜

vSANは筐体レベルで停止しても大丈夫な可用性を有していますが、「ビルの法定停電などで完全停止をしなければいけない」という環境で運用しているお客様も少なくありません。

ですが、正しくない手順でvSANシャットダウンすると、最悪データが欠落するリスクもわずかながらあるので、この手順をきちんと知ってほしい!!そう強く願います。



〜〜〜〜〜〜〜いままでは、どうしてた??〜〜〜〜〜〜〜

(1)メンテナンスモードへ移行
(2)ESXiをシャットダウン
(3)ストレージをシャットダウン

ですが、、これと同じ手順でvSANクラスタを落とすのはおすすめしません。



〜〜〜〜〜〜〜では、、手順の説明に入ります〜〜〜〜〜〜〜

まず、自分のvCenterServerがどこにいるか?でお作法が異なります。

(コース1)vCenterServervSANクラスタとは別のESXi上にて動作している

(コース2)vCenterServervSANクラスタの上で動作している


では、2つのコースごとに、流れを追っていきます。



(コース1)vCenterServer独立のあなた


(1) vSANコンポーネントの再同期(Resync)が完了していることを確認

ちなみに、最新のvSANではESXCLIで色々と便利な確認が拡張されています。(今回は割愛)

(2) vSANクラスタ上の 仮想マシンを “すべて”停止

これがないと、メンテナンスモードに移行できませんので、かならず落としてください。

(3) メンテナンスモードへの移行


ここで、WebClientによる作業が必要です。
C#Clientでは操作できないオプション項目があります)

ここでは、一番下の「データを退避しない」を選んでから メンテナンスモードに移行します。


※このオプションは C#版では選択ができません。強行して操作すると、デフォルトの「他のホストからデータのアクセシビリティを確保」が選ばれてしまい、なかなかシャットダウンができない!や、エラーでメンテナンスモードに移行できない!!などの地獄にハマってしまいます・・・


◯メンテナンスモードの移行時に選べる、vSANオプションは3択
  a)すべてのデータを他のホストに退避 
  b)他のホストからデータのアクセシビリティを確保
  c)データを退避しない

(4)ESXiのシャットダウン

あとは、いつも通りです。
簡単ですね〜

  

(コース2)vCenterServervSANクラスタ上にある場合


基本的な流れはすべて同じですが、vCenterServerのいるESXiだけ工夫が必要です。

(1)vSANコンポーネントの再同期(Resync)が完了していることを確認


 (2)vSANクラスタ上の 仮想マシンを “すべて”停止

vCenterServer以外の仮想マシンはすべて停止してください。
vCenterServerのいるESXiはオペレーションが後回しになります。

(3)メンテナンスモードへの移行vCenterServerのいないESXi

もちろん、WebClientにて「データを退避しない」オプションを選択して、メンテナンスモードに移行します。

(4)ESXiのシャットダウンvCenterServerのいないESXi

vCenterServerがいないESXiは、いつもどおりの操作で大丈夫です。

(5)vCenterServerの仮想マシンを停止

vCenterServerをシャットダウンします。

(6)メンテナンスモードへの移行vCenterServerのいるESXi

   vCenterServerがいないのに、どうやるのでしょうか???
   はい、ESXCLIで操作します。(大文字小文字は厳格に)

メンテナンスモードへの移行
% esxcli system maintenanceMode set -e true -m noAction

上記コマンドを実行しても何も返ってこないので、以下の確認コマンドで結果を確認
% esxcli system maintenanceMode get
Enabled

Enabled=メンテナスモードが実行中

(7)ESXiのシャットダウンvCenterServerのいるESXi

シャットダウンもコマンドで
% esxcli system shutdown poweroff -r “COMMENT”

(ちなみに、メンテナンスモード移行が終わってないと、以下のようなメッセージが出ますので、終わるまで待ちましょう。)
System is not in maintenance mode. Cannot perform requested operation.




立ち上げるときはvCenterServerのいるESXiから起動してください。

(コース1)vCenterServer独立のあなたに送る、復活の呪文


(1) ESXiサーバの電源ON
(2) メンテナンスモード解除
(3) vSAN健全性チェックでクラスタ復活したことを確認
(4) 残りの仮想マシンを起動

(コース2)vCenterServervSANクラスタ上にある場合の、復活の呪文


(1) まず、vCenterServerのいるESXiを電源ON
(2) ESXiにてコマンドでメンテナンスモードを解除
% esxcli system maintenanceMode set -e false
% esxcli system maintenanceMode get
Disabled
(3) vCenterServer仮想マシンを起動
(4) その他ESXiも電源ON
(5) vCenterServerからメンテナンスモードを解除
(6) vSAN健全性チェックでクラスタ復活したことを確認
(7) 残りの仮想マシンを起動


お作法さえ覚えてしまえば、すごく簡単なので しっかりと抑えておきましょう!!



2017年12月21日木曜日

vSANの障害試験、小ネタほか

このBlogvExpert Adventarに参加しています。


前回のところで割愛した小ネタを幾つか


◯SSDの障害試験にご注意


試験でキャッシュデバイスを抜いた場合、そのまま戻すとエラーとなるので、必ずパーティション情報を消してから戻してください。

partedUtilコマンドの詳しい使い方はこちら

キャッシュのSSDにかかれているメタデータをもとに、その配下にDiskGroupメンバーの情報を理解しようとします。



◯メンテナンスモードでの3つのモード


次回のBlogで非常に重要な要素となります。
恒久的にクラスタからESXを外す場合などには、この設定を調節してください。





◯Witnessって何?


Witness(監視)は その他のクラスタリング技術と同じ、多数決を決める役目というレベルです。



◯vSANはSPBMが重要


ポリシードリブンのインフラ(SDDC)を実現する入り口として、HCI powered by vSAN
ということなんです。





◯今後のvSANどうなる?


バックアップ機能を強化するという予告がありました。
2017ラスベガスで最も興奮した瞬間です。
#まだTechPreviewなので、どのように提供されるかは不透明ですが・・・

管理サーバ不要(Native)で動作するので、
vSAN領域に放り込んでくれれば、VMイメージの世代管理が出来るのはとても良いことですね。




詳細はこちらに。。。
http://www.yellow-bricks.com/2017/08/30/vmworld-sto1770bu-tech-preview-integrated-data-protection-vsan/


このセッションでは遠隔転送のデモンストレーションは時間切れで見せてもらえませんでした。

言いたいことが山盛りなのですが、お時間が来たようなので・・・




ではまた!!

2017年12月11日月曜日

vSANの耐障害性とは?

〜このBlogはvExpert Adventarに参加しています〜
https://adventar.org/calendars/2248


本当によく貰う相談なので、オープンにしちゃいます。vSANの色々…

以前にちょっとだけお話した、耐障害性について

「どうして大丈夫なのか?」を ベーシックなMirroring構成で説明したいと思います。


==おさらい==

http://vm-fun.blogspot.jp/2016/07/vsan.html

【1】RAID組まないとは?
 ・Raidを組む必要がない
 ・ESXサーバ内のHDDどうしでミラーリングではない(Raidではない)
 ・仮想マシンの可用性に合わせて、必要なデータは自動で他のESXサーバへ多重コピー

【2】キャッシュのSSDが1本では不安なので、Raid1で構成できる?
 ・1本で大丈夫、RAID不要!!
 ・キャッシュに書き込まれた内容は、他のESXサーバにもミラーリングしてくれる



==どうしてか?==


それはvSANのデータ保護の考え方が 従来のストレージとは全く異なるからです。
まずRAIDを必要としません。そしてパススルー構成が推奨されています。


「RAIDが無いのに、どうして大丈夫なの??」と非常に沢山の質問をいただくのですが、
それはデータを筐体(ESXサーバ)間で複数持ち合うことをしているからです。
※VMさんの資料から拝借します

2年前と本質は変わっていません。http://vm-fun.blogspot.jp/2015/12/vsan.html



で、「どのデータをどれだけ多重化するの?」という可用性ポリシーを決めているのが「FTT」といいます。

平たく言えば、何台ESXが倒れてもデータアクセスを継続したいですか?ということです。


必要なESXはの台数は「2N+1」で計算ができます。
  1台倒れてもOK・・・2+1=3台
  2台倒れてもOK・・・4+1=5台

この多重化は、ESXという単位ではなく「VMDKの単位」で指定ができます。



FTTに次いで、重要なのが、このデータ配置の原則です。
この挙動を理解すると「だからVSANはこうなるのね!」とよーくわかります。



同じESXには、多重化したデータを置かない。ということ
異なるESXに必ず配置されるのです。

ポリシで定義された状態を維持するために、自律的にデータを多重化してくれるので、運用が簡単なのです。
SPBM(Storage Policy-based Management)の本質はここにあります。



では、実際に障害を起こした結果をまとめます。
(具体的な画面は、DELLさんに寄稿した内容を参照いただければと思います)



==キャパシティ(HDD)を抜くと?==


3台構成と4台構成での比較を見ながら進めてみます。





FTT=1を定義しているので、I/Oアクセスは継続されます。




ポリシーを遵守しようと、自律的に HotSpareのような動作が始まります。


新しいディスクに交換しても、既にポリシ順守の状態のため何も起きません。





==キャッシュ(SSD)を抜いたら?==



3台構成と4台構成での比較を見ながら進めてみます。





FTT=1を定義しているので、I/Oアクセスは継続されます。

しかし、該当のDiskGroupにあるキャパシティ(HDD)へのアクセスがブロックされてしまいました。




3台構成(1DiskGroup)は何もできませんが、4台構成はコピーが始まります。
データ配置の原則に従って、コピーする先が無いという状態のためです。

そして、ディスクを交換すると
3台構成ではコピー先ができたので、そこからコピーが発生しますが
4台構成ではすでにコピーが終わっているので動きはありません。




==ESX停止の場合は?==


強制的に電源OFFにしてみます。




お約束ですが、HAが発動します。
HAの影響を受けない、他のESX上の仮想マシンは I/Oが継続されています。


ESXホストの場合、デフォルトでは60分待機状態となります。
一時的な停止(例:メンテナンス)
状態に入ったという判定が入ります。




やはり、4台構成は コピー先があるので、60分後に同期が走ります。
3台構成は何も動きがありません。




3台構成は復帰後に差分同期されますが、
4台構成は既にコピー完了のため、動きは特にありません。




==どういう同期をしているのか?==


必要なデータ(ポリシーで定義されたもの)だけをコピーしています。
なので、RAID再構築のような全体の負荷がかかるような処理がないのが特徴です。




「データ配置の原則」を冒頭にお話しましたが、
3台構成と4台構成でどうして挙動が違うのか?をまとめると下記のようになります。




このように、ポリシーを遵守しようと自律的に動いてくれるのです。
だから、”SPBM”ということなんです。 これがVSANの素晴らしいポイント。



==挙動の違い、まとめ==

この原則に従って、DiskGroup数やホスト数を考えてみてください。





次回、補足事項を書きます。
(すみません。。鉄板構成の話はまた今度。。。)