1. はじめに
「VMware Cloud on AWS」でマルチクラスタ(複数のESXiクラスタが1つのSDDCで稼働させる)を触ってみたので、構成イメージとユースケースについてまとめます。
※マルチAZ構成でVMware Cloud on AWSのクラスタを稼働させる「ストレッチクラスタ」については、まったく異なる構成なので本稿で触れません。次の記事をご参考ください。
カスタムCPUコアについては後続記事をご参考ください。
2. そもそもマルチクラスタって？
マルチクラスタは１つのSDDC環境(つまり1つのvCenter配下)に複数のクラスタがある構成です。
まずVMware Cloud on AWSで1つのSDDCをデプロイすると、1つのクラスタが作成されます。各クラスタの中には複数ホスト(最小1ホスト)のESXiが稼働します。
2.1 例えばこんな構成が可能です
3つの異なるSDDCを東京リージョン、大阪リージョンに配置します。
同じリージョンでもvCenterを分けたい場合や、ワークロードの種別によってクラスタを使い分けたいときなどにも柔軟に対応できるようになっています。
2.2 実際のVMware Cloud on AWS環境で確認してみた
ユーザー(グループ)は、複数のSDDCを管理しています。
１つのSDDCの中に、１つのクラスタだけが存在しています。
１つのSDDCの中に、２つのクラスタが構成されています。(マルチクラスタ)
どちらのクラスタも2ホスト構成ですが、「Cluster-1」はi3.metalを、「Cluster-2」はi3en.metalをデプロイしているのがわかります。
3. コンソール画面からみるマルチクラスタの設定
vCenterからみたマルチクラスタ
オンプレミスでVMware仮想環境を利用されていたら、1つのvCenterで複数のESXiクラスタを管理するのは一般的かと思います。実運用でクラスターを分けるシーンだと例えば、仮想マシンのユースケースごと、ネットワーク管理の体系ごと、物理サーバー導入時期ごと、「vSphere HA」「vSphere DRS」のまとまりごと、などなどいろいろ考えられます。
そういえば「vSphere HA」「vSphere DRS」って何だっけ？という方はこちらVMware社ブログがとても分かりやすいのでご参考ください。
VMware IT価値創造塾「VMware vSphereの基本機能とそのメリットを再確認 そして一歩進んだ仮想基盤の自動化を推進」
VMware Cloud on AWSのvCenterから実際にみてみるとこのようになっています。
「Cluster-1」の「Management Resource Pool」に管理系の仮想マシン(vCenterやNSX-Edgeなど) が稼働しているのが確認できます。「Cluster-2」の方には「Management Resource Pool」は存在せず、vCenter含む管理系の仮想マシンは「Cluster-1」と共通しています。
管理系の仮想マシンは初期作成されたCluster-1でのみ稼働するという点はご留意ください。
またvSANデータストアも、クラスターごとに物理的に分かれてそれぞれ作成されます。
図中では 「vsanDataStore」と「vsanDatastore(1)」となっています。
クラスタの追加
VMware Cloud on AWSのコンソール画面で「ADD Cluster」から簡単に設定できます。2つ目以降のクラスタは最小２ホストからのデプロイになりますが、1つ目のクラスタとは異なるインスタンスタイプ を選択できます。
今回1つ目のクラスタはi3.metalとしたので、2つ目の追加クラスタはi3en.metalを選択しました。
クラスタの削除
削除対象のクラスタを選択して、「Delete Cluster」します。注意点として、削除可能なのは「追加した２つ目のクラスタ」だけです。SDDC作成の際に構成された1つ目のクラスタは、SDDCと一緒にしか削除できません。
クラスタ間の仮想マシン移動
vCenterから操作して仮想マシンをマイグレーション(移行)するなど、オンプレミスの仮想マシンをクラスタ間で移動させるのと同様なオペレーションとなります。
VMware Cloud on AWS環境ではネットワークセグメントはクラスターをまたいでいるので、仮想マシンが所属するクラスターを変更してもネットワークセグメントは維持(同じIPアドレスのまま)とすることができます。
4. 関連記事