Home > Blogs > Japan Cloud Infrastructure Blog > 月別アーカイブ: 2018年6月

月別アーカイブ: 2018年6月

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

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の対応
    11. 分散ファイアウォールと連携したマルウェア検出時の自動隔離
    12. Cross-vCenter NSX 環境における Deep Security の構成ベストプラクティス

 

新卒 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 大田愛里香

新卒 SE 社員が贈る NSX のキソ︕第 7 回〜NSX Edgeが提供する各種ネットワーク機能〜

こんにちは!「新卒社員が贈る NSX のキソ!」第 7 回を担当する VMware 新卒第 4 期生の村田太郎です。
6 回では、NSX Data Center for vSphere の特徴的な機能である、分散ファイアウォールについてご紹介いたしました。この回では、NSX Data Center が提供する各種ネットワーク機能についてご紹介いたします。

NSX Data Center を導入した vSphere 環境では、NSX Edge を用いることで、ファイアウォール、ロードバランサ、DHCP、NAT などの各種ネットワーク機能を統合的に実現することができます。

今までの仮想環境では、仮想マシンの展開スピードにネットワークの構築が追い付けないという問題がありましたが、今回ご紹介する NSX Data Center の機能を用いることで、仮想マシンの展開スピードに合わせたネットワークの展開が可能になります。サーバ仮想化は、NSX Data Center によるネットワークの仮想化と合わせて使用することで、その真価を発揮すると言えます。

NSX Edge は、5 回でもご紹介した通り、仮想アプライアンスとして簡単に展開することができますので、必要なときにほぼリアルタイムでネットワークサービスを展開することができ、スケールアウトも簡単に実施することが可能です。

システムの運用を進めるにつれてネットワークのパフォーマンスが足りなくなってきた、といった場合、物理機器の買い替えはなかなか難しく、購入しても実際に届くまでには時間がかかりますが、NSX Data Center を利用している環境では NSX Edge の設定を変更するだけですぐに対応することができます。

役割 提供する機能
ルーティング 静的、動的(OSPF、BGP)ルーティング機能
ファイアウォール IP や Port に加え vCenter インスタンスベースで設定できるFW機能
NAT/NAPT 送信先、送信元の NAT 機能
DHCP DHCP サーバ機能、DHCP リレー機能
ロードバランサ TCP/UDP、HTTP、HTTPS サーバ負荷分散機能
IPsec VPN IPsec によるサイト間の VPN 機能
SSL VPN リモートからの SSL VPN アクセス機能
L2 VPN L2 延伸機能

 

それでは、簡単に NSX Data Center の提供する機能についてご紹介いたします。

 

1. ファイアウォール
第 6 回でご紹介した分散ファイアウォールに加え、NSX Edge による境界型ファイアウォールも提供可能です。NSX Edge は、主に North-South トラフィックフローに対するファイアウォール機能を提供します。

NSX Edge のファイアウォールでも、6 回の 2 節でご紹介した分散ファイアウォールと同様に、IP アドレスによる指定だけでなく、vCenter のオブジェクト単位でルールを作成することができます。

vCenter のオブジェクト単位で設定が可能であるということは、例えば「仮想マシン A から仮想マシン B への通信を禁止」というような設定ができるということです。仮想マシンの IP アドレスが変わったり、 vMotion などによって利用する物理ポートが変わったりしてもファイアウォールルールが仮想マシンに追従できるというメリットがあります。

図 1 Edge FW の設定画面

 

2. NAT/NAPT
NAT/NAPT(Network Address Translation/Network Address and Port Translation)は、IP アドレスを変換する機能です。IP アドレスを節約したい場合や、外部に社内 IP アドレスを公開したくない場合、システム統合時のテナント間での IP 重複を回避する場合などに用いられます。

NSX Edge では、NSX Edge を経由する通信に対して、SNAT(送信元 NAT)と DNAT(送信先NAT)を提供することができます。SNAT は送信元の IP アドレスを変換する機能、DNAT は送信先の IP アドレスを変換する機能です。

 

図 2 Edge NAT の設定画面

図 3 SNAT の動作

図 4 DNAT の動作

 

3. ロードバランサ
NSX Edge ロードバランサでは、アプリケーション要求、サービス要求をプール内の複数のバックエンドサーバ間に分散することができます。ロードバランサを使用する際には、ユーザがアクセスする際に使用する VIP アドレス(仮想 IP アドレス)と、実際にサービスを提供するサーバのプールを用意します。
例:VIP アドレス – 192.168.1.1 ポート 80、サーバプール – 10.10.10.1 から 10.10.10.3

NSX Edge ロードバランサでは以下のようなプロトコル、機能が提供されます。

NSX Edge ロードバランサの機能 内容
サポートされるプロトコル TCP/UDP

HTTP

HTTPS (SSL パススルー)

HTTPS (SSL オフロード)

ロードバランシングの方法 ラウンドロビン

送信元IP のハッシュ

最小接続数

URI/HTTP ヘッダ/URL

 

NSX Edge ロードバランサのデザインとしては、ワンアームロードバランサとインラインロードバランサの 2 種類が存在します。

図 5 ワンアームロードバランサ

ワンアーム構成では、NSX Edge はロードバランス対象の仮想マシンと同じセグメントに存在し、その名の通り、ネットワークと 1 つのリンクでつながるデザインとなります。

アクセスの流れは以下のようになります。
① 外部クライアントからロードバランサによって外部に公開されている VIP アドレスにパケットを送信する。
② ロードバランサはクライアントから受け取ったパケットに対しアドレス変換を行い、送信元 IP アドレスをロードバランサのアドレスへ、送信先 IP アドレスを VIP からサーバプール内の 1 台のサーバの IP アドレスに変換します(SNAT/DNAT)。
どのサーバが選択されるかは設定されたアルゴリズムによって異なります。
③ パケットを受け取ったサーバは、クライアントへのパケットをロードバランサに送信。
④ ロードバランサは再度 SNAT/DNAT を行い、送信元を VIP、送信先を外部クライアントとしてパケットを送信します。

ワンアーム型のロードバランサは、展開と構成がシンプルで、既存の NSX Edge に手を加えずに済む、ロードバランサの障害時の影響範囲が少ないなどのメリットがあります。

図 6 インラインロードバランサ

インライン構成では、NSX Edge をサーバプールのセグメントと外部セグメントとの境界に配置し、2 つのリンクでそれぞれに接続するデザインとなります。

インラインロードバランサ利用時のアクセスの流れは以下のようになります。
① 外部クライアントは、ロードバランサによって外部に公開された VIP アドレスにパケットを送信します。
② ロードバランサは DNAT により外部クライアントから受け取ったパケットの宛先を VIP から設定されたアルゴリズムに従いサーバプールに展開されているサーバの内の 1 台の IP アドレスに変換します。
③ サーバは、元のクライアントの IP アドレスを宛先 IP アドレスとして、ロードバランサにパケットを送信します。これは、上記の構成では NSX Edge ロードバランサがインラインで展開されており、サーバのデフォルトゲートウェイであるためです。
④ ロードバランサはサーバから受け取ったパケットに対して SNAT を実行し、送信元を自身の VIP に変換したうえで外部クライアントに送信します。

ワンアーム型との違いは、インライン型の場合はサーバにクライアントのアドレスが透過的であるということが挙げられます。また、インライン構成では内部セグメントと外部セグメントの中間にロードバランサが配置されるので、内部セグメントを外部から隠ぺいすることができるというメリットもあります。

インライン構成時には、サーバプール内のサーバで NSX Edge ゲートウェイがデフォルトゲートウェイとして指定されている必要があります。

 

4. IPsec VPN/SSL VPN/L2 VPN
NSX Data Center では、IPsec VPN、SSL VPN、L2 VPN の 3 種類の VPN をサポートしています。それぞれ、拠点間の VPN 接続、クライアントのリモート接続、データセンター間の接続に利用されます。

図 7 VPN の設定画面

図 8 IPsec VPN

図 9 SSL-VPN

図 10 L2 VPN

 

5. NSX Edge の高可用性
少しここまでの流れと話が変わりますが、NSX Edge には個別の機能として高可用性機能(HA)が存在します。NSX Edge で HA を有効化するには、設定画面で有効化ボタンをクリックするだけです。有効化すると、HA 用の NSX Edge が追加され、片方がアクティブ、もう片方はスタンバイ状態になります。

図 11 NSX Edge HA の設定画面

物理機器でロードバランサなどの機能を実現して可用性を担保するためには、同一の製品を 2 台購入し、配線し、HA の設定も複雑で、可用性を上げるはずがトラブルの原因になることもありました。これが NSX Edge の場合は設定画面から有効を選ぶだけで完了します。これもソフトウェアだからこそなせる業です。

 

6. おわりに
今回は、NSX Edge が提供する主要なネットワーク機能についてお話してきました。
NSX Edge を用いると、さまざまなネットワーク機能を簡単に展開することができるようになります。

この回の冒頭でも申し上げましたが、仮想環境は NSX Data Center を用いることでその真価を発揮します。NSX Data Center のメリットは、何と言っても今までご紹介した機能をすべてソフトウェアとして提供できることにあります。

今まで仮想サーバの展開が数クリックで終了していたとしても、サービスを開始するまでには物理環境上でさまざまな作業が必要でした。物理機器の選定をし、ラッキングして、配線して、バージョンアップや管理系の初期設定をして、、、これらの物理作業は NSX Data Center を使うことですべて不要になります。ほんの数クリックで新規ネットワークセグメントを作成したり、ロードバランサ、ファイアウォールの設定を行うことも可能です。物理配線を変えることなくネットワーク構成の変更も行えますし、トラフィック量が増えた場合に物理機器を購入することなく性能を向上させることも可能です。ネットワークが不要になった場合は簡単にネットワークの削除、リソースの開放ができます。

これらは物理ネットワーク環境では考えられなかった運用方法で、NSX Data Center だからこそ実現できることです。

 

さて、今まで 1 データセンターでの NSX Data Center の利用に関する説明をしてきました。NSX Data Center は複数のデータセンターにまたがる展開も可能であり、そういった環境でこそ活きる機能も持っています。

次の回では、複数データセンターにまたがった NSX Data Center に関してご紹介いたします。ご期待ください。

 

コラム ~ ハンズオンラボ(HOL)~
みなさんはVMware のハンズオンラボというものをご存知でしょうか?ハンズオンラボとは、簡単に言うとVMware の製品のお試し環境のことで、VMware の提供するさまざまな製品を実際に触ってみることができます。
このコラムでは、ハンズオンラボの使い方を簡単に説明いたします。

まず、ウェブブラウザで次のリンクにアクセスします。
https://www.vmware.com/jp/try-vmware/try-hands-on-labs.html
すると図 12 のような画面になるので、「VMware NSX:入門」の [ラボを開始する] をクリックします。

図 12 VMware HOL

図 13 VMware NSX ハンズオンラボ

既に My VMware のアカウントをお持ちの方はそのアカウントのメールアドレスとパスワードを用いてログインします。お持ちでない方は [アカウントの作成] からアカウントを作成したのち、ログインします。ログインが完了したら [開始] をクリックしてハンズオンラボを開始します。

図 14 HOL コンソール画面

右上の [LANGUAGE] をクリックし、日本語を選択するとハンズオン環境の日本語化ができます(図 15)。既に日本語環境になっている場合はそのままで OK です。

図 15 日本語への言語変更

図 16 Chrome の言語設定

このラボ環境内で用いるブラウザ(Google Chrome)の設定もデフォルトでは英語になっていますが、Google Chrome の右上のアイコンから Japanese を選択すると言語を日本語にすることができます(図 16)。2 重に設定がありややこしいですが、ハンズオンラボの環境と、ハンズオンラボで利用する仮想端末内のブラウザの設定です。

図 17 HOL の vSphere Web Client 画面

これでハンズオン環境への接続は完了です。あとは、右側のハンズオンガイドに従って機能を試してみるのもよし、自分で自由に触ってみるのもよしです。今まで説明してきたさまざまな機能、メリットをぜひ体感してみてください。

ハンズオンラボについてはこちらもぜひ御覧ください!
ハンズオンラボの始め方など、動画付きで詳しくご紹介しています。