仮想化エンジニア奮闘記

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

祝!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=0) 準備中

 

③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向けサーバーラインとなります。こちらも機会があればセミナー参加し、ブログに取り上げようと思います。

 

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

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

皆さまお疲れ様です。

 

今回はvSAN障害時の挙動について記事にします。ストレージではRAIDで可用性を提供しますが、vSANではどうなるのか?今回はCache Diskに焦点を当てて障害時の挙動を見ていきましょう。

 

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

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

 

【結論】Cache Diskが属するDisk Groupがエラーとなり、エラーとなったDisk Group内のキャパシティデータは無効となる。FTT=1以上であれば、Cache Disk障害時も仮想マシンは起動し続ける。FTT=0で、障害が発生したCache Diskが属するDisk Group内のCapacity Diskに保存された仮想マシンは停止する。

 

とまぁ結論は ↑ の通りなのですが、実際にHOLで挙動を確かめてみようと思います。

 

、、、と思ったのですが、HOLはNested ESXiで構成されており、疑似障害スクリプト(vsanDiskFaultInjection.pyc)が使えず、かつ親のESXiをいじることができないため障害を起こせませんでした。ですので結局家のNested ESXi環境を使用しました。

 

【自宅の環境について】(Nested ESXi 環境です)

f:id:kenta53682:20171111205334p:plain

 

なお、vSANのディスク障害状態は、下記2パターンがあります。今回は親のESXiでNested ESXiの仮想ディスクを削除して疑似障害(ディスクが抜けた障害)を発生させるため、障害表示は「Absent」となる想定です。

f:id:kenta53682:20171105203358p:plain

 

 

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

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

f:id:kenta53682:20171111205455p:plain

 

予想:Cache Disk が Absent 状態となり、仮想マシンが停止する。

 

1) 障害発生前の状態。CentOS7.3はESXi #1(10.17.101.71)上にいます。

f:id:kenta53682:20171105194544p:plain

 

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

f:id:kenta53682:20171105195022p:plain

 

3) vSANのステータスが下記に変わりました。ディスクの管理画面からESXi #1のCache Diskがエラーになり、ディスクグループが見えない状態となりました。

f:id:kenta53682:20171105200939p:plain

 

4) 仮想マシンコンポーネントも「なし=Absent」状態になっています。(日本語表示だと分かりづらいので英語表示も合わせて掲載します。)

【日本語表示】

f:id:kenta53682:20171105203844p:plain

【英語表示】

f:id:kenta53682:20171105204321p:plain

 

5) データストア画面を見ても、「リストは空」状態となります。

f:id:kenta53682:20171105201533p:plain

 

6) 仮想マシンはパワーオン状態に見えるものの、コンソールを接続しても接続できません。(勿論Pingも飛びません。)

f:id:kenta53682:20171105201658p:plain

 

というわけで、Step 1では予想通り、仮想マシンが停止しました。

 

 

長くなったので、一旦ここで切らせて頂きます。

次はStep2として、FTT=1の障害時挙動を書きたいと思います。

 

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

vForum 2017 1日目参加!

皆さまお疲れ様です!

 vForum 2017 1日目に参加したので、その感想を簡単に書いてゆきます。

 

業務の都合上、お昼頃からセッションに参加しましたが、キーワードとしてはやはりHCIが盛り上がっていたと感じました。

 

参加したセッションは下記の5つでした。

(セッションタイトルをクリックするとvForumのサイトに飛びます。)

 

HCI Powered by VMware vSAN、やっぱり気になる運用管理 | vFORUM 2017 TOKYO

はてなブログで 「"HCI" はじめました。」というタイトルで投稿をされているVMwareの中の人が登壇されるということで参加しました。

正直 vSAN を知っている私としては今更な情報でしたが、「HCI とか vSAN とか最近よく聞くけど、実際どんなもの?運用はどうなるの?」を知りたい方にはつかみのセッションとしてよいと思います。特に「とはいっても、変わること」(アジェンダの一項目)では従来の共有ストレージモデルとvSANでどのような変化が出るのか、はわかりやすいと感じました。

 

運用管理というセッション名の通り、vCenter上でのvSANのパフォーマンスの見かた、vROpsでのパフォーマンスの可視化、VUMによるアップデート方法などが主なアジェンダとなっていました。

 

 

【お客様事例講演】人気雑誌の編集者も利用中!集英社の全社VDI化による問題解決-その理想と現実 | vFORUM 2017 TOKYO

今回参加した中で2番目に面白かったセッションです。

やはりユーザーの実事例を聞くのは面白いですね。理想を描いてプロジェクトをスタートしても、実際VDIのプロジェクトは色々問題が起きます。その問題を「現実」として描いていました。メモリ・ディスクサイズが足りなかったり、AdobePhotoshop が起動しなかったり(起動時に裏でインターネットに接続するためhostsで解決)、VDI に接続できなかったり(原因不明)と色々問題が起きたようです 笑 VDIあるあるですね。

 

VMwareの三木会長とお会いする機会があり、VMのライセンス代をなんとかしましょう!と言ってくれたから(C社でなく)、VMwareにした!」と集英社の情シス部長代理様が仰っておりました。会場では笑いが起きましたが、私はVDI製品については、C社Loverなので苦笑でした 笑

 

 

ザ・ノンフィクション『ユーザ事例から見るvSANのリアル』 | vFORUM 2017 TOKYO

「vSANって実際ユーザー受け はどうなの?」というユーザーの生の声を「フィクションなし」でVMwareの方にお話頂きました。

vSANで気を付けることとしていくつかユーザー側からあがってきたものも紹介されていました。

UPSがvSAN対応していなかった → 今は対応している

ESXiのログ設定は忘れずした → スクラッチの作成 or syslog設定を行う

などなど

 

ユーザーの話では、「決して運用が楽になるわけではない」が「色々自分(ユーザー側)でできるようになるし、費用も抑えられる」という内容で結ばれておりました。

 

まぁ穿った見方をすると「VMwareに都合のいいようにユーザーの意見をまとめたのだろ!」とも考えられますが、個人的にvSANは本当に楽なのでユーザーの声はリアルに感じました。(逆にSIer側は今後イニシャルコストがどんどん安くさせられないか心配になりましたが 笑)

 

 

Deep Dive into “VMware Cloud on AWS” | vFORUM 2017 TOKYO

今回参加した中で1番目に面白かったセッションです。

技術屋として、新サービスにはわくわくしちゃいますね 笑

しかも オンプレ仮想化の雄 VMware × クラウドの雄 AWS ですよ!わくわくせずにはいられません!!

 

まだリージョンとしてはオレゴンだけでの提供に留まっていますが、今後日本リージョンでの提供が始まったら、DCや仮想基盤統合案件でVMware Cloud on AWSが提案の中の1案に入ってきそうだと感じました。現状では機能面で足りない部分もありますが、VMwareも機能追加をどんどん行ってゆくようなので期待ですね。

 

今後、VMエンジニアとしてAWSも勉強していかなきゃなと感じ、今勉強中です。

実際にAWS契約するのはお金がすごくかかりそうなのでVMware側はHOL頼り、AWSはQWIKLABS頼りですね 笑

 

 

本格的なネットワーク仮想化のためのベストプラクティス | vFORUM 2017 TOKYO

セッションには参加したものの、NSXの知識が浅いためあまりよくわからなかったです。NSXの勉強します。。。感想が適当ですみません。

 

 

本日は以上となります。

 

vForum 2017 2日目は業務都合で参加できない可能性が高いですが、もし都合がつけばまた今日と同じように感想を書こうと思います。

vSphere Data Protection デプロイ時の証明書エラー

皆さまお疲れ様です。

 

直近で vSphere Data Protection 6.1.5 の検証をする機会があったのですが、vSphere Web Client でデプロイをするとなぜか下記のエラーが発生し、デプロイが進まない事象に遭遇しました。

「OVFパッケージは無効な証明書で署名されています」

f:id:kenta53682:20171025105706p:plain

 

 

証明書を見てみると、、、なんと有効期限が2017年9月8日ではありませんか!

というわけで、証明書の有効期限切れが原因でデプロイに失敗します。

f:id:kenta53682:20171025105746p:plain

 

 

デプロイを行うためには、OVFツールでOVFの再構成を行う必要があります。

https://my.vmware.com/jp/web/vmware/details?productId=352&downloadGroup=OVFTOOL350

 

Windows端末にインストールし、以下のコマンドを実行してOVFの再構成を行います。インストールしただけでは、OVFツールのパス設定がされていないため、フルパスでコマンドを実行しています。

なお、この時デスティネーションのovaファイル名はVDPに設定しようと考えている仮想マシン名に合わせるようにして下さい

 

# OVFの再構成
"C:\Program Files\VMware\VMware OVF Tool\ovftool.exe" -acceptAllEulas [ソースのovaファイル名] [デスティネーションのovaファイル名]
例) "C:\Program Files\VMware\VMware OVF Tool\ovftool.exe" -acceptAllEulas D:\vSphereDataProtection-6.1.5.ova D:\vSphereDataProtection-6.1.5-ver2.ova

# 実行結果
Opening OVA source:D:\vSphereDataProtection-6.1.5.ova
Opening OVA target:D:\vSphereDataProtection-6.1.5-ver2.ova
Writing OVA package:D:\vSphereDataProtection-6.1.5-ver2.ova
Transfer Completed
Completed Successfully

 

 

OVFの再構成後、下記のように「証明書が存在しません」という状態となり、デプロイを引き続き行うことが可能です。

但し、先ほど赤字で記載をした通り、デプロイ時の仮想マシン名は再構成したOVAファイル名と合わせるようにして下さい。そうしないと、記画面で証明書検証エラーとなり先に進めません

 

f:id:kenta53682:20171025105907p:plain

 

 

なお、vSphere Data Protection は vSphere 6.5 が最後のサポートとなり、以降のバージョンではVDPが提供されなくなります。End of Techinical Guidance は 2022/3/12 となるため、今後仮想環境のバックアップをVDPで提案するのはあまりお勧めできないかと思います。

(勿論、上記踏まえてコストの関係でVDPを採用されるお客様であれば別ですが。)

 

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