1. はじめに

「VMware Cloud on AWS」でストレッチクラスタを作成したので、備忘録を前編と後編にまとめます。
前編である本稿は、VMworld 2021でのアップデートによって構成可能になった2ホスト構成のストレッチクラスタの作成手順およびvCenterからみた構成画面をご紹介します。

後編では、前編で作成した2ホスト構成を4ホスト構成のストレッチクラスタにスケールアップしてみたので手順含めてご紹介します。

2. そもそもストレッチクラスタって？

VMware Cloud on AWS 環境で、vSANのテクノロジーを活用することで、１つのAWS Region内の２つのAvailability Zone (AZ)にまたがってクラスタをデプロイすることで冗長性を高めます。非ストレッチクラスタ構成(通常のクラスタ)と比べて必要なホスト台数は比べて単純に２倍になりますが、SLAを最大99.99%まで高めることができます。

より正確な定義は、下記のVMware公式サイトからの引用をご参照ください。

VMware Cloud on AWS のストレッチクラスタとは何ですか？

ストレッチクラスタとは、ミッションクリティカルなアプリケーションのために目標復旧ポイント（RPO）ゼロのインフラストラクチャ可用性を実現する機能です。これにより、2 つの AWS アベイラビリティゾーン（AZ）にまたがるクラスタで、RPO ゼロでワークロードをフェイルオーバーできるようになります。開発者がインフラストラクチャの可用性ではなくコアアプリケーションの要件や機能に集中できるというメリットもあります。この機能を使用すると、1 つの SDDC を 2 つのアベイラビリティゾーンにまたがって展開できます。vSAN のストレッチクラスタ機能を利用して、1 つの SDDC クラスタで 2 つのアベイラビリティゾーンへの同期書き込みが実現されます。また、ワークロードの論理ネットワークが拡張されて、アベイラビリティゾーン間の vMotion がサポートされます。一方のアベイラビリティゾーンで障害が発生すると、vSphere HA によってもう一方のアベイラビリティゾーンで仮想マシンが再起動されます。 - 「VMware Cloud on AWS - FAQ」より。

最新のVMware Cloud on AWSのSLA情報は次をご参照ください。

「Service Level Agreement VMware Cloud™ on AWS」
本稿執筆時点では、2ホストおよび4ホストで構成されたストレッチクラスタのSLAは99.9%となります。6ホスト以上で構成されたストレッチクラスタのSLAは99.99%となります。

またストレッチクラスター間のCross-AZデータ通信量は無料(正確には月あたり10PBまで無料)となっています。

3. まずは手順の概要から

実際に私が辿ったおおまかな手順です。
(1)(2)ステップではAWSマネジメントコンソールを利用します。
(3)(4)ステップではVMware Cloudコンソールを利用し、(5)については後編でご紹介します。
本記事では(1)(2)ステップは完了したものとして進めます。ちなみに今回はAWS東京リージョンを選択しています。

(1) SDDCを作成するAWSリージョンにAmazon VPCを作成する
(2) (1)で作成したVPCにおいて、2つの異なるAZにサブネットを作成する
(3) 2ホスト構成のストレッチクラスタを作成する
(4) 仮想マシンをデプロイする
(5) 2ホスト構成のストレッチクラスタを4ホスト構成にスケールアップする

また前提条件として、VMware Cloudコンソール上でAWSアカウントの紐付けは完了しているものとします。
VMware Cloud on AWSのアカウントとVPCについての考え方は、次のAWS公式ブログで解説されているのでご参考ください。

4. i3.metalで2ホスト構成のストレッチクラスタをデプロイ

VMware Cloudコンソールでの作成手順を紹介します。

マルチホストの選択

Depolymentで「Multi Host」「Streched Cluster」を選択します。
デプロイ後に非ストレッチクラスタ構成からストレッチクラスタ構成に変更することは、現時点ではできないのでご注意ください。

AWSアカウントの指定

Connected VPCとして設定するAmazon VPCを所有するAWSアカウントを選択します。

Connected VPCの指定

Connected VPCとして指定するVPCを選択します。今回10.0.0.0/16のCIDRを持つVPCを指定しました。

Subnetの指定

各AZでSDDCからENI接続させる、Connected VPCのSubnetを指定します。

Connected VPCとSubnetの確認

重要なパートなので次に進む前に再度チェックします。

Managment Subnetの指定

vCenterおよびNSXなど、管理系の仮想マシンが稼働するサブネットを指定します。他の検証環境と被らないように今回は172.16.0.0/16のCIDRを指定しました。

設定項目の最終確認

2ホスト構成のストレッチクラスタをデプロイします。

作成されたSDDCを確認

2つのAZにまたがってデプロイされていることを確認します。

5. vCenterからみた2ホスト構成のストレッチクラスタ

デプロイ完了後、vCenterから構成を確認していきます。

ストレッチクラスターの確認

「Cluster-1」に"172.16.32.4"と"172.16.40.4"のManagement IPが付与されたESXiホストがデプロイされています。
２つのAZにまたがってデプロイされていること、「Management Resource Pool」には管理系の仮想マシン(vCenterやNSX-Edgeなど) が稼働していることが確認できます。

[参考] １つのSDDCの中に複数のクラスタが存在する「マルチクラスタ」構成については、「VMware Cloud on AWS マルチクラスタ構成をデプロイしてみた」の過去記事もご参考ください。

また「Cluster-1」とは別に"172.16.128.4"という見慣れぬ3台目のESXiホストが存在しますが、これは「ウィットネスノード」と呼ばれる特別なESXiホストで、ストレッチクラスターの可用性を監視します。
どちらのクラスターあるいはAZに障害が発生した際でも検知できるように、ストレッチクラスターが存在する2つのAZとは別の、第３のAZで稼働しています。「ウィットネスノード」はVMwareが管理運用するのでユーザー側で設定変更もしくは仮想マシンを稼働させることはできません。なお、「ウィットネスノード」に対してユーザー側に課金されることはないのでご安心ください。
より正確な定義は、下記のVMware公式サイトからの引用をご参照ください。

ウィットネスノードとは？

ストレッチクラスタでは、リクエストしたホストのほかに、常に追加の ESXi ホストが 1 台プロビジョニングされます。このホストは「ウィットネスノード」として機能します。これにより、ネットワークが分断された場合にスプリットブレインなどの問題を回避できます。このホストは UI に表示されますが、クラスタのメンバーにはならず、ゲスト仮想マシンを実行することもできません。このホストは、ゲストとして実行される特別なバージョンの ESXi です。ウィットネス ESXi は物理ホストを占有しないため、サービス利用料金の節約になります。 - 「VMware Cloud on AWS - FAQ」より。

vSANのストレッチクラスターでも「監視ホスト」という概念がありましたが、それをVMware Cloud on AWSに適用したものが「ウィットネスノード」となります。

Amazon Web Services ブログ「VMware Cloud on AWSの耐障害性設計に関する考慮事項とベストプラクティス」から図を引用

各ホストの詳細

「Cluster-1」のESXiホスト2台、「ウィットネスノード」を順にご紹介します。
稼働するAZおよび稼働する仮想マシンにご注目ください。

「Cluster-1」のESXiホスト 1台目

Management IP: 172.16.32.4
AZ: ap-northeast-1c
仮想マシン: vCenter, NSX Manager *2台, NSX-Edge *1台

「Cluster-1」のESXiホスト 2台目

Management IP: 172.16.40.4
AZ: ap-northeast-1a
仮想マシン: NSX Manager *1台, NSX-Edge *1台

ウィットネスノード

Management IP: 172.16.128.4
AZ: n/a
仮想マシン: n/a

6. 仮想マシンをデプロイ

VMware Cloud on AWS のスモールスタート時によく引っかかる制約として、
vSphere HAで仮想マシンを保護するために「i3.metalの場合2ノードクラスタでは同時に実行できるユーザー管理の仮想マシン数は最大35台」という制約が現時点ではありますが、2ホスト構成のストレッチクラスター構成ではどうなるか確認してみます。
より詳細はVMware公式サイトからの引用をご参照ください。

How many VM’s can I run on a 2-node Cluster?

While a 2-node cluster supports the same number of VM’s per host as any other configuration, due to Admission Control, a 2-node cluster can power on no more than 36 workload VMs at a time. This is to ensure vSphere HA will be able to restart any running workload in the event of a failure. - 「VMware Cloud on AWS - FAQ」より。※本引用だけ英語ですが、原文の方がより厳密であったのであえてグローバルサイトから引用しています。

仮想マシン1台をデプロイして、Power-Onした場合

仮想マシン36台をデプロイして、35台をPower-Onした場合

デプロイした仮想マシンは合計36台ですが、Power-Onしている仮想マシンは合計35台であることにご注目ください。
また「Management Resource Pool」で稼働する管理系の仮想マシン(vCenterやNSX-Edgeなど)は、ユーザー管理ではないので上記の制約外であることにもご留意ください。

仮想マシン35台をPower-Onした状態で、36台目をPower-Onしようとした場合

下図の通り、サービス側で設定されているポリシーにより、i3.metalの2ホスト構成では36台目の仮想マシンのPower-Onは実行されません。

すでに稼働中の仮想マシン35台には影響を与えませんし、仮想マシンのデプロイ自体は36台以上(例えば仮想マシン50台や100台)可能ですのでご安心ください。
もし別の仮想マシンを稼働したい場合は、すでに稼働中の仮想マシンを一旦Power-Offしてやり、別の仮想マシンをPower-Onしてやります。

仮想マシン36台以上をPower-Onさせたい場合

i3.metal 2ホスト構成のストレッチクラスタにおいて仮想マシン36台以上をPower-Onさせたい場合、ストレッチクラスタをスケールアップする必要があります。(i3en.metalあるいはi4i.metalの2ホスト構成ではこの制約はありません。)

後編で4ホスト構成のストレッチクラスタへのスケールアップ手順、およびvCenterからみた構成画面をご紹介します。

7. 関連記事