Home > Blogs > Japan Cloud Infrastructure Blog

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

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. コンバインモードの正しい理解と知っておきたいこと

 

新卒 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 画面

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

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

Veeam Backup & ReplicationのvSANバックアップ(後編)

こんにちは。株式会社ネットワールドのバックアップ製品担当SEの臼井です。前編では初回ということで、Veeam Backup & Replication(VBR)の概要について、ご紹介させていただきした。後編となる今回はvSAN環境でのVBRについてご紹介してきます。

Veeam Backup & ReplicationのvSANバックアップ(前編)

vSAN対応バックアップソフト

バックアップ製品によって、多少の違いはあるものの、最近ではほとんどバックアップ製品がvSAN対応を謳っていますが、VBRは独自にvSAN上でテストしているだけでなく、VMware様のvSAN認定を受けています。

VMware様のvSAN認定を受けているバックアップソフトは、下記のvSANのCompatibility Guideから確認することができます。

https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vsanps

このブログを書いている時点(2018年5月)では、Data Protectionのタイプで検索すると下記のバックアップ製品がリストされました。VBRも掲載されており、認定済みですので、安心してvSAN環境でご利用いただけます。

 

 

VBRvSANサポート

vSANは2014年3月11日にリリースされたvSphere 5.5 Update1において、vSAN1.0(vSAN 5.5)として最初にリリースされましたが、VBRはその3か月後の2014年6月にリリースしたVBR 7.0 Patch4でいち早くvSANのサポートを開始しました。そして、vSANのバージョンアップに合わせて、VBRも対応し、昨年末にリリースされたVBR 9.5 Update 3では vSAN 6.6.1まで対応しております。

現在はvSphere 6.7がリリースされておりますので、vSANの最新は6.7になりますが、VBRは次のアップデートでvSphere 6.7をサポートする予定になっておりますので、vSAN 6.7もすぐにサポートされることでしょう。

Veeam Backup & Replication support for VMware vSphere

https://www.veeam.com/kb2443

 

vSAN環境でのVBR

VBRのvSAN対応の特徴の1つとして、ストレージ ポリシーベース管理 (SPBM) への対応があります。vSANを使用する場合、パフォーマンスや可用性などの仮想マシンのストレージ要件(冗長化)を仮想マシンストレージポリシーという形で定義します。

 

 

バックアップソフトによっては、デフォルトの仮想マシンストレージポリシー(Virtual SAN Default Storage Policy)以外を割り当てていても、リストアするとデフォルトの仮想マシンストレージポリシーが割り当てられてしまい、リストア後に仮想マシンストレージポリシーの再適用が必要になることがあります。

それに対して、VBRは仮想マシンストレージポリシーを認識し、仮想マシンストレージポリシーの情報を含めてバックアップしているため、仮想マシンストレージポリシーの再適用は不要です。また、バックアップ時と異なる仮想マシンストレージポリシーを割り当ててリストアするといったことも可能です。

 

VxRailでの検証

実際に弊社環境で仮想マシンストレージポリシーがリストアされるのか検証してみました。vSAN環境としてDell EMC社のVxRail を使用し、非vSANのESXiホスト上に展開したData Domain Virtual EditionへDD Boostを使用してバックアップする構成です。

 

 

新規でRAID1-(Mirroring)の仮想マシンストレージポリシーを作成し、バックアップ対象の仮想マシンに割り当ててから、バックアップを取得しました。

 

 

仮想マシンのリストアウィザードのリストア先のデータストアの指定する箇所を見てみると、割り当てていた仮想マシンストレージポリシー(Mirror Policy)が表示されています。

 

 

検証では新しい別の仮想マシンとしてリストアしましたが、元通りに仮想マシンストレージポリシーが適用された状態でリストアされており、VBRが仮想マシンストレージポリシーに対応していることが確認できました。

 

 

vSANバックアップのベストプラクティス

vSAN上でVADPを使用して仮想マシンをバックアップする際、転送モードとしては、SANモードは使用できず、NBD(SSL)モードかHotAddモードのどちらかを使用する必要があります。

 

 

 

 

 

今回のVxRail上での検証では、VBRサーバを仮想マシンで用意しましたが、VBRは転送モードを選択することが可能です。追加でNBDモードとHotAddでバックアップ・リストアの時間がどれほど違うのか検証してみました。

 

 

 

バックアップ結果が下の表になります。47GBの少量のデータの場合、HotAddモードとNBDモードでバックアップ時間に大きな違いはありませんが、プロセスレートでは、HotAddモードはNBDモードの2倍以上のスループットが出ています。1.1TBのデータをバックアップした場合には、バックアップ時間としてもNBDモードはHotAddモードの2.5倍以上の時間がかかりました。

 

 

下の表はリストア時の結果ですが、リストア処理ではData Domain上の重複排除されたデータを元の状態に戻してリストアされる(データストアに書き込まれる)ため、バックアップよりプロセスレートは落ちます。47.6GBのリストアにおいては、NBDモードとHotAddモードは誤差の範囲で差はありませんが、1.1TBのリストアでは差が表れており、HotAddモードの方が早い結果となっています。

 

 

以上の結果から、vSAN環境では物理のバックアップサーバを構成して、NBDモードでバックアップするより、仮想でバックアップサーバを構成してHotAddモードでバックアップした方がより高速にバックアップ・リストアすることができると考えられます。

更に、Data DomainのDD BoostやStoreOnceの Catalystを利用すれば、VBRサーバ上で重複排除処理をしてからバックアップストレージにデータを転送することで、データ転送量を減らし、より高速なバックアップが期待できます。

まとめ

vSAN環境のバックアップの視点でVBRをご紹介させていただきましたが、如何でしたでしょうか?もっと詳しくvSANのバックアップやVBRについて知りたいという方は、お気軽に弊社までご相談いただければ幸いです。弊社ではVBR以外にも多くのバックアップソフトを扱っておりますので、お客様の環境や要件に合わせて最適なバックアップソリューションをご提案させていただきます。

 

執筆者:

株式会社ネットワールド

SI技術本部 ストレージ基盤技術部

ストレージソリューション2課

臼井 守(Usui Mamoru)

■ネットワールド Veeam製品情報

https://www.networld.co.jp/product/veeam/

■ネットワールドらぼ (ネットワールド ブログ)
https://blogs.networld.co.jp/

 

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

エージェントレス型とエージェントレス型の使い分けのポイント

 

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

前回までエージェントレス型セキュリティ対策を提供するDSVAでウイルス対策、侵入防御をどのような仕組みで提供しているかを解説してきました。
Deep Securityにはエージェントによるセキュリティ保護も可能ですが、うまく使い分けて頂くことでよりセキュアなインフラ環境を構築することが可能です。
今回はこれからDeep Securityの導入を検討している、またはこれから実装する!といった皆様に向けて、エージェントレス型のDeep Security Virtual Appliance(DSVA)とエージェント型Deep Security Agent(DSA)の使い分け、組み合わせのポイントを解説していきたいと思います。

 

DSVA/DSAで提供できる機能の違い

まずは、DSVAとDSAで提供できる機能について見てみましょう。

※GI:VMware NSX にてGuest Introspectionが有効である必要がある機能
※NI:VMware NSX にてNetwork Introspectionが有効である必要がある機能
※OSのバージョン、ディストリビューション毎の対応状況の詳細については、Supported features by platformをご確認ください。

詳細部分で機能、OS毎に対応できる内容に差異がありますが、大枠は上記で確認を頂けると思いますが、特に以下の点は見落としがちな内容ですので、留意してください。

  • DSVAによる推奨設定の検索は、Guest Introspectionが有効である必要がありますので、Linux OSの仮想マシンで侵入防御機能を利用する場合には利用できません。推奨設定の検索を利用する場合にはDSAが必要となります。
  • Webレピュテーションはネットワーク系のプロセスで処理を行うため、DSVA環境ではNetwork Introspectionを有効にする必要があります。
    (Deep Security Virtual Appliance ウイルス対策では不正プログラム対策とWebレピュテーションが利用できますが、Network Introspectionが利用できるVMware NSXライセンスが必要になります。)

 

DSVAとDSAを組み合わせて利用もできる

DSVAはVMware vSphere/VMware NSXと連携をしてセキュリティ機能を提供していますが、DSVAで保護しているESXiホスト上にDSAが導入された仮想マシンを稼動させることも可能です。
Windows系仮想マシンとLinux系仮想マシンでは動作仕様が異なります。

  1. Linux OSの場合
    DSVAによる保護は行われず、DSAがすべてのセキュリティ機能を提供します。(DSVAが稼動するESXiホスト上で、DSAがすべてのセキュリティ機能を提供)

  1. Windows OSの場合
    DSVAとDSAで予め決められたルール(アフィニティルール)に従って、保護機能を分担してセキュリティ機能を提供します。これをコンバインモードといいます。コンバインモードについては次回詳しく解説します。

上記のようにDSVAとDSAが混在した環境でも利用することができるため、サーバ環境で複数の機能を利用したい場合でも柔軟に設計することが可能です。

 

まとめ ~ DSVAとDSAを使い分ける上でのポイント
DSVAとDSAの機能の違いとESXiホスト上での基本的な動作仕様を踏まえて、導入されるケースとして多い組み合わせをいくつかご紹介しておきます。

  • 仮想デスクトップ環境でWindows OSを展開してウイルス対策を行いたい場合にDSVAを利用する。(Webレピュテーションを利用する場合にはVMware NSXでNetwork Introspectionを有効化する必要あり)
  • LinuxサーバとWindowsサーバが混在する、またはWindowsサーバが大多数を占める環境において、Windowsサーバは機能に応じてDSVA、LinuxサーバはDSAにて保護する。
  • セキュリティログ監視、アプリケーションコントロールが利用したいユーザでサーバ環境を全面的にDSAで保護する。実際にはシステム環境に応じてさまざまなケースがあると思いますが、DSVA/DSAそれぞれでできることを理解頂きながら、うまく使い分けて頂ければと思います。

 

執筆者:
トレンドマイクロ株式会社
セキュリティエキスパート本部
パートナービジネス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. コンバインモードの正しい理解と知っておきたいこと

 

Veeam Backup & ReplicationのvSANバックアップ(前編)

皆さん、はじめまして。株式会社ネットワールドでバックアップ製品のSEをしております臼井と申します。VMware vSANを導入するお客様の増加に伴い、多くのバックアップ製品を扱っている弊社にもvSAN環境のバックアップについて、お問い合わせいただく機会が増えてきました。そこで、VMware様のJapan Cloud Infrastructure Blogの場をお借りして、仮想環境のバックアップで多くの実績があるVeeam Backup & Replication(以下、VBR)を使用してのvSAN環境のバックアップについて掲載させていただくことになりました。
前後編の2回に分けて、vSAN環境でVBRを使うメリットや特徴をご紹介させていただきたいと思いますので、宜しくお願い致します。

Veeam(ヴィーム)って?

個人的には、Veeamという名前も仮想環境のバックアップとして日本で浸透してきたかなと勝手に思っているのですが、ご存じない方のために改めてご紹介させていただきます。
メーカーの正式名称はVeeam Softwareで、データ保護や監視ツールのソフトウェアを主に開発している会社です。本社はスイスのバールにあり、設立は2006年ですが、ここ数年で急速に顧客数や売り上げを伸ばしている注目のベンダーです。

 

 

Veeam Backup & Replicationとは?

VBRという製品を簡潔に言えば、VMware vSphere Storage APIs – Data Protection (通称、VADP)と連携して、仮想マシンを丸ごとバックアップする製品です。VMware様の製品で言うと、vSphere Data Protectionと同種の製品になります。vSphere Data ProtectionはvSphere 6.5での提供が最後になりましたので、今後のバックアップの選択肢の1つとしてVBRをご検討いただければ幸いです。

 

 

 

 

 

 

 

 

 

 

VBRの歴史は古く、2008年にVADPの前身のVMware Consolidated Backup対応のバックアップ製品としてバージョン1.0がリリースされました。その後、VADP対応や数々の機能追加や機能拡張を重ねて、現在は昨年末にリリースされたバージョン9.5 Update 3が最新バージョンとなっております。

 

 

 

他のバックアップソフトとVBRは何が違うのかというと、以下の3つの特徴が挙げられます。

 

✔アプリケーション対応

✔柔軟なリカバリ

ストレージ連携

 

それぞれの特徴を見ていきましょう。

特徴その1<アプリケーション対応>

VBRはVADPによるVMwareスナップショットと連携して仮想マシンをバックアップしますが、その際に、Active Directory, Exchange, SharePoint, MS SQL Server, Oracleについてはデータの整合性を保持してバックアップすることが可能です。

 

 

仮想マシンの静止スナップショットにより、VMware Toolsに含まれるVSS(Volume Shadow copy Service)を利用することで、ファイルシステムの整合性や一部のVSS対応アプリケーションの整合性を保持したバックアップできる製品もありますが、 VBRでは独自のVSSを提供しており、アプリケーションに合わせて、完全VSSバックアップの実施やバックアップ成功後のトランザクションログの切り捨て、カスタムスクリプトの実行などを行うことができ、より信頼性の高いバックアップを行うことが可能です。また、Oracleについては、Windowsだけでなく、Linux上のOracleにも対応しております。

特徴その2<柔軟なリカバリ>

VBRは仮想マシン単位でバックアップを行いますが、リストアは仮想マシン全体だけでなく、フォルダ・ファイル単位、仮想ディスク単位、アプリケーション単位など、シチュエーションに応じて様々なリストア方式を選択できます。

フォルダ・ファイルのリストアについては、17種類もの多数のファイルシステムに対応しております。アプリケーションについては、Active Directory のユーザーアカウントやExchangeのメールメッセージ、SharePointのドキュメントやSQL Server/Oracleはデータベースなど、粒度の細かいリストアをエージェントレスで実行することが可能です。

 


リストア操作も専用のリストアツールとして、Veeam Explorerが提供されており、直感的な操作が可能です。

 

 

特徴その3<ストレージ連携>

Veeam Softwareはアライアンスパートナーが多く、様々なベンダーのストレージと連携できることも大きな特徴です。プライマリストレージとして、Dell EMC, NetApp, HPE, IBM, Pure Storage等のハードウェアストレージのスナップショットと連携しての安定したバックアップやDell EMC Data Domain(Boost), HPE StoreOnce(Catalyst)といった重複排除ストレージと連携してバックアップすることもできます。

まず、ハードウェアストレージスナップショットとの連携ですが、仮想マシンのスナップショットのみを使用してVADPによるバックアップを行うと、スナップショット作成後の仮想マシンに対しての変更はスナップショットファイル(通称:デルタファイル)に変更ログが書き込まれ、バックアップが完了するまで保持し続けます。バックアップが長時間に及ぶケースや仮想マシンへの変更が多い環境ではスナップショットファイルの容量が肥大化し、データストアの空き容量不足やシステムのパフォーマンス低下などが起きる可能性があります。スナップショット削除時においてもスナップショットの統合処理に時間がかかるケースや仮想マシンが応答を停止する可能性があります。

 

 

 

スナップショットの仕組みや問題点については、下記のKBでも紹介されておりますので、参考にしていただければと思います。

-ESXi / ESX における仮想マシン スナップショットについて (1033239)

https://kb.vmware.com/kb/1033239

-vSphere 環境でスナップショットを使用するベスト プラクティス (1038295)

https://kb.vmware.com/kb/1038295

-仮想マシンのスナップショットを統合するのに必要な時間の推定 (2096780)

https://kb.vmware.com/kb/2096780

-スナップショットの削除で仮想マシンが長時間停止する可能性 (2079323)

https://kb.vmware.com/kb/2079323

このような問題を回避するには、ストレージスナップショットとの連携が有効です。ストレージスナップショットと連携することで、仮想マシンのスナップショット作成後にストレージスナップショットを作成し、仮想マシンスナップショットはすぐに削除されます。そのため、仮想マシンのスナップショットがある時間が最小限になり、前述の問題が起きる可能性も低くしてなります。仮想マシンスナップショットだけの場合とストレージスナップショットを組み合わせた場合をバックアップ時間の流れを比較すると下の図のようになります。

 

 

次に、重複排除ストレージとの連携です。VBR自身にも重複排除機能はありますが、重複排除ストレージと組み合わせることでバックアップデータ全体の重複排除され、より高い重複排除率を実現することが可能です。

また、vSphere Data ProtectionとData Domainを組み合わせた場合と同様、DD Boostを利用することにより、VBRサーバ上で重複排除処理を行い、Data Domain上に存在していないブロックのみを転送することでネットワークに流れるデータ量を削減でき、更に論理的な仮想合成フルバックアップ作成により、バックアップのパフォーマンスを高速化することも可能です。

vSphere Data ProtectionはData Domainのみの対応でしたが、VBRでは DD Boostと同様、Open Storage Technology (OST)を使う、HPE StoreOnceのCatalystとの連携も可能です。

 

 

ここに書き切れないほど、VBRならではの機能や特徴はまだまだ沢山ありますが、厳選してVBRの特徴を紹介させていただきました。後半は、いよいよvSAN環境でのVBRについてご紹介させていただきますので、お楽しみに。

Veeam Backup & ReplicationのvSANバックアップ(後編)

執筆者:

株式会社ネットワールド

SI技術本部 ストレージ基盤技術部

ストレージソリューション2課

臼井 守(Usui Mamoru)

■ネットワールド Veeam製品情報

https://www.networld.co.jp/product/veeam/

■ネットワールドらぼ (ネットワールド ブログ)
https://blogs.networld.co.jp/

 

 

新卒 SE 社員が贈る NSX のキソ︕第 6 回〜 NSX Data Center が提供するファイアウォール機能とは ~

こんにちは!「新卒 SE 社員が贈る NSX のキソ!」、第 6 回を担当する、VMware 新卒第4 期生の黒沢勇です。前回は、異なるセグメント間の通信に欠かせない「NSX Data Center のルーティング機能」についてご紹介させて頂きました。第 5 回までの内容で図 1 のような VXLAN、分散論理ルータ、Edge ルータを組み合わせた柔軟なネットワークを構築することが可能となりました(図 1)。

図 1 第 5 回で完成したサンプル構成図

さて、前回まで NSX Data Center を使うと、いかにネットワークを柔軟に構築できることをお話してきました。ですがここで気になることは、「セキュリティはどうなっているの?」というところです。従来はセグメントの境界に対して物理ファイアウォールを設置し、セグメント内に対してはアクセスリストを使用したセキュリティを用いていることが一般的でした。しかし、物理機器のみで構成されたセキュリティにはいくつかの課題が出てきています。今回は、NSX Data Center がどのように仮想環境でファイアウォール機能を提供し、課題を解決するのかをお話します!まずは、NSX Data Center のファイアウォールの概要についてお話していきましょう。

 

1. NSX Data Center が提供する2種類のファイアウォールの機能
第 5 回で NSX Data Center が提供するルーティング機能は 2 種類あるというご説明をさせていただきましたが、実はファイアウォールについても NSX Data Center は2種類の機能を提供しています。

 

1.1 NSX Edge Service Gatawayのファイアウォール機能
1 つ目は、NSX Edge Service Gateway(以下 NSX Edge)が提供するネットワーク機能の 1 つである仮想ファイアウォールです(図 2)。

図 2 NSX Edge ファイアウォール

 

第 5 回で NSX Edge で North-South 方向のルーティングを行えることをご説明しましたが、NSX Edge にはルーティング以外の機能を持たせることもできます。ファイアウォール機能も NSX Edge  機能の一部であり、従来の境界ファイアウォールと同様にセグメントの境界に設置することで、トラフィックの制御を行うことができます。ファイアウォール機能を持った仮想マシンとして機能を提供するため、素早い払い出しや、物理コストをかけずにすむなど、物理ネットワーク機器にはなかったメリットを得ることができます。

 

1.2 分散ファイアウォール
2 つ目は分散ファイアウォールと呼ばれる機能です。ハイパーバイザー カーネル モジュールに組み込まれており、仮想マシン1 つ 1 つに対して個別にファイアウォールルールやアクセスコントロールなどのセキュリティポリシーを適用することができます(図 3)。さらに、分散ファイアウォールのルール情報はホスト間で共有されているので、vMotion や DRS で仮想マシンが移動しても設定が引き継がれるという特徴を持っています。

図 3 分散ファイアウォール

 

どちらのファイアウォールも、これまで物理ファイアウォールで処理していたトラフィック制御をハイパーバイザや仮想マシンへ分散することが可能となります。その結果、トラフィックを最適化したり、セキュリティをより強固にしたり、柔軟な設定を行うことができるようになります。

 

2. 従来の物理ファイアウォールの課題を NSX Data Center が解決!
さて、NSX Data Center のファイアウォールが 2 種類あることはおわかりいただけたと思いますが、この 2 つのファイアウォールがどのように従来の課題を解決するのでしょうか?3 つの課題から考えてみましょう。

 

2.1 標的型攻撃の被害が広範囲に広がる
今回は図のような、事業部ごとに Web3 層構成のシステムが存在するケースを考えてみましょう(図 4)。

図 4 サンプルシステム図

 

今回の例ではシステムがフラットな L2 セグメントを持っており、社外との通信に対して境界ファイアウォールで制御を行っています。しかし、内部通信を行うときにはファイアウォールを通過しないため、社内のセキュリティレベルが同じ状態になっています。でも、よく考えてみると同じ L2 セグメントにあるからといってセキュリティレベルが一緒とは限りませんよね?財務部のサーバと、個人情報が詰まっている人事部のサーバは明らかにセキュリティレベルが異なります。
ここで、財務部のサーバがもしインターネット上からウィルスやマルウェアなどの標的型攻撃を仕掛けられてしまった場合を考えてみましょう。(図 5)

図 5 財務部のサーバが感染

 

標的型攻撃は感染をすると同じセグメントのマシンへ被害を広げようとします。そのため、感染したサーバが他のサーバへと通信できる状態だと、サーバ 1 つが感染しただけで、被害は同じセグメント全体に及んでしまいます(図 6)。

図 6 同じセグメントに感染が拡大

 

さらに、同じセグメントからの通信はファイアウォールを通らないため、アラートすら上がらないことも多いです。気づかない内に攻撃されて、気づいた時には機密情報や個人情報が盗まれていた…なんてことも起こり得ます(図 7)。

図 7感染したサーバから情報が漏えい

 

では、どのように NSX Data Center のファイアウォールがこの課題を解決するのかをお話させていただきます。実は、L2 セグメントが同じシステムであったとしても、通信が必要ないという場合は多々あります。しかし、従来の境界ファイアウォールはセグメント内の通信には手が出せないため、通信を許す状態になっていました。
ここに分散ファイアウォールを設定することにより、L2 セグメント内の通信を厳しく制限をかけることができます。このファイアウォール設定により、感染したサーバは他のマシンと通信が行えないので感染を広げることができなくなります(図 8)。

図 8 分散ファイアウォールで標的型攻撃の感染を抑制

 

境界型ファイアウォールを設置するだけではセグメント内の通信ができる状態なので被害が拡大してしまいますが、分散ファイアウォールを使えば他のマシンとの通信を遮断することができるので、感染が拡大しなくて済むのです!
ご存知とは思いますが、境界型のファイアウォールは突破される可能性が 0 ではありません。分散ファイアウォールを設定することによって被害を最小限にとどめられるのは、とても安心ですよね。

 

2.2 ヘアピン通信を分散ファイアウォールで解決
セキュリティレベルを高めるために、常にファイアウォールを通過する形で、通信を行うようにしているお客様もいらっしゃると思います。この場合、ネットワークのトラフィックパターンが複雑になり、余計な経路を通るヘアピン通信が発生してしまいます。1 回 1 回物理ファイアウォールを通ると、物理機器に負担がかかるうえに、遅延も大きくなってしまいます。
ここに分散ファイアウォールを導入するとどうなるのか考えてみましょう。ハイパーバイザー内部にファイアウォール機能を持っているので、いちいち物理ファイアウォールを通過する必要がなくなります。これで、仮想マシン間のヘアピン通信が発生しなくなるので、物理機器への負担を小さくすることができます。そのためシンプルなトラフィックパターンとなるので、物理機器のダウンサイジングや運用コストの低下も期待できます(図 9)。

図 9 ヘアピン通信と分散ファイアウォール

 

2.3 どっちを取る!? vMotion の自由度とセキュリティ
これまでのネットワーク環境はセキュリティ機能が物理機器頼りになっているため、vMotion の自由度と、セキュリティのどちらかを犠牲にしているような形が多々見られます。ご存知と思いますが、仮想マシンを vMotion で移動する際には移動先と移動元が同じセグメントでないと、移動先で正常に通信ができなくなってしまいます。つまり、仮想マシンの移動先を多くするためには広い L2  ネットワークが必要になります(図 10)。

図 10 フラットな L2 ネットワークを使った従来管理

 

従来の管理方法で L2 ネットワークを広く取ってしまうと、多くの仮想マシンを同じセキュリティポリシーで管理することになってしまいます。本来は別々のセキュリティポリシーを適用すべきですが、仮想マシンが移動できる代わりにセキュリティを犠牲にしていることになります。
一方、セグメントを細かく切り、仮想マシンのセキュリティポリシーを厳しく適用する運用方針もあります。しかし、セグメントを細かくすると今度は仮想マシンの vMotion 先が少なくなってしまいます。また、このように自由度の低い構成は集約率の低下を招いてしまうことも多々あります。せっかく仮想マシンを使っているのに vMotion ができない…なんていうのはもったいないですよね(図 11)。

図 11 細かくセグメントを分けた従来管理

 

では、NSX Data Center を導入するとどうなるのかを見てみましょう。分散ファイアウォールを導入すれば仮想マシン毎にセキュリティポリシーを適用できるようになるので、フラットな L2 ネットワークを作りつつ、セキュリティレベルを維持することができます。加えて、ホスト間で分散ファイアウォールの情報を共有しているため、仮想マシンが移動できるようにしても、移動先でセキュリティレベルを維持することができます。

図 12 分散ファイアウォールの活用で自由度とセキュリティポリシーを両立

 

NSX Data Center を使えばセキュアな環境も維持しつつ、仮想マシンのメリットも最大限に引き出すことが可能となるんですね。

これまでは NSX Data Center のファイアウォール機能について、どのようなメリットが出るのかについてご説明させて頂きました。ところでみなさんはファイアウォールの設定というと、IP アドレスや MAC アドレスをコマンドで入力しながら 1 つ 1 つ設定を行っていくイメージがあると思います。今まで当たり前のことでしたが、もっとわかりやすく設定が行えたらいいな…と思ったことはありませんか?

実は NSX Data Center のファイアウォールは設定も従来のファイアウォールよりも柔軟に行えるんです。

3. 機能だけじゃない!簡単で柔軟な NSX Data Center のファイアウォール設定
では、実際に NSX Data Center のファイアウォールを設定する画面を見てみましょう(図 13)

図 13 NSX Data Center のファイアウォール設定画面

 

設定項目は以下の 5 項目となります。全て GUI 上から設定を行えるため、従来の IP、MAC アドレスを対象とした従来の CUI で行う設定よりも可視性に優れており、簡単にセキュリティポリシーを適用できるようになります。

・ソース
サービスの送信元を IP、MAC アドレスに加え vCenter オブジェクトから設定可能
・ターゲット
サービスの送信元を IP、MACアドレスに加え vCenter オブジェクトから設定可能
・サービス
物理ファイアウォールでセッティングできるサービスの大半を選択可能
・操作
サービスを許可/ブロック/却下するかを選択可能
・適用先
ルールの適用先を分散 FW もしくは Edge FW から選択可能

ここで注目していただきたいのは、ソースとターゲットを IP アドレスや MAC アドレスだけでなく、仮想マシンやポートグループ、クラスタ、ホスト、データセンタ、論理スイッチ、vApp、vNIC といった vCenter オブジェクトでも設定可能な点です。
従来のファイアウォールは文字が羅列されているだけので見にくいだけでなく、セキュリティポリシーの適用先が IP、MAC アドレスのみに縛られていました。vCenter オブジェクトで設定を行えるようになると、ソースとターゲット設定を直感的にできるため、従来のファイアウォールと柔軟に設定が可能となります。
ここで、さらに NSX Data Center のファイアウォールの柔軟性に足を踏み入れてみましょう。その秘密はセキュリティグループという概念にあります。

 

4. セキュリティグループで俊敏性を向上!!
先の節で仮想マシンや、ホストごと、ポートごとにセキュリティポリシーを設定できることをお話しました。しかし、仮想マシンは何度も作成されます。GUI になったとはいえ、仮想マシンを作成するたびに、ファイアウォールのルールを変更するのは少々手間です。できることであれば、もう少しグルーピングをし、なおかつ追加、削除される仮想マシンに対して動的にセキュリティポリシーを適用していきたいものです。
NSX Data Center では動的にグループメンバーを追加、削除してくれるセキュリティグループというオブジェクトをてソース・ターゲットとして選択できます。
セキュリティグループは、”仮想マシンに Tech の名前を含むもの”といった形でグルーピングをすることができ、あとから仮想マシンを追加しても動的にグループへ対象の仮想マシンを追加してくれます。

図 14 セキュリティグループを使えば後からポリシーを適用可能

 

例えば、技術部の Web サーバを追加する例を考えてみましょう。仮想マシン名に“Tech という文字が含まれば、技術グループ”、“Web という文字が含まれれば Web サーバグループ”というように事前にセキュリティグループを定義しておきます。すると、追加した Tech-Web という仮想マシンの分散ファイアウォールには、技術グループと Web サーバグループの 2 つのセキュリティグループのルールが適用されます。
これで、仮想環境に新しく仮想マシンを追加したときに、毎回毎回煩わしいファイアウォールの設定を追加していく必要もなくなります。セキュリティグループを活用すれば柔軟かつ俊敏に設定を適用できるようになります。NSX Data Center でネットワークを仮想化することで、ネットワークを最適化するだけでなく、ファイアウォール機能を強化したり、柔軟に設定できるようになるメリットも得られることができることがお分かりいただけたでしょうか?

 

5. まとめ
最後に改めて、NSX Data Center の持つファイアウォール機能の特徴とメリットをそれぞれ整理しておきましょう。
NSX Data Center のファイアウォールで従来の物理ファイアウォールの課題を解決!
・標的型攻撃に対しては分散ファイアウォールで感染拡大を抑制
・仮想マシンの可搬性を最大限にして運用
・ヘアピン通信を抑制して物理機器をダウンサイジング
設定は GUI 上で簡単に行える上、設定項目が豊富!
・物理ファイアウォールと違い、GUI 上で簡単に設定
・ターゲットとソースを vCenter オブジェクトを使って柔軟に設定可能
・セキュリティグループを使えば動的にセキュリティポリシーを適用可能

 

6. おわりに
今回は NSX Data Center のファイアウォールについてお話させて頂きました。次回は NSX Edge について詳しく触れます!実は NSX Edge にはルーティング機能や、今回お話したファイアウォール機能以外にも様々な機能があるんです!!
次回、さらなる NSX Data Center の魅力に触れていきましょう!お楽しみに!

 

コラム ~ 3rd party連携について ~
NSX Data Center は 3rd party 製品との連携も可能となっております。Symantiecs 社、Palo Alto Network 社、Fortinet 社、Juniper 社製品など様々なベンダー製品との連携が可能ですが、今回はトレンドマイクロ社の Deep Security との連携がどのように行われるのか、見てみましょう。昨今流行している標的型攻撃に対して、Deep Security と連携することによって、標的型攻撃の被害にあった被害にあった仮想マシンを物理的に隔離することが可能となります。さらに、Deep Security を活用することで仮想マシンの浄化まで行うことができる上に、仮想マシンの再接続を行うことも可能です。
これにより、NSX Data Center 単体での運用以上に安全な仮想環境を運用することが可能となります。
トレンドマイクロ社との連携についてはこちらの記事をご参照下さい。
VMware NSX と Trend Micro Deep Security で実現する仮想化セキュリティの最適化

新卒 SE 社員が贈る NSX のキソ!第 5 回~仮想化されたネットワークのルーティング~

こんにちは!「新卒 SE 社員が贈る NSX のキソ!」第 5 回を担当する VMware 新卒第 4 期生の笠井伶花と申します。
前回の第 4 回では、論理スイッチをテーマに仮想環境のネットワークを VXLAN で払い出すことで物理環境に手を加えず、サーバ側で自由に仮想ネットワークを払い出すことができるというお話をしてきました。
構成図で見ると、図 1 のところまで完成している状態ですね。

 

図 1 第 4 回で完成した構成図

しかし、ここまでのお話で VXLAN によるセグメントをまたいだ通信はどうするんだろう?という疑問を持ったかたもいらっしゃるのではないでしょうか。そこで、第 5 回では、異なるセグメントネットワーク間の通信に欠かせない「NSX Data Center のルーティング機能」についてご紹介いたします。

VXLAN によるセグメントをまたいだ通信をする場合、もちろんルーティングが必要になります。しかし、VXLAN で払い出した仮想ネットワークのセグメント間のルーティングを従来通り物理のルータで行うとしたらどうなるでしょうか? 第 4 回でもお話がありましたが、結局はトラフィックが 1 度仮想化されたネットワークの外に出てしまいます。また物理ルータへの設定が都度必要になってしまうのです。折角サーバ側で自由にネットワークを払い出すことが出来るようになったのに、ルーティングで結局物理ネットワーク側での設定変更が必要になっては意味がありません。
しかし、NSX Data Center ではルーティング機能に関しても仮想の世界の中だけで行う機能を備えているんです!

 

1. NSX Data Center のルーティング機能

NSX Data Center には実は 2 種類のルーティング機能があります。1 つは NSX Edge の機能の 1 つである仮想ルータによるルーティング、もう 1 つは、ハイパーバイザのカーネルに組み込まれた分散論理ルータによるルーティングです。
しかしこの 2 種類のルーティングは一体何が違っているのか、ややこしいですよね。そこで、ここからは NSX Edge のルータ、分散論理ルータについてそれぞれ特徴を見ながら、2 つのルータの違いとメリットについて理解していきましょう。

 

2. NSX Edge Service Gateway とは ~NSX Edge を使うメリット~

第 2 回の主要コンポーネントの紹介の部分で簡単に説明しましたが、NSX Edge はネットワーク機能を提供する仮想アプライアンスです(図 2)。従来、物理ネットワーク機器で提供されていた各種ネットワーク機能を仮想マシンで提供しているというと分かりやすいかもしれません。NSX Edge はルータ、NAT、ファイアウォール、ロードバランサー、VPN、DHCP といった機能を提供することができます。

仮想アプライアンスの NSX Edge を使うと、例えば、従来では物理ネットワーク機器での運用が必要だったネットワーク機能と比較して、「仮想マシンだからこそ」の簡単かつ素早いネットワーク機能の展開、展開が簡単だからこその短期間でのスケールアウトの実現、そして、物理ネットワーク機器のダウンサイジングによるコスト縮小、といったメリットが得られます。また、NSX Edge の管理・運用についてもバラバラの管理コンソールではなく、vSphere Web Client で一元的に管理可能なことも管理者側から見て魅力的な部分です。

 

図 2 NSX Edge によるルータを含む構成図

 

2.1 NSX Edge Service Gateway のルータ ~North-South 方向のルーティング~

NSX Edge は物理ネットワーク機器が仮想アプライアンスになったイメージと言いましたが、物理ネットワーク機器のルータを使った場合と NSX Edge のルータを使った場合のトラフィックの流れと比べると図 3 のようになります。物理ネットワーク機器の代わりに NSX Edge のルータがルーティング処理していますね。また、ネットワーク仮想化環境で通信が完結する場合は、L3 スイッチまでトラフィックがあがらずに Edge で処理することができます。
このように NSX Edge ルータは、特に仮想ネットワークと外部ネットワーク間の通信、すなわち North-South 方向の通信のルーティングを処理するときに適しています。

 

図 3 物理ルータと NSX Edge ルータのルーティング経路の比較

 

では、データセンター内の通信、いわゆる East-West 方向のルーティングでは NSX Edgeルータを使わないのでしょうか?実は East-West 方向のルーティングに関しては、もっとトラフィックを減らせる最適な方法を NSX Data Center は持っているんです。

それが次に説明する「分散論理ルータ」です。

 

3. 分散論理ルータ(Distributed Logical Router/DLR)

さて、NSX Data Center が持つもう 1 つのルーティング機能、「分散論理ルータ」。この機能は NSX Data Center だからこそ、という特徴を持っています。この回の最初にお話した通り、従来の物理ルータによるルーティングは、同じホスト上にあるセグメントが異なる仮想マシン同士が通信しようとすると、1 度必ずホストからパケットが出て物理ルータで処理されてから、再度同じホスト上にある送信先仮想マシンにパケットが届きます。

なんだか遠回りしていると思いませんか?

このルーティングでは、同じホスト上に仮想マシンがあるにも関わらず 1 度通信がホストからネットワークに出てしまうため、その分ヘアピン通信(同じホスト上にある仮想マシン間の通信がホストから 1 度出て、また元のホストに戻るような通信)が発生してしまいネットワーク機器が処理するパケットの量が増大してしまいます。また、仮想ネットワークの追加・変更時には、物理ネットワーク機器への設定変更が必要になってしまいます。

実はこれらの問題を「分散論理ルータ」で一気に解決できてしまうんです!

 

3.1 分散論理ルータによるメリット ~East-West 方向トラフィックの最適化~

まず、ヘアピン通信の問題から見ていきましょう。
実はデータセンター内における通信のうち約 7 割はマシン-マシン間での通信であるとも言われています。つまり、仮想サーバで構成されたデータセンターでは、仮想マシン同士の通信によるトラフィックの量が大きいのです。この East-West 方向のトラフィックの最適化を分散論理ルータはどう実現しているのでしょうか?

実は分散論理ルータの正体はハイパーバイザー カーネル モジュールに組み込まれたルーティング機能です。もう少し噛み砕いて言うと、同じ設定のルーティングテーブルを持ったルータが複数の ESXi ホストのカーネル モジュールに実装されるイメージです。分散論理ルータでは、送信元の仮想マシンからパケットが投げられると、そのホスト内の分散論理ルータでルーティング処理され、そのまま送信先の仮想マシンにパケットが届けられます。

分散論理ルータでは、ダイナミックルーティングで構成する場合、ルーティング情報を集中して制御している「分散論理ルータコントロール仮想マシン」がルーティング情報を NSX Controller クラスタに集約し、NSX Controller から各ホストに情報をプッシュすることでルーティングの構成が各分散論理ルータに共有されます(図 4)。

 

図 4 分散論理ルータのルーティング情報の共有の仕方

 

ちなみに、スタティックルートで構成する場合は、新たにルートを学習することはないため、分散論理ルータコントロール仮想マシンは必要なく、静的に設定された分散論理ルータの構成が Controller クラスタから各 ESXi ホストにプッシュされます。

このように、各ホストのカーネル モジュールに構成された分散論理ルータがルーティングの情報を持っているため、ホスト内の分散論理ルータでルーティング処理ができるのです!

分散論理ルータを使った場合のトラフィックの流れは、図 5 のようになっています。まず、ルーティング処理は送信元の仮想マシンがのっているホスト内の分散論理ルータで処理されるため、1 度、物理ルータ、もしくは Edge を使用している場合は Edge に行く必要がなくなります。

もう少し詳しく説明しますと、図 5 の赤い線が示すように、送信先の仮想マシンがローカルのホスト上に存在する場合、ネットワーク側にパケットが転送されることなく、ローカルのホスト内でルーティングが完結するんです!
また、図 5 の橙色の線を見てもらうと分かるように、送信先の仮想マシンが別のホストに存在する場合は、分散論理ルータでルーティング処理が行われた後に VXLAN で該当の仮想マシンが起動しているホストまでパケットが転送されます。どちらの場合も仮想マシン間でルーティングを行うにあたり、物理ルータや Edge にパケットを転送する必要がありません!
このようにして East-West 方向におけるルーティングのトラフィックの最適化を可能にしているのです。

 

図 5 分散論理ルータによるルーティングの経路

 

そして皆様、本ブログ第 4 回の VXLAN の話を思い出してください!
VXLAN を使えば、物理ネットワーク機器への VLAN 設定変更は必要ない、というお話がありましたね。つまり分散論理ルータでルーティング処理された後は VXLAN による通信で転送される、すなわち L2 の通信ということですから、このときの物理ネットワークはただのパケットの通り道になっているんです。

ここまでくるとお気づきでしょう。
分散論理ルータを使うと、仮想マシン間のルーティングを行うための物理ルータは必要ありません!そして、ルーティング処理の追加・変更時においても物理ネットワーク機器への設定変更も必要ありません!
従来の物理ルータによるルーティングの問題が仮想ネットワークのルータにより解決されたのがお分かり頂けたでしょうか?

 

4. まとめ

最後に改めて NSX Data Center の持つ 2 種類のルーティング機能の特徴とメリットをそれぞれ整理しましょう。

NSX Edge のルータと分散論理ルータは適しているトラフィックの方向が違います!
分散論理ルータは East-West 方向のルーティングのトラフィックを最適化します。NSX Edge のルータの使いどころは、外部(物理)ネットワーク-仮想ネットワーク間の通信をルーティングすること、すなわち North-South 方向の通信のルーティングです。

 

図 6 論理図で見る NSX Data Center の 2 種類のルーティング

 

② VXLAN による L2 通信と同様、仮想ネットワーク内におけるルーティングまわりの設定追加・変更を物理ネットワークから切り離して実施できるため、ネットワーク運用の工程削減の実現が可能になります!

③ 2 種類のルーティングのデザインを活用し、ネットワーク処理の最適化を行うことで、物理ネットワーク機器のダウンサイジングが可能になります!

 

5. おわりに

ここまででスイッチ、ルータといったネットワークの基本が NSX Data Center の機能で仮想化の世界で閉じて実現しましたね(図 7)。

図 7 NSX Data Center のルーティング機能を実装した構成図

 

でもこれではまだセキュアなネットワーク環境にはなっていません。VXLAN で払い出した仮想ネットワークのセグメント間でも通信をさせたくない・・そんな状況ももちろん出てきますよね。

そこで次回の「新卒社員が贈る NSX のキソ!」では、セキュアなネットワークを実現する NSX Data Center のファイアウォール機能についてご紹介します!お楽しみに!

- VMware SE 笠井伶花

新卒 SE 社員が贈る NSX のキソ︕第 4 回〜論理スイッチがもたらす NSX Data Center の オーバーレイネットワーク〜

読者の皆様こんにちは!2017 年 4 月に VMware に入社しました、新卒第 4 期生の馬場浩太と申します。
「新卒社員が贈る NSX のキソ!」も第 4 回となりました。ブログの第 1 回では、ネットワークを仮想化することで、ネットワーク機能を様々な物理環境の制約から解放し、運用負荷を軽減する、と説明しました。第 4 回は、 NSX Data Center の「ネットワークの仮想化」の本質である、論理スイッチをテーマに(図 1)、この仕組みを技術的に理解し、NSX スゴイ!使ってみたい!提案したい!と感じていただくことを目的としています。

図 1 論理スイッチ作成前のネットワーク図(仮想マシン同士は通信できていない)

さて、ネットワーク仮想化をすることで、その運用負荷が大幅に削減される?本当でしょうか?外資ベンダーはいつも都合のいいことばかり言いますので、疑ってかかることは重要です。ネットワークを仮想化する前の、仮想マシンを新規ネットワーク上に構築するオペレーションについて具体的に確認してみましょう。

【サーバ側】
・標準仮想スイッチ (vSS:vSphere Standard Switch)の場合、通信に関連するすべての ESXi ホストに対して、追加する VLAN のポートグループを作成し、仮想マシンを追加したポートグループに所属させる
・分散仮想スイッチ(vDS:vSphere Distributed Switch)の場合、追加する VLAN のポートグループを 1 つだけ作成し、仮想マシンを追加したポートグループに所属させる

【物理ネットワーク側】
・通信に関連するすべての物理スイッチに対して、VLAN を作成する
・通信に関連するすべてのトランクポートに対して、Allowed VLAN を設定する
・PVST+ など、VLAN 単位でスパニングツリーを構成している場合、追加する VLAN に応じてスパニングツリーの設定をする

【その他】
・ネットワーク担当者に連絡して動いてもらう

図 2 ネットワーク仮想化前に新規ネットワークを追加する場合のオペレーションの一例

なぜこのようなオペレーションが必要なのでしょうか?それは、物理ネットワーク機器が仮想マシンを認識しているからです。
「新卒 SE 社員が贈る vSphere のキソ!」第 2 回では、「仮想マシンに入っている OSはあたかも物理サーバ上で動作していると思い込んでいる」と紹介しました。当然、物理ネットワーク機器も、仮想マシンを 1 つの物理サーバ/物理マシンと思い込んでいます。彼らにとって、物理か仮想かは関係がないのです(図 3)。

図 3 物理ネットワーク機器の認識する通信は物理サーバではなく仮想マシン

具体的には、異なる ESXi ホスト上の仮想マシン同士が通信をする時、物理ネットワーク機器を通るパケットは、仮想マシンの MAC アドレス/IP アドレスを送信元/送信先とします(ESXi ホストを送信元/送信先とはしません!)。つまり、仮想の世界の通信にも関わらず、物理の世界にも影響を及ぼしているのです。
仮想マシンが増えれば増えるほど、物理ネットワーク機器が認識する仮想マシンの数も増えてしまいます。そして、それらが接続されるネットワークの数が増えれば増えるほど、物理ネットワーク機器へのオペレーションはますます複雑になり、新規ネットワークを追加するときにでさえ、物理機器への面倒な作業が不可欠となり、ネットワーク担当者に動いてもらう必要があるのです。

 

仮想の世界の通信は、仮想の世界で完結してしまいませんか?

 

このような、NSX Data Center のネットワークの仮想化を実現するのが論理スイッチです。VXLAN という技術を使うことで、vDS 上にある仮想マシンを、論理スイッチという仮想ネットワーク上に接続させることができます。NSX Data Center では、クラスタの集合であるトランスポートゾーンと呼ばれる単位で、論理スイッチを有効化します。
先ほど、どの仮想マシンがどの仮想マシンに通信したかを、物理ネットワーク機器が認識してしまう、と説明しました。すなわち、MAC アドレステーブルなどの各種テーブルや ACL(アクセスコントロールリスト)などの情報は、通常は仮想マシンの MAC アドレス/IP アドレスで照合されるというわけです。
NSX Data Center を導入した場合、仮想マシン間の通信は各 ESXi ホストが持つ VTEP と呼ばれるインターフェース間の通信への置き換えられ、物理ネットワーク機器が認識する通信は、仮想マシンではなく VTEP となります。したがって、物理ネットワーク機器の持つ各種テーブルや ACL などの情報は、VTEP の MAC アドレス/IP アドレスで照合されるようになります(図 4)。

図 4 物理ネットワーク機器の認識する通信は論理スイッチによりVTEP に

これによって何が変わるでしょうか?再び、仮想マシンを新規ネットワーク上に構築する場合を考えてみましょう。vSS や vDS の場合に必要なオペレーションが、論理スイッチの場合はどうなるでしょうか?

【サーバ側】
・vSS の場合、通信に関連するすべての ESXi ホストに対して、追加する VLAN のポートグループを作成し、仮想マシンを追加したポートグループに所属させる
・vDS の場合、追加する VLAN のポートグループを 1 つだけ作成し、仮想マシンを追加したポートグループに所属させる
→ ポートグループはもはや意識する必要がありません。作成した論理スイッチに、仮想マシンを接続するだけです。

【物理ネットワーク側】
・通信に関連するすべての物理スイッチに対して、VLAN を作成する
→ 必要ありません。物理ネットワーク機器が認識する VTEP に変化がないためです。
・通信に関連するすべてのトランクポートに対して、Allowed VLAN を設定する
→ 必要ありません。物理ネットワーク機器が認識する VTEP に変化がないためです。
・PVST+ など、VLAN 単位でスパニングツーを構成している場合、追加する VLAN に応じてスパニングツリーの設定をする
→ 必要ありません。物理ネットワーク機器が認識する VTEP に変化がないためです。

【その他】
・ネットワーク担当者に連絡して動いてもらう
→ 必要ありません。vCenter Server から新規ネットワークを作成できるためです。VTEP には影響がありませんので、物理ネットワーク機器にも影響はありません。

図 5 ネットワーク仮想化で新規ネットワーク作成の手間は大幅に削減

どうでしょう?あれだけ手間がかかっていた新規ネットワーク構築作業が、物理スイッチへのログインを一切することなく、vSphere Web Client 内だけで完結しました。不思議ですよね?これが NSX Data Center によるネットワーク仮想化のスゴさです。NSX Data Center の論理スイッチの本質は、このような仮想マシン間の通信を隠蔽する、というところにあります。これにより、仮想の世界でいくら新しいネットワークを作成しても、物理ネットワーク機器側からは VTEP 間の通信と認識され、その判断ができません。したがって、物理ネットワーク機器に手を加えず、サーバ側で自由にネットワークを払い出すことができるようになり、ネットワークの運用負荷が大幅に削減されるのです。NSX Data Center が構築する仮想ネットワーク、すなわちオーバーレイの世界にとって、VTEP 間の通信、すなわち仮想ネットワークを支えるアンダーレイの世界はどうだっていいのです。
最後にまとめとして、もう一度、皆様にこの言葉を捧げたいと思います。

 

仮想の世界の通信は、仮想の世界で完結してしまいませんか?

 

おわりに
いかがだったでしょうか?今回は論理スイッチについて説明いたしました。論理スイッチを作成することで、仮想マシン間は物理ネットワークの制約を受けず、自由に仮想ネットワーク上で L2 接続ができるようになります(図 6)。

図 6 論理スイッチ作成後のネットワーク図(仮想マシン同士は L2 で接続)

しかしながら、これは NSX Data Center の魅力のほんの一部でございます。NSX Data Center にはまだまだ紹介していない機能、それによってもたらされる価値がたくさんございます。例えば、今回はNSX Data Centerの論理スイッチという L2 の部分だけをお話しましたが、次回はこの論理スイッチ間の「ルーティング機能」を提供する分散論理ルータ、Edge ルータをご紹介します。


コラム ~VXLANについて~

お気づきになられた読者も多いかとは思いますが、NSX Data Center の論理スイッチでは、ESXi ホスト単位でトンネリングを行っています。これについて補足します。
スイッチは L2 レベル、すなわち MAC アドレスを見てパケットを判断し、適切なポートから他の機器へパケットを伝達します。ルータは L3 レベル、すなわち IP アドレスを見て、パケットを判断し、適切なポートから他の機器へパケットを伝達します。
この時、スイッチやルータは、図 7 のように、パケットの先頭にある情報しか見ません。つまり、もし図 7 のようにパケットの先頭に本来のものとは異なる MAC アドレス/IP アドレスが付与された場合、スイッチやルータは一番先頭にある MAC アドレス/IP アドレスしか見ませんので、本来のパケットの送信元/送信先を捻じ曲げることができます。これがカプセル化です。
NSX Data Center では、VTEP の MAC アドレス/IP アドレスで、本来のパケットをカプセル化します。パケットがカプセル化されたことを物理ネットワーク機器は判断できず、VTEP の MAC アドレス/IP アドレスを見て、送信先仮想マシンが存在するサーバの VTEP にそのままフォワーディング/ルーティングしますが、パケットを受け取った VTEP はカプセル化されたことを判断できます。すなわち L3 以上の VXLAN ヘッダを見ますので、そこでカプセルが外され、送信先仮想マシンが存在する ESXi カーネル上で本来のパケットを処理するわけです。実は、VTEP はトンネルの入り口や出口なのです。

図 7 物理ネットワーク機器が認識するパケットのヘッダの違い

さて、もう少し論理スイッチと VXLAN を深堀りしてみましょう。トンネリングをすることで、サーバ間のネットワークが何であれ、 1 本の仮想の専用線、L2 ネットワークで接続することができます。まさに、サーバ間の複雑なネットワークを、トンネルで束ねて隠してているイメージですね。この、複雑なネットワークをトンネルで束ねて隠し、同じ L2 ネットワークでつなぐことを「L2 延伸」と呼びます。L2 延伸をすることで、vMotion が必要とする L2 サービスを、安定的な標準化技術である L3 ネットワーク上で構成することが可能となります。そしてこれは、本ブログの最終回でお話しするような、複数のデータセンター間の仮想ネットワーク環境の構築や、VMware のビジョンでもあるクロスクラウドを実現するために必要な技術です。
L2 ネットワークを単に広げるのは簡単です。しかしながら、ある程度の規模の L2 ネットワークを、どのように安定的に構成・管理するかはネットワークエンジニアの長年の課題でした。ブロードキャスト範囲の増加、それによる帯域圧迫、ループを防ぐための STP、新たなソリューションが出たとしてもベンダー独自技術の習熟コストがかかってしまうなど、L2 ネットワークを「安定的に」広げるのは、案外難しいのです。
論理スイッチは、これらの課題に対する 1 つの答えと言えます。NSX Controller がVTEP とそれに紐づく仮想マシンのテーブルを持っているため、必要のない ESXi ホストにはブロードキャストは届きません。論理スイッチ上ではループは生じませんし、VXLAN は VMware 独自の技術でもありません。VMware の NSX Data Center は、ハイパーバイザーである ESXi と VXLAN を効果的に組み合わせることで、ネットワーク運用負荷の削減と、L2 延伸によるネットワークインフラの抽象化を実現するのです。

-VMware SE 馬場浩太