VMware NSX マンガSDN講座 第3回～マルチサイト～
※本コンテンツは「NSX for vSphere」をベースにしています。
ページ内に記載のある「VXLAN」は「NSX for vSphere」の機能となります。
「NSX-T」では、同等のオーバーレイ機能として「Geneve」が提供されています。
マンガSDN講座 第3回～マルチサイト～
従来の複数サイト運用は課題がいっぱい
たとえば、東京と大阪に拠点がある場合、それぞれの拠点にデータセンター（以下、DC）を構築するケースは少なくありません。また、利用目的に合わせて、開発用DCを構築したり、外部クラウド環境を利用することもありますし、災害時の事業継続（BCP）のためには、平常時に運用するサイトとは別にDRサイトを構築することが必要です。このように、システムの効率運用や特定用途、事業継続のために、企業では複数のサイト（マルチサイト）を運用することが行われています。
これらマルチサイトのネットワークの構成は、各サイト内はL2ネットワークで構成され、サイト間はL3ネットワークで接続しています。このように異なるL2ネットワークを運用するマルチサイト環境では、特にDRの観点で以下のような課題があります。
- ネットワーク設定に工数がかかる
サイト間の移行にはIPアドレスの変更が必要で、待機サイト側のネットワーク・セキュリティの設定同期も必要。 - 目標復旧時間が長くなる
サーバー規模が大きくなり、管理上、サイト毎にIPアドレスを変更しなければならないため、復旧時間がかかる。 - DRサイトのリソースを使用できない
待機用環境では平常時に使用されないリソースが多く存在し、本番用環境のリソース不足などに柔軟に対応できない。 - 各サイト管理が煩雑
DRプランの事前検証や確認、切替手順が手作業で煩雑になっている。
DRサイト運用の課題
自然災害などのトラブルでシステムダウンするケースなど、企業にとって深刻なダメージとなることが予想される場合、事業継続用にあらかじめ別サイト（DRサイト）を準備しておくなどの対策が必要です。
この事業継続用のDRサイトですが、本番サイトとは別のネットワークで構成されているため、本番サイトからDRサイトに切り替える際にIPアドレスを振りなおし、ネットワーク構成を変更しなくてはなりません。システムダウンなどで混乱している時に、ネットワークの切替作業を迅速に行うことは困難で、ダウンタイムが長期にわたり、ビジネス上の損害が拡大することが考えられます。
また、多額な投資をしてDRサイトを構築しても、災害が発生し本番サイトがダウンするまで、DRサイトの出番が全くないのも、悩ましい課題です。平常時には全く使われないシステムに対して大きな投資を行うことには抵抗を感じるのではないでしょうか。だからといって十分な投資を行わなかった場合に非常事態に対応できないということは、避けなくてはなりません。
SDNでL2ネットワークを延伸することで、マルチサイトの課題を解決！
ネットワークをNSXで仮想化してSDN環境を構築し、それぞれのサイトのL2ネットワークを延伸・同期することで、マルチサイトのネットワークをあたかも同一ネットワークのように扱うことが可能となります。SDNでは、本番サイトがシステムダウンしDRサイトに切り替える際や、各拠点間で仮想マシンを移行する時に、面倒なIPアドレスの書き換えや物理ネットワーク機器の設定変更は必要ありません。簡単な操作で切り替えることが可能です。
本番サイトがシステムダウンした際、従来の物理ネットワーク機器で構成されたネットワークに比べ、SDNではDRサイトへの切替時間を80%削減することができると言われています。
下の図は、VMware社の調査結果ですが、DRサイトへの切替時間を80%短縮することは、年間で3億8000万円あまり（1ドルを115円とした場合。1社平均。）の費用効果があるとの試算もあります。企業の規模により費用効果の額は変わりますが、切替時間を短縮する（システムダウンの時間を短くする）ことは、企業にとって重要な課題です。
VMware NSXによるL2延伸の方法
～その1 NSX Edge L2VPNによるL2延伸～
ここからは、NSXによるL2延伸の2つの方法を解説します。従来のマルチサイト環境では以下の図のように、それぞれのサイトは別々のL2セグメントで構成されているため、仮想マシンを移動しようとするとIPアドレスを変更する必要がありました。
NSX Edge Service Gatewayが提供するL2VPNでは、それぞれのサイトで同一のL2セグメントを共有することができるため、仮想マシンの移動の際にもIPアドレスの変更は不要ですし、高価な専用線接続や専用ハードウェアも必要ありません。
また、災害対策の実現やデータセンターの移行以外にも、vSphere 6.0でサポートされたvCenter Server間のvMotionを実現することが可能となります。
VMware NSXによるL2延伸の方法
～その2 Cross-vCenter NSXによるL2延伸～
前述のNSX Edge L2VPNによるL2延伸では、複数のL2セグメントをつなぐことで、仮想マシンのサイト間の移行時にIPアドレスの変更が不要になります。しかし、ネットワークの設定変更は、それぞれのサイトで別々に行うことが必要です。
これに対して、Cross-vCenter NSX によるL2延伸は、それぞれのサイトのVXLAN設定、ルーティング設定、分散FW設定を同期し、マルチサイトのネットワーク管理自体も1つにすることができます。
上図では、3つの vCenter が地理的に離れたデータセンターに分散している状況を想定しています。NSX 6.2 では、これらの分散したシステムを、単一の「ユニバーサル」なコントローラークラスターからまとめて制御できます。論理スイッチと分散論理ルーター、そして分散ファイアウォールのルールなどは、vCenter もしくはデータセンターをまたいだ「ユニバーサル」な形で作成できるようになります。
NSX Manager は vCenter ごとに1対1で存在しますが、プライマリの役割を持つ NSX Manager は1つのみであり、残りの NSX Manager はセカンダリとしてユニバーサル オブジェクトの情報をプライマリから複製します。
ユニバーサル オブジェクトのわかりやすい利点は、仮想マシン（VM）を vCenter 間もしくはデータセンター間で移動したときに、ネットワークの設定変更が必要なく、一貫性のあるセキュリティポリシーを提供し続けられることです。これにより、災害復旧やデータセンター移行を従来よりずっとシンプルで高速に行うことができます。
また、vCenter もしくはデータセンターをまたいだリソースプールを作り、Cross vCenter vMotion と組み合わせて利用することもできます。
マルチサイト構成例
構成例①：Active-Standbyネットワーク
管理の異なるマルチサイトにおいて、それぞれのサイトのネットワークをNSX L2VPNで各サイトを接続します。災害時のサイト切り替えの際にもIPアドレスを変更せずに動作させることが可能になり、目標復旧時間（RTO）を短縮することができます。また、この構成例では、レプリケーションをストレージベースで行うことで、目標復旧地点（RPO）の短縮を図っています。
構成例②：Active-Activeネットワーク
各サイトのネットワーク設定を共有して一つのネットワークとして扱い、入出力トラフィック経路を管理することで、Active-Activeなマルチサイトを実現しています。サイト切り替え時にもルーティングやセキュリティのポリシーをそのまま利用できるため、災害時の目標復旧時間（RTO）のさらなる短縮が可能です。サイト間の仮想マシン移行も容易に行えるので、これまで平常時では利用できなかったDRサイトのリソースを最大限に有効活用できます。
ユースケース3「マルチサイト」はいかがだったでしょうか？DRサイトや外部クラウドの活用などネットワークは増える一方です。効率的なネットワーク管理のためにも、また、ITリソースの有効な活用のためにも、ぜひSDNをご検討ください。