仮想化エンジニア奮闘記

Citrix や VMware といったサーバー・デスクトップ仮想化の最新技術や設計情報の検証結果を共有します。(本ブログは個人のものであり、所属する会社とは関係ありません。)

vSANやるぞー!(9)-vSAN障害時の挙動(ホスト障害時)①

皆さまお疲れ様です。

今回からホスト障害時の挙動を確認してゆきます。

 

ポータルへ戻る場合はこちら

次:ホスト障害時の挙動②(ESXi4台、FTT=1) 準備中

 

今回もNested ESXi環境を利用し、親のESXi上でNested ESXiをパワーオフして疑似障害を発生させます。

 

 

ESXiホスト障害では、障害発生後すぐにコンポーネントの再同期は行われず、

既定では障害発生後60分後に再同期が行われる仕様となっています。

60分の設定は下記KBに従って変更することが可能です。

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

 

※システムの詳細設定⇒VSAN.ClomRepairDelay より変更可能です。(本環境では5分)

f:id:kenta53682:20171125110549p:plain

 

 

①Step 1 FTT=1の仮想マシンのvmdkが保存されたホスト障害

※FTT=0は実際の環境で構成しないと思うので、割愛します。

 

ESXi 3台(すべて仮想マシン)、ESXi #1上にあるFTT=1の仮想マシンが稼働している状態で、ESXi #3をパワーオフします。(あえてvSANの動きだけを見るため、ESXi #1をパワーオフしてHAはさせません。)

f:id:kenta53682:20171125135943p:plain

 

結論:仮想マシンは稼働し続ける。ホスト障害に伴いDisk Groupが無効となり、ESXiが4台ないため、コンポーネントの再同期は行われない。

 

1) 障害発生前の状態。CentOS7.3はESXi #1(10.17.101.71)上にいます。FTT=1のため、vmdkは ESXi #1(10.17.101.71) と ESXi #3(10.17.101.73) に保管されています。

f:id:kenta53682:20171125141203p:plain

 

2) ここで、ESXi #3の仮想マシンをシャットダウンします。

 

3) ESXi #3が(not responding)状態となり、ディスクグループが見えなくなりました。

f:id:kenta53682:20171125141345p:plain

 

4) 仮想オブジェクトを見ると、「再構築なしで低下した可用性」と表示されています。

f:id:kenta53682:20171125141939p:plain

 

5) CentOS7.3は稼働し続けています。

f:id:kenta53682:20171125142101p:plain

 

6) ESXi 3台なので、コンポーネントの再同期は5分経っても行われません。

f:id:kenta53682:20171125142305p:plain

 

7) 復旧のため、ESXi #3をパワーオンします。

 

8) 仮想オブジェクトは特に問題なく「健全」状態となりました。ESXi #3復旧前後でvmdkに差分がなかったためか、コンポーネントの再同期の画面は6)と同じ状態でした。

f:id:kenta53682:20171125143119p:plain

 

 

それでは、次回はESXi 4台でホスト障害時の挙動を確認します。

 

本日は以上となります。ありがとうございました。

vSANやるぞー!(8)-vSAN障害時の挙動(Capacity Disk障害時)②

皆さまお疲れ様です。

今回はESXi 4台でCapacity Disk障害時の挙動を確認してゆきます。ESXi 4台になっても、基本的にESXi 3台と同じ挙動を取ります。

 

ポータルへ戻る場合はこちら

次:ESXiホスト障害時の挙動①(ESXi3台、FTT=1)

 

 

②Step 2 ESXi 4台構成の時にFTT=1の仮想マシンが属するCapacity Disk障害

ESXi 4台(すべて仮想マシン)、ESXi #1上にあるFTT=1の仮想マシンが稼働している状態で、ESXi #1のCapacity Diskを仮想マシンから削除します。

f:id:kenta53682:20171125105536p:plain

 

結論:ESXi 3台の時と同じく、別Capacity Diskに対してコンポーネントの再同期が行われる。

 

1) 障害発生前の状態。CentOS7.3はESXi #1(10.17.101.71)上にいます。FTT=1のため、vmdkは ESXi #1(C0:T2:L0) と ESXi #3(C0:T2:L0) に保管されています。

f:id:kenta53682:20171119132224p:plain

 

2) ここで、ESXi #1の仮想マシン設定を編集し、C0:T2:L0 の Capacity Disk を削除します。

f:id:kenta53682:20171119132606p:plain

 

3) ディスク削除直後はvSANのステータスが「再構築なしで低下した可用」でしたが、その後コンポーネントの再同期が行われ始め、「低下した可用性」に変化しました。

f:id:kenta53682:20171119132935p:plain

f:id:kenta53682:20171119133239p:plain

 

4) 再同期中です。ESXi #4に再同期が行われています。

f:id:kenta53682:20171119133339p:plain

 

「障害前の状況」と「障害発生し、コンポーネントの再同期が行われた後の状況」を比べてみます。赤字が変わった部分です。ESXi 3台の時もそうでしたが、Witnessもコンポーネント配置場所が変わっています。

f:id:kenta53682:20171119133716p:plain

 

5) CentOS7.3は勿論起動しています。

f:id:kenta53682:20171119133916p:plain

 

6) 再同期完了後、健全状態に戻りました。

f:id:kenta53682:20171119134208p:plain

 

以上の通り、Capacity Disk障害時はESXi 3台 / ESXi 4台で挙動に差は出ませんでした。

次回はESXiホスト障害を取り上げていきます。

 

それでは本日は以上となります。

ありがとうございました。

vSANやるぞー!(7)-vSAN障害時の挙動(Capacity Disk障害時)①

皆さまお疲れ様です。

今回からCapacity Disk障害時の挙動を確認してゆきます。

 

ポータルへ戻る場合はこちら

次:Capacity Disk障害時の挙動②(ESXi4台、FTT=1)

 

今回もNested ESXi環境を利用し、親のESXi上でNested ESXiの仮想ディスクを削除して疑似障害を発生させます。

 

 

①Step 1 FTT=1の仮想マシンが属するCapacity Disk障害

※FTT=0は実際の環境で構成しないと思うので、割愛します。

 

ESXi 3台(すべて仮想マシン)、ESXi #1上にあるFTT=1の仮想マシンが稼働している状態で、ESXi #2のCapacity Diskを仮想マシンから削除します。

f:id:kenta53682:20171121205534p:plain

 

結論:仮想マシンは稼働し続ける。Cache Diskと異なり、Disk Group自体がエラーになるわけではないので、別Capacity Diskに対してコンポーネントの再同期が行われる。

 

 

1) 障害発生前の状態。CentOS7.3はESXi #1(10.17.101.71)上にいます。FTT=1のため、vmdkは ESXi #2(C0:T4:L0) と ESXi #3(C0:T2:L0) に保管されています。

f:id:kenta53682:20171119105102p:plain

 

2) ここで、ESXi #2の仮想マシン設定を編集し、C0:T4:L0 の Capacity Disk を削除します。

f:id:kenta53682:20171119105458p:plain

 

3) vSANのステータスが「再構築なしで低下した可用」というステータスになりました。(コンポーネントの再同期開始前)

f:id:kenta53682:20171119110531p:plain

 

4) Cache Diskと異なり、Disk Group自体は見えています。

f:id:kenta53682:20171119110842p:plain

 

5) 仮想マシンはもちろん稼働しています。

f:id:kenta53682:20171119110608p:plain

 

6) そうこうしている間に、コンポーネントの再同期が行われています。予想では同一ESXi(ESXi #2)の別Capacity Diskに対して優先的に再同期がかけられると思っていましたが、そういうわけではないようです。別ESXi(ESXi#1)のCapacity Diskに対して再同期がかけられています。

f:id:kenta53682:20171119111035p:plain

 

「障害前の状況」と「障害発生し、コンポーネントの再同期が行われた後の状況」を比べてみます。赤字が変わった部分です。

f:id:kenta53682:20171119111851p:plain

 

7) コンポーネントの再同期画面を確認し、ETAが7分であることと、ESXi #1に再同期がかけられていることを確認しました。

f:id:kenta53682:20171119111954p:plain

 

8) 再同期が完了した後の画面です。かつ仮想マシンストレージポリシーのコンプライアンスチェックも行っています。vSANオブジェクトはすべて健全となり、コンプライアンスステータスも準拠となりました。

f:id:kenta53682:20171119112347p:plain

 

Capacity Disk障害時は、Disk Groupが無効になるわけではないので、ESXi 3台の環境でもコンポーネントの再同期が行われます。ですので、復旧についてもゆっくり対応することが可能です。

 

勿論、本環境では仮想マシンは既にストレージポリシーのコンプライアンスに準拠しているため、Capacity Diskが復旧してもコンポーネントの再同期等は行われません。

 

それでは本日は以上となります。

ありがとうございました。

祝!10,000 PV突破しました!

皆さまお疲れ様です。

今回は技術とは全く関係ないこのブログ自身の話を記載します。

 

 

タイトルにもある通り、

 

 

 

本日「仮想化エンジニア奮闘記」の累計PV数が10,000を超えました!ありがとうございます!

 

 

 

そして、今月の月間PV数も3,000を超えそうです。

 

f:id:kenta53682:20171116203949p:plain

 

 

↓の記事を参考にすると、脱ビギナーになりそうです!

PV数でわかるブロガー番付|あなたのブログはどのレベル? | ブログ収益 | ブログ部

 

 

、、、まぁ先月末~今月にかけてvForumがあったので、その影響でVMwareとかのワードに引っ掛かりやすかったのかなと思っていますが。

 

 

このブログを始めたのが2017年4月20日となりますが、早いもので半年以上続けられています。vExpert受賞を目指してスタートしたものの、今ではVMwareはもちろん、Citrixも、その他の製品も、私が気になったことを記事にさせて頂いており、楽しくブログ更新ができています。

 

最初は3日坊主になると思っていたのですが、継続できているのはPV数が増える(=皆さまにブログを見て頂いているという実感が持てる)からです。

 

技術ブログの性質上、答えが見つかればすぐ閉じられてしまい、リピート率が低いと思っていたのですが、Google Analyticsではリピーターが30%あったりと意外と何度か見て下さっている方もいらっしゃるようです。リピートありがとうございます。

 

引き続き、流行に乗り遅れず色々な情報を発信できればと思っています。

皆さま、引き続きよろしくお願い致します。

 

本日は以上となります。

ありがとうございました。

vSANやるぞー!(6)-vSAN障害時の挙動(Cache Disk障害時)③

皆さまお疲れ様です。

 

今回はvSAN Cache Disk障害時のStep3として、ESXi 4台の環境で、FTT=1の時の挙動を確認します。

 

ポータルへ戻る場合はこちら

次:Capacity Disk障害時の挙動①(ESXi 3台、FTT=1)

 

③Step 3 ESXi 4台構成の時にFTT=1の仮想マシンが属するCache Disk障害

ESXi 4台(すべて仮想マシン)、ESXi #1上にあるFTT=1の仮想マシンが稼働している状態で、ESXi #1のCache Diskを仮想マシンから削除します。


ESXi 3台構成の前回に対して、今回はコンポーネントの再同期が行われるはずです。

 

f:id:kenta53682:20171112104212p:plain

 

結論:仮想マシンは稼働し続ける。ESXi #4へコンポーネントの再同期が行われる。

 

1) 障害発生前の状態。CentOS7.3はESXi #1(10.17.101.71)上にいます。FTT=1のため、vmdkは ESXi #1(10.17.101.71) と ESXi #2(10.17.101.72) に保管されています。

f:id:kenta53682:20171112113316p:plain

 

2) ここで、ESXi #1の仮想マシン設定を編集し、Cache Disk を削除します。

f:id:kenta53682:20171112113510p:plain

 

3) 予想と異なり「再構築なしで低下した可用」と表示され、コンポーネントの再同期が行われません、、、と思ったらコンポーネントの再同期が行われ始めました。「低下した可用性」という表示に変わりました。

f:id:kenta53682:20171112114248p:plain

f:id:kenta53682:20171112115915p:plain

 

4) コンポーネント再同期画面です。Hard Disk1(=vmdk)が再同期されています。ETAというのはポリシーに準拠した状態に戻るまでの予想残り時間です

f:id:kenta53682:20171112120037p:plain

 

5) コンポーネントの再同期が完了すると、「コンポーネントの再同期」画面に何も表示がされなくなり、「仮想オブジェクト」画面でCentOS7.3が「健全」状態に戻ります。コンプライアンスに非準拠」は、前回と同じくCentOS7.3で「仮想マシンストレージポリシーのコンプライアンスのチェック」を行えば「準拠」状態となります

f:id:kenta53682:20171112120532p:plain

f:id:kenta53682:20171112120520p:plain

 

6) CentOS7.3はもちろん稼働しています。

f:id:kenta53682:20171112120346p:plain

 

7) ここから復旧手順となります。ESXi #1のvmdkを元に戻します。

f:id:kenta53682:20171112121439p:plain

 

8) ディスクグループは見えないので、ストレージデバイスの再スキャンを行います。スキャン後、Cache Diskが復旧し、ディスクグループが復旧します。

f:id:kenta53682:20171112121716p:plain

f:id:kenta53682:20171112121950p:plain

 

9) vmdkはESXi #4へコピーされており、ポリシーに準拠しているのでESXi #1への再コピーは行われません。

f:id:kenta53682:20171112122216p:plain

f:id:kenta53682:20171112122305p:plain

 

それでは本日は以上となります。

次回はCapacity Diskの障害時の挙動について検証してゆきます。

vSANやるぞー!(5)-vSAN障害時の挙動(Cache Disk障害時)②

皆さまお疲れ様です。

 

今回はvSAN Cache Disk障害時のStep2として、FTT=1の時の挙動を確認します。

ポータルへ戻る場合はこちら

次:Cache Disk障害時の挙動③(ESXi4台、FTT=1)

 

②Step 2 FTT=1の仮想マシンが属するCache Disk障害

ESXi 3台(すべて仮想マシン)、ESXi #1上にあるFTT=1の仮想マシンが稼働している状態で、ESXi #1のCache Diskを仮想マシンから削除します。 

f:id:kenta53682:20171111205737p:plain

 

結論:仮想マシンは稼働し続ける。ESXiが4台ないため、コンポーネントの再同期は行われない。

 

1) 障害発生前の状態。CentOS7.3はESXi #1(10.17.101.71)上にいます。FTT=1のため、vmdkは ESXi #1(10.17.101.71) と ESXi #2(10.17.101.72) に保管されています。

f:id:kenta53682:20171111210315p:plain

 

2) ここで、ESXi #1の仮想マシン設定を編集し、Cache Disk を削除します。

f:id:kenta53682:20171111210510p:plain

 

3) vSANのステータスが「再構築なしで低下した可用」というステータスになりました。今回はESXiが4台ないため、コンポーネントの再同期(4台目のESXiホストにESXi #2のvmdkがコピーされること)が行われません。従って、追加でESXi #2のCache Diskに障害が起きたらCentOS7.3は停止します。ESXi #1のCache Disk復旧まで可用性が低下した状態となります。

f:id:kenta53682:20171111210909p:plain

 

4) 「ディスクの管理」画面を見るとディスクグループは表示されず、有効でないことがわかります。

f:id:kenta53682:20171111213727p:plain

 

5) CentOS7.3は問題なく稼働しています。(他のマシンからCentOS7.3に対してPing疎通も可でした。)

f:id:kenta53682:20171111211212p:plain

 

6) ここからは復旧手順となります。今度はESXi #1のvmdkを元に戻します。

f:id:kenta53682:20171111211621p:plain

 

6) 「ディスクの管理」を見ると、ディスクを追加しただけでは復旧しないようです。

f:id:kenta53682:20171111213727p:plain

 

7) ESXi #1のストレージデバイスを見ても、認識されていなかったので再スキャンを行います。再スキャンしたら5GBのCache Diskが見えてきました。

f:id:kenta53682:20171111214453p:plain

f:id:kenta53682:20171111214816p:plain

 

8) スキャンが終わった後、ディスクグループが見えるようになりました。

f:id:kenta53682:20171111215059p:plain

 

9) コンポーネントの再同期が行われ、CentOS7.3が「健全」ステータスとなりました。その割に「コンプライアンスに非準拠」となっていますね。

f:id:kenta53682:20171111215419p:plain

 

10) CentOS7.3を選択し、「仮想マシンストレージポリシーのコンプライアンスのチェック」を行ってみます。

f:id:kenta53682:20171111215545p:plain

 

11) コンプライアンスが「準拠」状態となりました。これで復旧は終わりです。

f:id:kenta53682:20171111215748p:plain

 

さて、次回はESXi 4台の時のコンポーネントが自動的に再同期する環境で検証を行ってみたいと思います。

 

本日は以上となります。ありがとうございました。

vForum 2017 2日目の資料を読んでみた!

皆さまお疲れ様です。

 

惜しくもvForum 2017 2日目は参加できませんでしたが、本日よりセッション資料が公開されたので資料を読んだ感想をつらつら書いていこうと思います。

 

vForum 1日目の参加したセッションの感想はこちら ↓

vForum 2017 1日目参加! - 仮想化エンジニア奮闘記

 

vForumセッション資料公開サイト(vForum Online)はこちら ↓

vFORUM ONLINE | デジタルトランスフォーメーションの実現に向けた国内最大級のITカンファレンス「vFORUM」をオンラインで先行開催!

※資料閲覧にはvForumへの登録が必要です。

 

 

ちなみに、読んだ資料は当初私が参加予定だったセッションです。

vSphere 6.5 パフォーマンス・ベストプラクティス | vFORUM 2017 TOKYO

Performance Best practice for VMware vSphere 6.5 をベースに要点を記載した資料と見受けられました。

 

vSphere自体のパラメーターの既定値は典型的な環境を想定して最適化されており、サーバーのBIOS設定はvSphereに最適化されているか確認する、という形で結ばれておりました。確かに私自身、HW側の設定はいじることはあっても、vSphere側の設定をいじることはあまりなかったですね。

 

HT・Turbo Boost・Power Management など vSphere を導入するときにはおなじみの設定が出てきておりました。今まで vSphere を入れるときに気を付けていた設定を、vSphere 6.5 でも同じように気を付ける、という感じですね。

 

 

②【お客様事例講演】ゲームサーバ&認証課金システムを刷新!! カプコンのSDDC化への第一章はvSAN導入から! | vFORUM 2017 TOKYO

私が子供の頃、ロックマンバイオハザード鬼武者・大神でお世話になったCAPCOM様の事例公演です 笑

ユーザー事例だったので、本セッションはぜひ会場で聞きたかったです 泣

 

ストレージ専門要員が必要で属人化が起きている、運用ツールが分散されている、などの問題を解消するため、vSAN導入を決めた、というのが大枠の流れと見受けられました。

 

現状はインフラ更改の第一ステップとして、vSAN仮想化基盤の導入を行っているそうで、今後はストレージをvSANへ移行してゆく方針とのことです。(但し、バックアップストレージをどうするかは検討事項)

 

1日目にセッションに参加したときに感じましたが、vSANは構築も楽ですし、運用する側にとっても、基本的に確認するコンソールは vSphere Web Client だけでよいというのは大きなメリットになりますよね。私も vSAN 導入案件をやってみたいと思いました。

 

 

レノボがVX ?? ついに登場 VMware vSANアプライアンス !新ブランドThinkAgileで実現する効率的なFuture-Defined Data Center | vFORUM 2017 TOKYO

Lenovoハードを扱う機会が多いので資料を確認しようと思ったのですが、資料非公開でした。。。残念。。。

 

というわけで、セッションとは全然関係ない展示会場の話を書きます 笑

 

Lenovoハードを入れる際、私はIBMから受け継がれたSystem x や Flex System を入れることが多かったですが、2017年7月頃に ThinkSystem が発表され、今後 System x が ThinkSystem に置き換わっていく、という話を聞きました。Flex System もシャーシは今までと同じですが、中のブレードは ThinkSystem で構成されるとのことです。

 

会場でも ThinkSystem が展示されており、Lenovoとしては System x の新機種開発は行わないということでした。ThinkSystem では おなじみの IMM が XClarity Controller (XCC) に置き換わるそうで、セミナーなどがあれば参加したいなと思っています。

 

なお、③セッションの ThinkAgile というのは、ThinkSystem と並ぶHCI向けサーバーラインとなります。こちらも機会があればセミナー参加し、ブログに取り上げようと思います。

 

本日は以上となります。ありがとうございました。