1
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

追加検証: VMware Cloud on AWS M7i インスタンス & FSxN (VPC Peering) ウォークスルー

Last updated at Posted at 2024-05-01

1. はじめに

とうとうVMware Cloud on AWS M7iインスタンスが提供開始されたということで、デプロイしてみました。
仮想マシンの作成、HCXのデプロイ、FSxNの別SDDCへの付け替えなども追加で試してみました。

VMware Cloud on AWS M7i インスタンスをデプロイしたので、コンソールから見えてきた様子などを備忘録として残します。

Arch_M7i_FSxN_2.png

本記事の内容は、2024 年 3 月時点での公開情報および個人的なハンズオンの結果をベースにしています。
最新情報については Broadcom 社公式サイトをご確認お願いします。

なお、本記事は前回紹介した内容の追加となります。

2. VMware Cloud on AWS M7i インスタンスをデプロイしてみる

SDDC初期デプロイ

M7i-24xl (DISKLESS)」を2ホスト構成でデプロイすると、初期状態は次のようになります。
M7iインスタンスはディスクレスタイプなので、この時点ではユーザーが利用できるストレージ容量はありません。

(※)ESXiブート領域とマネジメントデータストアは別途サービス側で準備されていますがこの画面上では確認できません。

image.png

vCenterから確認

vCenterにログインし、SDDCのデフォルト状態を確認します。

image.png

ESXiホストのモデルも「Amazon EC2 m7i.metal-24xl」となっていることが確認できます。
image.png

管理系VMのデータストア(managementDatastore)も確認してみます。
よくみるとAmazon FSx for NetApp ONTAP (FSxN)が利用されていることがわかります。
image.png

vCenterやNSXなど、管理系VMが格納されています。
image.png

3. FSxNのNFSデータストアマウント後

VMware Cloud コンソールから確認

作成したVMware Cloud on AWSからFSxN(1TB)をNFSデータストアマウントしてみました。
image.png

Storage容量が反映されています。
image.png

仮想マシンをデプロイしてみる

手持ちのOVFファイルをアップロードして、仮想マシンをいくつかデプロイしました。

デプロイ対象のストレージは当然FSxNを選択します。
image.png

仮想マシンを確認すると、ディスク領域としてFSxNが選択されているのが確認できます。
image.png

データストアからも、作成した仮想マシンを確認できます。
image.png

4. FSxNデタッチ & VPC Peeringの接続解除

今回は一時的な検証環境だったのでSDDCを削除する必要がありました。
一旦FSxNデタッチし、VPC Peeringを接続解除してからSDDCを削除します。その後、別のSDDCからFSxNを再度NFSデータストアマウントします。

NFSデータストアのデタッチ

まずはNFSデータストアとして利用しているFSxNをデタッチします。

image.png

image.png

サクサク進む、と思いきや早速エラーが出ました。
仮想マシンがNFSデータストアに登録されているため、デタッチができないとのこと。
image.png

FSxNをデータストアとして利用している仮想マシンを、「Remoce from Inventory」を実行してインベントリーから登録解除します。
image.png

image.png

同じ作業を繰り返し、FSxNをデータストアとして利用している仮想マシンをすべてインベントリーから登録解除しました。

image.png

image.png

もちろんデータ自体は削除していないので、仮想マシンイメージはFSxNに残り続けています。(#5で再利用します)
image.png

そして再度、NFSデータストアをデタッチします。
image.png

今度こそ処理が進み、1-2分ほどでNFSデータストアのデタッチが完了しました。
image.png

VPC Peeringの接続解除 (VMware Cloudコンソール側作業)

次は、VPC Peeringの接続を解除します。
image.png

対象のVPC Peeringを選択し、「DELETE」を実行します。

image.png

すぐに処理が進み、1分ほどでVPC Peering接続が解除されました。
image.png

NFSデータストアもVPC Peering接続もない初期状態になりました。
image.png

このSDDCはこれ以上利用しないので、SDDCも削除しておきます。

image.png

VPC Peeringの接続解除の後始末 (AWSマネジメントコンソール側作業)

AWSマネジメントコンソールから「VPC」に遷移し、「Peering Connection」を確認します。
VPC Peering接続が解除されたので、当然ながら削除されています。
image.png

ですがルートテーブルには「Target」として残り続けており、Blackholeとなっています。
image.png

不要なルートテーブルのエントリーは削除しておきます。これで後片付けは完了です。
image.png

5. FSxN (NFSデータストア)を別SDDCから再利用し、格納されている仮想マシンを復旧させる

M7i環境でNFSデータストアとして利用したFSxN (Single-AZ, 1TiB)を、今度はI4i環境からNFSデータストアとして再利用してみます。その後、格納されている仮想マシンを再度起動させます。

VMware Cloud on AWS I4i環境の作成

今回はI4iインスタンス x1ホストの環境を作成します。

image.png

作成時点では外部ストレージが存在しないので、内蔵ストレージ(vSAN)のみが利用されています。
image.png

vCenterから見ても、利用できるのは「WorkloadDatastore」のみです。
image.png

I4i環境からFSxNをNFSデータストアマウント

上述のM7i環境と同様に、対象のFSxN (Single-AZ, 1TiB)をNFSデータストアマウントします。
FSxN用VPCとFSxN自体はすでに作成済みなので、この作業はすぐに完了します。

image.png

「Summary」タブからも確認すると、「External Storage」として表示されています。
image.png

vCenterでも同様にNFSデータストアが確認できます。

image.png

FSxNに格納されている仮想マシンをインベントリーに再登録

NFSデータストアの「Files」を確認すると、M7i環境で作成後にインベントリーから登録解除しておいた仮想マシンのイメージデータが確認できます。

image.png

この時点では「VMs」のタブには当然どの仮想マシンも登録されていません。
image.png

「ACTIONS」から「Register VM」を選択します。

image.png

再度インベントリーに登録したい仮想マシン(今回はUbuntu Linux仮想マシン)を選択します。

image.png

任意の仮想マシン名を入力し、選択可能な任意の仮想マシンのフォルダを選択します。
image.png

選択可能な任意のコンピュートリソースを選択します。
image.png

選択内容を最終確認し、「FINISH」に進みます。
image.png

インベントリーに対象の仮想マシンが再度登録できました。
image.png

同じ手順を繰り返し、他の仮想マシンもインベントリーに再度登録します。

image.png

インベントリーに再度登録した仮想マシンの起動

対象の仮想マシンを起動させていきます。
image.png

インベントリーから再度登録したままの状態では、「Network Adapter」の設定が新しい環境に対応できていません。

image.png

「Network Adapter」を利用可能なネットワークに設定変更します。
image.png

設定変更の後、仮想マシンを起動させます。
これで完了です。無事、M7i環境で作成した仮想マシンをI4i環境でも再利用することができました。
image.png

6. おまけ1: VMware Cloud on AWS M7i環境に VMware HCXをデプロイ

作成した VMware Cloud on AWS M7i 環境でVMware HCXをデプロイしてみます。

image.png

image.png

image.png

おっと・・・。
2024年3月時点では、Vmware HCXをM7iインスタンス環境でデプロイする際には各SDDC環境ごとにVMware SupportにSRチケット起票する必要があるようです。

ちなみに他インスタンスタイプ「i3.metal」 「i3en.metal」 「i4i.metal」の場合はVMware Supportへの依頼は必要ありません。

image.png

というわけで、VMware SupportにSRチケットを起票します。
image.png

チケットはすぐに受領され、数営業日後に完了したとの通知あったので、再度HCXのデプロイを実行します。
今度はうまくHCXのデプロイがスタートしました。
image.png

HCXのデプロイ作業が自動で行われます。
image.png

しばし待つと、HCXがデプロイされました。
image.png

管理系VMのデータストア(managementDatastore)の中に格納されています。
image.png

最後にHCXにログインして、完了です!
image.png

VMware Cloud on AWS M7iインスタンスのFAQ

よく見ると、FAQにもM7i環境におけるVMware HCXデプロイについて記載がありました。

image.png

7. 前回記事

8. 参考資料

1
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?