VMware Cloud on AWSのNSX-T概要と設定方法
VMC on AWSは当初、NSXはVかTがオプションで提供されるという話がありましたが、結局NSX-Tが標準搭載で提供されています。
NSXが標準で搭載されたことで、きめ細やかなファイアウォールなどの通信制御を実施することができます。
VMC on AWSのファイアウォールを設定できる箇所は以下のものがあります。
CGW(Compute Gateway)
MGW(Management Gateway)
DFW(Distributed Firewall)
それぞれどのようなユースケースで使用するかというと、CGWはVMC以外との通信を制御・MGWは管理系(vCenterなど）との通信を制御、DFWはeast-west間の通信を制御するために利用します。
↓VMC内のネットワーク概要図
※T0=外部と接続するための仮想ルータです
※仮想マシンはCGW配下のワークロード部分にぶら下がるイメージです
例えば仮想マシンとvCenter間の通信を制御したい場合はMGWを設定します。
仮想マシンとインターネット間の通信を制御したい場合はCGWを設定し、
また、DFWはオンプレと同様に同じクラスタ内の仮想マシン間で通信制御を行いたい場合に設定します。
実際の設定はVMCコンソールから行います。
青=MGW
緑=CGW
紫=DFW
ルールについては送信元・先、サービス(anyなど)、アクション(dropなど）を設定可能です。
予めセグメントやIPをグルーピングしておくと簡単に設定できるのでお勧めです。
名前的にCGWで仮想マシン間の通信を制御できそうに思いますが、実際にはDFWを利用する必要がありますのでご注意ください
VMware Cloud on AWSのIPアドレスについて
今回はVMware Cloud on AWS(VMC on AWS)のIPアドレスについて記載していこうと思います。
まず、基盤部分のIPアドレスについて記載していきます。
基盤部分とは以下赤枠のESXi自体やvCenterなどの管理系です。
VMC on AWSはVMware社が提供するマネージドサービスのため、基盤部分についてIPレンジは指定できますがオンプレのようにIPアドレスを個別に指定することはできません。※仮想マシンについてはもちろん自由に指定可能です
ただし、採番規則がありますので参考までに記載しておきます。
1-3オクテットは自由に決めることができます。
ESXi=第4オクテットが68から順に採番
vCenter=第4オクテットが196
NSX Manager=第4オクテットが131
NSX Controller1-3号機=第4オクテットがそれぞれ132,133,134
NSX Edge1-2号機=第4オクテットがそれぞれ135,136
vSAN VMkernerl=第4オクテットが4から順に採番
vMotion VMkernel=第4オクテットが36から順に採番
※vSANとvMotion用IPはESXi毎に1つ必要となります
※管理系は相互に通信する必要がありますので同じセグメントで構成する必要があります。
ESXiの障害時にはIPアドレスがどうなるか説明します。
詳細な挙動は以前のブログを参照頂きたいのですが、障害が発生したESXiはクラスタから自動で離脱します。
その後、自動で新しいESXiが自動で追加されるのですがその際にESXIの68以上で空いている番号が採番されます。
例えばIPアドレスが末尾68,69,70のクラスタでIP68のESXiに障害が起こると、
71番のESXiがクラスタに追加され、障害のあった68はクラスタから離脱します。
その後、もしもESXiを追加することになった場合は、空きとなっている68のIPが採番されます。
IPアドレスが枯渇しないようにリサイクルしてくれる仕組みになっているのだと思われます。
今回記載した内容はあまり意識しないことかと思いますが、IPアドレスを設計書に記載しないといけない人にとって参考になればと思います
VMware Cloud on AWSのホスト追加方法と豆知識
今回はVMware Cloud on AWS(VMC on AWS)のホスト追加方法について記載します。
VMC on AWSはAWSのベアメタルサーバ上でvSphere,vSAN,NSX-Tが稼働しています。
今回はこのベアメタルサーバをクラスタにオンラインで追加してみます
まず、VMCコンソールにログインします。
ログイン後、ホストを増やしたいクラスタで「アクション」→「ホストの追加」を選択します。
次にホストを何台増やしたいか選択します。
今回は3ノードから6ノードにしますので、3ホスト追加します。
新しいSDDCキャパシティが想定通りの数値になっていることを確認してHOSTS追加を押下します。（当然、追加料金が発生しますので注意！）
ホスト追加のリクエストが発行され、5分ほど待機状態となります。
暫くするとメンテナンスモード状態のホストがクラスタに1台追加されます。
3台一気に追加されるわけではなく、1台ずつクラスタに追加される動きです。
vSANクラスタにホストを追加する準備が整った後、ホストのメンテナンスモードが解除されます。
HOSTS追加を押下してから約15分くらいで正常に追加されました。
追加中はVMCコンソール上で追加中のメッセージが表示されます
この処理があと2台分続き、完了するとVMCコンソール上で作業完了した旨のメッセージに変わります。
以上で作業は完了となります。
数クリックで操作でき、1台追加あたり15~20分程度で完了しますので非常に簡単です！
ここからは豆知識ですがVMC on AWSではノードが6以上の場合、SLAがFTT=2以上となります。
FTTとはvSANの機能で「仮想マシンのデータを何重で持つか」の設定値となります。
FTT=0は1重となり、FTT=2は3重でデータを持つ設定となります。画像はFTT=1ですね。
FTT=2ではホストが2台障害になっても仮想マシンは動作し続けることが可能です
ノードが3台ですと仕様上、FTTは0か1しか選択できませんので、vCenterやNSX Managerなどの管理サーバのFTTを2に変更する必要があります。
ですがVMC on AWSではVMC on AWSは自動で管理サーバのFTTを変更してくれます。
作業前は仮想マシンストレージポリシーが「Management Storage Policy-Regular」だった管理サーバ群が作業後は自動でLargeのほうへ移ります。
RegularのほうはFTT=1ですがLargeのほうはFTT=2ですので勝手にデータを3重に持つように変更してくれます。
ちなみに管理サーバ以外のユーザが作成した仮想マシンは自分でFTTを変更する必要があります。
VMC on AWSのストレージは高速のためFTTの変更は数分で完了します。
ちなみに既存のポリシーを変更するのではなく、新しくポリシーを作成しそちらに仮想マシンのポリシーを変更することが推奨のようです。
（KBがあるみたいですが探せず・・・）
仮想マシンのポリシーを変更したあと暫くすると自動でFTTが適用され、ステータスが準拠になります。
以上、今回はクラスタへのホスト追加でした～
