Azure VMware Solution とは

Azure VMware Solution は、専用のベアメタル Azure インフラストラクチャから構築された VMware vSphere クラスターを含むプライベート クラウドを提供します。 Azure VMware Solution は、Azure Commercial と 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 へのネットワーク アクセスにより、SLA に基づく Azure サービス エンドポイントの統合が提供されます。 ExpressRoute Global Reach では、オンプレミス環境を Azure VMware Solution のプライベート クラウドに接続します。

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

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 = 1000000000000 バイト。コンピューターが計算するバイナリ (1 TB バイナリ = 1099511627776 バイト バイナリ) は、Raw の 10 進数値から変換された 931.3 ギガバイトと等しくなります。

Azure portal または Azure CLI を使用して、新しいプライベート クラウドをデプロイするか、既存のものをスケーリングできます。

AV64 ノード サイズによる Azure VMware Solution プライベート クラウドの拡張

AV64 は、新しい Azure VMware Solution ホスト SKU であり、既存の AV36、AV36P、または AV52 SKU で構築された Azure VMware Solution プライベート クラウドを拡張できます (作成するのではありません)。 リージョンでの AV64 SKU の可用性を確認するには、Microsoft ドキュメントを参照してください。

AV64 を使用するための前提条件

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

• AV64 がサポートされているリージョンまたは AZ で AV36、AV36P、または AV52 を使用して Azure VMware Solution プライベート クラウドを作成します。

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

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

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

1. 少なくとも 3 つのノードを使用して、AV64 クォータの承認を Microsoft から取得します。 AV64 を使用して拡張する予定の Azure VMware Solution プライベート クラウドに関するその他の詳細を追加します。
2. RAID-6 FTT2 または RAID-1 FTT3 のサポートについては、AV64 クラスターごとに 7 つの障害ドメインを使用する機能フラグを提供するよう Microsoft サポートに依頼してください。
3. AV64 ホストで既存の Azure VMware Solution の add-cluster ワークフローを使用して拡張します。

新しい 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. RAID-6 FTT2 または RAID-1 FTT3 のサポートについては、AV64 クラスターごとに 7 つの障害ドメインを使用する機能フラグを提供するよう Microsoft サポートに依頼してください。
4. AV64 ホストで既存の Azure VMware Solution の add-cluster ワークフローを使用して拡張します。

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

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

従来の Azure VMware Solution ホスト クラウドには、明示的な vSAN FD 構成がありません。 その理由は、ホスト割り当てロジックにより、クラスター内で、Azure リージョン内の同じ物理障害ドメインに 2 つのホストが確実に存在しないようにされるためです。 この機能は本質的に、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 リージョン可用性ゾーン (AZ) から SKU へのマッピング テーブル」を参照してください。

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

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

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

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

現在、ユーザーは、ポータルまたは 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 リージョンについて、Microsoft では、サービス レベル アグリーメント (SLA) を満たすために、お客様が 6 つ以上のノードを持つ AV64 クラスターに対して RAID-5 FTT1 vSAN ストレージ ポリシーを使用できるようにしています。 詳しくは、「Azure リージョン可用性ゾーン (AZ) から SKU へのマッピング テーブル」を参照してください。

Storage

Azure VMware Solution では、Azure Storage サービスを使用して 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 のプライベート クラウドの新しいデプロイで使用される VMware ソリューション ソフトウェアのバージョンは次のとおりです。

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

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

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

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

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

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

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

Azure VMware Solution における監視パターンは、IaaS プラットフォーム内の Azure VM に似ています。 詳細と操作方法については、Azure Monitor を使用した Azure VM の監視に関する記事をご覧ください。

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

Service Health を介して発行される、サービスの問題、計画メンテナンス、正常性の勧告、セキュリティに関する勧告の通知は、Azure portal で見つけることができます。 これらの通知に対してアクティビティ ログ アラートを設定すると、適切なタイミングで対処することができます。 詳細については、「Azure portal を使用して Service Health アラートを作成する」を参照してください。

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

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

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

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

次のステップ

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