Azure VMware Solutionとは

Azure VMware Solutionは、専用のベアメタル Azure インフラストラクチャから構築された VMware vSphere クラスターを含むプライベート クラウドを提供します。 Azure VMware Solutionは、Azure商用およびAzure Governmentで利用できます。 最小の初期デプロイは 3 ホストですが、クラスターあたり最大 16 ホストまで追加するオプションがあります。 プロビジョニングされたすべてのプライベート クラウドに VMware vCenter Server、VMware vSAN、VMware vSphere、VMware NSX があります。 その結果、オンプレミス環境からワークロードを移行し、新しい仮想マシン (VM) をデプロイし、プライベート クラウドからAzureサービスを使用できます。 SLA の詳細については、「Azure サービス レベル アグリーメント」ページを参照してください。

Azure VMware Solutionは、拡張機能とアップグレードの継続的な検証とテストを行う VMware 検証済みソリューションです。 プライベート クラウドのインフラストラクチャとソフトウェアは Microsoft によって管理および保守されるため、ユーザーはプライベート クラウドでのワークロードの開発と実行に専念できます。

この図は、Azure、Azure サービス、オンプレミス環境のプライベート クラウドと VNet の間の隣接関係を示しています。 プライベート クラウドから Azure サービスまたは VNet へのネットワーク アクセスにより、Azure サービス エンドポイントの SLA 駆動型統合が提供されます。 ExpressRoute Global Reach は、オンプレミス環境をAzure VMware Solutionプライベート クラウドに接続します。

Azure VMware Solution のプライベート クラウドタイプ

Azure VMware Solutionでは、次の 2 つの異なるプライベート クラウド世代が提供されます。

1. 第 1 世代Azure VMware Solutionは、Azure データセンター施設にデプロイされた専用のベアメタル ホストから構築された VMware vSphere クラスターを提供します。 Microsoft が管理ExpressRoute 回線は、VMware vSphere ホストと仮想ネットワークにデプロイされたネイティブ Azure リソース間の接続を提供します。

2. Azure VMware Solution第 2 世代 は、専用のAzureベア メタル ホストから構築された VMware vSphere クラスターを提供します。 Azure VMware Solution第 2 世代では、VMware vSphere ホストが Azure Virtual Networks に直接接続される、更新されたネットワーク アーキテクチャが備わります。 このオファリングは、AV64 SKU でのみサポートされます。

ホスト、クラスター、およびプライベート クラウド

Azure VMware Solution クラスターは、ハイパーコンバージド インフラストラクチャに基づいています。 次の表に、ホストの CPU、メモリ、ディスク、およびネットワークの仕様を示します。

Azure VMware Solution クラスターには、少なくとも 3 つのホストが必要です。 同じ種類のホストは、1 つのAzure VMware Solutionプライベート クラウドでのみ使用できます。 クラスターの構築またはスケーリングに使用されるホストは、ホストの分離プールから取得されます。 これらのホストはハードウェア テストに合格しており、クラスターに追加される前にすべてのデータが安全に削除されました。

上記のすべてのホストの種類には、100 Gbps のネットワーク インターフェイス スループットがあります。

*詳細は、Azure料金計算ツールから入手できます。

**AV64 の前提条件: AV64 を追加する前に、AV36、AV36P、または AV52 でデプロイされたAzure VMware Solutionプライベート クラウドが必要です。

Raw は、ディスクメーカーから報告された 国際単位規格 (SI) に基づいています。 例: 1 TB Raw = 100000000000 バイト。 バイナリ (1 TB バイナリ = 1099511627776 バイト バイナリ) でコンピューターによって計算される領域は、生の 10 進数から変換された 931.3 ギガバイトに相当します。

ESA は AV64 Gen 2 の展開に適用されます。

Azure ポータルまたはAzure CLIを使用して、新規または既存のプライベート クラウドをデプロイできます。

AV64 ノード サイズを使用したプライベート クラウド拡張機能のAzure VMware Solution

AV64 は Azure VMware Solution ホスト SKU であり、既存の AV36、AV36P、または AV52 SKU で構築されたAzure VMware Solutionプライベート クラウドを拡張するために使用できます。 AV64 を直接デプロイする場合は、Azure Virtual Networkで Azure VMware Solution を参照してください。 リージョンでの AV64 SKU の可用性を確認するには、Microsoft ドキュメントを参照してください。

AV36、AV36P、および AV52 での AV64 拡張の前提条件

AV64 クラスターをデプロイするには、次の前提条件を参照してください。

• Azure VMware ソリューションプライベート クラウドは、AV36、AV36P、AV48、または AV52 を使用して、AV64 でサポートされている 地域/AZ に作成されます。

• AV64 クラスターの管理用に、1 つの /23 アドレス ブロックまたは 3 つの (連続または非連続) /25 アドレス ブロックが必要です。

顧客シナリオのサポート可能性

既存のAzure VMware Solutionプライベート クラウドを使用するCustomer: 顧客がプライベート クラウドAzure VMware Solutionデプロイされている場合は、別の AV64 vCenter ノード クラスターをそのプライベート クラウドに追加することで、プライベート クラウドをスケーリングできます。 このシナリオでは、お客様は次の手順を使用する必要があります。

1. 少なくとも 3 つのノードを使用して、AV64 クォータの承認を Microsoft から取得します。 AV64 を使用して拡張する予定のAzure VMware Solutionプライベート クラウドに関するその他の詳細を追加します。
2. AV64 ホストと共に既存のAzure VMware Solution追加クラスター ワークフローを使用して展開します。

Customer は、新しいAzure VMware Solutionプライベート クラウドの作成を計画しています: AV64 SKU を使用できるが拡張にのみ使用できる新しいAzure VMware Solutionプライベート クラウドが顧客に必要な場合。 この場合、お客様は、AV36、AV36P、または AV52 SKU を使用してAzure VMware Solutionプライベート クラウドを構築する前提条件を満たしています。 お客様は、AV64 を使用して拡張する前に、AV36、AV36P、または AV52 SKU の少なくとも 3 つのノードを購入する必要があります。 このシナリオでは、次の手順を使用します。

1. 少なくともそれぞれ 3 つのノードを使用して、AV36、AV36P、または AV52、および AV64 クォータの承認を Microsoft から取得します。
2. AV36、AV36P、または AV52 SKU を使用して、Azure VMware Solutionプライベート クラウドを作成します。
3. AV64 ホストと共に既存のAzure VMware Solution追加クラスター ワークフローを使用して展開します。

Azure VMware Solution ストレッチ クラスター プライベート クラウド: Azure VMware Solution のストレッチ クラスター プライベート クラウドでは、AV64 SKU はサポートされていません。 つまり、av64 ベースの拡張は、Azure VMware Solutionストレッチ クラスターのプライベート クラウドでは実行できません。

AV64 拡張機能を使用した vMotion 互換性 (EVC) の強化

AV64 ノードをAzure VMware Solutionプライベート クラウドに追加すると、異種環境が作成されます。その結果、AV64 クラスターと AV36、AV36P、または AV52 SKU を使用する AV64 クラスターとベース SKU クラスター間で、Enhanced vMotion Compatibility (EVC) の問題が発生します。 AV64 クラスターでは、Intel Icelake CPU が原因で Icelake EVC モードが使用されますが、以前の Intel CPU 上に構築された AV36、AV36P、および AV52 クラスターでは、明示的な EVC モードは有効になっていません。 各 SKU の CPU 世代の詳細については、上記を参照してください。

クラスター間の EVC モードの異種性は、特定のシナリオと移行の方向に基づいて Broadcom によって定義されるライブ vMotion 操作の課題を示します。 次のセクションでは、AV64 とベース クラスターの間でライブ vMotion を実行するときのユーザー エクスペリエンスの概要を示します。

• ベース SKU クラスターから AV64 クラスターへの vMotion – 仮想マシンが下位 EVC モード クラスターから上位の EVC モード クラスターに vMotioned されるため、これは正常に動作します。

• AV64 クラスターから基本 SKU クラスターへの vMotion - 2 つのシナリオ

  • 仮想マシンが以前にベース クラスターから移動され、電源が入っていない場合、ライブ vMotion は成功します。

  • 仮想マシンが AV64 クラスターで作成されたか、電源が切れた場合、以前はベース SKU クラスターから vMotion が実行されていた場合でも、ライブ vMotion は EVC 互換性エラーで失敗します。

ベース SKU と AV64 クラスターの間のライブ vMotion の問題を回避するには、下位のベース クラスター EVC に一致するように VM レベルの EVC モードを設定するか、仮想マシンの電源をオフにしてコールド vMotion を実行します。

AV64 クラスター vSAN 障害ドメイン (FD) の設計と推奨事項

従来のAzure VMware Solution ホスト クラスターには、明示的な vSAN FD 構成がありません。 その理由は、ホスト割り当てロジックによって、クラスター内で、2 つのホストが、Azure リージョン内の同じ物理障害ドメインに存在しないようにすることです。 この機能は本質的に、vSAN FD 構成によって実現される必要があるストレージの回復性と高可用性をもたらします。 vSAN FD の詳細については、VMware のドキュメントを参照してください。

Azure VMware Solution AV64 ホスト クラスターには、明示的な vSAN 障害ドメイン (FD) 構成があります。 Azure VMware Solutionコントロール プレーンは、AV64 クラスター用に 7 つの vSAN 障害ドメイン (FD) を構成します。 ユーザーがクラスター内のホストを 3 個のノードから 16 個のノードにスケールアップすると、ホストは 7 つの FD 間で均等に分散されます。 一部のAzure リージョンでは、AV64 SKU の初期リリースの一環として最大 5 つの FD がサポートされます。 詳細については、Azureホスト型マッピング テーブルへのリージョン可用性ゾーンを参照してください。

クラスター サイズに関する推奨事項

サポートされている vSphere ノードの最小クラスター サイズAzure VMware Solutionは 3 です。 vSAN のデータの冗長性は、3 つのホストの最小クラスター サイズが、確実に異なる vSAN FD に存在するようにすることで処理されます。 3 つのホストがあり、それぞれが異なる FD 内にある vSAN クラスターでは、FD に障害が発生した場合 (たとえば、ラック スイッチの上部に障害が発生した場合) でも、vSAN データは保護されます。 オブジェクトの作成 (新しい VM、VMDK など) などの操作は失敗します。 ESXi ホストがメンテナンス モードになったり、再起動されたりするメンテナンス アクティビティにも同じことが当てはまります。 このようなシナリオを回避するには、少なくとも 4 つの ESXi ホストを含む vSAN クラスターをデプロイすることをお勧めします。

AV64 ホストの削除ワークフローとベスト プラクティス

AV64 クラスター vSAN 障害ドメイン (FD) 構成と、すべての FD 間で分散されたホストが必要であるため、AV64 クラスターからのホストの削除は、従来の Azure VMware Solution ホスト クラスターと他の SKU とは異なります。

現在、ユーザーは、ポータルまたは API を使用して、クラスターから削除する 1 つ以上のホストを選択できます。 1 つの条件として、クラスターには、少なくとも 3 つのホストが必要です。 ただし、AV64 クラスターは、AV64 で vSAN FD を使用する場合、特定のシナリオで動作が異なります。 ホスト削除要求は、vSAN FD の不均衡の可能性についてチェックされます。 ホスト削除要求によって不均衡が生じる場合、要求は拒否され、http 409-Conflict 応答が返されます。 http 409-Conflict 応答状態コードは、要求がターゲットのリソース (ホスト) の現在の状態と競合していることを示します。

次の 3 つのシナリオは、通常エラーが出力されるインスタンスの例を示しており、vSAN 障害ドメイン (FD) の不均衡を生じさせることなくホストを削除するために使用できるさまざまな方法を示しています。

• ホストを削除すると、vSAN FD の不均衡が生じ、最も多く実装されている FD と最も少なく実装されているものの間のホストの差が複数になります。 次の例では、ユーザーは他の FD からホストを削除する前に、FD 1 からホストの 1 つを削除する必要があります。

  

• 複数のホスト削除要求が同時に行われ、特定のホストの削除によって不均衡が生じます。 このシナリオでは、Azure VMware Solution コントロール プレーンによってホストのみが削除され、不均衡は発生しません。 次の例では、ユーザーは、クラスター サイズを 4 以下に削減しない限り、同じ FD から両方のホストを削除できません。

  

• 選択したホストを削除すると、アクティブな vSAN FD が 3 つ未満になります。 すべての AV64 リージョンに 5 つまたは 7 つの FD がある場合、このシナリオは発生しないと予測されます。 ホストの追加中、Azure VMware Solution コントロール プレーンは、7 つの FD すべてからホストを均等に追加します。 次の例では、ユーザーは、FD 1 からホストの 1 つを削除できますが、FD 2 または 3 からはできません。

  

vSAN FD の不均衡を生じることなく削除できるホストを特定する方法: ユーザーは、vSphere クライアント インターフェイスに移動して、vSAN FD とそのそれぞれに関連付けられたホストの現在の状態を取得できます。 これは、vSAN FD のバランスに影響を与えることなく削除できるホストを (前の例に基づいて) 特定し、削除操作のエラーを回避するのに役立ちます。

AV64 でサポートされる RAID 構成

次の表は、AV64 クラスターでサポートされる RAID 構成とホスト要件の一覧を示しています。 一部のリージョンでは、AV64 SKU で RAID-6 FTT2 および RAID-1 FTT3 ポリシーがサポートされています。 現在 5 つの FD に制限されているAzureリージョンでは、お客様は、サービス レベル アグリーメント (SLA) を満たすために、6 つ以上のノードを持つ AV64 クラスターに対して RAID-5 FTT1 vSAN ストレージ ポリシーを使用できます。 詳細については、Azureホスト型マッピング テーブルへのリージョン可用性ゾーンを参照してください。

Storage

Azure VMware Solutionでは、Azure ストレージ サービスを使用して vSAN に含まれる容量を超えるデータストア容量の拡張がサポートされるため、クラスターをスケーリングせずにデータストア容量を拡張できます。 詳細については、「データストアの容量拡張オプション」を参照してください。

ネットワーク

Azure VMware Solutionでは、オンプレミスサイトとAzureベースのリソースからアクセスできるプライベート クラウド環境が提供されます。 Azure ExpressRoute、VPN 接続、Azure Virtual WANなどのサービスが接続を提供します。 しかし、これらのサービスでは、サービスを有効にするために特定のネットワーク アドレス範囲とファイアウォール ポートが必要になります。

プライベート クラウドをデプロイすると、管理、プロビジョニング、vMotion 用のプライベート ネットワークが作成されます。 これらのプライベート ネットワークを使用して、VMware vCenter Server と VMware NSX Manager、仮想マシンの vMotion またはデプロイにアクセスします。

ExpressRoute Global Reach は、プライベート クラウドをオンプレミス環境に接続するために使用されます。 Microsoft Edgeレベルで回路を直接接続します。 この接続には、サブスクリプション内にオンプレミスへの ExpressRoute 回線がある仮想ネットワーク (vNet) が必要です。 その理由は、vNet ゲートウェイ (ExpressRoute ゲートウェイ) ではトラフィックを転送できないからです。すなわち、2 つの回線を同じゲートウェイに接続できますが、一方の回線から他方にトラフィックが送信されません。

各Azure VMware Solution環境は、独自の ExpressRoute リージョン (独自の仮想 MSEE デバイス) であり、Global Reach を "ローカル" ピアリングの場所に接続できます。 これにより、1 つのリージョン内の複数のAzure VMware Solution インスタンスを同じピアリングの場所に接続できます。

プライベート クラウドにデプロイされた仮想マシンは、Azure Virtual WANパブリック IP 機能を介してインターネットにアクセスできます。 新しいプライベート クラウドでは、インターネット アクセスが既定で無効になっています。

詳細については、ネットワーク アーキテクチャに関するページを参照してください。

アクセスとセキュリティ

プライベート クラウドAzure VMware Solutionは、セキュリティ強化のために vSphere ロールベースのアクセス制御を使用します。 vSphere SSO LDAP 機能をMicrosoft Entra IDと統合できます。 詳細については、アクセスと ID のアーキテクチャに関するページを参照してください。

vSAN の保存データの暗号化は既定で有効になっており、vSAN データストアのセキュリティを提供するために使用されます。 詳細については、ストレージ アーキテクチャに関するページを参照してください。

データ所在地と顧客データ

Azure VMware Solutionは顧客データを格納しません。

VMware ソフトウェアのバージョン

次の表に、Azure VMware Solutionプライベート クラウドの新しいデプロイで使用されるソフトウェア バージョンを示します。

リストされているビルド番号がリリース ノートに記載されているビルド番号と一致しない場合は、クラウド プロバイダーにカスタム パッチが適用されたためです。

vCenter Server バージョンでサポートされている場合、現在実行中のソフトウェア バージョンは、既存のプライベート クラウドに追加される新しいクラスターに適用されます。

ホストとソフトウェアのライフサイクル メンテナンス

Azure VMware Solutionプライベート クラウドと VMware ソフトウェアの定期的なアップグレードにより、最新のセキュリティ、安定性、および機能セットがプライベート クラウドで実行されます。 詳細については、「ホストのメンテナンスとライフサイクル管理」を参照してください。

プライベート クラウドの監視

サブスクリプションにAzure VMware Solutionをデプロイすると、Azure Monitor ログが自動的に生成されます。

プライベート クラウドでは、次のことが可能です。

• 各 VM でログを収集する。
• MMA エージェントを Linux および Windows VM にダウンロードしてインストールします。
• Azure診断拡張機能を有効にします。
• 新しいクエリを作成して実行する。
• VM で通常実行するものと同じクエリを実行する。

Azure VMware Solution内の監視パターンは、IaaS プラットフォーム内のAzure VM と似ています。 詳細と使い方については、「Azure Monitor を用いた Azure VM の監視」を参照してください。

顧客とのコミュニケーション

Azure ポータルで、Service Health を通じて発行されたサービスの問題、計画メンテナンス、正常性アドバイザリ、およびセキュリティ アドバイザリ通知を確認できます。 これらの通知に対してアクティビティ ログ アラートを設定すると、適切なタイミングで対処することができます。 詳細については、「Azure ポータル>を使用してサービス正常性アラートを作成するを参照してください。

Azure VMware Solution責任マトリックス - Microsoft と顧客

Azure VMware Solutionは、オファリングに関与する 2 つの当事者 (顧客と Microsoft) の個別の役割と責任を定義する共有責任モデルを実装します。 役割の共同責任について、次の 2 つの表で詳しく説明します。

共有責任マトリックス テーブルでは、プライベート クラウド ワークロードと顧客アプリケーション ワークロードの両方をデプロイし、管理する際、顧客と Microsoft がそれぞれ処理する主なタスクの概要になっています。

次の表には、最も頻繁なタスクと定義を含む、顧客と Microsoft 間の役割と責任の詳細な一覧を示しています。 その他の質問がある場合は、Microsoft にお問い合わせください。

次のステップ

次の手順では、重要なプライベート クラウドとアーキテクチャの概念について学習します。