みなさま、こんにちは、VMware の知久です。
この連載では、VMware のマルチクラウド戦略の中心アーキテクチャである VMware Cloud Foundation がどの様な製品で、どの様な価値をお客様に提供するのかを改めてお伝えしています。
前々回と前回の連載では、番外編ということで、VMware Cloud Foundation 5.0の新機能や変更点、そして VMware Cloud Foundation 4.x から 5.0 へのインプレースアップグレードの手順や注意事項をお伝えしましたが、今回からまた通常編に戻り VMware Cloud Foundation の詳細をコンポーネント毎にお伝えしていきます。
今回は VMware Cloud Foundation のネットワーク構成についてお伝えします。
1. VMware Cloud Foundation でのネットワークに関する考慮事項
VMware Cloud Foundation を導入すると、コンピュート仮想化の vSphere に加えて、ネットワーク仮想化の NSX も含んだ仮想化基盤が構成されます。
その際に vSphere の下地となるネットワーク構成は勿論、NSX のコンポーネントについても導入する前にデザインや設計を考慮しておく必要がありますが、VMware Cloud Foundation の導入時に考慮する主なネットワークの項目は以下の4つとなりますので、それぞれどの様な検討事項があるのかをお伝えしていきます。
- 基本ネットワーク構成に関する VLAN ID と IP アドレスのアサイン
- ESXi ホストの物理 NIC の数
- Application Virtual Network 構成の可否
- NSX Edge Cluster の展開方法
2. 基本ネットワーク構成に関する VLAN ID と IP アドレスのアサイン
初期セットアップであるマネジメントドメインを構成する Bring up、もしくは SDDC Manager からワークロードドメインを構成する場合、事前に以下の必要ネットワークに関して、ToR スイッチへの VLANの構成や IP アドレスの確保をしておく必要があります。
- 管理ネットワーク
- vMotion ネットワーク
- vSAN ネットワーク
- NSX Overlay ネットワーク
ちなみに通常の vSphere 環境であれば、これらのネットワークを同一の VLAN ID で構成することも可能ですが、VMware Cloud Foundation の場合には、
全てネットワークが別々の VLAN ID を有している必要があるため、注意が必要です。
また、IP アドレスのアサインに関しては、管理ネットワークは 各 ESXi ホストに固定の IP アドレスを指定しますが、vMotion や vSAN、NSX Overlayに関しては、IP プール からの IP アドレスの払い出しとなります。
図2-1： VMware Cloud Foundation ネットワーク構成概要#1
以前の VMware Cloud Foundation では、NSX Overlay は IP プールに対応しておらず、別途 DHCP サーバを準備して、そこから IP アドレスの払い出しを行なっていたのですが、VMware Cloud Foundation 4.2 からIP プールもサポートされるようになり、DHCP か IP Pool のどちらかを選択することが出来ます。
ただし、vSAN や vMotion ネットワークの IP プールは SDDC Manager で管理されるのに対して、NSX Overlay の IP プールは NSX Manager で管理される形になりますので、ワークロードドメイン間で NSX のインスタンスが異なる場合、同一の IP プールは利用出来ませんのでご注意下さい。
図2-2： VMware Cloud Foundation ネットワーク構成概要#2
3. ESXi ホストの物理 NIC の数
VMware Cloud Foundation では最初のリリースから暫くの間、ESXi ホストで使用出来る物理 NIC の数は10GbE 以上の NIC を2つという制約がありました。
その後、VMware Cloud Foundation 3.9 で制約が緩和され、マネジメントドメインでは最大で6つ( 分散仮想スイッチは 最大3、分散仮想スイッチあたりの アップリンク数は最大4)まで、ワークロードドメインでは、VMware の構成の上限までの物理NIC までサポートされましたが、2つよりも多いマルチNIC を利用する場合には、VMware Cloud Foundation の初期セットアップである Bring up やワークロードドメインの作成時に GUI を利用出来ず、API 経由で構成する必要があり、現在もその部分に関して変更はありません。
図3-1： VMware Cloud Foundation マネジメントドメインでの物理 NIC と 分散仮想スイッチの最大構成
Bring up に関しては、VMware Cloud Foundation 4 では以下の特定の構成であれば、マルチ NIC 構成でも GUI での Bring up を実行出来ますが、それ以外の構成にしたいのであれば、API が必須となります。
図3-2： VMware Cloud Foundation Bring up 時のネットワークプロファイル構成図
※ネットワークプロファイル1は通常の2つの物理 NIC と1つの分散仮想スイッチによる構成になります。
マルチ NIC の ESXi で構成したマネジメントドメインやワークロードドメインに関しては、増設時のホスト追加なども API 経由となるため、ある程度 API に精通している方であれば支障はないのですが、慣れてない方や、そもそも VMware Cloud Foundation は SDDC 環境の運用を簡素化する事を目的とした製品ですので、運用負荷を最小限にするためにも可能な限り2つの NIC で構成する事を推奨しています。
その際に帯域などに不安がある場合には 25GbE 以上の NIC を利用するなどして回避する事も可能ですので、この辺りはリソース要件と運用要件をよく考慮して決定する必要があります。
4. Application Virtual Networkの構成の可否
VMware Cloud Foundation 3の後半のリリースである3.9 から新たに Application Virtual Network (以下 AVN)という概念が追加されています。
AVN はマネジメントドメインで構成される、NSXで構成した ソフトウェア定義のネットワークで、VMware Cloud Foundation 付属している vRealize 系の製品の管理サーバはこちらのネットワーク上に構成されます。
そのため、VMware Cloud Foundation から vRealize 製品を統合管理する場合には AVN の構成が必須となります。
AVN 構成のメリットとしては、ソフトウェア定義のネットワークを利用することで、vRealize 製品のデータモビリティやセキュリティの向上に加え、将来的には災害復旧時のサイト間フェイルオーバ手順の簡素化を実現することが可能です。
AVNの実装時では、Bring up 時に AVN を構成するか否かを決める必要がありましたが、VMware Cloud Foundation 4.3 から柔軟性が強化され、Bring up 後に SDDC Manager から AVN を構成する機能が追加されています。
図4-1： VMware Cloud Foundation AVN と vRealize 製品管理サーバネットワーク構成
なお、AVN を構成する場合、以下の要件が必須となりますので、AVN を構成する場合にはこれらを考慮する必要があります。
特にルーティングプロトコルの BGP の要件に関しては、社内ネットワークに依存する部分も強いと思われますので、事前の確認が重要になります。
- NSX Edge Cluster を SDDC Manager から構成する必要がある
- AVN 用の Edge Cluster のルーティングプロトコルでサポートされるのは BGP のみ
AVN の構成が完了すると、SDDC Manager の UI から vRealize 製品を統合管理するための、vRealize Suite Lifecycle Manager を展開することが出来る様になります。
図4-2： VMware Cloud Foundation SDDC Manager から vRealize Suite Lifecycle Manager の展開
5. NSX Edge Cluster の展開方法
VMware Cloud Foundation では、Bring up 時や SDDC Manager からのワークロードドメインの作成時、NSX のソフトウェアインストールに加え、各プロファイルの作成やトランスポートゾーンの作成など、ある程度の初期設定も含めて実行されますので、手動インストールに比べるとかなりの作業が軽減されます。
ただし、仮想ネットワークと物理ネットワークを繋ぐための NSX Edge Cluster は上記には含まれていませんので、必要に応じて追加をする必要があります。
VMware Cloud Foundation 3.x では、NSX Edge Cluster の作成は完全に手動で NSX Manager から実施する必要がありましたが、VMware Cloud Foundation 4.0 から SDDC Manager から NSX Edge Cluster を追加する機能が追加されています。
図5-1： VMware Cloud Foundation SDDC Manager から NSX Edge Cluster 展開ワークフロー
ただし、SDDC Manager の UI から NSX Edge Cluster を追加する場合には、ある程度構成が決まってしまっています。
そのため、例えば 通常の T0/T1 構成ではなく、T0のみやT1 Router のみの構成にしたい場合や、T0 の Uplink を2 VLAN 構成にするのではく、1VLAN で構成したいなどの特殊要件がある NSX Edge Cluster を展開したいケースでは、NSX Manager から手動で NSX Edge Cluster を展開する必要があります。
手動で展開した場合でも、SDDC Manager のライフサイクル管理では、展開されている NSX Edge Cluster をアップデート対象として認識しますので、
その点は特に心配ありませんので、ある程度細かい要件や設定を導入する想定であれば、手動での展開で進めておいた方が作り直しなどの手戻りを防げる可能性があります。
※前述の通り、AVN 用の NSX Edge Cluster に関しては、SDDC Manager の UI からの展開が必須になります。
6. まとめ
今回は、VMware Cloud Foundation のネットワーク部分についてまとめさせて頂きました。
VMware Cloud Foundation ではセットアップの自動化により、NSX の導入とセットアップ作業を大きく簡素化するため、ネットワーク仮想化の実装の敷居を大きく下げることが出来ます。
ただし、導入前の最小限のデザインやパラメータ、一部の導入後作業など VMware Cloud Foundation の導入と運用を成功させるためには、事前にきちんと考慮しておく必要がありますので、その際のご参考になればと思います。
さて、次回は仮想化基盤のもう一つの重要な要素である、ストレージについてお伝えさせて頂きますので、楽しみに待っていて下さい。
