Home > Blogs > Japan Cloud Infrastructure Blog

vROps 6.7は初心者に優しい!#3

3回目:仮想マシンのリストはカスタムビューで

 

— Back Number —

#1:仮想基盤のパフォーマンスは使用率だけでは図れない
#2:アラートからブレイクダウン
#3:仮想マシンのリストはカスタムビューで
#4:6.7バージョンはメトリックの活用がポイント(近日公開予定)
#5:vSAN運用管理者にはvROpsは欠かせないツール(近日公開予定)

 

日本ヒューレット・パッカード株式会社の中川明美です。

3回目は「仮想マシンのリストはカスタムビューで」です。

vROps 6.7のビューでは、「仮想マシンの診断リスト」が提供されていません。私は仮想マシンの診断リストを使用して、各仮想マシンのデマンドや競合を比較分析していたため、かなりの痛手です(笑)

提供されないなら、「ビューをカスタム作成しよう、みなさんにもカスタムビューの作成方法を共有しよう」と今回テーマに取り上げました。

 

カスタムビューを作成するには、Advanced / Enterpriseエディションが必要です。

リリースノートに、次の記述があります。

「vRealize Operations Standardエディションでは、ビュー、ダッシュボード、スーパー メトリック、およびレポートを作成または編集する機能は使用できません。」

vROpsを活用するには、Advanced以上のエディションが必要ということですね。

<vRealize Operations Manager 6.7 リリースノート>

https://docs.vmware.com/jp/vRealize-Operations-Manager/6.7/rn/vRealize-Operations-Manager-67.html

仮想マシンの診断リストを作成する前に、「ホストのCPU診断リスト」の内容を確認します。「ホストの診断リスト」は6.7でも引き続き提供されています。

 

◆ホストのCPU診断リスト◆

メインメニュー「ダッシュボード」で「ビュー」を選択します。「ホストのCPU診断リスト」を選択し、「ビューの編集」アイコンをクリックします。

ビューの数が多いため、この画面では右上のフィルタ (赤点線枠) を使用しています。

 

下図は、「ビューの編集」画面です。

ビューのポイントは「データ」です。「データ」で表示したいメトリックを指定します。

 

表示される値は、「平均ですか」「最大値ですか」と算出方法を聞かれます。その場合は、編集画面で確認します。※ Standardエディションは編集画面を表示できません。

「変換」で算出方法のタイプを選択できます。また「詳細設定を表示」 (赤色点線枠) をクリックすると、「ロールアップ間隔」を選択できます。

「競合(%)」は、「CPU競合 (%) 」メトリックの5分間の最大値を表示していることがわかります。

 

「メトリック相関」は、指定した「相関メトリック」の変換タイプが最小値または最大値である時に、値を表示します。この画面では、競合 (CPU競合) に「最大値」が選択されているため(青色枠)、「デマンド」や「使用量」などのデータも表示されるよう設定されています。

 

◆カスタムビューの作成◆

仮想マシンの「仮想CPUの数」と「CPUのパフォーマンスに関するメトリック」、仮想マシンが配置されている「ESXiホストの名前」が表示されるビューを作成してみましょう。

「ホストのCPU診断リスト」のメトリックを参考に、仮想マシン用のCPU診断リスを作成します。

ビューの画面で、「ビューの作成」アイコンをクリックします。5つのStepを進めます。

 

「1. 名前と説明」ではビューの名前を、「2. プレゼンテーション」ではデータの見せ方(リストやトレンドなど)を指定します。下図ではプレゼンテーションで「リスト」を選択しています。

 

「3. サブジェクト」では、データ対象のオブジェクトを選択します。

ここでは、「vCenter Server アダプタ」内の「仮想マシン」を選択します。

 

「4. データ」では、表示するプロパティやメトリックを選択します。

対象を「プロパティ」に変更し、「サマリ-親ホスト」「構成-ハードウェア-仮想CPU数」を右側のウィンドウにドラッグします。

 

対象を「メトリック」に変更し、パフォーマンスに関するメトリックを追加します。「デマンド」「使用率」は、単位を「自動」から「GHz」に変更しています。

 

「5. 可視性」では、作成したビューを、「ダッシュボード」「レポート」「詳細タブ」で使用するのかしないのかを指定します。

 

◆詳細タブで確認◆

作成したビューは、環境の詳細タブで確認します。

変更したい場合は、「ビューの編集」アイコンをクリックします。確認しながら変更できるため、作成後はこの画面で作業するのが便利です。

私も確認後、検索を容易にするためビューの名前変更、プロパティの「仮想CPU数」からメトリックの「プロビジョニングvCPU数 (vCPU) 」へ変更、「キャパシティ合計」を追加しました。

ビューのクローン、エクスポート、インポートもこの画面から行うことができます。

 

ビューの編集画面の「時間設定」で、データ表示期間を変更することができます。デフォルトは直近7日間です。この画面で変更せず、詳細タブのビュー画面でカレンダーのアイコン (上図の緑色枠) で都度変更することもできます。

 

ビュー作成時の詳細な説明は、こちらのドキュメントをご確認ください。

https://docs.vmware.com/jp/vRealize-Operations-Manager/6.7/com.vmware.vcom.config.doc/GUID-BC800026-25B4-4EDD-AE6F-E4A82BDE88C0.html

 

◆まとめ◆

vROps 6.7になり、仮想マシンの診断リストを見つけられなかった時は、困ったなぁと思いましたが、必要なメトリックを考えながらの作成は楽しかったです。

vROpsの操作を始めた数年前は、カスタム作成はハードルが高いのではと思っていたのですが、やってみると簡単でした。提供されているビューを参考にしてもよいですしね。

ビューは、ダッシュボードやレポートの元になるオブジェクトでもありますから、vROpsを超活用するためには必要な知識です。ぜひトライしてみてください!

 

 

 

 

vROps 6.7は初心者に優しい!#2

2回目:アラートからブレイクダウン

— Back Number —

#1:仮想基盤のパフォーマンスは使用率だけでは図れない
#2:アラートからブレイクダウン
#3:仮想マシンのリストはカスタムビューで
#4:6.7バージョンはメトリックの活用がポイント(近日公開予定)
#5:vSAN運用管理者にはvROpsは欠かせないツール(近日公開予定)

日本ヒューレット・パッカード株式会社の中川明美です。
2回目は「アラートからブレイクダウン」です。vROpsを使用してアセスメントをする時、私はアラートの確認から始めます。アラートの確認は現在の問題を把握するために最適なアプローチだからです。一般的にも問題が起きているオブジェクトを特定する場合、最初に行うステップはアラートの確認ですもんね。

アラートの説明の前に、ユーザーガイドのご紹介を!
VMware社が提供するドキュメント「vRealize Operations Manager ユーザー ガイド」では、次の3つのシチュエーションにしたがい、問題解決までのアプローチを提示しています。
• 問題が発生したユーザーから問い合わせがあった場合
• 受信箱にアラートが到着した場合
• オブジェクトの状態を監視しているときに問題を発見

◆vRealize Operations Manager ユーザー ガイド◆
https://docs.vmware.com/jp/vRealize-Operations-Manager/6.7/vrealize-operations-manager-67-user-guide.pdf
下図は、ユーザーガイドの目次です。先にご紹介した3つのシナリオにアラートの項目が続きます。ガイドの構成も、アラートから始め、次にパフォーマンスやキャパシティの状態を確認する手順になっています。私もこのプロセスでアセスメントを行っています。
こちらのユーザーガイドはとても参考になるのですが、文字だけの73ページのボリュームは文章を読みなれていない人には、ハードルが高いかもしれませんね。。。

 

では、vROpsのアラートの活用方法をご紹介します。

 

◆vSphere基盤全体の現状把握◆

vSphere基盤全体の現状を把握するために、vROpsのメインメニューのアラートを選択します。この画面で「すべてのアラート」を確認します。

下の画面ショットでは、2つの仮想マシンで同じ内容のアラートが表示されています。

この段階では、仮想マシンに何らかの問題が発生していることを認識します。

 

◆対象オブジェクトの現状把握◆

対象オブジェクトのアラートの詳細を確認するために、リンク文字列(青色表示)をクリックすると、下の画面が表示されます。

この画面から、4つの情報を得ることができます。

赤枠:アラートの原因

上の画面ショットでは電源管理の設定がなされていないことが原因として挙げられ、それによってパフォーマンスに影響を与えているのではと推測します。

電源管理のアラートはvROps 6.6から表示されるようになりました。それより前のバージョンでは、非常に高いCPU Ready値またはオーバーヘッドから電源管理が原因なのでは?と分析していました。

 

青枠:現状を解消するための推奨アクション

「推奨」には、現状を解消するための具体的な操作方法が表示されます。

他の推奨がある場合は、「>その他の推奨事項」の「>」をクリックすると、表示されます。

上の画面ショットでは、BIOSとESXiホストで電源管理の設定方法を紹介しています。

BIOSの設定は、各サーバーベンダーに問い合わせることをお勧めします。この画面では、「OS Controlled」がありますが、ベンダーによってメニュー名は異なります。

BIOS設定の詳細については、VMware社の以下Knowledge Baseも参考になるかと思いますので是非ご参照下さい。
Virtual machine application runs slower than expected in ESXi

 

緑枠:詳細情報の表示

いつからパフォーマンスに影響がある状況になったのか、どのメトリックの値が原因なのかを知りたい場合に、次の3つのリンクをクリックします。「ログの表示」は、vRealize Log insightと連携すると表示されます。このBlogでは、「追加メトリックの表示」と「イベントの表示」を取り上げます。

  • 追加メトリックの表示
  • ログの表示
  • イベントの表示

 

追加メトリックの表示

「追加メトリックの表示」をクリックすると、対象オブジェクトのメットリック画面に遷移します。

パフォーマンス低下の原因となるメトリックの左側の◆が黄色で表示されます。

次に、メトリックをダブルクリックすると、右側のウィンドウにグラフが表示されます。このグラフから値の変遷を確認することができます。

メトリックの詳細については、4回目で説明します。

イベントの表示

アラートで表示されているイベントが、いつ警告(またはアラート)レベルに至ったかを時系列で確認することができます。下図にあるように、赤い▲にマウスカーソルを合わせるとイベントの詳細が表示されます。この画面ショットでは、グレーの▲時点でCPUに高負荷がかかり、10分以内に警告レベルに至っていることがわかります。

 

黒枠:シンプトン

シンプトンは「事象」と訳されます。vSphere仮想基盤で発生した、クリティカル (またはその兆候) な事象を確認することができます。

下の画面ショットで表示されているシンプトンは、「電源管理テクノロジーがOS Controlledに設定されていません」という事象です。このシンプトンには、「CPU競合」のメトリックとそのメトリックに指定された条件 (しきい値) が設定されています。競合値が30%以上の場合、クリティカルレベルのアラートが発生されます。

アラートは、問題の発生を知らせ
るだけでなく、「シンプトン」と「推奨アクション」を関連付けて構成 (作成) することもできます。

 

メインメニューのアラートはすべてのオブジェクトを対象とします。任意のオブジェクトの詳細な状況を確認する場合は、各オブジェクトを選択します。各オブジェクトのアラート機能をご紹介します。

 

◆任意オブジェクトのサマリ◆

環境メニューから、任意のオブジェクトを選択し、「サマリ」を確認します。

サマリでは、「健全性」「リスク」「効率」のステータスとアラートが表示されます。バッジ (赤い点線枠) で表示を切り替えます。

右下のパフォーマンス (青い点線枠) ではパフォーマンスに関わる主要なメトリックが表示されます。下の画面ショットでは、電源管理の設定により、競合値が高く、100%を超えるデマンド値になっています。物理CPUが割り当てられず、CPUリソースの要求が高くなっていますね。

 

◆任意のオブジェクトのアラート◆

アラートのシンプトンでは、リスト形式でクリティカルな事象を時系列で確認できます。

下の画面ショットでは、パフォーマンスに影響があるシンプトンが表示されています。

 

◆まとめ◆

今回はアラートを取り上げました。このBlogを書くにあたり、アラート画面をじっくり確認した結果、この画面だけで1時間は話せるなという情報量です (笑) 。

vSphere仮想基盤の運用担当者になったばかりという方は、アラート画面の情報量だけで原因を特定するための工数を短縮できるのではないかと思います。アラートによっては推奨アクションも表示されますしね。

vROpsは情報量が多いのが、よいところでもあり、初心者のハードルを上げてしまうところでもあります。しかし、理解度 (習熟度) レベルに合わせて使用するダッシュボード (ユーザーインターフェース) を使い分けると活用の幅が広がります。コンサルティングの場で、ユーザーの方に安心いただくために、順番に覚えればいいのですよとお伝えしています。

次回は少々レベルを上げて、カスタムビューの作成方法をご紹介します。

第2回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!

第2回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!! ~電力消費量計算編~

 

#第1回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!
~導入構成編~

 

#第2回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!
~電力消費量計算編~

 

#第3回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!
~2 Node vSAN 対応とよくある QA編~

 

◆はじめに

はじめまして! 田中電機工業株式会社 中野 (左) と 村上 (右) です。

田中電機工業は広島でシステム・ネットワーク構築、アプリケーション開発をはじめ、コンサルティングから設計、構築、運用、保守まで、システム全般のサポートを行っております。

http://www.tanaka-elec.co.jp

 

前回のシュナイダーエレクトリック 出口さんの続きとして、VMware vSANとシュナイダー UPSを自社の本番環境に導入した実績を基に、「構成と製品選定のコツ」、「バッテリー稼働時の耐久時間」「シャットダウン時の動き」をご紹介していきます。

 

1.構成と製品選定のコツ

2018年10月現在で、我々の会社では3ノードの vSAN 上で約50台のVMが稼働しています。

 

👉 vSAN を構成しているハードウェアはこちら

👉 vSAN と UPS の構成図

vSAN と UPS の物理接続構成はこの様になっています。

もし導入構成で迷われている方がいましたら、ぜひ参考にしてください!!

 

では具体的にUPS製品の選び方を見ていきましょう!

 

シュナイダー社が提供している UPS 製品のラインナップは以下の様に豊富に提供されていますが、HCI 環境で使う場合には赤字でマークしてある製品を検討いただくことが多くなるかと思います。 (2018年1月現在のラインナップ)

 

お気づきの方もいるかも知れませんが、製品名に書かれている「2200」「3000」という数字は UPS の保持電力量になります。

vSAN 環境で UPS を使う場合は複数のノードの扱うことになりますので、上の表でマークしたような、ある程度の電源容量がある型番が選ばれることが多くなりそうですね。

 

 

2.電源容量とUPS稼働時間の計算方法

では、いよいよ UPS を選んでいくにあたって 皆様が気にされていると思われる電源容量と稼働時間の算出方法を見ていきたいと思います。

稼働時間を算出するには、以下のポイントを確認いただければ簡単に算出していくことが可能です。

  • UPS の電源容量

    👉こちらは先程お見せしたリストのように、UPS型番をみれば電源容量は一目瞭然ですね (^^♪

  • 接続するサーバーの合計消費電力

    👉 弊社で導入したvSAN基盤は Lenovo 社のサーバーを使っていますので、こちらのサイトから詳細に電力を算出しました。
    http://dcsc.lenovo.com/


最大電力消費量は3ノードで1983.6 W。

運用中の負荷が70%  程度の使用率と考えた場合の消費量は以下になります。

「皮相電力」 ・・・ 2009.7 VA × 70% = 1406.79 VA
「消費電力」 ・・・ 1983.6 W × 70% = 1388.52 W

 

2台冗長構成で実装しており、3台の電源消費量を2台で分散して処理しますので、UPS 1台あたりの消費量は以下のとおりです。

「皮相電力」 ・・・  1406.79 VA ÷ 2 = 703.395 VA
「消費電力」 ・・・  1388.52 W ÷ 2 = 694.26 W

使っている UPS 型番と機器の消費電力が算出できたら、シュナイダー社の以下ドキュメントに記載されている各 UPS 毎のバックアップ時間表を確認することで、簡単に計算をすることができます。
http://catalog.clubapc.jp/pdf/ups/small-ups_1510.pdf

※P23 を参照。以下に抜粋

今回の使用している UPS は一番右の SMT3000RMJ2 です。

先程算出した皮相電力と消費電力が当てはまる部分を赤枠で囲ってみました。

ということで、今回の構成ではバッテリー稼働時に20分間は問題なく稼働できるということが確認できました。

 

 

3.UPS稼働時のシャットダウン動作と電源復旧時の起動方法

最後に望まないことではありますが、もし実際に電源障害が発生してしまい、UPSで vSAN を安全にシャットダウンしなければならない状況が発生した場合に、「どのような流れでシャットダウンが行われているか?」と「電源復旧時のシステム起動方法」を実際に運用した際の勘所を交えてお伝えします。

 

[シャットダウンフローはこちら]

 

[電源を復旧させる場合のフロー]

・vSAN ノードと vCenter Server が異なるホスト上にある場合

今回はこちらの流れになります。

1.UPSの通電を開始
2.vCenter Server の起動
3.ESXiホストの起動
4.ESXi ホストのメンテナンスモードを終了
5.各仮想マシンを起動

※2番でESXiホストよりも先にvCenter Server を起動していますが、Virtual Appliance 版のvCenter ServerをvSANノード上に配置している場合は、次にご紹介するフローで起動可能です。

 

・vSANノード上にvCenter Serverが配置してある場合

1.UPSの通電を開始
2.ESXi ホストの起動
3.ESXi ホストのメンテナンスモードを終了
4.vCenter Server の起動
5.各仮想マシンを起動

vSANの機能はESXiホストが実装している機能なので、vCenter Serverが起動していなくても
vSANデータストアは使用できるのです  ε-(´∀`*)ホッ

 

最後に実装と運用する際の勘所をサマリにまとめました。

・vSAN をメンテナンスモードに移行していく際に、一度に全てのホストがメンテナンスモードには移行するのではなく、1台ずつ順番にメンテナンスモードに移行します。

・PowerChute Network Shutdownでコマンド実行を行う場合、サービスを起動するユーザで実行します。うまくいかない場合は、管理者権限のあるユーザに変更する必要があります。

・ホストをメンテナンスモードに移行させるためにSSH接続を使用しますが、初回にセキュリティ警告が表示されますので、unknown_hostsリストに該当のESXiホストサーバを追加する必要があります。

実装するスクリプトや、詳細な情報については以下のURLが参考になりましたのでご覧ください。

 

https://www.schneider-electric.co.jp/ja/faqs/FA329212/

 

 

4.さいごに

 

いかがでしたでしょうか?

HCI を導入する際に vSAN を採用すれば、今まで vSphere で蓄えた知識を基に、簡単にUPSを導入できることがイメージしていただけたのではないかと思います。

弊社では検証環境用に 2 ノード vSAN も導入しています。
社内で身につけた 2 ノード vSAN 構築、運用、3rd パーティ製品連携の勘所なども、いずれご紹介したいと思いますのでご期待ください!!

PS : 広島へお越しの際は、お土産に平安堂梅坪にも寄ってみてください。
特にバターケーキが村上のオススメです。

 

平安堂梅坪

※株式会社平安堂梅坪は、田中電機工業の子会社になりました。

仮想基盤のパフォーマンスは使用率だけでは図れない

1回目:仮想基盤のパフォーマンスは使用率だけでは図れない

– Back Number –

#1:仮想基盤のパフォーマンスは使用率だけでは図れない
#2:アラートからブレイクダウン
#3:仮想マシンのリストはカスタムビューで
#4:6.7バージョンはメトリックの活用がポイント(近日公開予定)
#5:vSAN運用管理者にはvROpsは欠かせないツール(近日公開予定)

日本ヒューレット・パッカード株式会社の中川明美です。

VMware vRealize Operations Manager 6.7が2018年4月にリリースされましたね。

6.7を操作した感想は、「仮想基盤の運用管理に必要なメトリック (カウンタ) にフォーカスしている!」です。フォーカスされていると、覚えるべき項目が少なくなり、初めて仮想基盤の運用に携わる方は助かりますね。

6.7バージョンの一番の変更点は、「分析」タブがなくなったことです。分析タブがなくなったのは残念ですが、初心者に優しいダッシュボードが準備されています。

#1:仮想基盤のパフォーマンスは使用率だけでは図れない

#2:アラートからブレイクダウン

#3:仮想マシンのリストはカスタムビューで

#4:6.7バージョンはメトリックの活用がポイント

ここ数年vROpsに関わるお仕事で、現在も物理マシンと同様の手法で仮想マシンを監視されていらっしゃる方をお見受けします。よくあるのは「使用率」のみを監視する方法です。

仮想基盤は、「キャパシティ」と「パフォーマンス」の2つの視点で監視する必要があります。「使用率」に加え、仮想基盤特有のメトリックと合わせて監視するのがポイントです。

数バージョン前からVMware vRealize Operations Manager (以降はvROps) のワークロードには、CPUは「デマンド」、メモリは「消費 (実際に使用された物理メモリ量) 」を分析結果に表示しています。これらのメトリックを調査するのは仮想マシンのパフォーマンスを最適化する前提となります。標準で提供されるVMのトラブルシューティングダッシュボードでは、使用率と仮想基盤に特化するメトリックが並べて表示されています。

 

仮想基盤において、なぜ使用率のみでは正しい判断ができないのでしょうか。コンピュータリソースのCPUとメモリを例に検証します。

 

◆ワークロード◆

下図は、vROps 6.6まで提供されていた、「分析」タブの「ワークロード」画面です。

この画面はデータセンターを選択しています。ESXiホスト2台分で、CPUのキャパシティは16.76GHz、メモリは32GBです。

<CPU>

ESXiホストの使用率は23.2%です。物理マシンの使用率を監視するならば、問題なしと判断されます。しかしこの画面から2台の仮想マシンのワークロードが高い状態であることがわかります。この画面だけでは根本原因はわかりませんが、ホストの「デマンド」が「使用量」より高い状態であることが1つのヒントになります。

参考までに、この画面でオーバーヘッドが高いのは、CPUの省電力機能が原因です。

KB: Virtual machine application runs slower than expected in ESXi (1018206)

 

<メモリ>

ESXiホストの使用率は82.48%です。物理マシンの使用率を監視するならば、高い使用率から問題ありと判断されるのではないでしょうか。しかし仮想マシンのワークロードは高くありません。この結果から、仮想マシンからのデマンド(要求)により、物理マシンの多くの物理メモリが消費されていることがわかります。

ESXiホストの使用率は90%を超えないように監視するのがポイントです。

仮想マシンからの要求により割り当てられた物理メモリの回収の発生タイミングは、次のBlogにまとめられています。

https://blogs.vmware.com/vsphere/2012/05/memminfreepct-sliding-scale-function.html

ESXiホストに96GBの物理メモリが搭載されていた場合、バルーニングが発生するタイミングは残りメモリが10244.26MBになった時です。このスライディングスケールというアーキテクチャを知ると、90%を超えないように監視するというのも納得できますね。

そして物理マシンの高いメモリ使用率が単純に仮想マシンのパフォーマンスに影響を与えるわけではないこともわかると思います。

 

CPUの高いワークロードの原因を特定しましょう。

◆仮想マシンのCPU診断リスト◆

下図は、vROps 6.6まで提供されていた、「仮想マシンのCPU診断リスト」ビューの画面です。

高いワークロードの原因は、高い競合値です。仮想CPUに物理CPUが割り当てられず、待ちが発生すると、高い競合値となります。

さらにこのBlogのテーマである使用率を確認します。VM-2を例にします。

VM-2のCPUキャパシティは約2.8MHzです。使用量を確認すると、約1.4MHzですから、使用率は50%です。低い使用量は物理CPUが割り当てられないためと考えられます。

 

上記から、物理マシンや仮想マシンの使用率のみでは、仮想基盤のパフォーマンスを分析するための判断材料が不足していることはおわかりになるかと思います。

次にデマンドの値も確認しましょう。競合値が特に高い、2つの仮想マシンでは、「キャパシティ」よりも「デマンド」の方が高い値が表示されています。これも物理CPUが割り当てられないために、リソース要求 (デマンド) が高くなっているためです。

 

 

◆「VMのトラブルシューティング」ダッシュボード◆

vROps 6.7では、「VMのトラブルシューティング」ダッシュボードが標準で提供されています。

このダッシュボードの内容から、「慣れるまではこのダッシュボートを活用すれば問題ないよ」というメッセージを感じます。私が個人的にお勧めする初心者に優しいダッシュボートです。

左側のリストから仮想マシンを選択すると、仮想マシンの構成情報、アラート、ワークロード、稼働ホスト、格納先データストア、VMware Toolsのバージョンを一覧表示できます。

ダッシュボードをスクロールすると、左側に各リソースの使用量 (CPUはデマンド/メモリはワークロード/ディスクはIOPS総数/ネットワークは使用率)、右側にパフォーマンスに影響を与えるメトリックが表示されています。そのメトリックには、CPUとメモリは競合、ディスクは遅延、ネットワークはドロップパケット数が選択されています。

 

複数の画面を遷移せずとも、このダッシュボードから、パフォーマンスに影響を与える原因と対応方法のおおよその検討をつけることができます。

CPUを例にします。CPUのデマンドが高くかつ競合が高いのであれば、パフォーマンスに問題があると判断し、他のESXiホストへの移行を検討します。CPUのデマンドが高くかつ競合が低いのであれば、キャパシティに問題があると判断し、その仮想マシンの仮想CPUの追加を検討します。

 

◆「運用概要」ダッシュボード◆

「運用概要」ダッシュボードで表示される上位15でも、「使用率」ではなく、「CPU競合」「メモリ競合」「ディスク遅延」が選択されています。このダッシュボードも標準で提供されています。

なぜ使用率 (使用量) が選択されていないのかはもうおわかりですよね!

競合の詳細な原因や、ディスク遅延およびネットワークのドロップの発生原因は、「ビュー」または「メトリック」を使用して分析します。こちらについては、以降の回でご紹介します。

 

 

◆まとめ◆

仮想基盤のパフォーマンスに影響を与えるメトリックには仮想基盤特有のメトリックがあるにも関わらず、物理基盤と同様の方法で監視されている方がいらっしゃるのが気になっていました。それをご存じないために、物理基盤と同様の方法で監視されるのではないかと推測します。vROpsで仮想基盤に特化したメトリックが表示されていても、活用するには少々ハードルが高いというお話も私の耳には入っていました。

「VMのトラブルシューティング」ダッシュボードを見た時に、「そうそう、このメトリックが必要なの!」とうれしく思いました。仮想基盤の運用に慣れていない方も、VMのトラブルシューティングダッシュボードを活用すれば、一時切り分けが可能です。

vROps 6.7から、初心者が活用することを意識した構成になっていると個人的に感じています。知識習熟度レベルによって、使い分けられたら費用対効果もあります。

次回は、アラート対象のオブジェクトの原因を探る方法をご紹介します。

VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化(10) 

エージェントレス型セキュリティ環境におけるWindows 10 Creators Updateの対応

 

トレンドマイクロ VMwareテクニカルアライアンス担当 栃沢です。

Windows 10環境への移行が進む中でWindows 10 Creators Updateへの対応についてご質問を頂くことが多くなってきております。
仮想デスクトップ環境では、Creators Updateがリリースされた場合にVMware vSphereVMware NSXVMware Horizon、VMware Toolsを確認する必要があります。そして、エージェントレス型セキュリティ対策ではさらにDeep Security Virtual Appliance(DSVA)との互換性を意識していく必要があります。今回は各ソリューションが互換性の面でどのような関係性があり、どのようなポイントを確認していけばよいか、順を追って解説したいと思います。

 

仮想マシンOSがVMware仮想環境で利用できるか確認するポイント

仮想マシンにはポップアップツールであるNotifierを除いてセキュリティ機能を提供するDeep Securityのコンポーネントは導入されません。DSVAによるエージェントレス型セキュリティを提供するためには、仮想マシン側にVMware Tools のVMCIドライバに含まれるNSXファイル自己検証ドライバ(vsepflt)を導入しておく必要があり、NSXファイル自己検証ドライバがフックする情報を基に不正プログラム対策などの機能を提供しています。
詳細は第5回ブログをご覧ください。

VMwareの仮想環境上でどのWindows OSが利用できるかを確認するためには、VMware Tools とOSの互換性をチェックする必要があります。
確認のポイントは以下の2つです。

1) 仮想マシンに導入するOSがVMware Toolsに対応しているかを確認する
 VMware Compatibility Guide にて確認することができます。

2) VMware Toolsが利用を予定している vSphere / NSX に対応しているかを確認する
 VMware Product Interoperability Matrices にて確認することができます。

ここでのポイントは、該当するWindows OSがサポートするVMware Toolsを確認し、VMware Toolsが利用可能なvSphereNSXの組み合わせを把握する、という点です。この組み合わせ(=互換性)が満たされていないとVMwareのサポートを受けられなくなる可能性がありますので、必ずチェックをしましょう。

 

エージェントレス型セキュリティ提供可否を確認するためのDSVA互換性チェック

導入する仮想環境のバージョンが確認できたら、その環境でDSVAが利用可能かを確認します。
DSVAの互換性は、vSphere及びNSXのバージョンに依存します。VMware Toolsとは直接の互換性を持っていません。また、仮想デスクトップ環境において利用されるHorizonとも依存関係はないので意識する必要はありません(もう少し踏み込むとvCenter Server、NSX ManagerがDeep Security Managerと連携できれば、仮想デスクトップ展開ソフトウェアは意識しない)。
以下のサイトにてDSVAがvSphere及びNSXのどのバージョンと互換性があることをDeep Securityのバージョン毎に確認することができます。

Deep Security and VMware compatibility matrix

 

DSVA利用時のWindows 10 Creators Update の対応について

ここまでの解説を見てお分かりいただけたかと思いますが、DSVA環境における利用可能なOSは直接的にはVMware Toolsのバージョンに依存します。VMware Toolsについては、仮想マシンのOS種別単位で対応が定義されており、Windows 10のCreators Update(RS3、RS4など)のサービスオプションごとの互換性を意識する必要はありません。 対応OSについては、VMware Toolsのリリースノートを参照してください。

 

[参考情報]VMware HorizonのWindows10のサポート

DSVAとの互換性とは直接関係ありませんが、Horizonによる仮想デスクトップ環境の導入の際にはOSがどのようにサポートしているかを確認する必要があり、よくご質問をいただきますので、その情報もここでご案内しておきたいと思います。

以下のKBにはHorizonのWindows 10のサポートバージョンが記載されていますが、あくまでHorizonの互換性であり、VMware Toolsの対応バージョンは考慮されていませんので上記の互換性の確認を行って対応OSの確認をする必要があります。
https://kb.vmware.com/s/article/2149393

また、Horizon環境のサポートポリシーとして、Windows10サービスオプションが「対象(Targeted)」となっているバージョンについてはTech Preview Supportということで上記KBでもサポートされないステータスとして管理されています。
Microsoftが公開しているWindowsのリリース情報も適宜確認するようにしましょう。
https://www.microsoft.com/ja-jp/itpro/windows-10/release-information

 

まとめ

仮想マシンのOSの利用できる環境を確認する方法についてご理解いただけたでしょうか?
簡単な互換性の関係をまとめると以下のようになります。

Windows 10を例にここではお話してきましたが、レガシーOS(Windows Server 2003など)の対応も同様に確認することができます。
ただし、VMware、トレンドマイクロそれぞれでレガシーサポートの対応について定義しておりますので、必ずサポートの可否、対応条件および制限事項について事前に確認するようにしましょう。

 

執筆者:
トレンドマイクロ株式会社
セキュリティエキスパート本部
パートナービジネスSE部 パートナーSE2課
栃沢 直樹(Tochizawa Naoki)

 

【VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化】

    1. Horizon インスタントクローンにも適用可能!仮想デスクトップ環境にフィットしたセキュリティ対策
    2. VMware NSX + Deep Secuirty連携によるエージェントレスセキュリティとは?
    3. VMware NSX + Deep Security連携にかかわるコンポーネントと基本構成
    4. VMware NSXとDeep Securityのユースケースと実現できることとは?
    5. エージェントレス型ウイルス対策のアーキテクチャ(1)
    6. エージェントレス型ウイルス対策のアーキテクチャ(2)
    7. エージェントレス型による侵入防御/Webレピュテーションの実装
    8. エージェントレス型とエージェントレス型の使い分けのポイント
    9. コンバインモードの正しい理解と知っておきたいこと
    10. エージェントレス型セキュリティ環境におけるWindows 10 Creators Updateの対応

 

仮想スイッチのお作法~Network I/O Control#6~

6回目:仮想スイッチのお作法#6    (Network I/O Control#6)

– Back Number –
#1…仮想スイッチのお作法#1
#2…仮想スイッチのお作法#2
#3…vSphere 6. 5の分散スイッチの機能とアーキテクチャ#3
#4…分散スイッチの管理①#4
#5…分散スイッチの管理②#5
#6…Network I/O Control#6

日本ヒューレット・パッカード株式会社の中川明美です。

6回目は、分散スイッチが提供する「vSphere Network I/O Control バージョン3」についてご紹介します。「Network I/O Control」は、複数の種類のトラフィックが共通のリソースを使用する場合に、競合する問題を解決します。

サーバーの最新モデルによっては、10Gbpsの物理NICを16個まで搭載することができるようになりました。16個もあれば、10Gbpsの物理NICを必要なトラフィックで占有できそうですね。参考までに、vSphere 6.5の10Gbps物理NICの最大構成数は、Intel製は16個、QLogic製またはEmulex製は8個です。

数年前までは10Gbps物理NICは2個が大半で、物理NICを共有する複数の種類のトラフィックをどのようにコントロールするかは設計者の腕の見せ所だったのではないかと思います。

また、Network I/O Controlバージョン2をお使いの方で、物理NICのコントロールはNetwork I/O Controlを、仮想NICのコントロール (制限) はトラフィックシェーピングを使用されていた方もいらっしゃったのではないかと思います。

バージョン3では物理NICおよび仮想NICのリソースコントロール機能を提供しています。ぜひこの機会に、Network I/O Control バージョン3の使いどころを知っていただけたら幸いです。

 

 

◆vSphere Network I/O Control バージョン2とバージョン3

vSphere 6.0から提供されたNetwork I/O Control バージョン3では、vSphere 5.5までのバージョン2にいくつかの機能を追加しています。バージョン2と3の違いを確認します。

 

<バージョン2>

バージョン2では、たとえば仮想マシンのネットワークトラフィックで、物理NICを対象に異なるコントロールを行いたい場合、ユーザー定義のネットワークリソースプールを使用します。

新規ネットワークリソースプールで、「制限」「シェア値」「CoS優先順位タグ」を指定します。作成したネットワークリソースプールを分散ポートグループに割り当てます。

 

 

 

 

 

 

 

 

 

 

 

 

<バージョン3>

バージョン3では、仮想マシンのネットワークトラフィックで、物理NICを対象にコントロールを行いたい場合は「仮想マシンシステムトラフィック」を、仮想NICを対象にする場合は「ネットワークリソースプール」または「仮想マシンの設定」を使用します。

ネットワークリソースプールを作成する前に、仮想マシンシステムトラフィックでバンド幅の予約設定が必要です。

 

◆システムトラフィックのバンド幅割り当て

システムトラフィックには、事前に定義された9つのトラフィックタイプがあります。

物理NICを対象に、「シェア」「予約」「制限」の設定値を使用して、各システムトラフィックにバンド幅を割り当てます。バージョン3から、設定値に「予約」が追加されました。

設定値 説明
シェア 同じ物理NICを使用するシステムトラフィックタイプの優先順位の相対的な比率です。低/標準/高/カスタム (1から100) を指定します。

たとえば、FTとiSCSIに100、それ以外には50のシェア値が設定され、対象の物理NICはFT/iSCSI/vMotion用に使用されているとします。

ある時点でFTとiSCSIの2つのトラフィックが物理NICの帯域を超えたら、各トラフィックは物理アダプタのバンド幅の50%を使用します。

ある時点で3つのトラフィックが物理NICの帯域を超えたら、FTとiSCSIに物理アダプタのバンド幅の40%、vMotionに物理アダプタのバンド幅の20%が使用されます。

予約 1個の物理NIC上で確保が必要な最小バンド幅 (Mbps) です。

すべてのシステムトラフィックタイプで予約される合計バンド幅は、物理NICのバンド幅の75%を超えることはできません。

制限 1個の物理アダプタでシステムトラフィックタイプが使用できる最大バンド幅 (MbpsまたはGbit/s) です。

 

下図は、vMotionトラフィックの設定の編集画面です。この分散スイッチには1Gbpsの物理NICが割り当てられています。

 

 

 

 

 

 

 

 

 

 

<10Gbps物理NIC上のシステムトラフィックのバンド幅予約例>

たとえば、次の予約設定によって、1つの物理NICを対象に、仮想マシン用の0.5Gbpsのバンド幅を確保できたことになります。

 

◆仮想マシントラフィックのバンド幅割り当て

仮想マシンを対象に異なるコントロールを行いたい場合には、「ネットワークリソースプール」を使用する方法と、仮想マシンの設定の編集で設定する方法の2つがあります。

設定値 説明
シェア 仮想マシントラフィックをネットワークに転送する物理NICのキャパシティに応じ、この仮想マシンの仮想NICを通過するトラフィックの優先順位の相対的な比率です。低/標準/高/カスタム (1から100) を指定します。
予約 仮想マシンの仮想NICが物理NIC上で受け取る必要がある、最小バンド幅(MbpsまたはGbit/s) です。

ネットワークリソースプールは予約 (Mbps) のみの設定です。

制限 同じESXiホストまたは別のESXiホストに配置されている他の仮想マシンへのトラフィックに使用できる、仮想マシンの仮想NIC上の最大バンド幅(MbpsまたはGbit/s) です。

 

 

<ネットワークリソースプール>

ネットワークリソースプールのバンド幅割り当ては、そのプールに関連付けられている分散ポートグループ間で共有されます。仮想マシンには、その仮想マシンが接続されている分散ポートグループを介して、ネットワークリソースプールからバンド幅が割り当てられます。

デフォルトでは、分散スイッチ上の分散ポートグループは、割り当てが構成されていない「デフォルト」と呼ばれるネットワークリソースプールに割り当てられています。

 

下図を例にすると、分散ポートグループAに接続される仮想マシンに割り当てられるバンド幅の合計が最小2Gbps確保 (保証) されます。

先に述べたように、ネットワークリソースプールを使用するには、仮想マシンシステムトラフィックで予約の設定をします。

下図は、仮想マシンシステムトラフィックの設定の編集画面です。物理NICのバンド幅の75%を超えない値を設定します。

 

下図は、新規ネットワークリソースプールの画面です。ここで予約値 (最小バンド幅) を設定します。最大割り当て値は、仮想マシントラフィックで設定した予約値×アップリンク (物理NIC) の数です。このアップリンク数は分散スイッチで設定した値です。

 

 

下図は、分散ポートグループの設定の編集画面です。ここで作成したネットワークリソースプールを割り当てます。

<仮想マシン>

各仮想マシンのバンド幅割り当ては、仮想マシンの設定の編集で行います。

「制限」と「予約」は、仮想NICが接続されている分散ポートグループのトラフィックシェーピングポリシーにも依存します。たとえば、トラフィックシェーピングポリシーで平均バンド幅を100Mbpsに設定したなら、仮想マシンの仮想NICの予約値によって仮想マシンが200Mbpsを要求したとしても、実際のバンド幅は100Mbpsになります。

下図は、仮想マシンの設定の編集画面です。ネットワークアダプタを分散ポートグループへ変更し、「シェア」「予約」「制限」を設定します。

 

◆仮想マシンバンド幅のアドミッションコントロール

仮想マシンに十分なバンド幅を確実に割り当てられるようにするため、バンド幅予約とチーミングポリシーにしたがい、ESXiホストおよびクラスタレベルでアドミッションコントロールを実装します。

仮想マシンをパワーオンすると、分散スイッチのNetwork I/O Control機能が、ESXiホストで次の条件が満たされることを確認します。

  • ESXiホスト上の物理NICが、チーミングポリシーと予約に従って、仮想NICに最小限のバンド幅を提供できる
  • 仮想NIC用の予約が、ネットワークリソースプール内の空き割り当て量より小さい

 

<vSphere DRSのバンド幅のアドミッションコントロール>

DRSクラスタ内の仮想マシンをパワーオンすると、vSphere DRSはアクティブなチーミングポリシーに従って、その仮想マシン用に予約されたバンド幅が確保されるキャパシティを持つESXiホストに、その仮想マシンを配置します。下図は極端な例です。

<vSphere HAのバンド幅のアドミッションコントロール>

HAクラスタ内のESXiホストでエラーが発生するかホストが隔離されると、vSphere HAはバンド幅予約とチーミングポリシーに基づき、HAクラスタ内の別のESXiホスト上で仮想マシンをパワーオンします。

 

 

◆まとめ

仮想マシン上のアプリケーションによっては、ネットワークリソースが競合した場合により多くのリソースを割り当てたい、最小限のバンド幅を割り当てたい等のご要望はあると思います。

Network I/O Control バージョン3であれば、これらの要望を仮想NICレベルで満たすことができます。CPUやメモリと同様のコントロール方法ですから、取り組みやすいと思います。予約は仮想マシンがパワーオンできない要因になりますから、その点は注意が必要です。

今回で分散スイッチの投稿は終了です。今後はNSXのご紹介を予定しています。ネットワークは詳しくないと思われているサーバー管理者の方がNSXを検討するなら、を前提に進めたいと考えています。引き続きよろしくお願いします。

仮想スイッチのお作法~分散スイッチの管理②#5~

5回目:仮想スイッチのお作法#5  (分散スイッチの管理②#5)

– Back Number –
#1…仮想スイッチのお作法#1
#2…仮想スイッチのお作法#2
#3…vSphere 6. 5の分散スイッチの機能とアーキテクチャ#3
#4…分散スイッチの管理①#4
#5…分散スイッチの管理②#5
#6…Network I/O Control#6

日本ヒューレット・パッカード株式会社の中川明美です。

5回目は、分散スイッチの障害からのリカバリ方法、vCenter ServerとESXiホスト間のネットワーク接続に問題が生じた場合の対処方法をおもにご紹介します。

◆分散スイッチのネットワーク構成のバックアップとリストア

分散スイッチのネットワーク構成のバックアップとリストアは、次の目的で使用します。

  • vCenter Serverデータベースの破損または誤った設定からの復旧
  • アップグレードでエラーが発生した場合に以前の設定へロールバック
  • 分散スイッチのコピーを作成するためのテンプレート

次の操作により、上記目的を達成します。

  • 非同期でディスク上へ分散スイッチ/分散ポートグループ/アップリンクポートグループ設定のバックアップ (エクスポート)
  • バックアップから分散スイッチ/分散ポートグループ/アップリンクポートグループを復旧 (リストア)
  • 変更後に以前の分散ポートグループ/アップリンクポートグループ設定にロールバック (リストア)
  • バックアップから新しい分散スイッチの作成 (インポート)

◆ネットワーク構成のバックアップ

<分散スイッチのバックアップ>

「設定のエクスポート」メニューで、分散スイッチ/分散ポートグループ/アップリンクポートグループの設定をバックアップします。

ここでは、分散スイッチのバックアップを行います。

「分散スイッチを右クリック → 設定 → 設定のエクスポート」を選択します。

次にエクスポート対象を選択します。

バックアップデータを保存して、終了です。

以前、vCenter Serverデータベースの障害により、複数のVLANを構成した分散スイッチにエラーが発生しました。再作成を前に、導入エンジニアが嘆いていたのを思い出します。

新規作成や構成変更のタイミングで、バックアップを取得しておくことは心の安定を得られますね。様々な設定を構成した分散スイッチのエラーを解消できず、最初から作成するのは心が折れます!

◆ネットワーク構成のリストア

設定ミスを想定し、次の内容に変更しています。

リストアは、分散スイッチ単位/分散ポートグループ単位/アップリンクポートグループ単位で行うことができます。

 

<分散スイッチのリストア>

分散スイッチ単位でリストアする場合は、「分散スイッチを右クリック → 設定 → 設定のリストア」を選択します。次にバックアップファイルとリストア対象を選択します。

<分散ポートグループのリストア>

分散スイッチのバックアップデータから、分散ポートグループのみをリストアすることもできます。リストアしたい分散ポートグループを右クリックし、「設定のリストア」を選択します。

次に、バックアップデータから戻すのか(「設定を次のファイルからリストア」)、正常に動作していた以前の設定にロールバックするのか(「以前の設定にリストア」)を選択します。

バックアップ時の設定に戻されているかは、「設定」 → 「ポリシー」で確認します。下の画面では、先のリストア操作で変更前の状態に戻っています。

 

◆分散スイッチのインポート

バックアップした構成ファイルのインポートから、「新しい分散スイッチの作成」「削除された分散スイッチの再作成」「アップグレードに失敗した分散スイッチの復元」を行うことができます。

また既存の分散スイッチに、エクスポートした分散ポートグループのインポートすることもできます。

ここでは分散スイッチのインポートを行います。データセンターを右クリック、「Distributed Switch」 → 「Distributed Switchのインポート」を選択します。

次に、バックアップファイルを選択します。再作成や復元をする場合は、「元のDistributed Switchとポートグループ識別子を保存します」オプションを選択します。

◆管理ネットワークのロールバックとリカバリ

管理ネットワークの構成ミスのためにvCenter Serverへの接続を失った場合、分散スイッチでは管理ネットワークのロールバックとリカバリを行うことができます。

<ロールバック>

ロールバックはデフォルトで有効の設定になっています。接続を失ったことを検知後、30秒 (デフォルトのタイムアウト値) でロールバックします。タイムアウト値の変更方法はKB2096691を参照ください。

分散スイッチのロールバックは、分散スイッチ/分散ポートグループ/分散ポートに不適切な変更が行われると自動で起動します。

ロールバックを無効にするには、vCenter Serverの詳細設定で「config.vpxd.network.rollback」を「false」にします。

<リストア>

ロールバックを無効にした場合や物理ネットワークの変更によって管理ネットワークに問題を生じた場合、ダイレクトコンソール ユーザーインターフェイス (DCUI) を使用して、管理ネットワークの復旧を行います。

DCUIには次の3つのリストア設定があります。

  • Restore Network Settings
  • Restore Standard Switch
  • Restore vDS

「Restore Standard Switch」「Restore vDS」は、分散スイッチで管理ネットワークが構成されている場合に選択可能になります。管理ネットワークが構成されていない場合はグレーアウト表示になります。

「Restore Network Settings」を選択し、次の画面で<F11>を選択すると、工場出荷時の状態に戻ります。

管理ネットワークの構成エラーから復旧する場合は「Restore vDS」を選択します。次の画面で、ポートバインドの方法を選択します。

分散スイッチを標準スイッチに復元する場合は「Restore Standard Switch」を選択します。

「Restore Standard Switch」を選択すると、IPアドレスを割り当てることができる新しいVMkernelポートと標準仮想スイッチがESXiホスト上に作成されます。分散スイッチのアップリンクは、新しい標準仮想スイッチに移動されます。

<KBのご紹介>

◆分散スイッチのアップグレード

アップグレード対象の分散スイッチを右クリックし、「アップグレード」 → 「Distributed Switchのアップグレード」を選択します。

アップグレードメニューには、他に「Network I/O Controlのアップグレード」「LACPサポートの強化」があります。

< Network I/O Controlのアップグレード>

Network I/O Controlをバージョン3へアップグレードすると、システムトラフィックおよび個々の仮想マシン (仮想NIC) へバンド幅割り当てることができます。#6で紹介します。

<LACPサポートの強化>

バージョン5.1の分散スイッチからバージョン5.5/6.0にアップグレードした分散スイッチで、拡張LACPサポートに変換すると、複数のLAGを作成することができます。

アップグレード前に分散スイッチで基本LACPサポートが有効になっていた場合、拡張LACPサポートへは手動で拡張します。

次の画面で、アップグレードするバージョンを指定します。

 

アップグレード前には、分散スイッチの設定のエクスポートをおすすめします!

 

◆まとめ

今回ご紹介した、「ネットワーク構成のバックアップとリストア」や「管理ネットワークのロールバックとリカバリ」は、バージョン5.1から提供されている機能です。分散スイッチはvSphere 4.0から提供されていますから、こなれた仮想スイッチではありますね。

10Gbpsの物理NICの使用が一般的となり、管理するESXiホストが増設され、分散スイッチを活用する機会が増えてきたのではないかと個人的には思います。

管理ネットワークを分散スイッチで構成するなら、設計も変わってきますよね。分散スイッチで管理ネットワークを構成し、接続が失われた時に慌てた方もいらっしゃると思います。実際に正常に復元するの?と問われたこともあります。事前の復元検証は必須かと思いますが、分散スイッチが提供する復旧機能をぜひ活用いただけたらと思います。

次回は、Network I/O Control バージョン3をご紹介します。

 

仮想スイッチのお作法~標準スイッチから分散スイッチへの道~

4回目:仮想スイッチのお作法#4    (分散スイッチの管理①#4)

– Back Number –
#1…仮想スイッチのお作法#1
#2…仮想スイッチのお作法#2
#3…vSphere 6. 5の分散スイッチの機能とアーキテクチャ#3
#4…分散スイッチの管理①#4
#5…分散スイッチの管理②#5
#6…Network I/O Control#6

日本ヒューレット・パッカード株式会社の中川明美です。

4回目は、分散スイッチの特長であるポートの管理機能および分散スイッチで提供されるアラームや権限付与についてご紹介します。

◆ポートバインド

「ポートバインド」設定によって、仮想マシンの仮想NICを分散スイッチのポートに割り当てるタイミングと方法を指定します。ポートバインドは分散ポートグループで設定します。

下図は、仮想マシンの分散ポートグループの編集画面です。

ポートバインドには、次の3つのオプションがあります。

  • 静的バインド (デフォルト設定)
  • 動的バインド (ESXi 5.0から廃止)
  • 短期-バインドなし

「静的バインド」と「短期-バインドなし」の違いをまとめます。

<KBのご紹介>Choosing a port binding type in ESX/ESXi (1022312)

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

<参考>標準スイッチのポート数

ESXi 5.5以降の標準スイッチのポート数は、分散スイッチのポート割り当ての弾性と同様に8個ずつポートが追加されます。標準スイッチではポートバインドはされません。

標準スイッチは、ESXiホストでサポートされているポートの最大数まで拡張できます。vSphere 6.5の標準スイッチ1台あたりの最大作成ポート数は4,088です。

◆ポート単位の管理

分散スイッチでは、ポート単位でポリシーを設定することができます。

下図は分散ポートグループの編集画面です。「詳細」ページで、各ポリシーのオーバーライドを「許可」に設定します。この設定により、分散ポートグループのポリシーをポートのポリシーで上書きすることができます。

下図はアップリンクチーミングでオーバーライドの許可をした後のポート0の編集画面です。

許可していない項目はオーバーライドを選択することができません。

◆アップリンクポートの管理

分散スイッチでは、アップリンクポートグループやアップリンクポート単位でポリシーを設定することもできます。

下図はアップリンクポートグループのオーバーライドを設定する画面です。この画面でベンダー設定を「許可」にすると、「VLAN」「NetFlow」「トラフィックのフィルタリングとマーキング」に対して、一度にオーバーライドの許可を行うことができます。

◆監視機能

監視機能には、「NetFlow」「ポート状態の監視」「アラーム」があります。

<NetFlow>

NetFlowを有効にすると、分散ポートグループのポートまたは分散ポートを通過するIPパケットを監視することができます。

分散スイッチでNetFlowの構成をする場合は、分散スイッチの設定で、「NetFlow」を選択し、「編集」をクリックします。

編集画面で、コレクタのIPとポート番号を指定します。コレクタから分散スイッチを識別できるように、スイッチIPアドレスに分散スイッチ用のIPアドレスを指定します。

<ポート状態の監視>

「ポート状態の監視を開始」アイコンをクリックすると、ランタイム統計情報を表示することができます。

<アラーム>

分散スイッチでは、「分散スイッチ」「アップリンクポートグループ」「分散スイッチポートグループ」で、新しいアラームを定義することができます。標準スイッチでは定義することはできません。

下図は分散スイッチの新しいアラームの定義を設定する画面です。

<参考>

パケットのキャプチャ用のコマンド「pktcap-uw」をご紹介します。

下図はVMkernelアダプタの「vmk0」をキャプチャした画面です。他に物理アダプタ、vmxnet3仮想マシンアダプタ、ドロップされたパケットのキャプチャを行うこともできます。

3パケットの内容を保存し、Wiresharkなどのツールで表示することもできます。

◆まとめ

4回目は、分散スイッチの分散ポートにフォーカスし、どのような機能があるのかをご紹介しました。物理スイッチの運用管理をされている方には、ポートを番号で管理するのは当然と思われるかもしれませんが、仮想スイッチも分散スイッチなら可能です。

今回ご紹介した機能は、私がインストラクターをしていた時に、「仮想スイッチで〇〇の機能はありますか」とご質問いただいた機能でもあります。

標準スイッチをお使いの方は、運用の効率性もふまえ、分散スイッチの使用をぜひご検討いただけたらと思います。

VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化(9)

コンバインモードの正しい理解と知っておきたいこと

 

トレンドマイクロ VMwareテクニカルアライアンス担当 栃沢です。

前回、DSVADSAの使い分けについて解説をしましたが、Deep Security Virtual ApplianceDSVA)で保護しているESXiホスト上にDeep Security Agent(DSA)がインストールされたWindows仮想マシンが配置された場合、Deep Securityでは“コンバインモード”というモードで動作します。
コンバインモードについては、誤解しやすい点もあるので、今回はその正しい理解と抑えておいていただきたい点をまとめてお伝えしたいと思います。

 

コンバインモードの有効化と状態

前回のブログにも書きましたが、コンバインモードが有効化されるのはWindows仮想マシンのみとなります。
コンバインモードを有効にするために必要な設定は特段ありません。対象の仮想マシンが DSVA で保護可能な状態になっており、かつDSA がインストールされていると自動的にコンバインモードによる保護が有効になります。そして、コンバインモードが有効になるのはWindows OSのみです。(前回も解説しましたが、設定が特に必要ないという点では、DSAをインストールしたLinux OSをDSVAが稼動しているESXiホスト上で動作させる際にDSAでの保護が自動的に継続されることと共通しています。詳細は前回ブログをご確認ください。)

コンバインモードで動作していることは、Deep Security ManagerDSM)コンソール、DSAがインストールされたWindows OSのタスクトレイから確認することができます。

Deep Security Managerコンソール

■Deep Security Agentタスクトレイ

 

コンバインモードのアフィニティルール

コンバインモードでは、機能群ごとにDSA、DSVAどちらの防御コンポーネントで保護を実施するか(保護ソース)選択できるようになっています。
デフォルトでは以下のように動作するように設定されています。

  • 不正プログラム対策                 Appliance優先
  • Web レピュテーション/ファイアウォール/侵入防御   Agent優先
  • 変更監視                      Appliance優先

DSVAで対応していない機能であるセキュリティログ監視、アプリケーションコントロールは、DSAでの保護となるためコンバインモードのアフィニティルールの設定項目はありません。
また、コンバインモードはDeep Security 9.6から実装された機能ですが、アフィニティルールをデフォルトの設定から変更できるのはDeep Security 10.0以降になります。

機能群毎に選択できるコンポーネントの保護ソースの選択には以下の4つがあります。

  • Appliance 優先 : Appliance 有効化不可時に Agent にてセキュリティ機能を提供
  • Agent優先   : Agent 有効化不可時に Appliance にてセキュリティ機能を提供
  • Appliance のみ : Appliance 有効化不可時に Agent でのセキュリティ機能の移行を行わない
  • Agentのみ   : Agent 有効化不可時に Appliance でのセキュリティ機能の移行を行わない

このアフィニティルールの設定は、利用したい機能と仮想マシンに対するDeep Securityの機能利用による負荷を考慮して適宜変更することが可能です。

 

コンバインモードの保護ソースの変更のトリガー

Appliance優先、Agent優先を選択した場合、選択された保護ソース(DSVAまたはDSA)が無効化された場合に、もう一方の保護ソース(DSAまたはDSVA)に保護機能を移行するためのDSMからポリシーの配信が実行され、保護ソースが変更されます。各機能のステータスにエラーがあった場合などに保護ソースが変更されるようなフェイルオーバー(エラーに備えた冗長化)には対応していませんので、留意してください。

 

コンバインモード利用にあたって知っておくべきこと

コンバインモードの利用にあたって、知っておいて頂きたい点をいくつか挙げておきたいと思います。

  • Appliance優先、Agent優先を選択した場合、前述のとおりDSMからのポリシー配信が実行されます。Appliance優先でAgentに保護ソースが切り替わった場合、該当の機能モジュールがインストールされていない場合、機能モジュールのインストールが行われた後、ポリシーの配信が行われます。コンバインモードの保護ソース変更時にモジュールの自動インストールをさせたくない場合にはあらかじめ機能モジュールをインストールしておくか、Applianceのみを選択する必要があります。
  • コンバインモードでは、DSVA による保護を仮想マシン単位で無効化することはできません。
  • Deep Security Virtual ApplianceのCPU課金、かつ、侵入防御・ファイアウォール・Webレピュテーションを利用できるライセンスをご購入いただいている場合に限り、DSAで上記の機能を実装することが許諾されています。(vShield Endpoint環境でDSVAを利用していた場合に利用できた機能をDSAにて補完するための措置)ライセンスの詳細はこちらをご覧ください。

まとめ ~ DSVAとDSAを使い分ける上でのポイント

コンバインモードについてご理解をいただけたでしょうか?
少し複雑な部分もありますが、ポイントを抑えてコンバインモードもうまく活用を頂ければと思っております。
コンバインモードについてはこちらのFAQにも記載されておりますので、ご参照ください。

 

執筆者:
トレンドマイクロ株式会社
セキュリティエキスパート本部
パートナービジネスSE部 パートナーSE2課
栃沢 直樹(Tochizawa Naoki)

 

【VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化】

    1. Horizon インスタントクローンにも適用可能!仮想デスクトップ環境にフィットしたセキュリティ対策
    2. VMware NSX + Deep Secuirty連携によるエージェントレスセキュリティとは?
    3. VMware NSX + Deep Security連携にかかわるコンポーネントと基本構成
    4. VMware NSXとDeep Securityのユースケースと実現できることとは?
    5. エージェントレス型ウイルス対策のアーキテクチャ(1)
    6. エージェントレス型ウイルス対策のアーキテクチャ(2)
    7. エージェントレス型による侵入防御/Webレピュテーションの実装
    8. エージェントレス型とエージェントレス型の使い分けのポイント
    9. コンバインモードの正しい理解と知っておきたいこと
    10. エージェントレス型セキュリティ環境におけるWindows 10 Creators Updateの対応

 

新卒 SE 社員が贈る NSX のキソ!第 8 回~Cross-vCenter NSX で実現するマルチサイト環境~

おひさしぶりです。第 1 回からご無沙汰しておりました大田です。
この回は最終回になります。「新卒 SE 社員が贈る NSX のキソ!」最終回のテーマはこちら!「Cross-vCenter NSX」
うわ、なに Cross て!ていうかもう NSX Data Centerでなにができるかわかったんだけどまだあるの?サンプル構成完成したじゃん!
そうです、まだあるのです。皆様はまだ NSX Data Center の最強奥義を知らないのです。最終奥義を習得しないと、この NSX Data Centerアドベンチャーは全クリできません!それはもったいない!あれ、何の話でしたっけ。とにかく、最後に Cross-vCenter NSX を理解して、気持ちよく終わりましょう。

1. 一般的な企業の事情
世の中には色々な事情がありますが、企業にも当然色々な事情があります。

事情① 災害が起きた時も事業を継続するための対策考えなきゃ!
事情② 海外にも事業を展開してガンガン成長するぞ!
事情③ 買収だ!合併だ!てんやわんや!
事情④ 古いデータセンターから新しいデータセンターに移行しなきゃ(汗)
事情⑤ あっちとこっちに 2 個データセンター持ってるけど、あっち余裕そうだからちょっと使わせてほしいなー。。

。。。と、このような事情から、企業はすでにマルチサイトでデータセンターを複数もっていたり、あるいはマルチサイトでデータセンターがほしくなったりするわけです。そして、すでに持っている場合にも、これからほしいという場合にも、いずれにせよせっかく複数あるのだからたとえ災害対策用だけにあるサイトだとしても Active-Standby ではなく Active-Active で上手いこと日ごろからサイトを意識せずに仮想マシン(以下 VM)を稼働させてどちらのサイトも有効活用できないかなと思うところではないでしょうか。

図 1 複数拠点のデータセンターの扱い

ということで、従来の別々のデータセンターをそのまま利用しようとしたら、どのような問題が生じるかといいますと、

・サイトをまたいだ vMotion には IP アドレスの変更が必要→システム停止
・IP アドレスの変更に伴い物理ネットワーク構成やロードバランスの設定変更が生じることも
・セキュリティポリシーは手動で同期したり、vMotion 時に設定変更の必要が生じたりする

といった具合に、サイト内の仮想マシン移行なら難なくできるどころかもはやこっちがvMotion しているつもりがなくても勝手に物理サーバの負荷を見て vCenter がよしなに vMotion してくれているくらいなのに、ネットワークをまたいでサイト間でワークロードを移行しようとした途端に影響範囲が物理構成やセキュリティ設定まで非常に大きい話になってしまい、一言で言うと「こんなのやだ!」といった状況でした。

図 2 データセンター間のワークロード移行

2. 従来のマルチサイトソリューション
では、今まで「こんなのやだ!」で終わりにしていたのかといいますと、そうではありません。データセンター内では簡単に移行でも負荷分散でも何でもできるんだからということで、複数サイトをまたいでも、まるで 1 つのデータセンターかのように扱えるように工夫しよう!ということで、L2 ネットワークを延伸しデータセンター間で 1 つのネットワーク環境を作るための様々なソリューションが生まれました。そんな今までの文明の利器を軽くご紹介したいと思います。突然専門用語が出てきたりしますが、「実に興味深い」程度でスルーしていただいて大丈夫です。

① キャリアの広域 Ethernet サービス+STP

図 3 キャリアの L2 サービスを借りるの巻

通信キャリアが提供する L2 サービス(広域 Ethernet)を使用するというのはどうでしょう。うんうん、L2 サービスね、、、ん?なんか赤字の Block Port っていうのが気になりますね。今この図、なんで黄緑の線が 2 本あるのかというと、1 本だと物理的な障害が起きた時に一発アウト!…っていうのを防ぐためです。こうやって物理障害対策で冗長構成を取ると、L2 のEthernet フレームはその仕組み上延々とループしてしまうことがあり、それを防ぐためにはこのようにBlock Port を作らなくてはならないのです。この技術を STP (スパニングツリープロトコル)といいますが、ざっくり言うとこちら管理がすごく大変です。これが 3 拠点とかになっちゃったら、もっと大変です、つまり拡張性に欠けています。しかもそもそも、Block Port の存在自体、Mottainai!そして設定ミスか何かでもしサイトをまたいだ広範囲でループを起こしたら、つまりブロードキャストストームを起こしたら、、、全シャットダウンで大惨事、なんてこともありえるのです。L2 サービス自体には様々なメリットもあるかと思いますが、大切なデータセンター間を STP で直接 L2 接続っていうのは、あまり現実的ではないでしょう。

② キャリアサービス or ダークファイバの上で専用のハードウェアによるオーバーレイの実装

図 4 専用ハードウェアによるオーバーレイ

こちらもまずはキャリアのネットワークを借りるか、ダークファイバというただの線を借りてネットワークを構築し、その上にオーバーレイネットワークを、秘密道具、「専用ハードウェア」によって構築する(例:MPLS/VPLS or EVPN ・ OTV)という方法です。つまりやりたいことはハードウェアがやってくれますが、ハードウェアを購入する手続きとか、サポートの期間とか、なんだか腰が重いですね。。。やっていることといえば、片方のサイトで作られた Ethernet フレームにさらにヘッダをかぶせてなにかのプロトコルでなんやかんやで宛先のサイトにお届けして、ついたところでしれっとヘッダを外し、宛先のサイトからしたら、これまで IP ヘッダやら MPLS のラベルやらつけられていたことなどつゆ知らずのんきに Ethernet フレームを受け取り、はい、L2 延伸のできあがり~、、と、第 4 回でもお伝えしたトンネリングの技術です。

このように 2 つの手法をご紹介させていただきましたが、何か思いませんでしたか?この 2 つ、どちらも物理ネットワークの世界でなにかしら頑張っているんですね。①だと L2 ネットワークの上で頑張って STP を設定する、②だと専用のハードウェアに物理ネットワークのトンネリングを頑張ってもらう。。。でももっとシンプルに、それぞれのデータセンター内で設定をいじっただけでそのデータセンター同士が L2 でつながっちゃった、みたいな、お手軽なこと、ソフトウェアで頑張れないの?って思いませんか?だって NSX Data Centerでネットワークは仮想化されて仮想環境内にソフトウェアで定義されてるんですし、物理ネットワークを延伸するんじゃなくて、それぞれのデータセンターで仮想化されたネットワークをデータセンター同士でソフトウェア的につながっていると認識してくれればよくない?と。はい、お察しの通り、それを実現できるのが Cross-vCenter NSX の機能となりますので、前置きが長くなりましたが本題に入りたいと思います。

3. Cross-vCenter NSX 概要
Cross-vCenter NSX とはズバリ、「複数サイトをまたいで 1 つの仮想ネットワーク環境を構築することを実現する NSX Data Centerの機能」です。言葉では伝わりにくいので、図にします。

図 5 物理ネットワーク延伸

今まで L2 延伸をしようとしたら、物理ネットワークを延伸しようとするので、物理ネットワークの領域でがちゃがちゃと工夫をする必要がありました。

図 6 仮想ネットワーク延伸

NSX Data Centerでは、ネットワークは物理ではなく仮想環境で定義されていますので、物理的に頑張る必要はありません。サイト 1 に存在する仮想的なネットワークセグメントが、サイト 2 にも仮想的に存在すればいいのです。このようなことは、ネットワークが仮想化されなければ不可能であり、逆に言えば、ネットワークが仮想化された環境においては当然ともいえる仕組みではないでしょうか。

と、ここまで物理ネットワークの延伸と仮想ネットワークの延伸の比較という観点でご説明してきましたが、前回まで説明していた NSX Data Centerのネットワーク世界の観点で図にすると、次のようになります。
まず、NSX Data Centerを各サイトに導入しているものの、Cross-vCenter NSX の機能は使用しないといった場合、このような図になります。

図 7 Cross-vCenter NSX 以前

それと比較して、Cross-vCenter NSX を導入した環境は、このような構成となります。

図 8 Cross-vCenter NSX 以後

前回までは、1 つの vCenter 配下に、NSX Manager と NSX Controller がそれぞれ存在し、ルーティングや FW ルールの情報については 1 つの vCenter 配下で完結しておりました。
Cross-vCenter NSX では、1 つのサイトの NSX Manager がプライマリロールを持ち、ルーティングや FW ルールの情報をほかのサイトのセカンダリ NSX Manager と同期し、1 つの NSX Controller クラスタが複数サイトにまたがって一貫したルーティング情報や FW ルールの情報をすべてのホストにプッシュするといった形になり、サイト 間で情報の一貫性を保ちます。これらの設定は、全て今まで通り、vSphere Web Client のコンソールから設定をポチポチするだけで実現でき、物理ネットワークの設定や構成は全く触る必要がありません!(サイト間で物理的にルーティングが可能であることは前提となりますが。)この「L2 延伸をソフトウェア的な設定だけでお手軽に実現できる!」ということ自体が、従来の物理的な L2 延伸の費用や大がかりな作業を削減するという意味で Cross-vCenter NSX のすごいメリットとなります。

4. Cross-vCenter NSX の使いどころ
ということで、L2 延伸それ自体について、従来との比較をさせていただきましたが、Cross-vCenter NSX を導入する気になりましたか?。。。。。。実際に Cross-vCenter NSX を導入して、どんなことを実現できるのかがわからないと、わざわざ Cross-vCenter NSX なんてしませんよね。ということで、ここからは Cross-vCenter NSX がどんな場面で力を発揮するのか、しっかりお伝えしたいと思います。

その 1:災害用サイトリソースの有効活用
たとえば、東京にデータセンターを持っていて、東京でなにか災害があったときのために、東京ではないどこかにもデータセンターをもっているとしましょう。

図 9 災害用のマルチサイト構成

従来でしたら、普段のデータセンターと災害時用データセンターはネットワーク的に完全に違うセグメントにおり、災害が起きた時だけアクセス先をバシっと切り替える形になりますが、普段は災害時用のサイトは完全に災害に備えて静かにスタンバっているということになります。これ、もったいなくないですか?こう、うまいこと工夫して、災害時の事業継続性も確保しつつ、2 つのデータセンターのリソースをもっと活用できないですかね?うーん、、、、あ、こんなのはどうでしょう。

図 10 システムごとにアクティブとなるサイトを分散

このように、システムごとにアクティブになるサイトをばらけさせる方法がとれると思います。これなら、どちらかのサイトが障害にあったときに、生きている方のサイトで元々稼働していた VM は引き続きそちらで稼働し、障害にあった VM のみリカバリさせればいいですね。でも、これ、どこに Cross-vCenter NSX を活用する必要があるんでしょう?
1 つ目に、障害時のサイト切替にあたって、VM の IP アドレスを変更する必要がないというところがポイントになります。今まででしたら、別サイトでリカバリする際に、別サイトは違うセグメントになるので、切替用の IP アドレスを事前に設定する必要がありましたが、これからは単純にサイトが変わるだけでネットワーク的な変更は無し、ということになり、よりリカバリ作業が単純な話になります。
2 つ目に、今までだと FW ルールがサイト間で共有されず、サイト障害に備えてどちらのサイトにも同じ FW ルールを設定する必要がありました。こちら、口だけで言うと簡単そうですが、L2 延伸無しの場合 VM が移行先で IP アドレスを変更しているので、単純に FW ルールをコピーすればいいという話ではないのです。そのような状態で図 10 のような構成をしようとしたら、どうでしょう?えーと、システム A は災害用サイトではこんな IP アドレスで、セキュリティポリシーは、、、といった設定を、2 つのサイトでシステムごとにごちゃごちゃ計画・実施しなくてはならないんですね。そもそも、災害対策なんて、実際に災害が起きた時にしか必要ないしコストでしかないのに、こんなに苦労したくないというのが企業の本音ですよね。

その 2:マルチサイトでかしこく経路選択
以前にもご紹介した、NSX Data Centerの賢いルーティング経路選択について、サイトをまたいだ場合にはどうなるのか、ご紹介します。

図 11 マルチサイトのネットワーク

図 11 は、マルチサイトにおけるネットワークを少々詳しく表しております。ユニバーサル分散論理ルータは、今までご紹介した分散論理ルータと同じ役割をもち、この図に 1 つ書いてある NSX Controller Cluster が、別サイトのホストにも同じルーティング情報を一生懸命お届けしております。

図 12 別サイトに移行したい VM

注:DGW=Default Gate Way, UDLR=Universal Distributed logical router(ユニバーサル分散論理ルーター)

さて、ここで落ち着きのない VM 君が現れたようです。どうやら今いるサイトでリソースが足りてなくて、もう 1 つのサイトに移動したいようです。この VM のネットワーク設定において、デフォルトゲートウェイはいつでもどこでも分散論理ルータになります。そう、たとえサイトを移動しても、この VM がおしゃべりしたいエンドポイントとセグメントをまたいだ通信をするには、VM が送信したパケット君は、分散論理ルータ、つまり VM がそのとき乗っているホストにこう聞くのです。「ネクストホップはー?」

仮にこの VM がインターネット上のエンドポイントと通信したいとしましょう。インターネットにいくには、パケット君は一度仮想環境から脱出しなくてはなりません。仮想環境と物理環境の窓口は Edge ルータになります。ここで問題です、インターネットに出るためには、もし VM 君が別サイトに移行しても、同じ Edge ルータを通る必要があるでしょうか??

図 13 移行した VM の物理ネットワークへの出口

答えは NO です。ユニバーサル分散論理ルータは、どのホスト上でも冷静にルーティングします。インターネットに出たいなら、普通にその VM がいるホストから 1 番いきやすく、インターネット上のエンドポイントにパケット君が最短で到着できる Edge にルーティングするのです。これ自体はルーティングという観点でいうとごくごく普通の話ですが、従来こんな風に分散してルーティングする機能なんてありましたっけ?この機能があるから、移行しても変わらず VM 君のデフォルトゲートウェイはホスト上に散らばっている分散論理ルータの IP アドレスのままでいいのです。しかし物理環境へのゲートウェイという意味だと、VM の設定は変えずに、勝手に最適なゲートウェイが選択されるという意味で、まるで VM のゲートウェイ設定が自動で適切に変更されているようですね。この機能、あたりまえのようで、あたりまえではないのです!

5. さらなるポイント:ハイブリッド環境の将来像
最近ハイブリッドクラウド環境に移行している企業は多くあると思います。移行作業、大変じゃないですか?FW ルールなど色々な設定をパブリッククラウド側で用意して、移行して、IP アドレスとかデフォルトゲートウェイとか設定しなおして、、、って、VM たちがめっちゃダルがっていますね既に。オンプレミスとパブリッククラウドをまたいで NSX Data Center で 1 つの仮想ネットワークを構築すれば、VM にとってパブリッククラウドへの移行はホスト間の vMotion となんら変わらなくなります。ユーザーからしても当然 VM 自体にネットワーク的にも FW ルール的にもなんの変化もないのですからハイブリッド環境であるからといって気にしなければならないことがなくなります。このようなことは、クラウドプロバイダーの IaaS を利用してオンプレミスと IaaS 間で NSX Data Centerを構築すれば実現可能です!これを活用すれば、移行作業の計画に長い間骨を折るのではなく、Cross-vCenter NSX の構築さえすれば移行自体は通常の vMotion と変わらないスタンスで実行することができますね。
また、パブリッククラウドを活用し、インフラ管理から解放されるということ以外のもう一つの重要なメリットとして、必要なときに必要な分だけ使って、従量課金ができるというポイントがありますので、これについて考えてみましょう。ある一定の時期だけめちゃくちゃ利用負荷が増える Web サーバーがあったとします。例えばキャンペーン中だけアクセスが 10 倍になるとか。こんなとき、その 10 倍のアクセスに備えて自社のデータセンターに 10 倍のアクセスが必要になったときに必要なリソースを常にスタンバらせておきたいですか?普段全然使わないのに。うーん、、嫌ですね。絶対嫌だ!じゃあ、パブリッククラウドをその時だけ使えばよくないですか?
でも、簡単にはいかないですよね。だって、リソースが足りなくなりそうになったらパブリッククラウドに移行するっていったって、IP アドレス体系変えなきゃだし、Web サーバだけ増やしたいのに IP アドレス体系変えたら App サーバに通信できるようにルーティング設定しなきゃ。FW ルールだって事前にパブリッククラウド側にも準備しておかなきゃ。。。
こんなとき、もしオンプレミス環境と従量課金のパブリッククラウド環境を、先ほどご紹介したサイト間 L2 延伸と同様につなぐことができたら、こうなります。

図 14 VM にとってオンプレミスかパブリックか全く関係ない様子

いやいや、こんなこと、ほんとにできるの?と、この雑すぎる図解を見る限りでは到底真に受けられないかと思いますが、実際にすでにこのようなことが我々のテクノロジーで実現が可能になってきております。Cross-vCenter NSX でマルチサイト間で実現していることと同様に、パブリッククラウドと複数サイトのオンプレミスを含めて統合的なネットワークやセキュリティポリシーで管理運用できる将来もすぐそこに実現できる段階にきつつあります!弊社の Vision としては、このようにサーバやストレージ、ネットワークといった物理インフラ環境に左右されない柔軟な世界を創りたく、さらに将来的にはパブリッククラウドすらも自由に選択できるような、人間様のご都合に難なく適応してくれるインフラ環境を作るべく絶賛奮闘中です!乞うご期待!

6.おわりに
さあ、遂に最終回もまとめに入ってしまいましたが、この回はお伝えしたことが多かったので内容を整理したいと思います。

まず初めに、企業が複数データセンターを持つにいたる事情を色々と上げさせていただきました。
次に、複数データセンターをひとまとめに扱うために、従来物理ネットワークの範疇でお金や手間をかけて頑張らなくてはならなかったということをお伝えしました。
そして、Cross-vCenter NSX では複数データセンターをソフトウェア的に 1 つのデータセンターのように扱うことが可能になるということをご紹介し、それ自体が従来の手間と比較してメリットになるということと、L2 延伸、FW ルールの共有によってワークロード移行の手間が軽減され災害対策の工数の簡素化やリソースの有効活用、そして経路選択の最適化といった具体的なメリットもご紹介させていただきました。実のところ、ユースケースとしてお伝えできることはまだまだたくさんありますが、今回はぐっとこらえて、皆様の探求欲、クリエイティビティを刺激したところで締めさせていただきたいと思います。最後の最後になりましたが、この冊子では、NSX という名の下の NSX Data Center for vSphere について解説してきました。実は NSX SD-WAN、NSX Cloud、NSX Hybrid Connect、など続々と仮想ネットワークを支える NSX ファミリーが弊社のラインナップに加わっております。こちらの最新情報もぜひチェックしていただき、VMware NSX による仮想ネットワークの最先端を一緒に突っ走りましょう!それでは、またいつか!

-VMware SE 大田愛里香