VMware認定インストラクター兼vExpertによるVMworld 2018 レポート(スペイン、バルセロナ編) - Day 5. Breakout Session&会場レポート
おはようございます、バルセロナ滞在5日目です。朝は肌寒いですが過度な防寒は不要で上着があれば全然問題ない気候です。日本の11月と同じ装いで過ごせます。
ということで、VMware Education Japan Teamから貰ったユニフォームで今日は参加しましました。
さて、こちらが今日の予定です。今日はVMWorldとしては3日目であり、2つ目のGeneral Sessionがあります。
そんな私は今日参加をしたセッションは次の通りです。
- Advanced VMware NSX Data Center, Demystfing the VTEP, MAC, and ARP Tables
- Ensure Maximum Uptime and Performance of your vCenter Server Appliance
- Clustering Deep Dive 2: Quality Control with DRS and Network I/O
各セッション1時間(Q&A込)です。ここに来て、毎日新しい情報を取り込むというのは思った以上に体力が必要です。これに加え会場内の移動と脳内で英語→日本語変換も行っているので個人的にはCPU常時100%な状態です。もうちょっと物理コアが欲しい。
ちなみに今日もvBreakfastを頂きます。メニュー内容はやや変わる程度で、基本的には同じものが期間中は続きます。ヘルシーかと言われればお察しください。ただ、ジャンクフードは好きな方なので個人的には全然いいんですが(笑)
★Breakout Sessions★
1. Advanced VMware NSX Data Center, Demystfing the VTEP, MAC, and ARP Tables
VMworld 2017の同内容のセッションがありましたので載せておきます。
本年分の動画及び資料は本記事寄稿時点では確認出来ませんでしたので、確認次第Upしようと思います。内容を比較しましたが、2018年度の方では、VMware NSX Central CLIという機能について紹介がありましたが、それ以外はこの動画にある内容で全て同じです。
VMware NSXと言えば、SDN(ソフトウェアにより定義するネットワーク)製品なわけですが、簡単に言ってしまえば、L2スイッチング/L3ルーティング/L4以上のファイアウォール/ロードバランサ/VPNサービスなどを物理アプライアンスではなく、仮想マシンまたはハイパーバイザー内で動作するプロセスとして動かす製品です。
本セッションでは特にL2スイッチング/L3ルーティングにフォーカスした内容となっています。
ネットワークの世界ではトラフィックを制御するに当たり、”テーブル”と呼ばれるトラフィックを送受信するに当たり基準としている情報がありますが、それらがVMware NSXではどこで、どのように、どのタイミングでテーブルが更新されるのか、という内容です。テーブル無くして、ネットワーク通信は成しえません。
物理ネットワークの環境では、このテーブルという情報を物理ネットワーク製品が収集するわけですが、その手法には”ブロードキャスト通信”を利用します。
※ブロードキャストって何？という方はこちらのリンクをご覧いただくといいでしょう。3分間ネットワーキングという、私も初めてネットワークを勉強した時に使った超優良ページです。
ネットワークへの理解がある方であれば、”ブロードキャスト＝減らしたいトラフィック”であると言えるでしょう。一言で言えば、このセッションの趣旨は、”VMware NSXは、ブロードキャストを使わずしてテーブル情報を生成するので、効率的的でしょ？”っていう内容です。
簡単に図を使って説明しましょう:)
こちらの図は動画内からの抜粋ですが、4つの物理サーバー上で仮想マシン(Power OnとOffが混在)が動作している図です。
仮想マシンから下方に伸びる緑と赤のラインは、個別の仮想マシン用のスイッチです。赤スイッチと緑スイッチがあると考えてください、そしてこれらは異なるVLAN IDであると考えて下さい。(正しくはVXLANですが、今回はその意味の説明は割愛します)
今回は緑スイッチに接続された3つの仮想マシンに注目しましょう。3台中2台はESXi01ホスト上で動作しています。最後の1台はESXi03ホスト上で動作をしています。
上スライド内の1番下にあるCLIの出力情報は、NSXで取り扱う3種類のテーブル情報です。左から順にVTEPテーブル、MACテーブル、ARPテーブルです。
VTEPテーブルは、どのESXiホストがNSXのネットワークに現在参加しているかを示すものです。出力内のVTEP IPと書いている所には動作中の仮想マシンのオーナーのIPがリストとして出ていることがわかります。これは、”このIPの持ち主の上に、NSXによるトラフィック制御が必要な仮想マシンがいるよ”という事を示します。それ以外のMACとARPテーブルですが、これらは従来のネットワークに登場するテーブルと同じです。MACテーブルですが通常物理スイッチの世界では”各物理ポートの先に、どのMACアドレスのデバイスがいるか”を対応付けするテーブルです。
こちらをご覧いただくと、”このMACアドレスの仮想マシンは、このVTEP IPを持つホスト上にいる”という事を示すテーブルになっています。ESXiホストの集合体である”クラスタ”を大きなスイッチに見立てて、1つのホストは物理ポートのように解釈が出来ます。
ここまでは従来のネットワークとNSXならではの点の解説をしました。本題に戻りましょう。本セッションのキーポイントは、”物理ネットワークの場合は、これらの情報を集めるのにブロードキャストが必要だ”と言いました。
VMware NSXでは”NSX Controller Cluster”と呼ばれる特別な仮想マシンが動作しており、このVMがテーブルを集中管理します。ブロードキャスト通信というのは言葉は悪いですが、総当たり的に通信を投げるため帯域幅の非効率な消費を生みます。
VMware NSXではこの仮想マシンが、全てのテーブル情報を保持しますので、ブロードキャストを使わなくても、テーブル情報の更新が必要な場合はこの”NSX Controller Cluster”からテーブル情報を持ってくれば良いという点がNSXの利点です。
なお、テーブルの生成は”NSX用仮想スイッチにつながった仮想マシンがPower Onされた”というトリガーにより生成されます。ここ、重要です。
ですので、NSXでトラフィックを制御する対象の仮想マシンが電源が落ちている状態だとこのようにテーブルには何もエントリされていません。
なおセッション内では”じゃあ、”NSX Controller Clusterがダウンしたら通信出来ないじゃないか”という状況において利用する”Controller Disconnected Operationモード”の紹介がされています。
Controller Disconnected Operation (CDO) モード
余談ですが、皆様、Lord of the Ringという映画はご存知でしょうか。本セッションはVMware Education ServicesインストラクターのBurkard, Tim氏によるものですが、彼は別名v_gandalfと呼ばれています。
Tim Burkard (@v_gandalf) | Twitter
担当製品はVMware NSXがメインですが、その容姿が本映画内に出てくるウィザード”ガンダルフ”を思わせます。映画内では主人公たちに襲いかかる敵を追い払い、道を示すような役割だったかと。つまりトラフィックを制御しているネットワークとかけているわけです。
※そんなにこの映画のことは知りませんでしたが、彼の動画を見たとき、トレーニングを見ているというよりショーを見ている感覚でした。とてもいい動画なので2つ載せておきます。
ここまで書いてまだ1セッション分にしか至っていません。が、続けて残りも書いていきます。
2. Ensure Maximum Uptime and Performance of your vCenter Server Appliance
資料ダウンロードリンク Click Here(VMworld USの資料です)
本セッションのテーマは、vCenter Serverの監視手法についての紹介です。
なお、監視であって、対処手法の紹介ではない点をご留意下さい。
vCenter Serverの監視手法は主に2つあるという事を始めに説明を受けました。
- VAMI (vSphere Appliance Management Interface, 略称ヴァミと発音)
- vimtop (ヴィムトップと発音)
また、vCenterの監視におけるポイントは上記の点です。って、まぁ全部じゃん、という感じではありますが...(笑)
VAMIは、vCenter ServerのFQDNまたはIPにTCPポート番号5480に、Webブラウザベースでアクセスする画面です。
CPUとメモリについては瞬間的に70%以上を超える利用率はOKですが、恒常的に70%を上回るのはNGとの事。(なぜ70%までなのか話がありませんでした)
ディスク系の話では、vCSAが持つ仮想ディスクのサイズのモニタリングの重要性の話がありました。VAMIで視覚的な監視も可能です。
ディスクサイズの変更についてはナレッジがありますので以下をご覧ください。
https://kb.vmware.com/s/article/2145603
上記のように、監視の仕方とポイントが解説されるセッションで、安定してvCenterが動作しているかどうかを判断するのにはとてもいい情報だったと言えます。
3. Clustering Deep Dive 2: Quality Control with DRS and Network I/O
本セッションは、前回のDuncanとFrankのvSphere HAとDRSのセッションの続編です。同書籍の著者であるNiels Hagoort氏です。(フリーランスのVMwareエンジニア)
本来のvSphere DRSは物理ホスト群のCPU/メモリの均衡化が目的ですが、そこに更に、“Network aware DRS”という機能がvSphere 6.5から追加されましたがその動きの紹介がありました。
基本的にvSphere DRSはコンピュータリソースの視点から最適な仮想マシンの配置を計算、移動を行いますが、このNetworkd aware DRSによりコンピュータリソースの観点から最適な移動先が複数ある場合、さらにその中からネットワークリソースの観点も加えて比較的帯域幅に余裕があるホストを選択してvMotionしてくれる可能です。(あくまでもCPUとメモリの負荷判定が主役です)
※勘違いしてはいけないのは、本ブログ機構時点で、本機能はネットワーク帯域の輻輳だけでvMotionするものでは無いです。
こちらの図では、Network DRSによりどのホストがvMotionの移動先として最適であるかを判断する情報を順を追って確認しています。
DRSの視点ではCPUの利用率から不均衡であると判断しており、2つのESXiホストは利用率が低い、他の2台は高い状況です。
この際に更にネットワークの利用率も見た結果、ホスト 10.156.232.163はネットワークの利用率が高いため、vMotion移行先としては不適切であると判断されていることが確認出来ます。
一方で、この機能の注意点としてはホストレベルでのネットワーク利用率を判定基準としているという点です。つまり、仮想マシンのワークロード以外にESXiホストのワークロードも判定基準に入っているので例えば仮想スイッチが仮想マシン用とホスト用など分かられていても、全ての物理アップリンクを加味した値を用いてNetwork aware DRSは動くということです。
また、2台の仮想マシンは同一ホスト上で相互通信する場合は物理アップリンクを経由しない為、高速通信が可能です。
こうした内部パスによる高速通信中の仮想マシンも、DRSにより移行される可能性があるため、場合によってはDRSによる自動vMotion以降パフォーマンスの劣化が発生する可能性もあります。
また、この課題点についてはNetwork aware DRS登場以前からある話ですので、vSphere DRSの既存機能である”アフィニティルール”を使えば、複数の仮想マシンを常に同一のホストに配置することが出来ます。
このテクニックはDRSユーザーなら馴染みはあるかもしれません。
以上のように、この日はvSphereやNSXなどの、仮想基盤の基本的な要素についての様々な要素について学びました。
既にトレーニングを日々行なっている製品であっても、まだまだ知らないことや深く知るべき範囲があることがあるなとしみじみ思うばかりです。
そしてこの日はWelcomeパーティーという事で18:30くらいから会場の様子が一変しました。
ゼネラルセッションの会場前が賑わっています。
毎年”VMworld FEST”ということで、バンドを呼んでの音楽フェスをやっているようです
the Kooksというバンドが登場するようです。
イベントごとに登場するバンドは毎回変わります。
正直この時点でブレークアウトセッションの参加と徒歩移動の多さで体力的に限界です、空腹と眠さで。
次の日に備えるために早く帰りたい反面、せっかく来たのだから120% VMworldを楽しむ必要があると思い会場内に足を運びました。
料理は必要十分にあり、ブース以外にもありこのような形でバーガー、サンドイッチ、ビールの配布も行われていました。
ナチョスと軽食を頂きます。歩きながらの移動を考慮されたサイズや包装がとても有り難いです。
目の前のステージではDJや前座のバンドによるミニライブが始まっています。
近くを歩いていたバーガーを配っているスタッフからバーガーを頂きます。なかなかのボリュームのバーガーでした。この時点でお腹も満たされました。
そろそろ会場を出ようと思ったところでビールサーバーのお兄さんにビールを頼みました。ちょうど最後だったのでやや泡が多くなりお兄さん苦笑い、いいんです、ありがとうお兄さん😊
いよいよ来たる翌日は最終日です。最終日分まで内容盛りだくさんでお届けしたいと思います。お楽しみに！
