Home > Blogs > Japan Cloud Infrastructure Blog > 作成者別アーカイブ: Erika Ota

作成者別アーカイブ: Erika Ota

新卒 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 のキソ!第 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 大田愛里香