Azure VMware Solution のエンタープライズ規模のシナリオでのプラットフォームの自動化

  • [アーティクル]

エンタープライズ規模のランディング ゾーンでは、自動化と DevOps に関する一連のベスト プラクティスを使用します。 これらのベスト プラクティスは、Azure VMware Solution プライベート クラウドのデプロイに役立ちます。 このガイドでは、Azure VMware Solution の初期デプロイでのデプロイに関する考慮事項をおおまかに説明します。 また、運用の自動化に関するガイダンスも示します。 この実装は、スケールの設計に重点を置いた、クラウド導入フレームワークのアーキテクチャとベスト プラクティスに従っています。

このソリューションは、2 つの主要部分で構成されています。 最初の部分は、Azure VMware Solution のデプロイと自動化の実践に関するガイダンスです。 2 番目の部分は、プライベート クラウドのデプロイを支援するように調整できる一連のオープンソース成果物です。 このソリューションはエンドツーエンドの自動化プロセスを開始することを目的としていますが、組織がこの記事の考慮事項に基づいて手動でデプロイするコンポーネントを決定できます。

Azure VMware Solution のランディング ゾーン アクセラレータの自動化は、このリポジトリ内のテンプレートとスクリプトを使用して Azure VMware Solution のデプロイを開始できるように設計されています。 デプロイする前に、テンプレートを確認して、デプロイされるリソースと、関連するコストを把握しておくことをお勧めします。

この記事では、次の分野の考慮事項と推奨事項について説明します。

  • 手動や自動化など、Azure VMware Solution のデプロイ オプション。
  • 自動スケールに関する考慮事項と実装の詳細。
  • プライベート クラウド内での VMware SDDC レベルの自動化に関する考慮事項。
  • エンタープライズ ランディング ゾーンから拡張された自動化アプローチに関する推奨事項。
  • Azure CLI、Azure Resource Manager、Bicep、PowerShell など、デプロイと管理に使用する自動化テクノロジに関する考慮事項。

展開戦略

Azure VMware Solution は、手動でデプロイすることも、キュレーションされた自動化ツールを使用してデプロイすることもできます。

手動デプロイ

Azure portal を使用して、Azure VMware Solution プライベート クラウドをグラフィカルに構成してデプロイできます。 このオプションは、小規模のデプロイに適しています。 大規模な Azure VMware Solution トポロジを繰り返しデプロイする場合は、自動化されたデプロイを検討してください。 また、プライベート クラウドへの接続を構成した後に、Azure portal を使用して手動でスケーリングすることもできます。

考慮事項:

  • 手動デプロイは、初期のパイロットと小規模な環境に使用できます。 また、既存の自動化やコードとしてのインフラストラクチャのプラクティスが用意されていない場合にも使用できます。
  • Azure portal、Azure CLI、または Azure PowerShell モジュールを使用して Azure VMware Solution をデプロイする際に、ソリューションでのデータ保護に関する一連の使用条件が表示されます。 Azure Resource Manager API を直接使用する場合、または Azure Resource Manager または Bicep テンプレートを使用してデプロイする場合は、自動化をデプロイする前にこちらの使用条件を確認するようにしてください。
  • 必要に応じて起動されるオンデマンド環境の場合は、Azure VMware Solution プライベート クラウドの作成プロセスを自動化して、手動操作の量を制限します。
  • Azure portal 内のターゲット リソース グループの [展開] ブレードを使用すると、プライベート クラウドの作成プロセスを監視できます。 プライベート クラウドをデプロイしたら、[成功] 状態であることを確認してから次に進みます。 プライベート クラウドが [失敗] 状態になっている場合は、vCenter Server に接続できない可能性があります。 プライベート クラウドを削除して再デプロイすることが必要になる場合があります。

推奨事項:

  • 手動デプロイ方法を選択する場合は、プライベート クラウドのプロビジョニングに使用する構成をドキュメント化しておくことが重要です。 デプロイが完了したら、ドキュメントに使用したデプロイ テンプレートをダウンロードします。 このテンプレート成果物には、プライベート クラウドのデプロイに使用された ARM テンプレートが含まれています。 また、テンプレート成果物には、選択した構成を含むパラメーター ファイルも含まれています。
  • Azure portal で定期的にプライベート クラウドと対話する場合は、リソースの削除を制限するためにリソース ロックを設定することをお勧めします。 また、読み取り専用リソース ロックを使用してスケール操作を制限することもできます。

自動化されたデプロイ

自動化されたデプロイを使用すると、Azure VMware Solution 環境を繰り返しデプロイできます。 これにより、必要に応じてその環境を設計してデプロイできます。 こうような使用法により、複数の環境とリージョンを大規模にロールアウトする効率的なデプロイ メカニズムが実現します。 また、低リスクでオンデマンドの反復可能なデプロイ プロセスも実現します。

自動の Azure VMware Solution 実装オプション

実装オプション 説明 GitHub リポジトリへのデプロイ リンク
Azure への接続を使用して Azure VMware Solution と依存関係をデプロイする このデプロイは、新しい Azure VMware Solution のプライベート クラウドをプロビジョニングするのに最適です。 これは本格的なバージョンのデプロイであり、さまざまなサポート コンポーネントを作成するのに役立ちます。 これらのコンポーネントには、Azure 接続、監視、アドオンが含まれます。

Azure portal UI、PowerShell、Terraform の 3 つのデプロイ オプションがあります。 これらのデプロイ オプションをそれぞれ使用して、以下のリソースのデプロイを選択できます。

▪ Azure VMware Solution のプライベート クラウド
▪ 新規または既存の仮想ネットワーク (VNet) の選択
▪ VPN 接続用 Azure Route Server のデプロイ ("省略可能")
▪ Azure VMware Solution 監視のデプロイ ("省略可能")
▪ HCX と SRM のデプロイ ("省略可能")		 Azure にデプロイする (Azure portal UI)

Azure にデプロイする (PowerShell)

Azure にデプロイする ("Terraform モジュール")
Azure に接続せずに Azure VMware Solution をデプロイする このデプロイは、より軽量なバージョンです。 これは、概念実証 (POC) やパイロットに適しています。 これにより、次のリソースをデプロイできます。

▪ 新しい Azure VMware Solution のプライベート クラウド: (1) カスタム リソース グループ名とプライベート クラウド名、または (2) 既存の Azure VMware Solution のプライベート クラウドを選択します。
▪ Azure VMware Solution 監視のデプロイ ("省略可能")。
▪ HCX と SRM のデプロイ ("省略可能")。		 Azure にデプロイする (Azure portal UI)

考慮事項:

  • Azure VMware Solution プライベート クラウドのデプロイは、完了に数時間かかる場合があります。 プライベート クラウドで Azure Resource Manager のデプロイ状態または status プロパティを使用して、このプロセスを監視します。 デプロイ パイプラインを使用するか、PowerShell または Azure CLI によってプログラムでデプロイします。 その場合は、プライベート クラウドのプロビジョニング プロセスに対応するために適切なタイムアウト値を選択する必要があります。
  • ネットワーク トポロジと接続に関するページの推奨事項に従って、プライベート クラウドとワークロード ネットワークのアドレス範囲を事前に割り当てることができます。 その後に、それらを環境構成ファイルまたはパラメーター ファイルに追加します。 アドレス範囲の重複は、デプロイ時には検証されません。 検証が行われないために、2 つのプライベート クラウドのアドレス範囲が同じ場合に問題が発生するおそれがあります。 問題は、範囲が Azure またはオンプレミス内の既存のネットワークと重複する場合にも発生するおそれがあります。
  • デプロイにサービス プリンシパルを使用することで、最小限の特権アクセスを実現できます。 Azure のロールベースのアクセス制御 (RBAC) を使用して、デプロイ プロセスに対するアクセスを制限することもできます。
  • プライベート クラウドのデプロイに DevOps 戦略を使用し、ローカル ツールに依存せずに、自動化された反復可能なデプロイにパイプラインを使用できます。

推奨事項:

  • 最小限のプライベート クラウドをデプロイし、その後、必要に応じてスケーリングします。
  • デプロイを成功するために、事前にホストのクォータまたは容量をリクエストします。
  • サブリソースをデプロイする前に、プライベート クラウドのデプロイ プロセスおよびプライベート クラウドの状態の両方を監視します。 プライベート クラウドに対する追加の構成更新は、プライベート クラウドが [成功] 状態の場合にのみ処理できます。 プライベート クラウドが [失敗] 状態の場合は、以降の操作を停止し、サポート チケットを発行して解決することをお勧めします。
  • 関連するリソース ロックを自動化されたデプロイに含めるか、ポリシーを使用して適用します。

自動化された接続

Azure VMware Solution プライベート クラウドをデプロイしたら、ExpressRoute を使用して接続を設定できます。 この構築セット内で説明されているネットワーク接続には、次の 2 つのクリティカル パスがあります。

  • 仮想ネットワーク ゲートウェイを経由する仮想ネットワークまたは Azure Virtual WAN への接続。
  • Global Reach を経由する Azure VMware Solution と既存の ExpressRoute との間の接続。

推奨されているネットワーク トポロジの詳細については、ネットワーク トポロジと接続 に関するページを参照してください。

考慮事項:

  • Azure VMware Solution プライベート クラウドは、Azure 仮想ネットワークまたは既存の ExpressRoute に接続できます。 この接続により、プライベート クラウド内の管理ネットワークとワークロード ネットワークの両方からのルートが自動的にアドバタイズされます。 重複チェックが行われないため、アドバタイズされたネットワークを接続前に検証します。
  • ExpressRoute 承認キーの名前は、接続先リソースの既存の名前付けスキームに合わせて調整できます。 この調整により、関連リソースを簡単に識別できます。
  • ExpressRoute 仮想ネットワーク ゲートウェイと ExpressRoute 回線は、Azure VMware Solution プライベート クラウドとは異なるサブスクリプション内に存在する場合があります。 1 つのサービス プリンシパルにこれらすべてのリソースに対するアクセス権を与えるか、個別に保持するかを決定します。
  • Azure portal を使用する NSX-T Data Center ワークロード ネットワークでは、重要なネットワーク リソースをプライベート クラウドにデプロイできますが、NSX-T Manager では NSX-T Data Center コンポーネントをより高度に制御できます。 ネットワーク セグメントで必要な制御レベルを検討することが重要です。
    • Azure portal 内で NSX-T Data Center ワークロード ネットワークを使用して、プライベート DNS 統合用にドメイン ネーム システム (DNS) ゾーンを設定します。
    • 1 つの階層に 1 つのゲートウェイのみを必要とするネットワーク トポロジでは、Azure portal 内で NSX-T Data Center ワークロード ネットワークを使用します。
    • 詳細な構成では、NSX-T Manager を直接使用できます。
    • ネットワーク管理者のスキル レベルを考慮します。 ネットワーク管理者に VMware NSX-T Data Center に関する知識がほとんどまたはまったくない場合は、代わりに Azure portal を使用してネットワーク操作のリスクを軽減することを検討してください。

推奨事項:

  • ExpressRoute 構成ではなく、Azure VMware Solution のデプロイに個別のサービス プリンシパルを使用している場合は、Azure Key Vault または同様のシークレット ストアを使用して、必要に応じてデプロイ間で承認キーを渡します。
  • Azure VMware Solution プライベート クラウドに対して実行できる並列操作の数には、常に制限があります。 多くの Azure VMware Solution プライベート クラウド サブリソースを定義するテンプレートの場合は、依存関係を使用して順次形式でデプロイすることをお勧めします。

自動化されたスケール

既定では、Azure VMware Solution クラスターには、クラスターのスケールによって一定の数のホストが定義されています。 クラスターごとのスケーリングをプログラムで変更すると、自動化によってスケールインおよびスケールアウトできます。 この自動化は、オンデマンドで、スケジュールに基づいて、または Azure Monitor のアラートに対応して行われます。

考慮事項:

  • 自動スケールアウトを使用すると、オンデマンドで提供される容量が増加しますが、増えるホストのコストを考慮することが重要です。 このコストはサブスクリプションに提供されているクォータに制限されますが、手動の制限を設定する必要があります。
  • スケールインを自動化する前に、クラスター内で実行中のワークロードと適用されているストレージ ポリシーへの影響を考慮してください。 たとえば、RAID-5 が割り当てられたワークロードを、3 ノード クラスターにスケールインすることはできません。 また、メモリとストレージの使用について検討することも重要です。この使用によってスケールイン操作がブロックされるおそれがあるためです。
  • 一度に実行できる単一スケール操作は 1 つだけです。そのため、複数のクラスター間でスケール操作のオーケストレーションを検討することが重要です。
  • Azure VMware Solution のスケール操作は瞬時に行われるわけではなく、既存のクラスターに別のノードを追加するためにかかる時間を考慮する必要があります。
  • サードパーティ製ソリューションと統合では、ホストが継続的に削除および追加されることは想定されていない場合があります。 サードパーティ製のすべての製品の動作を検証します。 この検証により、ホストの追加または削除時に製品を更新または再構成するための追加手順が不要になります。

推奨事項:

  • スケールインとスケールアウトの両方の操作に対して、クォータ以外でのハード制限を設定します。
  • 事前にクォータをリクエストして、スケール操作に影響を与えないようにします。 クォータは容量の保証ではなく、特定の制限までデプロイできるようにするものです。 クォータの制限を定期的に確認し、常にヘッドルームを確保するようにします。
  • 自動スケーリング システムが監視されていること、およびスケール操作の完了時にアラートが表示されることを確認します。 このアラートにより、予期しないスケール イベントがなくなります。
  • Azure Monitor のメトリックを使用して、スケールイン操作の前にクラスターの容量を確認し、十分なヘッドルームがあることを確認します。 スケール操作の前後とその最中に、CPU、メモリ、ストレージに注意を払ってください。 容量に注意を払うことで、サービス レベル アグリーメント (SLA) に影響を与えません。

Azure の統合

Azure VMware Solution プライベート クラウドでは、複数の異なる Azure ネイティブ サービスを使用することもできます。 これらのサービスは Azure VMware Solution のデプロイに含めることも、個別のコンポーネントとしてデプロイすることもできます。 この記事で取り上げられていない場合は、エンタープライズ規模のランディング ゾーン アーキテクチャ内の既存のパターンを使用して、これらのサービスと統合することをお勧めします。

考慮事項:

自動化を計画している各コンポーネントのデプロイ ライフサイクルを検討します。 ライフサイクルによって緊密にバインドされたグループ コンポーネントをグループ化して、1 つのユニットとしてデプロイできるようにします。 ライフサイクルが異なるコンポーネントは別々に分けます。

自動化ツール

Azure VMware Solution プライベート クラウドは Azure Resource Manager 内にリソースとして存在し、複数の異なる自動化ツールを介して対話できるようにします。 Azure Resource Manager 仕様で生成されたファーストパーティの Microsoft ツールは、リリース直後に機能をサポートするようになる傾向があります。 自動化の観点では、この記事の考慮事項は、さまざまなツールセット全体に適用できるように準備されています。

考慮事項:

  • Azure Resource Manager や Bicep テンプレートなどの宣言型ツールを使用すると、構成を 1 つの成果物として定義できます。 Azure CLI や PowerShell のようなコマンド ラインおよびスクリプト ベースのツールには、実行のためのステップバイステップのアプローチが必要であり、これは手動デプロイに合っています。
  • Terraform のようなサードパーティ製の自動化ツールを使用して、Azure VMware Solution と Azure ネイティブ サービスをデプロイできます。 Azure VMware Solution 内で使用する機能が現在、使用可能なリソースに含まれているか確認することが重要です。
  • スクリプトベースのデプロイ アプローチを採用する場合は、デプロイの失敗による影響を常に考慮し、適切に監視します。 具体的に Azure VMware Solution の場合は、デプロイとプライベート クラウドの状態の両方を監視します。 Azure VMware Solution の監視の詳細については、Azure VMware Solutionの管理と監視に関するページを参照してください。

推奨事項:

  • Azure CLI、PowerShell、または宣言型テンプレート (Azure Resource Manager や Bicep など) を使用して、Azure VMware Solution を自動化方式でデプロイします。
  • 可能であれば、What-If を使用して実行前に変更を確認し、リソースの削除時には一時的に止まって検証します。
  • 単一のデプロイであってもコードとしてのインフラストラクチャを必要とする操作の場合は、Azure Blueprints を使用します。 Azure Blueprints は、自動化パイプラインを必要としない、スタンプ付きの反復可能なデプロイを実現します。

DevOps アプローチ

Azure VMware Solution のデプロイの自動化は、理想的にはワークフローまたはパイプラインを使用する、一連の反復可能な手順として実装する必要があります。 デプロイに含める必須の手順をよく調べることが重要です。 これらの手順には以下が含まれます。

  • プライベート クラウドのデプロイ。
  • ExpressRoute ゲートウェイの接続。
  • Global Reach 接続。
  • NSX-T Data Center DHCP、DNS、セグメントの作成の簡略化。

プライベート クラウドをデプロイしたら、そのプライベート クラウドにリソースをデプロイできます。 詳細については、「VMware SDDC プラットフォームの自動化」を参照してください。

考慮事項:

  • 既存の自動化手法がある場合があります。そうでない場合は、エンタープライズ規模のランディング ゾーンの一部として DevOps 戦略を構築します。 その場合は、Azure VMware Solution のデプロイに同じパターンを再利用し、ボード全体で一貫した自動化スタイルを維持するようにします。
  • 詳細については、エンタープライズ規模のランディング ゾーンのプラットフォーム自動化と DevOps に関するドキュメントを参照してください。

VMware プラットフォームの自動化

Azure VMware Solution プライベート クラウド内では、vCenter Server および NSX-T Manager 内でのリソースの作成を自動化することもできます。 VMware SDDC レベルの自動化の設計に役立つ一連の考慮事項の一覧を次に示します。

vCenter Server の自動化 - PowerCLI

考慮事項:

  • PowerCLI を使用して仮想マシン (VM)、リソース プール、VM テンプレートを作成および構成して、vCenter Server をプログラムでフル制御できます。
  • vCenter Server はプライベート接続またはプライベート IP 経由でのみ使用できます。そのため、PowerCLI は、Azure VMware Solution 管理ネットワークへの通信経路があるマシンで実行する必要があります。 パイプラインの実行にはセルフホステッド エージェントを使用します。 このエージェントを使用すると、仮想ネットワークまたは NSX-T Data Center セグメント内の VM で PowerCLI を実行できます。
  • CloudAdmin ロールによって制限されているために、特定の操作を実行するアクセス権がない場合があります。 実装しようとしている自動化に必要なアクセス許可を綿密に計画し、CloudAdmin アクセス許可に対して検証します。
  • 最小特権アクセスの場合は、Active Directory の統合による vCenter Server レベルの自動化にサービス アカウントを使用することを検討してください。

NSX-T Data Center の自動化 - PowerCLI

考慮事項:

  • Azure VMware Solution プライベート クラウドでは、管理者ユーザーには既定で NSX-T Data Center への管理アクセス権があります。 この既定のアクセス権のため、PowerCLI または NSX-T Data Center API を使用して直接行われる変更の影響を考慮してください。 トランスポート ゾーンや階層 0 のゲートウェイなど、Microsoft が管理するコンポーネントは変更できません。注意が必要です。
  • NSX-T Data Center とやりとりするには、PowerCLI を実行している VM から Azure VMware Solution プライベート クラウドへのプライベート接続が必要です。
  • Azure Resource Manager を使用してワークロード ネットワークを制御できます。 この制御により、Azure Resource Manager API を使用して操作のサブセットを実行できます。これにより、NSX-T Data Center ID ではなく Azure RBAC を使用して Azure CLI と PowerShell によって操作を実行できます。

Terraform の vSphere および NSX-T Data Center プロバイダー

考慮事項:

  • Terraform の vSphere および NSX-T Data Center プロバイダーを使用して、リソースをデプロイできます。 これらのリソースは、宣言型の方法でプライベート クラウドの範囲内にデプロイされます。
  • Terraform では vCenter Server と NSX-T Manager 内の API エンドポイントと通信する必要があるため、プライベート クラウド管理ネットワークへのプライベート接続が必要です。 プライベート クラウドにルーティングできる Azure 仮想マシンからデプロイします。

vRealize Automation および vRealize Operations

考慮事項:

  • vRealize Automation はオンプレミス環境と同様に使用できるため、Azure VMware Solution 内での仮想マシン内のプロビジョニングを自動化できます。
  • Azure VMware Solution でサポートされるデプロイ モデルには制限があります。 vRealize Cloud Management を使用するか、またはオンプレミスで vRealize Automation アプライアンスをホストするようにします。
  • PowerCLI と同様に、vRealize Automation および vRealize Operations アプライアンスがある環境から Azure VMware Solution へのプライベート接続が必要です。

ワークロード レベルの自動化

Azure VMware Solution の個々のワークロード内では、VM ごとのレベルで自動化を設定できます。 この自動化はオンプレミスと同じ方法で実現され、この記事では取り上げていません。 この自動化の例として、Microsoft Configuration Manager、Chef、Puppet、Ansible があります。 オンプレミス エージェントを使用する VM レベルの構成で Azure Automation を使用することもできます。

次の手順

設計分野を読み終えたら、エンタープライズ規模のシナリオでの Azure VMware Solution のアーキテクチャのアプローチと実装について学びます。

Azure VMware Solution のランディング ゾーン アクセラレータ