1. はじめに
とうとうVMware Cloud on AWS M7iインスタンスが提供開始されたということで、デプロイしてみました。
仮想マシンの作成、HCXのデプロイ、FSxNの別SDDCへの付け替えなども追加で試してみました。
VMware Cloud on AWS M7i インスタンスをデプロイしたので、コンソールから見えてきた様子などを備忘録として残します。
本記事の内容は、2024 年 3 月時点での公開情報および個人的なハンズオンの結果をベースにしています。
最新情報については Broadcom 社公式サイトをご確認お願いします。
なお、本記事は前回紹介した内容の追加となります。
2. VMware Cloud on AWS M7i インスタンスをデプロイしてみる
SDDC初期デプロイ
M7i-24xl (DISKLESS)」を2ホスト構成でデプロイすると、初期状態は次のようになります。
M7iインスタンスはディスクレスタイプなので、この時点ではユーザーが利用できるストレージ容量はありません。
(※)ESXiブート領域とマネジメントデータストアは別途サービス側で準備されていますがこの画面上では確認できません。
vCenterから確認
vCenterにログインし、SDDCのデフォルト状態を確認します。
ESXiホストのモデルも「Amazon EC2 m7i.metal-24xl」となっていることが確認できます。
管理系VMのデータストア(managementDatastore)も確認してみます。
よくみるとAmazon FSx for NetApp ONTAP (FSxN)が利用されていることがわかります。
3. FSxNのNFSデータストアマウント後
VMware Cloud コンソールから確認
作成したVMware Cloud on AWSからFSxN(1TB)をNFSデータストアマウントしてみました。
仮想マシンをデプロイしてみる
手持ちのOVFファイルをアップロードして、仮想マシンをいくつかデプロイしました。
仮想マシンを確認すると、ディスク領域としてFSxNが選択されているのが確認できます。
4. FSxNデタッチ & VPC Peeringの接続解除
今回は一時的な検証環境だったのでSDDCを削除する必要がありました。
一旦FSxNデタッチし、VPC Peeringを接続解除してからSDDCを削除します。その後、別のSDDCからFSxNを再度NFSデータストアマウントします。
NFSデータストアのデタッチ
まずはNFSデータストアとして利用しているFSxNをデタッチします。
サクサク進む、と思いきや早速エラーが出ました。
仮想マシンがNFSデータストアに登録されているため、デタッチができないとのこと。
FSxNをデータストアとして利用している仮想マシンを、「Remoce from Inventory」を実行してインベントリーから登録解除します。
同じ作業を繰り返し、FSxNをデータストアとして利用している仮想マシンをすべてインベントリーから登録解除しました。
もちろんデータ自体は削除していないので、仮想マシンイメージはFSxNに残り続けています。(#5で再利用します)
今度こそ処理が進み、1-2分ほどでNFSデータストアのデタッチが完了しました。
VPC Peeringの接続解除 (VMware Cloudコンソール側作業)
対象のVPC Peeringを選択し、「DELETE」を実行します。
すぐに処理が進み、1分ほどでVPC Peering接続が解除されました。
NFSデータストアもVPC Peering接続もない初期状態になりました。
このSDDCはこれ以上利用しないので、SDDCも削除しておきます。
VPC Peeringの接続解除の後始末 (AWSマネジメントコンソール側作業)
AWSマネジメントコンソールから「VPC」に遷移し、「Peering Connection」を確認します。
VPC Peering接続が解除されたので、当然ながら削除されています。
ですがルートテーブルには「Target」として残り続けており、Blackholeとなっています。
不要なルートテーブルのエントリーは削除しておきます。これで後片付けは完了です。
5. FSxN (NFSデータストア)を別SDDCから再利用し、格納されている仮想マシンを復旧させる
M7i環境でNFSデータストアとして利用したFSxN (Single-AZ, 1TiB)を、今度はI4i環境からNFSデータストアとして再利用してみます。その後、格納されている仮想マシンを再度起動させます。
VMware Cloud on AWS I4i環境の作成
今回はI4iインスタンス x1ホストの環境を作成します。
作成時点では外部ストレージが存在しないので、内蔵ストレージ(vSAN)のみが利用されています。
vCenterから見ても、利用できるのは「WorkloadDatastore」のみです。
I4i環境からFSxNをNFSデータストアマウント
上述のM7i環境と同様に、対象のFSxN (Single-AZ, 1TiB)をNFSデータストアマウントします。
FSxN用VPCとFSxN自体はすでに作成済みなので、この作業はすぐに完了します。
「Summary」タブからも確認すると、「External Storage」として表示されています。
vCenterでも同様にNFSデータストアが確認できます。
FSxNに格納されている仮想マシンをインベントリーに再登録
NFSデータストアの「Files」を確認すると、M7i環境で作成後にインベントリーから登録解除しておいた仮想マシンのイメージデータが確認できます。
この時点では「VMs」のタブには当然どの仮想マシンも登録されていません。
「ACTIONS」から「Register VM」を選択します。
再度インベントリーに登録したい仮想マシン(今回はUbuntu Linux仮想マシン)を選択します。
任意の仮想マシン名を入力し、選択可能な任意の仮想マシンのフォルダを選択します。
同じ手順を繰り返し、他の仮想マシンもインベントリーに再度登録します。
インベントリーに再度登録した仮想マシンの起動
インベントリーから再度登録したままの状態では、「Network Adapter」の設定が新しい環境に対応できていません。
「Network Adapter」を利用可能なネットワークに設定変更します。
設定変更の後、仮想マシンを起動させます。
これで完了です。無事、M7i環境で作成した仮想マシンをI4i環境でも再利用することができました。
6. おまけ1: VMware Cloud on AWS M7i環境に VMware HCXをデプロイ
作成した VMware Cloud on AWS M7i 環境でVMware HCXをデプロイしてみます。
おっと・・・。
2024年3月時点では、Vmware HCXをM7iインスタンス環境でデプロイする際には各SDDC環境ごとにVMware SupportにSRチケット起票する必要があるようです。
ちなみに他インスタンスタイプ「i3.metal」 「i3en.metal」 「i4i.metal」の場合はVMware Supportへの依頼は必要ありません。
というわけで、VMware SupportにSRチケットを起票します。
チケットはすぐに受領され、数営業日後に完了したとの通知あったので、再度HCXのデプロイを実行します。
今度はうまくHCXのデプロイがスタートしました。
管理系VMのデータストア(managementDatastore)の中に格納されています。
VMware Cloud on AWS M7iインスタンスのFAQ
よく見ると、FAQにもM7i環境におけるVMware HCXデプロイについて記載がありました。
7. 前回記事
8. 参考資料