この記事は、意思決定者が、デプロイ前に所有権、ガバナンス、スキル、運用モデルを定義することで、Azure VMware Solutionでワークロードを実行するように組織を準備するのに役立ちます。
Azure VMware Solution Generation 2 は、VMware Cloud Foundation ベースのプラットフォームを提供します。これにより、組織は VMware ワークロードをAzureでネイティブに実行し、Azure サービスと統合できます。 Azure VMware Solutionは、組織がデプロイを開始する前に運用所有権、ガバナンス、スキル、財務アカウンタビリティを確立するときに最も成功します。 早期の意思決定により、移行リスクが軽減され、導入の規模に応じてチームがプラットフォームを一貫して運用できるようになります。 第 1 世代Azure VMware Solution既に実行している組織の場合、これらの推奨事項は、Gen 2 が推奨されるデプロイ モデルになるため、最新化と運用の調整をガイドするのに役立ちます。
推奨事項: デプロイ前に運用所有権、ガバナンスコントロール、スキルプラン、ライセンスコミットメント、コスト管理プラクティスを定義し、導入の拡大に合わせてチームが自信を持ってワークロードを移行し、プラットフォームを効率的に運用できるようにします。
1. デプロイ モデル
Azure VMware Solutionは、1 つ以上のプライベート クラウドとしてデプロイされます。 各プライベート クラウドは、運用、ガバナンス、ライフサイクルの境界を表します。 プライベート クラウドでは、分離、コンプライアンス、パフォーマンス、所有権の要件に応じて、複数のワークロードをホストしたり、1 つのワークロード専用にしたりできます。
組織は、運用モデルを確立する前に、ワークロードがプライベート クラウドを共有するか、専用の環境を必要とするかを決定する必要があります。 この決定は、所有権の境界、運用上の責任、コストの割り当て、ガバナンスの要件に影響します。 また、 スケーラビリティの制限 を確認して、プライベート クラウドアプローチがワークロードに必要な容量を提供することを確認する必要があります。 決定は、組織が運用する必要があるプライベート クラウドの数です。
1 つのプライベート クラウド、多くのワークロード。 セキュリティ要件、運用所有権、ライフサイクルの目標を共有するときに、ワークロードをまとめて配置します。 この方法では、ホストの使用率が高く、コストが抑え込まれます。 トレードオフ: 共有ワークロードは、同じメンテナンス期間、クラスター リソース、および障害への影響を継承するため、変更やインシデントがそれらのすべてに影響を与える可能性があります。
1 つのプライベート クラウド、1 つのワークロード。 分離、規制上の義務、パフォーマンスの保証、または独立したライフサイクルによって追加のコストと管理が正当化される場合は、個別のプライベート クラウドを作成します。 トレードオフ: 追加のプライベート クラウドごとに、独自の最小ホスト数と管理オーバーヘッドが伴うので、実際の要件で必要な場合にのみ 1 つ追加します。
アプリケーションの開発/テスト インスタンスなど、運用以外のワークロードをプロビジョニングする方法を検討します。 運用ワークロードと同じプライベート クラウド上でこれらを併置することもできます。これにより、単一のアプリケーション チームが管理しやすくなりますが、運用ワークロードでパフォーマンスを維持するためにクラスター リソースを慎重に割り当てる必要があります。 または、非運用ワークロード用の専用プライベート クラウドを作成することもできます。この場合、コストを削減するためにリソースをより積極的にオーバーコミットできますが、アプリケーションのさまざまな環境が管理境界を越えて分散されます。
2. 運用モデル
Azure VMware Solutionをデプロイする前に、所有するチームを決定し、日々運用します。 適切なモデルは、組織の規模と規模、チームの構造、異なる部署が異なるテクノロジ スタックを実行するかどうかによって異なります。 既に共有プラットフォームを実行する方法に最も適したモデルを選択します。 次の 3 つの一般的な方法があります。
プラットフォーム チーム所有:中央プラットフォーム チームは、各Azure VMware Solutionプライベート クラウドを共有サービスとしてプロビジョニングし、運用します。 プラットフォーム チームは、Azure プラットフォーム ランディング ゾーン全体を担当し、Azureでの VMware 運用に対して追加の責任を負います。 ワークロード チームは、基になる環境を管理せずに容量を消費します。 Azure プラットフォーム チームが既にあり、多くのアプリケーション チーム間で一貫した構成、ネットワーク、監視が必要な場合に選択します。
選択するタイミング: このオプションは、同じチームが複数のテクノロジを管理する小規模な組織で一般的です。 Azure プラットフォームと Azure VMware Service に責任を持つ 1 つのチームは、チーム間のハンドオフを減らすことができますが、非常に大規模で複雑な組織や VMware 資産にスケーリングすることはできません。
トレードオフ:ワークロード チームの自律性が低く、プラットフォーム チームの応答性に依存しており、そのチームには VMware とAzureの両方のスキルが必要です。
専用 VMware ホスティング チーム:専用チームは、オンプレミスのデータ センターやその他のパブリック クラウド内の他の VMware 資産と共にAzure VMware Solutionを所有しています。 ランディング ゾーンや ID など、Azure プラットフォーム チームの共有サービスを使用し、アプリケーション チームにプラットフォームを提供します。 VMware を中核サービスとしてすでに運用しており、Azure プラットフォームの作業と VMware の運用を明確に分離したい場合は、これを選択します。
選択するタイミング: 組織に異なるクラウドまたはデータ センターにまたがる多数の VMware 環境がある場合、単一の VMware 管理チームを使用すると、ワークロードの所有者と開発者に一貫性が生まれます。 このオプションは、高度な VMware スキルを必要とする複雑な自動化と管理ワークフローを備えた非常に成熟した VMware 環境がある場合にも一般的です。
トレードオフ:Azureチームと VMware チームの間の強力なコラボレーションと明確に定義された境界に依存します。
分散型所有権:各ワークロード チームまたはビジネス ユニット チームは、独自のプライベート クラウドを所有して運用し、接続や ID などの共有Azure サービスを使用しますが、VMware 操作自体は実行します。 分離された環境、または個別の要件に対して自律性を必要とするビジネス ユニットに対して選択します。
選択するタイミング: 各部署または子会社が大きな自律性を持つ疎結合の組織がある場合、ワークロード管理者が独自のプラットフォームを管理できるようにすることで、独立して動作する能力がサポートされ、生産性が低下することはありません。
トレードオフ: 複数のチームがそれぞれ独自の環境を実行し、コストとセキュリティ コンプライアンスの 1 つのビューを維持することが難しい場合は、運用上のオーバーヘッドと重複作業を追加します。
スケールの一貫性と経済性が最も重要な場合は、中央モデルを優先します。 自律性と分離性が標準化よりも重要な場合は、ワークロード チーム モデルを優先します。 多くの大規模な組織はモデルを組み合わせ、プラットフォームまたはホスティング チームはほとんどのワークロードに対して共有プライベート クラウドを実行し、いくつかの事業単位は特別なケースで独自に実行します。
3. 役割と責任
所有権の責任は、運用モデルによって異なります。 以下のガイダンスは、ほとんどのAzure VMware Solutionデプロイに適用される傾向がある一般的な責任を反映しています。 次のセクションでは、"サービス所有者" という用語 (プラットフォーム チーム、専用 VMware チーム、または分散型チーム) を使用して、先ほど選択したAzure VMware Solution プラットフォームを運用する責任をチームに示します。
3.1 導入フェーズ別の責任
さまざまなチームが、ライフサイクルのさまざまな段階でAzure VMware Solution導入に貢献します。 フェーズごとに責任を定義することで、組織はアカウンタビリティを早期に確立し、チーム間で意思決定を調整し、デプロイを遅らせたり、運用リスクを高めたりする可能性のあるギャップを回避するのに役立ちます。
- 戦略フェーズ: 上級リーダーは、ビジネス目標を定義し、投資の優先順位を承認します。 財務チームと商用チームは、ビジネス ケースを開発し、コストを予測し、ライセンスと予約のコミットメントを評価します。 Azure プラットフォーム チームと VMware IT 運用チームは、実現可能性を検証し、サイズ要件を見積もり、ワークロードで共有プライベート クラウドと専用プライベート クラウドのどちらを使用するかを決定します。
組織の準備フェーズ: Azure プラットフォーム チームと VMware IT 運用チームは、準備状況を評価し、スキルのギャップを特定し、所有権モデルを定義します。 セキュリティ管理者と ID 管理者は、デプロイ前に ID、アクセス制御、コンプライアンス、監視、ライフサイクル管理の要件を確立するのに役立ちます。 組織の準備の一環として、Azureと VMware の両方で十分なスキルを持っているか、運用機能を構築するために経験豊富なパートナーが必要かどうかを検討します。 Azure VMware Solution専門知識を持つパートナーは、プロジェクトのリスクと遅延を軽減するのに役立ちます。
アーキテクチャ フェーズ: ネットワーク管理者は、接続とネットワーク設計の決定を導きます。 ID 管理者は、vCenter Server ID モデルと管理アクセスを構成します。 Azure プラットフォーム チームは、ランディング ゾーン、ガバナンス制御、プラットフォーム接続を確立します。 セキュリティ管理者は、セキュリティと監視の要件を定義します。 ストレージ管理者は、外部ストレージ サービスが必要な場合に参加します。
運用フェーズ:Azure プラットフォーム チームは、ガバナンス、ランディング ゾーン、共有Azure サービスを管理します。 VMware IT 運用チームは、プライベート クラウドの運用、容量、プラットフォームのライフサイクル アクティビティを管理します。 ワークロード所有者は、アプリケーションのパフォーマンスとビジネス成果に対して引き続き責任を負います。 セキュリティ管理者は、コンプライアンスの監視を維持します。 財務チームと商用チームは、使用率、コストの割り当て、予約、最適化の機会を確認します。
移行フェーズ: VMware 管理チームとワークロード所有者は、移行アクティビティを主導します。 ネットワーク管理者は、接続とアプリケーションの依存関係を検証します。 IT 運用チームとセキュリティ管理者は、運用のカットオーバーの前に監視、バックアップ、回復、およびセキュリティ制御を検証します。 アプリケーション所有者は、移行の前後にアプリケーションのパフォーマンスと安定性をテストして検証します。
3.2 役割別の責任
ロールベースの責任により、Azure VMware Solutionの計画、デプロイ、運用、管理に必要なスキルと機能の詳細なビューが提供されます。 組織は、運用モデルに基づいてこれらの責任を同じチームまたは異なるチームに割り当てることができますが、すべての責任には明確に識別された所有者が必要です。
表: チームと役割が責任に対応付けられた表
| チームまたはロール | Responsibilities |
|---|---|
| VMware 管理者 | VMware プライベート クラウドのリソースとパフォーマンスを管理します。 vCenter Server や Live Recovery などのAzure VMware Solution サービスを構成します。 仮想マシンのイメージ、テンプレート、スナップショットを維持します。 VMware ライフサイクル操作を管理します。 VMware ソフトウェア更新プログラムやAzureサービス通知などのサービスの変更を計画します。 他の VMware 環境からAzure VMware Solutionにアプリケーション ワークロードを移行します。 |
| ネットワーク管理者 | Azure VMware SolutionがAzure、オンプレミス、WAN ネットワークに統合されていることを確認します。 パフォーマンス、セキュリティ、信頼性の設計。 NSX-T、HCX、vDefend Firewall を構成します。 ネットワーク トポロジとレイヤー 2 拡張機能を計画します。 |
| ストレージ管理者 | vSAN ストレージ ポリシーを設計する。 外部ストレージ サービスを構成します。 バックアップサービスとデータ保護サービスを構成します。 |
| セキュリティ管理者 | Azure VMware Solutionのセキュリティ ベースラインを推奨します。 サーバーと Sentinel のDefenderなどのセキュリティ サービスをデプロイして構成します。 継続的なリスク評価、セキュリティ コンプライアンス、アラートを評価します。 |
| ID 管理者 | Microsoft Entra IDとActive Directory Domain ServicesとのAzure VMware Solution統合を構成します。 Azure VMware Solution管理者のカスタム ロールを作成します。 Azure VMware Solution リソースにロールベースのアクセス制御 (RBAC) アクセス許可を適用します。 |
| クラウド運用チーム | 監視ポリシーとアラート ポリシーを設計および構成します。 Azure Arcを VMware 仮想マシンにデプロイします。 Azure Update Managerやゲスト構成などのAzure サービスを構成します。 |
| ワークロード所有者 | ワークロードの互換性と構成を検証します。 日常的な管理アクションを実行します。 ワークロード リソースのライフサイクルを管理します。 |
| Azure プラットフォーム チーム | Azure VMware Solutionをサポートするようにアプリケーションランディングゾーンを設計する。 ガバナンスとセキュリティの要件をサポートするようにAzure Policyを構成します。 一元化されたコードとしてのインフラストラクチャのデプロイ パイプラインを管理します。 |
| シニア リーダーシップ | 長期的なクラウド導入目標の監視。 資金と商業機関を提供する。 チーム間の所有権を解決し、優先順位を調整します。 スポンサー ガバナンスと運用モデルの変更。 自己リスクの受け入れとアーキテクチャのトレードオフ。 |
| ビジネス アナリスト | ビジネス目標を把握して文書化します。 ビジネス成果を要件にマップします。 メリットと導入の成功を追跡します。 依存関係と制約を特定します。 アプリケーションの処理を開発し、クラウド戦略に合わせます。 |
| 財務および商業チーム | コスト モデル、予算、財務管理を作成します。 ビジネス ケースの想定に対する支出を追跡します。 予約、ライセンス、コミットメントの決定についてアドバイスします。 |
4. Azure VMware Solutionスキル
所有権モデルとロールの割り当てによって、スキルが必要な場所と、その深さが決まります。 Azureと VMware のユーザーが 1 つのチームとして機能するように、知識の重複を目指します。 スキルを構築する方法と、スキルを集中させる場所を決定します。
スキルを運用モデルに合わせます。 前のセクションの 3 つのモデル (Azureプラットフォーム チーム所有、VMware 管理チーム所有、またはワークロード チーム所有) を使用して、Azure VMware Solutionプライベート クラウドを管理するユーザー、使用するユーザー、各グループに必要なアクセス許可を決定します。 責任マッピングを使用して、チームのスキルとトレーニング計画を作成します。
チーム間で共有された理解を構築します。 所有権モデルに関係なく、Azureチームと VMware チーム間の知識の重複を目指します。 VMware 管理者は通常、Azure ポータル、CLI/PowerShell、Azure Monitor、Azure Arcを使用するなど、Azure VMware Solution日常的に動作するのに十分なAzure機能が必要です。 Azureプラットフォーム チームは、統合に最も影響する VMware の概念を理解する必要があります。 この理解には、ネットワーク構成体、セキュリティ境界、監視が含まれます。 この理解により、アプリケーション ランディング ゾーンとのクリーンな統合と、Microsoft Foundry、SQL Database、ストレージ アカウントなどのAzure サービスの効果的な使用が可能になります。
Azure VMware Solutionでは、ストレージには VMware vSAN、ネットワークには VMware NSX、移行には VMware HCX が使用されます。 チームが現在これらのテクノロジを使用していない場合は、移行前にターゲットトレーニングが必要です。 管理者にハンズオン ラボと最新のリファレンス 資料を提供します。 このガイダンスにより、実行リスクが低下します。 次の領域に重点を置くトレーニングを行います。
ネットワーキング。 NSX が VLAN ベースのネットワークを置き換える方法と、移行中に HCX がネットワークを拡張する方法について説明します。 移行する前に、オンプレミスの VLAN、アプリケーションの依存関係、トラフィック フローを評価します。 仮想ネットワーク、ピアリング、ルーティング、ネットワーク セキュリティ グループなど、Azure ネットワークの概念に関する知識を構築します。
アイデンティティ。 Azure VMware SolutionをActive Directory Domain ServicesおよびEntra IDと統合します。 管理者特権をセキュリティで保護し、アプリケーション開発者が先進認証サービスを使用できるようにサポートしていることを確認します。
セキュリティとコンプライアンス Azure VMware Solution Microsoft Defender for Cloud、Sentinel、Azure Policyと統合する方法、および VMware とAzureの境界を越えてコンプライアンスがどのように動作するかを理解します。 プラットフォームとエンドポイント間で脆弱性スキャンと脅威保護を維持します。
Azureプラットフォームのスキル。 Azure Monitor、コスト管理、Azure ポータルや CLI など、Azure VMware Solutionの運用と管理に使用されるAzure サービスを使用して機能を構築します。
ストレージとバックアップ。 vSAN がプライマリ ストレージを提供する方法、外部Azureストレージ サービスが適切な場合、およびバックアップとデータ保護がAzure VMware Solutionでどのように動作するかを理解します。 VM レプリケーションでディザスター リカバリーのニーズが満たされていることを確認します。
5. Broadcom ライセンス
ポータブル VMware Cloud Foundation (VCF) サブスクリプション ライセンスを Broadcom から購入するには、 ライセンス持ち込み (BYOL) モデルで購入する必要があります。 Azure VMware Solution プライベート クラウド内のすべての物理コアをカバーするには、適切な数の VCF ライセンスが必要です。 Azure VMware Solutionプライベート クラウドを作成するときは、デプロイ プロセスの一環としてライセンス情報を入力します。 ライセンスを含むホストのアクティブな予約インスタンスがある場合は、ライセンスを VCF BYOL に変換することが必要になる場合があります。 VMware vDefend Firewall などのオプションのアドオンには、独自の Broadcom ライセンスが必要です。 Azure VMware Solutionでのポータブル VMware Cloud Foundation (VCF) の使用に関する記事を参照してください。
6. Azure VMware Solution のクォータ
早期にホスト クォータを要求します。 Azure VMware Solutionプライベート クラウドをプロビジョニングする前に、ターゲット リージョンで承認されたホスト クォータが必要です。 承認には最大 5 営業日かかる場合があり、リージョンとホストの可用性によって異なります。 遅延要求はスケジュール スリップの頻繁な原因であるため、リージョンとホストの数がわかったらすぐに要求を送信します。 また、サブスクリプションでは、エンタープライズ契約やMicrosoft 顧客契約などの対象プランを使用する必要があります。 Azure VMware Solutionの要求ホスト クォータを参照してください。
7. コスト管理と FinOps
Azure VMware Solutionのコスト管理は、ホスト上で実行される仮想マシンの数に関係なく、ホストの料金を支払うため、他のAzure リソースとは異なります。 VMware Cloud Foundation ソフトウェア ライセンスを個別に購入し、プライベート クラウドに適用する必要があります。 また、Windows ServerやSQL Serverなど、他のソフトウェアに必要なライセンスがあることを確認する必要があります。
少なくとも 3 つのホストのクラスターをデプロイする場合は、容量が許す限り多くの仮想マシンを実行できるため、ワークロードをホストにどれだけ密にパックするかによってコスト効率が向上します。 ワークロードのパフォーマンスを損なうことなくプラットフォームの価値を最大限に引き出すために、リソースの最適な使用率を決定する必要があります。 Aria Operations などの VMware ツールは、クラスター リソースの最適化に役立ちます。
7.1 コストの割り当て
Azure VMware Solutionが FinOps アプローチに与える影響を確認します。 すべてのクラスター コストを 1 つの部署に請求したり、プラットフォームの使用方法に基づいてビジネス ユニット間でコストを割り当てたりすることができます。 割り当てられたリソース (たとえば、各ワークロードに割り当てられた vCPU コアとメモリ) に基づいてコストを割り当てることもできます。これにより、アプリケーション所有者は仮想マシンのサイズを適切に設定できます。 Azure Arc対応の VMware vSphere は、アプリケーション名、コスト センター、所有者などの VMware 仮想マシンに Azure リソース タグを適用することで、コストの属性に役立ちます。
アプリケーション チームの使用量をクロスチャージするかどうかにかかわらず、Azure VMware Solutionプライベート クラウドのコストを明確に把握する必要があります。 クラスターが十分に利用されている場合、Azure VMware Solutionは最もコスト効率が高くなります。 CPU とメモリの使用率が低い場合は、クラスターが大きすぎる可能性があり、コストが増加します。 ワークロードの変化に応じて、使用率を定期的に確認し、クラスターサイズを調整しながら、予想される成長に十分な余裕を保ちます。 CPU とメモリの使用率のターゲット範囲を定義すると、時間の経過に伴うコストの最適化に役立ちます。
7.2 コスト予測
Azure VMware Solution プライベート クラウドのコストを予測するには、必要なホストの数を計算します。 ホスト数は、仮想マシンの CPU、メモリ、ストレージの要件によって決まります。 Azure Migrateは、仮想マシンのインベントリに基づいてホストの数を計算するのに役立ちます。 移行と最新化ツールを使用した VMware VM のエージェントレス移行に関する記事を参照してください。
要件を計算するときは、現在割り当てられているものではなく、仮想マシンの需要を確認します。 Azure Migrateは、観察されたパフォーマンスの要求に基づいて最適な CPU とメモリの割り当てを推奨することで、仮想マシンのサイズを適切に設定するのに役立ちます。 VM よりも多くの CPU とメモリを割り当てると、プラットフォームのコスト効率が低下します。
7.3 コンピューティングコミットメント
需要が安定している場所にコミットし、そうでない場所で柔軟性を維持します。 予約インスタンス割引を 1 年または 3 年間のコミットメントでAzure VMware Solutionに適用すると、従量課金制よりも大幅に節約できます。 2 つを組み合わせて、コア ワークロード用のホストを予約し、移行や季節的な需要などの一時的なニーズに合わせて従量課金制ホストを追加します。 トレードオフ:予約によって支出がロックされるため、戦略が変更された場合に他のAzure サービスと交換できるかどうかを確認します。 予約済みホストと従量課金制ホストの両方に、引き続き正しい VMware Cloud Foundation ライセンスが必要であることに注意してください。 Azure VMware Solutionの予約インスタンスを参照してください。