Azure VMware Solution は、専用のベア メタル Azure インフラストラクチャから構築された VMware vSphere クラスターを含むプライベート クラウドを提供します。 オンプレミス環境からワークロードを移行し、新しい仮想マシン (VM) をデプロイし、プライベート クラウドからAzureサービスを使用できます。 VMware と Azure ネイティブ機能の組み合わせを使用して、ワークロードの高可用性と回復性を実現できます。
Azureを使用する場合、信頼性は共有の責任です。 Microsoftには、回復性と回復性をサポートするためのさまざまな機能が用意されています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害、可用性ゾーンの停止、リージョンの停止など、潜在的な障害や問題に対するAzure VMware Solution回復性を確保する方法について説明します。 また、バックアップを使用して他の種類の問題から復旧する方法についても説明し、Azure VMware Solution サービス レベル アグリーメント (SLA) に関するいくつかの重要な情報を強調します。
運用環境のデプロイに関する推奨事項
Azure VMware Solutionデプロイでは、さまざまな領域にわたって慎重に計画する必要があり、多くの場合、複数のAzure サービスが必要です。 詳細については、Azure Well-Architected Framework の Azure VMware Solution ワークロード を参照してください。
信頼性アーキテクチャの概要
Azure VMware Solutionは、VMware vSphere クラスターと共にハイパーコンバージド インフラストラクチャ (HCI) を使用します。
Azure VMware Solutionをデプロイするときは、1 つ以上のクラスターを持つ private cloud をデプロイします。 各クラスターには、コンピューティング、仮想 SAN (vSAN) 経由のストレージ、VMware NSX 経由のネットワークを提供する ESXi ホストが含まれています。 Azure VMware Solutionには次の 2 つの世代があります。
Gen 1 では、ノードに専用のベア メタル ハードウェアを使用し、専用のネットワーク アプローチを使用します。 主要な概念の詳細については、「Azure VMware Solutionプライベート クラウドとクラスターの概念を参照してください。
Gen 2 では、標準のAzure VM の種類とAzure仮想ネットワークが使用されます。 このアーキテクチャにより、ネットワーク アーキテクチャが簡素化され、データ転送速度が向上し、ワークロードの待機時間が短縮され、他のAzure サービスにアクセスするときのパフォーマンスが向上します。
障害耐性
Azure VMware Solutionには、インフラストラクチャレベルとアプリケーション レベルの両方で障害を処理するいくつかのメカニズムが用意されています。
vSphere High Availability (HA): vSphere HA は ESXi ホストと VM を監視します。 ホストが失敗した場合、正常なホスト上の影響を受ける VM が自動的に再起動されます。 vSphere HA は既定でオンになり、単一ノードの障害に対してコンピューティング容量とメモリ容量が予約されます。
vSAN フォールト トレランス: vSAN ストレージ ポリシーは、ホスト間でデータの複数のコピーを保持することで、ストレージ レベルの一時的な障害から保護します。 ストレージ パスまたはディスクで一時的な問題が発生した場合、vSAN は正常なストレージ パスへのフェールオーバーを自動的に処理します。
Network redundancy: Azure VMware Solution は、ネットワーク レベルの一時的な障害を処理するための冗長なネットワーク パスと複数の VMkernel ネットワーク アダプターを提供します。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。
クラウドでホストされているすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure一時的な障害処理ガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
Azure VMware Solution VM 上で実行されるアプリケーションの場合は、一時的な障害を処理するための標準プラクティスを実装します。
指数バックオフを使用して適切な再試行ポリシーを設定します。
外部サービス呼び出しにはサーキット ブレーカー パターンを使用します。
アプリケーションの正常性を監視し、デグレードのなめらかな低下を実装します。
可能な限りステートレス アプリケーションを設計して、VM の再起動の影響を軽減します。
可用性ゾーンの障害に対する回復性
Availability zones は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
Azure VMware Solution Gen 1 は、ストレッチクラスターを通じて、リージョン内の 2 つの可用性ゾーンに ESXi ホストを分散させることで、可用性ゾーンをサポートします。 Microsoft使用するゾーンを選択します。 クラスターは 2 つのゾーン間でアクティブ/アクティブ構成で実行され、vSAN も複数のゾーンにまたがる。 各ワークロードを 1 つまたは 2 つのゾーンにデプロイするかどうかを指定できます。
監視ノードは、スプリット ブレイン シナリオのクォーラムを提供するために、3 番目の可用性ゾーンに自動的にデプロイされます。 Microsoftは監視ノードを自動的に管理します。
標準クラスターは、ゾーン間で拡張されないクラスターです。 標準クラスターでは、クラスターとそのすべての ESXi ホストは 非ゾーン または リージョンと見なされます。 非ゾーン クラスターは、リージョン内の任意の可用性ゾーンに配置される可能性があり、Microsoftはゾーンを選択します。 リージョン内の可用性ゾーンで障害が発生した場合、非ゾーン クラスターとホストが影響を受けるゾーンに存在し、ダウンタイムが発生する可能性があります。
Azure VMware Solution Gen 2 では、プライベート クラウドの zonal デプロイがサポートされています。 ゾーンプライベート クラウドを設定すると、その各クラスターとそのすべての ESXi ホストが、選択した単一の可用性ゾーンにデプロイされます。
ゾーンプライベート クラウドでは、可用性ゾーンの障害から保護されません。 複数のプライベート クラウドを個別の可用性ゾーンにデプロイして回復性を高めることができますが、各プライベート クラウドを個別にデプロイおよび構成する必要があります。
可用性ゾーンを選択しない場合、プライベート クラウド、そのクラスター、およびすべての ESXi ホストは 非ゾーン または リージョンと見なされます。 非ゾーン クラスターは、リージョン内の任意の可用性ゾーンに配置される可能性があり、Microsoftはゾーンを選択します。 リージョン内の可用性ゾーンで障害が発生した場合、影響を受けるゾーン内の非ゾーン クラスターでダウンタイムが発生する可能性があります。
他の世代の可用性ゾーンのサポートの詳細については、この記事の冒頭で適切な世代を選択してください。
Requirements
Region support: Stretched クラスターは、ストレッチ クラスター構成をサポートするAzureリージョンでのみ使用できます。 現在のリージョンでのサポート状況については、Azure リージョンの可用性ゾーンとホスト型のマッピング テーブルを確認してください。
最小ホスト数: ストレッチ クラスター構成を有効にするには、少なくとも 6 つのホストを 2 つの可用性ゾーン (ゾーンごとに 3 つのホスト) にデプロイします。 スケール インまたはスケールアウトするときは、各ゾーンに同じ数のホストが含まれるように、ペアでスケールインする必要があります。
ホスト SKU: AV36、AV36P、および AV52 ホストの種類では、ストレッチ クラスターがサポートされます。 AV64 SKU では、ストレッチ クラスターはサポートされていません。
- Region support:Azure VMware Solution Gen 2 と availability zones の両方をサポートするリージョンにゾーン プライベート クラウドをデプロイできます。
考慮事項
リージョン内の各可用性ゾーンは、特定のホストの種類をサポートできます。 各ゾーンで使用できるホストの種類の詳細な一覧については、「Azure リージョン可用性ゾーンからホスト型マッピング テーブルを参照してください。
費用
クラスターの可用性ゾーンの構成に関係なく、クラスター内の各ノードのコストが発生します。 価格の詳細については、「Azure VMware Solution pricing」を参照してください。
可用性ゾーンのサポートを設定する
新しいクラスターをデプロイする: サポートされているリージョンに新しいAzure VMware Solutionプライベート クラウドを作成する場合は、デプロイ時に拡張クラスターとして設定できます。 この構成では、2 つの可用性ゾーンにホストが自動的に分散されます。 詳細については、「vSAN ストレッチ クラスターをデプロイする」を参照してください。
既存のクラスター: 標準クラスターをストレッチ クラスターに変換することはできません。また、ストレッチ クラスターを標準クラスターに変換することもできません。 代わりに、新しいクラスターをデプロイし、ワークロードを移行する必要があります。
新しいクラスターをデプロイする: サポートされているリージョンに新しいAzure VMware Solutionプライベート クラウドを作成するときに、その可用性ゾーンを選択できます。
既存のクラスター: 既存のクラスターの可用性ゾーンの構成を変更することはできません。 代わりに、新しいクラスターをデプロイし、ワークロードを移行する必要があります。
すべてのゾーンが正常な場合の動作
このセクションでは、クラスターが拡張され、すべての可用性ゾーンが運用可能な場合に想定される内容について説明します。
ゾーン間操作: VM は、いずれかの可用性ゾーン内のホストで実行できます。 vSphere Distributed Resource Scheduler (DRS) アフィニティとアンチアフィニティ ルールを使用して VM の配置を制御し、パフォーマンスまたは可用性の要件を最適化できます。
ゾーン間データ レプリケーション: vSAN は、可用性ゾーン間でデータを同期的にレプリケートします。 両方のゾーンで、一貫性のあるデータ整合性を確保するために、各書き込み操作が完了する前に確認されます。
このセクションでは、クラスターがゾーンプライベート クラウドにデプロイされ、すべての可用性ゾーンが運用可能な場合に想定される内容について説明します。
ゾーン間操作: VM は、クラスターの可用性ゾーン内のホストで実行されます。
ゾーン間データ レプリケーション: データは別のゾーンにレプリケートされません。
ゾーン障害時の動作
このセクションでは、クラスターが拡張され、可用性ゾーンの停止が発生したときに想定される内容について説明します。
- 検出と応答: Azure VMware Solution は、ゾーン障害に対するインフラストラクチャ レベルの応答を管理します。 vSphere HA はゾーン障害を自動的に検出し、必要に応じて VM の再起動手順を開始します。
- Notification: ゾーンがダウンしても、Microsoftから自動的に通知はされません。 ただし、Azure Resource Health を使用して個々のリソースの正常性を監視したり、Resource Healthアラートを設定して問題を通知することができます。 また、Azure Service Health を使用して、ゾーンエラーを含むサービスの全体的な正常性を把握し、Service Health アラートを設定して問題を通知することもできます。
アクティブな要求: 障害が発生した可用性ゾーンで実行されるすべての VM は、正常な可用性ゾーン内のホストで再起動されます。 影響を受ける VM へのアクティブな要求と接続は終了し、クライアントはそれらを再試行する必要があります。
予想されるダウンタイム: 正常なゾーンで失敗した VM を再起動する時間は、通常、VM の構成と起動手順に応じて数分です。 ストレッチ クラスターは、容量を減らして動作したままです。
障害が発生した可用性ゾーンにミラーリング監視ノードが含まれている場合、ミラーリング監視サーバーは到達不能になります。 十分なデータ レプリカを使用できる限り、データ ホストと実行中のワークロードは、データを即座に失うことなく動作し続けます。 ただし、vSAN では、この状態ではクォーラム認識が失われます。 クォーラム損失により、配置と回復の決定を安全に行うことができなくなります。 また、障害後の VM の電源オン、再調整、修復など、特定の操作もブロックされます。
予想されるデータ損失: vSAN ではゾーン間の同期レプリケーションが使用されるため、ゾーン障害時にデータ損失は発生しません。
再配布: vSphere DRS は、VM ワークロードを正常な可用性ゾーンに自動的に再配布します。 VMware NSX 経由のネットワーク トラフィック ルーティングは、新しい VM の配置に自動的に適応します。
このセクションでは、クラスターがゾーン プライベート クラウドにデプロイされ、可用性ゾーンの停止が発生した場合に想定される内容について説明します。
- 検出と応答: 可用性ゾーンの損失を検出する必要があります。 必要に応じて、別の可用性ゾーンで先ほど作成したセカンダリ クラスターへのフェールオーバーを開始できます。
- Notification: ゾーンがダウンしても、Microsoftから自動的に通知はされません。 ただし、Azure Resource Health を使用して個々のリソースの正常性を監視したり、Resource Healthアラートを設定して問題を通知することができます。 また、Azure Service Health を使用して、ゾーンエラーを含むサービスの全体的な正常性を把握し、Service Health アラートを設定して問題を通知することもできます。
アクティブな要求: 影響を受ける VM へのアクティブな要求と接続は終了し、クライアントはそれらを再試行する必要があります。
予想されるダウンタイム: ゾーンが使用できない場合、クラスターとそのワークロードは、可用性ゾーンが復旧するまで使用できません。
予想されるデータ損失: 影響を受けるゾーン内のデータは、ゾーンが回復するまで使用できません。
再 分配： 必要に応じて、正常なゾーン内の他のクラスターにトラフィックを切り替える必要があります。
ゾーンの回復
可用性ゾーンが復旧すると、vSphere DRS は必要に応じて、DRS の構成とアフィニティの規則に基づいて、復旧されたゾーンに VM を再配布できます。 vMotion 操作を使用して VM の配置を手動で制御することもできます。
可用性ゾーンが復旧すると、ゾーン内のクラスターとホストが再び使用できるようになります。 ワークロードに必要なゾーン回復手順とデータ同期は、お客様が担当します。
ゾーンエラーのテスト
ゾーンの障害に備えて、VM の再起動とネットワーク パスの変更に対するアプリケーションの回復性をテストします。特に、クラスターを拡張したり、異なるゾーン内の個別のクラスターにアプリケーションをデプロイしたりする場合です。
Azure VMware Solutionはゾーン障害に対するインフラストラクチャの応答を管理するため、主に VM の再起動に対するアプリケーションの応答をテストする必要があります。
別のゾーンまたはリージョン内の別のクラスターへのフェールオーバーなど、ゾーンの障害に対するインフラストラクチャの応答は、お客様が担当します。 応答プロセスを十分にテストしていることを確認します。
リージョン全体の障害に対する回復性
各Azure VMware Solution クラスターは、1 つのAzure リージョン内にデプロイされます。 リージョンが使用できなくなった場合、プライベート クラウドとその中のすべてのリソースが使用できなくなります。
ただし、さまざまなアプローチを組み合わせたり、既存のインフラストラクチャと統合したりして、特定のビジネス要件と回復目標を満たすカスタムマルチリージョン ソリューションを設計することもできます。
回復性のためのカスタム マルチリージョン ソリューション
Azure VMware Solutionを使用して複数リージョンの回復性を実現するには、複数のリージョンに個別のプライベート クラウドをデプロイし、フェールオーバーやその他のディザスター リカバリー (DR) ソリューションを実装する必要があります。
さまざまなオプションで、さまざまな回復性要件がサポートされます。 詳細については、Azure VMware Solution仮想マシンの Disaster 復旧ソリューションを参照してください。
バックアップと復元
Azure VMware Solutionは、vCenter Server、NSX Manager、HCX Manager (有効な場合) などの管理コンポーネントを自動的にバックアップします。 これらの管理バックアップからコンポーネントを復元するには、Azure サポート要求を作成します。
VM ワークロードの場合、Azure VMware Solutionでは複数のバックアップ 方法がサポートされます。 詳細については、「Azure VMware Solution VM のBackup ソリューションを参照してください。
サービス メンテナンスに対する回復性
Azureは、セキュリティ更新プログラムの適用、新機能のデプロイ、サービスの信頼性の向上のためのプラットフォームの自動メンテナンスを行います。
メンテナンスがAzure VMware Solutionコンポーネントに与える影響について学習し、メンテナンスを担当するコンポーネントと、Microsoftが管理するコンポーネントについて理解するには、Azure VMware Solutionプライベート クラウドメンテナンスに関するページを参照してください。
メンテナンスが運用環境のワークロードに影響する可能性を減らすために、クラスターのメンテナンス期間を設定できます。 詳細については、「Azure VMware Solution のセルフサービスメンテナンス計画」を参照してください。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) では、各サービスの予想される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について説明します。 詳細については、オンラインサービスのSLAを参照してください。
Azure VMware Solutionでは、ワークロード インフラストラクチャと管理操作にさまざまな可用性 SLA が提供されます。
ストレッチ クラスターとして設定したクラスターでは、ワークロード インフラストラクチャの可用性 SLA が高くなります。
ただし、可用性 SLA を満たすには、特定の方法でクラスターを設定する必要があります。 詳細については、SLA テキストを参照してください。