Azure VMware Solution第 2 世代プライベートクラウドの設計に関する考慮事項

この記事では、第 2 世代 (Gen 2) プライベートクラウドAzure VMware Solution設計上の重要な考慮事項について説明します。この世代が VMware ベースのプライベートクラウド環境にもたらす機能について説明し、オンプレミスインフラストラクチャとAzureベースのリソースの両方からアプリケーションにアクセスできるようにします。 Azure VMware Solution Gen 2 プライベートクラウドを設定する前に、いくつかの考慮事項を確認する必要があります。この記事では、プライベートクラウドの種類を使用しているときに発生する可能性があるユースケースの解決策について説明します。

注

第 2 世代は、特定のAzureパブリックリージョンで使用できます。対象範囲を確認するには、Microsoft アカウントチームまたはMicrosoft サポートにお問い合わせください。

制限事項

この期間中は、次の機能が制限されます。これらの制限は、今後解除される予定です。

プライベートクラウドを含む リソースグループを削除することはできません。リソースグループを削除する前に、まずプライベートクラウドを削除する必要があります。
Azure仮想ネットワークごとに1 プライベートクラウドのみをデプロイ。
リソースグループごとに作成できるプライベートクラウドは 1 つだけです。 1 つのリソースグループ内の複数のプライベートクラウドはサポートされていません。
プライベートクラウドと、プライベートクラウドの仮想ネットワークは、同じリソースグループに存在する必要があります。
プライベートクラウドの作成後に、プライベートクラウドをリソースグループ間で移動することはできません。
プライベートクラウドの作成後に、プライベートクラウドをテナント間で移動することはできません。
AVS プライベートクラウドに ExpressRoute FastPath または Global Virtual Network ピアリングが必要な場合は、Azure ポータルを使用してサポートケースを作成します。
サービスエンドポイント Azure VMware Solution ワークロードからの直接接続はサポートされていません。
Azure VMware Solution に接続されたプライベートエンドポイントがリージョン間でグローバルにピアリングされている場合はサポートされていません。
プライベートエンドポイントを使用する vCloud Director がサポートされています。ただし、パブリックエンドポイントを使用する vCloud Director はサポートされていません。
vSAN ストレッチクラスター はサポートされていません。
インターネットを構成するための VMware NSX Microsoft Edge へのパブリック IP はサポートされていません。サポートされているインターネットオプションについては、インターネッ接続オプションで確認できます。
ソフトウェア定義データセンター (SDDC) の最初の 4 つのホストのいずれかで、ホストハードウェアの障害などの 計画外のメンテナンス 中に、一部のワークロードで一時的な North-South ネットワーク接続の中断が発生し、最大 30 秒続く場合があります。 North-South 接続とは、AVS VMware ワークロードと、Azure サービスやオンプレミス環境など、NSX-T Tier-0 (T0) Edge を超える外部エンドポイント間のトラフィックを指します。この制限は、特定のAzureリージョンで削除されました。 Azure サポートに問い合わせて、リージョンがこの制限の影響を受けるかどうかを確認します。
プライベートクラウドホスト仮想ネットワークに関連付けられているネットワークセキュリティグループは、プライベートクラウドとその仮想ネットワークと同じリソースグループに作成する必要があります。
お客様の仮想ネットワークから Azure VMware Solution の仮想ネットワークへの、クロスリソースグループ参照およびクロスサブスクリプション参照は、既定ではサポートされていません。これには、ユーザー定義ルート (UDR)、DDoS 保護プラン、その他のリンクされたネットワークリソースなどのリソースの種類が含まれます。お客様の仮想ネットワークが、Azure VMware Solution仮想ネットワークとは異なるリソースグループまたはサブスクリプションに存在するこれらの参照のいずれかに関連付けられている場合、ネットワークプログラミング (NSX セグメント伝達など) が失敗する可能性があります。問題を回避するには、Azure VMware Solution仮想ネットワークが別のリソースグループまたはサブスクリプション内のリソースに接続されていないことを確認する必要があります。続行する前に、DDoS Protection プランなどの接続を仮想ネットワークから削除します。
- リソースグループ間の参照を維持するには、クロスリソースグループまたはサブスクリプションからロールの割り当てを作成し、"AzS VIS Prod App" に "AVS on Fleet VIS ロール" を付与します。ロールの割り当てでは、参照を使用して、Azure VMware Solutionプライベートクラウドに対して参照を正しく適用できます。
Gen 2 プライベートクラウド 展開は、Azure ポリシーでネットワークセキュリティグループまたはルートテーブル (特定の名前付け規則など) に厳密な規則が適用されている場合に失敗する可能性があります。これらのポリシー制約により、展開中にAzure VMware Solutionのネットワークセキュリティグループおよびルートテーブルの作成がブロックされる可能性があります。プライベートクラウドをデプロイする前に、Azure VMware Solution仮想ネットワークからこれらのポリシーを削除する必要があります。プライベートクラウドがデプロイされたら、これらのポリシーを Azure VMware Solution プライベートクラウドに追加し直すことができます。
Azure VMware Solution Gen 2 プライベートクラウドがデプロイされている仮想ネットワークで Custom DNS を使用して、Azure VMware Solution Gen 2 プライベートクラウドにプライベート DNS を使用している場合は、サポートされていません。カスタム DNS を使用すると、スケーリング、アップグレード、修正プログラムの適用などのライフサイクル操作が中断されます。
プライベートクラウドを削除していて、Azure VMware Solution によって作成されたリソースの一部が削除されない場合は、Azure CLI を使用して Azure VMware Solution のプライベートクラウドの削除を再試行できます。
Azure VMware Solution Gen 2 では、HTTP プロキシを使用して、顧客と管理のネットワークトラフィックを区別します。一部の VMware クラウドサービスエンドポイント は、一般的な vCenter で管理されるトラフィックと同じネットワークパスまたはプロキシ規則に従わない場合があります。たとえば、"scapi.vmware" や "apigw.vmware" などがあります。VAMI プロキシは、vCenter Server Appliance (VCSA) の一般的な送信インターネットアクセスを制御しますが、すべてのサービスエンドポイントの対話がこのプロキシを経由するわけではありません。一部の対話は、ユーザーのブラウザーまたは統合コンポーネントから直接発生します。その代わりに、ワークステーションのプロキシ設定に従うか、個別に接続を開始します。その結果、VMware クラウドサービスエンドポイントへのトラフィックが VCSA プロキシを完全にバイパスする可能性があります。
Gen 2 での HCX RAV および一括移行では、基本同期とオンライン同期のフェーズ中にストールが発生するため、パフォーマンスが低下する可能性があります。お客様は、より長い移行期間を計画し、現時点では段階的なスケジュールを立てる必要があります。適切なワークロードに対して、vMotion は、ホストとネットワークの条件が許す場合に、より高速でオーバーヘッドの少ないオプションを提供します。
仮想ハブ (仮想 WAN) ピアリング: Gen-2 仮想ネットワークと仮想ハブ (仮想 WAN) の間にピアリング接続を確立するには、仮想ハブが Gen-2 仮想ネットワークと同じリージョンにある必要があります。別のリージョンの仮想ハブとピアリングする必要がある場合は、Azure ポータルを使用してサポートケースを作成する必要があります。
ピアリングされたVirtual Network (VNET) からのルート宛先の/32: NSX から /32 ルート (HCX MON ルートや DNS フォワーダールートなど) をアドバタイズしていて、ピアリングされたvirtual networkからその /32 宛先にアクセスする必要がある場合は、Azure ポータルでサポートケースを開く必要があります。 /32 宛先への接続は、ローカル VNET 内から正しく機能します。
VNET ピア同期サブネットアドバタイズメントと Azure ルートテーブル (UDR) の関連付け - Azure VMware Solution Gen 2 では、2 つの内部アーキテクチャが利用されます。現在のアーキテクチャでは、NSX セグメントまたはサブネットルートの特定のサブネットと、より広いAzureアドレス空間の両方が、ピアリングされたAzure仮想ネットワークと同期されます。その結果、Gen 2 の現在のアーキテクチャでは、Azure VMware Solutionワークロードセグメントに一般的なアドレス空間ルートを使用するのではなく、より具体的な NSX セグメントサブネットルートを使用してAzure ルートテーブル (UDR) を構成する必要がある場合があります。

サポートされていない統合

次のファーストパーティとサードパーティの統合は使用できません。

Zerto DR

Gen 2 の委任されたサブネットとネットワークセキュリティグループ

Azure VMware Solution (AVS) Gen 2 プライベートクラウドがデプロイされると、Azureはプライベートクラウドのホスト仮想ネットワーク内に複数の委任されたサブネットを自動的に作成します。これらのサブネットは、プライベートクラウドの管理コンポーネントを分離して保護するために使用されます。

これらのサブネットへのアクセスは、Azure ポータルまたは Azure CLI/PowerShell で表示されるネットワークセキュリティグループ (NSG) を使用して管理できます。 AVS は、顧客が管理できる NSG に加えて、システムで管理される追加の NSG を重要な管理インターフェイスに適用します。これらのシステム管理 NSG は、お客様が表示または編集することはできず、プライベートクラウドが既定でセキュリティで保護された状態を維持するために存在します。

既定のセキュリティ体制の一部として、次の手順を実行します。

お客様が明示的に有効にしない限り、プライベートクラウドのインターネットアクセスは無効になります。
必要な管理トラフィックのみがプラットフォームサービスに到達できます。

注

Azure ポータルに、特定のポートがインターネットに公開されているように見えるという警告が表示されることがあります。これは、ポータルが顧客が認識できるネットワークセキュリティグループ (NSG) 構成のみを評価するためです。ただし、Azure VMware Solutionでは、ポータルに表示されない追加のシステム管理ネットワークセキュリティグループも適用されます。これらのシステム管理ネットワークセキュリティグループは、Azure VMware Solution構成によってアクセスが明示的に有効になっていない限り、受信トラフィックをブロックします。

この設計により、AVS 環境はセキュリティで保護され、既定で分離され、顧客はニーズに合わせてネットワークアクセスを管理および調整できます。

ルーティングとサブネットに関する考慮事項

Azure VMware Solution Gen 2 プライベートクラウドは、オンプレミスおよびAzureベースの環境またはリソースからユーザーとアプリケーションからアクセスできる VMware プライベートクラウド環境を提供します。接続は、標準の Azure ネットワーク経由で配信されます。これらのサービスを有効にするには、特定のネットワークアドレス範囲とファイアウォールポートが必要です。このセクションは、Azure VMware Solutionで動作するようにネットワークを構成する際に役立ちます。

プライベートクラウドは、標準のAzure ネットワークを使用してAzure仮想ネットワークに接続します。 Azure VMware Solution Gen 2 プライベートクラウドでは、サブネットには少なくとも /22 CIDR ネットワークアドレスブロックが必要です。このネットワークによってオンプレミスのネットワークが補完されるため、アドレスブロックは、サブスクリプションの他の仮想ネットワークやオンプレミスネットワークで使用されているアドレスブロックと重複しないようにする必要があります。管理、vMotion、レプリケーションのネットワークは、仮想ネットワーク内のサブネットとしてこのアドレスブロック内に自動的にプロビジョニングされます。

注

アドレスブロックで許可される範囲は RFC 1918 プライベートアドレス空間 (10.0.0.0/8、172.16.0.0/12、192.168.0.0/16) です。ただし、172.17.0.0/16 を除きます。レプリケーションネットワークは AV64 ノードには適用されず、将来の一般的な非推奨となる予定です。

VMware NSX の使用のために予約されている次の IP スキーマを使用しないでください。

169.254.0.0/24 - 内部転送ネットワークに使用
169.254.2.0/23 - VRF 間転送ネットワークに使用
100.64.0.0/16 - T1 および T0 ゲートウェイを内部的に接続するために使用
100.73.x.x – Microsoft の管理ネットワークで使用されます

注

表に示されているサブネットのほとんどは、Azure仮想ネットワーク内のサブネットとして表示されます。これらのサブネット構成は、Azure VMware Solution コントロールプレーンによって管理され、変更によって悪影響が生じる可能性があるため、これらのサブネット構成に手動で変更を加えないでください。

/22 CIDR ネットワークアドレスブロック 10.31.0.0/22 の例は、次のサブネットに分かれています。

ネットワークの使用状況	サブネット	説明	例
VMware NSX ネットワーク	/27	NSX Manager ネットワーク。	10.31.0.0/27
vCSA ネットワーク	/27	vCenter Server ネットワーク。	10.31.0.32/27
avs-mgmt	/27	管理アプライアンス (vCenter Server、NSX マネージャー、HCX クラウドマネージャー) は、このサブネットのセカンダリ IP 範囲としてプログラムされた "avs-mgmt" サブネットの背後にあります。管理アプライアンスのネットワークトラフィックが NVA またはファイアウォールを経由してルーティングする必要がある場合は、このサブネットに関連付けられているルートテーブルを調整することが必要になる場合があります	10.31.0.64/27
avs-vnet-sync	/27	Azure VMware Solution Gen 2 によって、VMware NSX で作成されたルートを仮想ネットワークにプログラムするために使用されます。	10.31.0.96/27
avs-services	/27	Azure VMware Solution Gen 2 プロバイダーサービスに使用されます。プライベートクラウドのプライベート DNS 解決を構成するためにも使用されます。	10.31.0.224/27
avs-nsx-gw、avs-nsx-gw-1	/27	2 つの avs-nsx-gw サブネットは、Azure VMware Solutionから Virtual Network 以降へのすべての送信トラフィックを処理します。そのため、すべてのシナリオで、Azureルートテーブル (UDR) とネットワークセキュリティグループ (NSG) をこれらのサブネットに適用する必要があります。初期 AVS Gen-2 プライベートクラウドでは、これらのサブネットも受信トラフィックを管理し、すべての NSX セグメントサブネットをセカンダリ IP として構成します。現在の AVS Gen-2 プライベートクラウドでは、"avs-network-infra-gw" と呼ばれる 3 つ目のサブネットが追加され、すべての受信トラフィックが処理されます。これで、すべての NSX セグメントが、avs-nsx-gw サブネットではなく、このサブネットに割り当てられます。	10.31.0.128/27, 10.31.0.160/27
AVSネットワークインフラゲートウェイ (avs-network-infra-gw)	/26	このサブネットが存在する場合、VNET からのすべての NSX ワークロードの受信トラフィックを処理し、Azure VMware Solution管理によって NSX セグメントサブネットをセカンダリ IP として構成するために使用されます。 Azureルートテーブルをこのサブネットに関連付けないようにします。代わりに、"avs-nsx-gw" サブネットを使用して、Azure Firewallやサードパーティのネットワーク仮想アプライアンス (NVA) などの送信 AVS トラフィックを管理します。	10.31.2.128/26
esx-mgmt-vmk1	/25	vmk1 は、顧客がホストにアクセスするために使用する管理インターフェイスです。 vmk1 インターフェイスからの IP は、これらのサブネットから取得されます。すべてのホストのすべての vmk1 トラフィックは、このサブネット範囲から送信されます。	10.31.1.0/25
esx-vmotion-vmk2	/25	vMotion VMkernel インターフェイス。	10.31.1.128/25
esx-vsan-vmk3	/25	vSAN VMkernel インターフェイスとノード通信。	10.31.2.0/25
予約済み	/27	予約済みの領域。	10.31.0.128/27
予約済み	/27	予約済みの領域。	10.31.0.192/27

注

Azure VMware Solution Gen 2 のデプロイでは、SDDC デプロイ中に入力された /22 に加えて、HCX 管理とアップリンク用に 2 つの追加の /24 サブネットを割り当てる必要があります。 AVS Gen 2 では、HCX mgmt と HCX アップリンクサブネットのみが必要です。 VMotion とレプリケーションネットワークは、AVS Gen 2 には必要ありません。

Azure Virtual Network への NSX ルートのプログラミング

Azure VMware Solution Gen-2 NSX ルートは、アドレス空間を使用してAzureに統合され、"avs-network-infra-gw" システムによって作成されたサブネット上のセカンダリ IP として割り当てられるので、Azureと AVS の顧客ワークロード間のスムーズな接続が可能になります。 NSX Tier-0 がユーザー設定 (セグメントの作成、静的ルートの追加、HCX MON 仮想マシンの使用など) に基づいてルートをアドバタイズする場合、Azure VMware Solutionコントロールプレーンは、ルートプレフィックスが仮想ネットワークアドレス空間に存在するかどうかを確認します。そうでない場合は、アドレス空間が作成され、"avs-network-infra-gw" サブネットにセカンダリ IP としてルートプレフィックスが追加されます。 HCX MON ルートなどの Tier-0 アドバタイズされた /32 ルートの場合、セカンダリ IP は設定されませんが、データプレーンは内部的に構成され、Azure VMware Solution上の /32 宛先への接続が確保されます。

NSX ルートのアドレス空間とサブネットの更新に加えて、特に低いサブネットマスクが使用される場合にサポートされるスケールに関して、お客様が認識する必要がある内部プログラミングがあります。スケールの側面の詳細については、「Azure VMware Solution Gen 2Route アーキテクチャ」を参照してください>

Azure ルートテーブル (UDR) の関連付けの考慮事項

Azure VMware Solution Gen-2 には、わずかなバリエーションを持つ 2 つの内部アーキテクチャが含まれています。最初の Gen-2 プライベートクラウドの一部では、初期内部アーキテクチャが使用されます。これらは、スケジュールされたメンテナンスを通じて現在のアーキテクチャに更新され、顧客と調整されます。ただし、次に示すように、最初のアーキテクチャと比較して、現在のアーキテクチャの動作が変更されています。これは、特定のネットワーク設計上の考慮事項に影響する可能性があります。

初期 Gen-2 プライベートクラウド:

Azure VNET には、"avs-nsx-gw" という名前の 2 つのベースゲートウェイサブネットがあり、現在のアーキテクチャのように "avs-network-infra-gw" サブネットがありません。
すべての AVS NSX セグメントサブネットは、"avs-nsx-gw" サブネットの下に、Azureを NSX ワークロードに接続するための追加の IPv4 アドレスとしてプログラミングされます。
AVS から Azure VNET 以降 (オンプレミスなど) へのトラフィックのルートテーブル (UDR) またはAzure NSG を "avs-nsx-gw" サブネットに適用する必要があります。

現在の Gen-2 プライベートクラウド:

この動作の変更に注意してください。

Azure VNET では、最初のアーキテクチャのように、"avs-network-infra-gw" というプレフィックスが付いた追加のサブネットと、"avs-nsx-gw" という名前の 2 つのベースゲートウェイサブネットが表示されます。
すべての AVS NSX セグメントサブネットは、このサブネットの下に、Azureを NSX ワークロードに接続するためのセカンダリ IPv4 アドレスとしてプログラミングされるようになりました。これにより、お客様のネットワーク接続は変更されません。
VNET ピアリングでは、アドレス空間とサブネットの両方がピアリング先の VNET に通知されます。これは、アドレス空間のみが同期される初期アーキテクチャや Azure ネイティブの VNET 同期とは異なります。

Gen-2 内部アーキテクチャの変更による設計上の考慮事項

お客様は、VNET ピア同期動作の変更により、ピアリングされた VNET 内の AVS サブネットの追加の有効なルートを確認します。
お客様が Azure ルートテーブル (UDR) を使用して、ファイアウォールまたはネットワーク仮想アプライアンス経由でオンプレミスから AVS にトラフィックを送信する場合は、以前に使用した広範なスーパーネットアドレス範囲ではなく、特定の NSX サブネットルートを使用するように UDR を更新する必要があります。これは、Azure ルーティングの最長プレフィックス一致動作により、AVS 宛てのトラフィックがより具体的な VNET サブネットルートを使用して意図したファイアウォールをバイパスしてしまうのを防ぐために必要です。そうしないと、非対称ルーティングが発生し、接続の問題が発生する可能性があります。
ただし、AVS から Azure VNET 以降 (オンプレミスなど) へのトラフィックのルートテーブル (UDR) またはAzure NSG は、"avs-network-infra-gw" ではなく"avs-nsx-gw" サブネットに引き続き適用されます。 NSX セグメントサブネットがセカンダリ IP として構成されている場合でも、"avs-network-infra-gw" サブネットでルートテーブル (UDR) を使用しないでください。

次のステップ

前提条件として、Azure VMware Solution サービスプリンシパルの構成を開始します。その方法については、Azure VMware Solution サービスプリンシパルの有効化のクイックスタートをご覧ください。
Azure VMware Gen 2 プライベートクラウドの作成

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-05-14