Home > Blogs > Japan Cloud Infrastructure Blog > タグ別アーカイブ: NSX のキソ!

タグ別アーカイブ: NSX のキソ!

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

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

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

新卒 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 馬場浩太

新卒 SE 社員が贈る NSX のキソ︕第 3 回〜NSX Manager・NSX Controller・ハイパーバイザー カーネル モジュールについて〜

こんにちは! VMware 新卒 4 期生 SE の甫木佑美佳です。第 3 回の「新卒 SE 社員が贈る NSX  のキソ!」では、私たちが NSX Data Center を勉強した時に少々理解にてこずり、でもここが分かると NSX Data Center のアーキテクチャへの理解が深まる気がする…そんなコンポーネントである NSX Manager、NSX Controller、ハイパーバイザー カーネル モジュールをご紹介していきます。

 

1. NSX Manager・NSX Controller・ハイパーバイザー カーネル モジュール

図 1 サンプル構成図 NSX Data Center 導入前

前回は、NSX Data Center を構成する主要なコンポーネントやサンプル構成についてお話してきました。NSX Edge や分散論理ルータコントロール仮想マシンは、ネットワークに触れたことのある方ならエッジ、ルータといった単語からなんとなく環境の境界にあるんだろう、ルーティングに関連するんだろうと想像できると思いますが、NSX Manager、NSX Controller、ハイパーバイザー カーネル モジュールはなかなかイメージがつきにくいですよね。Manager と Controller って似てそうだけどどう違うの?、モジュールって一体何?、今回はそういった疑問にお応えすべくこれらの 3 つのコンポーネントを解説していきます。

図 2 NSX Manager、NSX Controller クラスタ、ハイパーバイザー カーネル モジュール

図 2 が今回ご紹介するコンポーネントの全体像です。NSX Data Center は管理・制御・データプレーンによって構成されていることは前回お話ししました。それぞれのプレーンについて、一度ここでおさらいしましょう。管理プレーンでは NSX Data Center が提供する機能の設定・管理を実施します。実際のデータトラフィックが流れてスイッチングやルーティングが行われるのがデータプレーン、そしてスイッチングやルーティングに必要な計算を行いデータプレーンを制御するのが制御プレーンです。今回ご紹介するコンポーネントはそれぞれ、NSX Manager は管理プレーン、NSX Controller は制御プレーン、ハイパーバイザー カーネル モジュールはデータプレーンに属しています。

これだけの説明だとちょっと抽象的ですよね。それでは、より具体的なイメージを掴んでいただくために、従来の物理ルータ 1 台が提供する基本的な機能を NSX Manager、NSX Controller、ハイパーバイザー カーネル モジュールの 3 つのコンポーネントがそれぞれどのように提供するか、図 3 で示してみました。

図 3 物理ルータと NSX Data Center の比較(例)

図 3 の左にある従来の物理ルータでは、管理者がコマンドで作成した設定の反映や、ルーティング情報の制御、そして実際のデータトラフィックの処理といったサービスを 1 台の機器で集中的に提供していました。一方で図 3 の右側にある、今回ご紹介する 3 つのコンポーネントでは、管理者による設定の反映は NSX Manager が、ルーティング情報の制御は NSX Controller が、データトラフィックの処理はハイパーバイザー カーネル モジュールがそれぞれの機能を提供します。このように、従来物理機器 1 台で提供されていた機能が複数のNSX Data Center のコンポーネントに分散されます。

これらのコンポーネントへの認識が少し深まったところで、ここから NSX Manager、NSX Controller、ハイパーバイザー カーネル モジュールそれぞれの展開方法、役割、機能についてもっと詳しくお話ししていきます!

 

2. NSX Manager について

2.1 役割

NSX Manager は、管理プレーンに属しており NSX Data Center 環境全体の管理はこのコンポーネントで実施します。NSX Data Center を構築する際に最初に立てる必要があるコンポーネントで、これなしでは NSX Data Center によるネットワーク仮想化のサービスは提供されません。NSX Data Center を集中管理するという点から、vSphere における vCenter Server 的な存在だと考えてください。

2.2 展開方法

この NSX Manager、先ほど vSphere における vCenter Server のような存在とお伝えしましたが、デプロイは vCenter Server の管理コンソールである vSphere Web Client で実施します。vSphere Web Client 上で NSX Manager の ova ファイルをアップロードし、仮想アプライアンスとして展開します。デプロイされた NSX Manager は vCenter Server と 1:1 でマッピングされます。vSphere Web Client にプラグインが追加されることで、NSX Data Center が提供するサービスは vSphere Web Client を通じて展開および管理されます。

2.3 機能

NSX Manager が提供する機能は、主に 4 つあります。

① GUI の提供

図 4 vSphere Web Client 上のNSX Data Center 管理画面

NSX Data Center では NSX Manager が唯一の管理ポイントであり、NSX Data Center に関するすべての設定はNSX Manager で実施します。図 3 のスクリーンショットが実際の管理画面です。

② REST API の提供

NSX Data Center は、セキュリティ製品など様々なサードパーティ製品と連携することが可能です。他のソリューションとの連携には、NSX Manager が唯一のエントリポイントとなります。

③ コンポーネントのデプロイ

図 5 コンポーネントのデプロイ

今回ご紹介する NSX Controller、ハイパーバイザー カーネル モジュールや第 2 回の記事で登場した NSX Edge ゲートウェイ、分散論理ルータコントロール仮想マシンといった NSX Data Center を構成するコンポーネントは NSX Manager からデプロイします。

④ 構成情報の配布・保持

図 6 NSX Manager による構成情報の配布

NSX Manager が提供する GUI 上で設定を実施することはこの記事でお伝えしました。NSX Data Center のコンポーネントに対する設定は図 3 の画面から実施し、各コンポーネントに配布されます(図6)。

このように、NSX Manager は NSX Data Center のすべての構成情報を保持しているため、NSX Manager のバックアップを取ってしまえば NSX Controller、論理スイッチ、ファイアウォールルールなど、あらゆる NSX Data Center の設定のバックアップまで取ることになります!

 

3. NSX Controller について

3.1 役割

NSX Controller は制御プレーンに属しており、冒頭でお話ししたようにカーネル モジュールがデータトラフィックの処理を実施する論理ネットワークの制御を行います。また、NSX Manager と ESXi ホストのカーネル モジュールからそれぞれ情報を受け取って管理する役割を担います。

3.2 展開方法

NSX Controller は、他のコンポーネント同様 NSX Manager からデプロイされ、NSX Manager が提供する GUI から仮想アプライアンスとして展開されます。図 7 をご覧いただくと、NSX Controller が 01、02、03 と 3 台構築されていることがお分かりいただけると思います。なぜ 3 台も立てる必要があるのでしょうか?この理由については、後ほどご説明します。

図 7 NSX Controller ノード

3.3 NSX Controller の機能

NSX Controller が提供する機能は 2 つあります。

① NSX Data Center 環境の論理スイッチング・分散論理ルーティングに関する情報の制御

NSX Controller は、それぞれのホストのハイパーバイザー カーネル モジュールや分散論理ルータコントロール仮想マシンから送られてくる仮想マシンの情報を管理、制御します。このあたりの仕組みについては、第 5 回でもう少し詳しい説明をします。

② ESXi ホストに対して、論理スイッチング・分散論理ルーティングに関する情報の提供

図 8 NSX Controller による情報のプッシュ

上記 ① の機能で収集した論理スイッチング・分散論理ルーティングの情報を NSX Controller は環境内のホストに送信します。NSX Controller がこれらの情報をまとめてホストに提供することで、それぞれのホストはそのホスト上にない仮想マシンの情報も把握します。

3.4 NSX Controller が3 台必要な理由

ところで、このシリーズの冒頭から登場している NSX Controller ですが、サンプル構成図では「NSX Controller クラスタ」と表記され、アイコンが 3 つ並んでいることにはお気づきでしょうか?

NSX Controller の展開方法をご説明した際にも 3 台立てられていたことをご確認いただきましたが、実は NSX Controller は 3 台構成する必要があります。なぜ NSX Controller が 3 台必要なのか、端的にお伝えすると以下の 2 つがその理由です。

・負荷分散

・冗長性の確保

まずどのように負荷分散させているかというと、NSX Controller が論理スイッチング・分散論理ルーティングの情報を管理することは既にお話ししましたが、NSX Controller が 3 台あることで、そのワークロードを分散させることが可能となります。その際にNSX Controller クラスタでは、それぞれの情報に対してマスターのロールを持つノードが 1 台選ばれ、そのマスターが他のノードにワークロードの割り当てを実施します。

図 9 NSX Controller 間でのワークロードの分散

そして冗長性の確保については、もし 3 台の NSX Controller のうち 1 台のホストで障害が発生してサービス提供が出来なくなってしまった場合には、その 1 台が担っていたワークロードが他の 2 台の NSX Controller に再分散されます。このワークロードの再分散も、マスターによって実施されます。マスターを選出する際は、クラスタ内にある全ノードの過半数票が必要となります。これが、NSX Controller クラスタのノード数が奇数である 3 台必要な理由です。

また、ホスト障害への可用性を担保するため、それぞれの NSX Controller は異なるホスト上に立てる必要があります。このように、NSX Controller は障害が発生した場合でもサービスが継続して提供できるようなアーキテクチャになっています。

図 10 NSX Controller 間でのワークロードの再分散

ちなみに、仮に NSX Controller 全台に障害が発生するという事態が起きたとしたらどうなると思いますか?仮想マシンの通信が止まってしまう…なんて心配はありません!なぜなら、 ESXi ホストは NSX Controller から配布された情報を自身で保持していますし、データトラフィックはデータプレーンに属しており制御プレーンである NSX Controller を経由しないからです。

NSX Controller が 3 台立てられる理由、お分かりいただけたでしょうか。それでは続けて、ハイパーバイザー カーネル モジュールについてご紹介していきます。

 

4. ハイパーバイザー カーネル モジュールについて

4.1 役割

ハイパーバイザー カーネル モジュールとは、データプレーンに属しており、ESXi ホストにインストールされます。カーネルモジュールによって、NSX Data Center では論理スイッチ、分散論理ルータ、分散ファイアウォールを提供できるようになります。ESXi ホストのカーネル内には分散仮想スイッチ(vDS: vSphere Distributed Switch)と呼ばれる仮想スイッチが存在する、というのは前回の記事でご認識いただいていると思いますが、カーネルモジュールのインストールによってこの vDS の機能が拡張されます。つまり、カーネルモジュールをホストのカーネルにインストールすることは、vDS に更に論理スイッチ、分散論理ルータ、分散ファイアウォールの機能を持たせることと同義です。

4.2 展開方法

ハイパーバイザー カーネル モジュールは、NSX Manager によって各ホストのカーネルに対してインストールされます。インストールは、NSX Manager と紐づいている vCenter Server で管理されているクラスタ単位で実施されます。

図 11 ホストへの NSX Data Center コンポーネントインストール

4.3 機能

ハイパーバイザー カーネル モジュールが提供する機能は、主に2つあります。

① 論理スイッチング・分散論理ルーティングの処理

図 12 分散論理ルータによるルーティング

カーネル モジュールのインストールは、ホスト上に論理スイッチ、分散論理ルータの機能を追加することと同様だと先ほどお話ししました。例えば、同じホスト上に異なるセグメントの仮想マシンが存在する状況でお互い通信をする場合、カーネル モジュールがルーティングの処理をしてくれます。

② NSX Manager 上で設定された分散ファイアウォールルールの反映

図 13 分散ファイアウォールルールの適用

NSX Data Center では、vDS のポートグループや仮想マシンの vNIC など、様々なオブジェクトに対して分散ファイアウォールルールを設定できます。NSX Manager で作成した分散ファイアウォールルールは、各ホストのカーネルモジュールによって管理・処理されます。NSX Data Center ではこの分散ファイアウォールと、NSX Edge が提供する境界ファイアウォールという 2 つのファイアウォールが提供されます。これらのファイアウォールについては、第 6 回で詳しくご紹介していきます。

 

5. おわりに

図 14 サンプル構成図 NSX Manager、NSX Controller 追加後

今回は NSX Manager、NSX Controller、ハイパーバイザー カーネル モジュールについてご説明してきました。それぞれのコンポーネントが果たす役割や機能についてご理解いただけたでしょうか?この 3 つのコンポーネントが分かると、次回以降の記事で紹介される論理スイッチ、分散論理ルータ、分散ファイアウォールといった NSX Data Center が提供するネットワークサービスの仕組みをより理解しやすくなります。次回は NSX Data Center の L2 ネットワークサービスである論理スイッチをご紹介します。お楽しみに!

 

-VMware SE 甫木 佑美佳

新卒 SE 社員が贈る NSX のキソ︕第 2 回〜NSX Data Center for vSphere の基本構成(登場人物の整理)〜

こんにちは!「新卒社員が贈る NSX のキソ!」第 2 回を担当する VMware 新卒第 4 期生の村田太郎です。第 2 回では NSX Data Center for vSphere を構成する主要なコンポーネントと、ブログ全体で利用する NSX Data Center のサンプル構成についてご紹介いたします。

図 1 NSX Data Center を構成する主なコンポーネント

NSX Data Center for vSphere を構成する主なコンポーネントは図 1 のようになります。 vCenter Server と ESXi ホスト以外は全て NSX Data Center 導入時に新たに展開されるコンポーネントになります。

念のため簡単に説明すると、 ESXi ホストは仮想化の基盤であるハイパーバイザーのインストールされた物理ホストで、この上に仮想マシンが作成されていきます。vCenter Server は ESXi ホストの管理を行うためのコンポーネントで、複数ホストにまたがったネットワークの設定を行う際に必要となります。

vCenter Server によって提供される管理画面が vSphere Client (HTML5)と vSphere Web Client (Flash)ですね。現在はFlash 版と HTML5 版が利用可能になっていますが、今後 Flash 版はなくなり、HTML5 に統合されていく予定です。

図 2 vSphere Client (HTML5)

各コンポーネントはその役割によって、管理プレーン(Management Plane)、制御プレーン(Control Plane)、データプレーン(Data Plane)のいずれかに分類されます。プレーンという言葉は聞きなれないかもしれませんが、あるひとつの機能を実現するのにもいろいろなコンポーネントが関わっていて、それぞれの役割で分類されている、程度に思ってください。

1. NSX Data Center のプレーンについて
NSX Data Center では、各コンポーネントがプレーンごとにぞれぞれ独立して動作しているので、もし制御プレーンに障害が発生しアクセスができない状態になったとしても、データプレーンが動作していれば通信を継続的に正常に処理することができる、などのメリットがあります。

プレーンが分かれておらず、設定、制御、実際の通信を同じコンポーネントで実現していると、そのコンポーネントに障害が発生してしまったときの影響範囲が非常に広くなってしまいますが、役割を分けてコンポーネントが存在しているとそういったことは起こりづらくなります。

管理プレーンは NSX Manager によって構築される NSX Data Center の管理コンポーネント群であり、管理者への一元的な設定、管理を提供します。管理プレーンでは管理トラフィックを扱います。制御プレーンは NSX Data Center における論理スイッチや論理ルーティングなどの制御を行います。データプレーンでは制御プレーンによって与えられたルーティング情報などをもとに実際にパケットのスイッチングなどデータのやりとりを行います。

実際に管理者が操作するのは管理プレーンのコンポーネント、ネットワークの実データが流れるのがデータプレーン、管理者からの操作を受けてデータプレーンを制御するコンポーネントは制御プレーンといったイメージになります。

図 3 NSX のプレーン

2. 各コンポーネントについて
NSX Manager は、NSX Data Center 導入における管理コンポーネントであり、NSX Data Center 導入時に最初に仮想アプライアンス(仮想マシン)として展開されるコンポーネントです。NSX Manager は vCenter Server に登録され、1 対 1 でマッピングされます。NSX Manager の初期構成を終えたのちは、NSX Data Center に関連する設定は対応する vCenter Server 上で行うことが可能になります。

 

NSX Controller は、NSX Data Center の仮想ネットワークを制御するコンポーネントで、論理ネットワークの制御を行っています。こちらも NSX Manager 同様、実体は仮想マシンで、NSX Manager を展開したのちに vSphere Client から作成します。仮想マシン、ホスト、論理スイッチ、分散論理ルータに関する情報を保持しており、重要な役割を持っているので、可用性を担保するために 3 台でクラスタを組む必要があります。

 

NSX Data Center には仮想アプライアンスによって提供される機能と vSphere のカーネル上で提供される機能がありますが、 vSphere のカーネル上で提供される機能はハイパーバイザー カーネル モジュールによって実現されます。ハイパーバイザー カーネル モジュールは、もともと vSphere のカーネルで提供されている仮想スイッチである分散仮想スイッチ(vDS: vSphere Distributed Switch)を拡張する形で提供される NSX Data Center のコンポーネントです。論理スイッチ、分散論理ルータ(DLR: Distributed Logical Router)、分散ファイアウォール(DFW: Distributed FireWall)などの機能を提供します。
NSX Data Center の論理スイッチは VXLAN(Virtual eXtensible LAN)というカプセル化の技術を使って実現されています。VXLAN を用いると、L3 ネットワーク上に仮想的な L2 ネットワークを構築することができるようになります。ピンと来ないかもしれませんが、後の回で別途説明がありますので、少々お待ちください。

分散論理ルータ コントロール仮想マシンはその名の通り、分散論理ルータの制御を行います。制御プレーンに属するコンポーネントで、分散論理ルータと他のルータとルーティングプロトコルセッションの確立を行います。

 

 

NSX Edge ゲートウェイは、North-South 方向のルーティング、境界ファイアウォール、NAT、DHCP、VPN、ロードバランシングなどのネットワークサービスを提供します。

分散論理ルータ コントロール仮想マシンと NSX Edge ゲートウェイもそれぞれ別々の仮想マシンとして作成されるコンポーネントです。分散論理ルータ自体は ESXi の「カーネル」で動作しますが、分散論理ルータを制御するのは分散論理ルータ コントロール「仮想マシン」であることに注意してください。この辺はよくこんがらがりますが、基本的に実データのやりとりは ESXi のカーネルで行われると思ってください。

NSX Data Center のコンポーネントの中でルーティングの機能を有するものは分散論理ルータと NSX Edge の 2 つがあります。なぜ同じ機能を複数のコンポーネントが持っているのか不思議に思われる方もいるかもしれませんが、分散論理ルータと NSX Edge ルータはルーティングを担当するトラフィックのタイプによって使い分けられます。

図 4 North-South/East-Westトラフィック

データセンターにおける通信は、データセンターの内外を行き来する North-South トラフィックと、データセンター内部の East-West トラフィックに分類されます。
分散論理ルータは East-West トラフィックのルーティングを、NSX Edge では North-South トラフィックのルーティングを主に行います。

3. サンプル構成図と今後の流れ
さて、NSX Data Center の主要なコンポーネントについての紹介を終えたところで、これらのコンポーネントがどのように展開されていくのかを、サンプル構成図を用いて次の回から順を追ってご紹介いたします。

このサンプル構成図は、論理ネットワーク構成図になっており、物理ネットワーク図ではないことに注意してください。ESXi ホストの絵が載っており、なんとなくその上に仮想マシンが配置されているように見えますが、気にしないでください。これは論理ネットワーク図なのでデバイスの物理的な配置には左右されません。この辺りの頭の切り替えが仮想ネットワークを理解する際のポイントになります。

図 5 サンプル構成図(NSX Data Center 導入前)

図 6 サンプル構成図(NSX Data Center 導入後)

 

図 5 が NSX Data Center 展開前、図 6 が NSX Data Center 展開後のサンプル構成図になります。

このサンプル構成(NSX Data Center 展開前)では、ESXi ホスト 4 台でクラスタを組んでおり、vCenter Server が 1 台の非常にシンプルな構成となっています。NSX Data Center 展開前の仮想マシンはどのネットワークにも接続していません。ネットワークは 4 つの VLAN に分かれており、それぞれ VTEP(後述)用、仮想マシンネットワーク用、管理ネットワーク用、vMotion 用となっています。今回はこのサンプル構成図を用いて NSX についてご紹介いたしますので vMotion 用の VLAN については特に関係ありませんが、通常 vSphere 環境を構築する際には管理ネットワーク、vMotion ネットワークなどでセグメントを分けるので、それにならった形の構成になっています。

それでは、NSX Data Center がどのように展開されていくのか見ていきましょう。

コラム ~ vSS と vDS ~
ハイパーバイザー カーネル モジュールのご紹介の際に、何気なく vDS の拡張ですと書いてしまいましたが、ここで簡単におさらいしておきたいと思います。

もともと、vSphere 上の仮想マシンが通信を行う際には、vSphere のカーネル内部に存在する仮想的なスイッチ、vSS(vSphere Standard Switch)を経由していました。vSS は各物理ホスト単位で設定を行う、ESXi に標準の機能になります。
各物理ホスト単位でスイッチの設定を行うとなると、ホスト数が多い場合、仮想スイッチの管理が手間になってきますし、設定ミスの可能性も上がってきますが、この問題を解決するものが、vDS(vSphere Distributed Switch)になります。

vDS では複数ホストの仮想スイッチを一元的に設定、管理することが出来るようになります。

VMware は、仮想ネットワークに取り組んできた長い歴史があり(スイッチの出荷ポート数で考えると、データセンタ―にある物理の ToR スイッチ以上のポート数を既に出荷済み!)、この vDS が仮想ネットワークの基礎となり、次世代のネットワーク仮想化プラットフォームとしての NSX に昇華されることになったのです!

vSS と vDS

vSS、vDS に関する詳しい説明は、「新卒 SE 社員が贈る vSphere のキソ」(https://blogs.vmware.com/jp-cim/2014/08/vsphere_kiso01.html)をご覧ください。

新卒 SE 社員が贈る NSX のキソ!第 1 回~ネットワーク仮想化への第一歩~

はじめまして!
2017 年 4 月入社 VMware 新卒 4 期 SE の大田愛里香と申します。VMware ではこれまで社会人なり立てほやほやの新卒 SE 社員が一生懸命自社製品について勉強した努力の結晶として、新卒にしていきなり SE という職種を放り投げブロガーと化し、サーバ仮想化製品であるvSphereデスクトップ仮想化製品である Horizon について、それぞれ新卒の目線からご紹介してきました。今回はそのネットワーク仮想化編としまして、これから 8 回に分けて「新卒 SE 社員が贈る NSX のキソ!」と題して、NSX Data Center for vSphere の用語や機能、仕組み、メリットを新卒 SE 大田(Ota)、村田(Murata)、甫木(Hogi)、馬場(Baba)、笠井(Kasai)、黒沢(Kurosawa)の 6名でご紹介します。

記念すべき NSX  ブログ第 1 回となりますが、まずこのブログで想定している読者、ネットワーク仮想化をとりまく背景、このブログの進み方についてご説明いたします。

 

1. このブログの対象
弊社のネットワーク仮想化製品であるVMware NSX Data Center (以下NSX Data Center)は、前提としてサーバ仮想環境の上で機能します。サーバ仮想化については、弊社の記念すべき新卒第 1 期生(!)が新卒 1 年目の時に作成した(!!)、記念すべき初めての弊社新卒 SEブログ(!!!)、「新卒 SE 社員が贈る vSphere のキソ!」ですでにご紹介していますので、今回はサーバ仮想化については改めて詳細なご紹介はいたしません。もちろん、サーバ仮想化について、「FT とは Fault Tolerance の略であり常にレプリケーション VM を別の物理サーバにスタンバイさせることにより物理障害発生時のダウンタイm」というように全て完璧な理解をしている必要はありません。このブログでは積極的に図解をしていこうと思いますので、図をみれば仮想環境上のネットワークについては十分イメージしてもらえると思います。サーバ仮想化の知識について、あやしいなと思ったときに、vSphere 編をかいつまんで見返していただけると、理解が深まるのではないかと思います。

また、ネットワーク仮想化をするにあたって、今まで物理ネットワーク機器で実現していた機能を仮想化するということになりますので、ルーティング、スイッチング、VLAN、ロードバランシング、ファイアウォール、NAT、VPN といったこれまでの機能がネットワーク仮想化環境にも実現されます。これらの機能についてそれぞれどのようなものなのかといったことは、私たちそもそもネットワーク初心者だしネットワーク仮想化という大きなテーマを語るうえでボリュームの問題もあり、このブログでは基本的には改めての詳細なご紹介はできませんでした、ごめんなさい!ですが、それぞれの機能の概要だけ理解していれば内容としては読み進められるように、適宜図やスクリーンショットを交えてご紹介しています。

上記の前提はありますが、このブログでは広くネットワーク仮想化について興味があり、まずは「どんな機能があるか?」「どんなメリットがあるか?」というところを理解したい方を対象にしており、さらに深く知りたい方にも「どんな仕組みなのか?」といったところまで分かりやすく説明することを目的にしております。私たちは入社後わからないことがあまりにも多く、特にネットワーク仮想化については複雑でかなり苦戦しましたが、実際に学び、操作しているうちに、専門的な知識が乏しくても、「なるほど、こんなことができるのか!」とだんだんわかるようになりました。本ブログでは、私たちが初心者的な目線で NSX Data Center を理解した時の視点をそのまま、NSX Data center の全体像をお伝えできたらと思います。

 

2. ネットワーク仮想化をとりまく背景
まずネットワーク仮想化の導入として、サーバ仮想化を導入してからインフラがどのように変わったのかを歴史の教科書ばりに真面目に復習してみたいと思います。

下記の通り、サーバ仮想化によって、物理リソースの集約、機器調達時間や作業工数、人的コストの削減といったメリットがありました。

図 1 サーバ仮想化によって得られた効果

図 1 サーバ仮想化によって得られた効果

 

しかし、企業のインフラを構成するものはサーバだけではありません。サーバ側の最適化により作業工数が削減されても、下記のようにネットワーク側では昔のままで機器調達や作業工数に時間を割かれることにより、インフラ全体としての提供スピードは結局変わらず、サーバ仮想化によるメリットを最大限に享受できない状態になってしまいます。

図 2 従来のネットワークにおける課題

 

そこで、今まで物理的に提供してきたネットワーク機能をソフトウェアで提供することで、サーバ仮想化の時に得られたメリットと同じように、ネットワーク機能を仮想マシンの作成と同様の手順でお手軽に提供したり、様々な物理環境の制約から解放したサービスを提供したり、そしてそれらの管理を一元化して運用負荷を軽減したりするために、弊社のネットワーク仮想化ソリューションである NSX が生まれました。

図 3 仮想環境ならネットワーク機器も気軽に構築

 

さらに、NSX Data Center は、従来のネットワーク機能を仮想環境に置き換えるのみならず、仮想環境に特化したファイアウォール 機能(第 6 回でご紹介予定)による最新のセキュリティソリューションや、ハイパーバイザーのカーネルで処理される各種分散ネットワーク機能、複数のデータセンター、およびハイブリッドクラウド環境(第 8 回でご紹介予定)に柔軟に対応するマルチサイトソリューション、など様々な新しい形のネットワークサービスとして活用いただけます。このように、これまでの物理的なハードウェアの制約に縛られていたネットワークとは異なった、NSX Data Center の仮想ネットワークであるがゆえに実現できることは非常に多くあり、本書でお伝えできることに限らず幅広い用途でメリットをご提供できますが、今回はそのエッセンスとなるものをできる限り分かりやすくひも解くことによって、読者の皆さん自身でも NSX Data Center の多岐にわたるユースケースを連想していただけたら何よりです。

...はい、ということで、背景となるところを真面目に説明させていただきました。退屈でしたか?そうですよね、「なんか、めっちゃざっくり当たり障りない概要説明!!!よくある結局なにもわかんないやーつ!」って感じだったと思います。ちょっと待ってください、このブログはネットワーク仮想化についてこのようなふんわりとした概要しか知らないという方が、ビビビッと、鮮明に理解していたけるように、一同頑張って書いております。ということでお待たせいたしました、今からこのブログの流れを説明させていただきます。

 

3. このブログのながれ
このブログでは、「結局のところ、NSX Data Center でどんな世界が作れるのか?」ということを皆さんにイメージしていただきたいという思想の元、NSX Data Center のサンプル構成をご用意しております。前述の通り、NSX Data Center で実現できる世界は実に多様になっており、コンポーネントの役割だけを淡々とお伝えしても、おそらくたいていの人が「んー、今どこの話してて、結局なんなの?あーなんか退屈だし、飽きた(笑)」と SNS を眺めはじめ、私たちは皆様に何も残すことができず終わってしまうかもしれません。そこで、読者の皆さんにも、あらかじめ「今からどんなものを作ろうとしているのか?」という視点を合わせていただき、その上で、実際に構築するときの手順と同じ流れで様々なコンポーネントをご説明いたします。これにより、各コンポーネントがどのような役割、機能を持ち、それがお互いに作用することによって何を実現できているのかということを実感していただければと思います。しかしこれだけでは、「で?!この機能何の意味があんの?!(笑)」とビジネス的にあっさり切り捨てられてしまうので、各機能を実現することによるメリットについても、皆さんに具体的にイメージしていただけるように一生懸命ご説明させていただきます。機能を理解した上で、「この機能があればこんなことがメリットになるのか!」と感じていただき、NSX Data Center という製品の意義を伝えられたらと思います。ついでに SNS で「VMware NSX Data Center サイコー!」などテンション高めに紹介していただけるとうれしいです。

それでは、次回よりさっそく、NSX Data Center を構成するイケてるメンツを紹介するぜ!ということで、NSX Data Center の登場人物(コンポーネント)と、今回のサンプル構成をご紹介いたします。各回ごとにサンプル構成の NSX Data Center 環境がどんどん完成していき、それに伴い NSX  Data Center のイケてる機能がどんどん増えていきますので、どうぞ最後までお楽しみください!

-VMware SE 大田愛里香