次の方法で共有

Virtual Machines の信頼性

Azure Virtual Machines (VM) は、オンデマンドでスケーラブルなコンピューティング リソースを提供します。 VM は、基本的なインフラストラクチャ サービスとして、ミッション クリティカルなワークロードにエンタープライズ レベルの信頼性と可用性を提供するように設計されています。

この記事では、可用性ゾーンのサポート、バックアップ、プラットフォームのメンテナンス中の信頼性の維持など、 Azure Virtual Machines での信頼性のサポートについて説明します。

信頼性は、お客様と Microsoft の間で共有される責任です。 このガイドを使用して、特定のビジネス目標とアップタイム目標を満たす信頼性オプションを決定できます。

信頼性は、お客様と Microsoft の間で共有される責任です。 このガイドを使用して、特定のビジネス目標とアップタイム目標を満たす信頼性オプションを決定できます。

重要

VM の信頼性を考慮する場合は、ディスク、ネットワーク インフラストラクチャ、VM で実行されるアプリケーションの信頼性も考慮する必要があります。 VM の回復性を高める場合でも、他のリソースやアプリケーションにも回復性がない場合、その増加は影響を受けない可能性があります。 回復性の要件によっては、複数の領域で構成の変更が必要になる場合があります。

運用環境のデプロイに関する推奨事項

ソリューションの信頼性要件をサポートするために VM をデプロイする方法、および信頼性がアーキテクチャの他の側面にどのように影響するかについては、「 Azure Well-Architected Framework での Azure Virtual Machines とスケール セットのアーキテクチャのベスト プラクティス」を参照してください。

信頼性アーキテクチャの概要

VM は、自分で VM をプロビジョニングする場合でも、透過的にプロビジョニングして管理する他の Azure コンピューティング サービスを使用する場合でも、Azure の基本的なコンピューティング ユニットです。

個々の VM は、 単一インスタンス VM と呼ばれることもあります。 これは、物理サーバーである特定のホストで実行されます。 ほとんどの VM は、ホストを他の VM と共有します。

VM を作成すると、基になるインフラストラクチャで VM を実行する場所に影響を与えることができます。 一般に、信頼性、待機時間、分離の要件に基づいて選択します。 Azure には、VM の配置に影響する次の構成オプションが用意されています。

  • 地域： VM を実行する Azure リージョン を選択できます。 リージョンは、複数のデータセンターを含む地理的な領域であり、それぞれが多数のホストを持つ場合があります。

  • 可用性ゾーン:可用性ゾーン は、各 Azure リージョン内のデータセンターの物理的に分離されたグループです。 可用性ゾーンをサポートするリージョンでは、VM が実行されているゾーンを選択できます。 詳細については、この記事で後述 する可用性ゾーンのサポート を参照してください。

  • 可用性セット: 可用性セットは、冗長性と可用性を提供するためにアプリケーションがどのように構築されているかを Azure が理解できるようにする VM の論理的なグループです。

    可用性セットを使用する場合は、VM のグループを異なる 障害ドメインに分散するように Azure に指示します。 このディストリビューションは、共通の電源とネットワーク スイッチを共有する仮想マシンをグループ化することで、ローカライズされたハードウェア障害のリスクを最小限に抑えます。

    可用性セットでは、異なる 更新ドメインに異なる VM を配置することもできます。これは、Azure プラットフォームによるプラットフォーム更新プログラムのロールアウト方法を制御します。 更新ドメインを使用すると、一度に更新のために VM のサブセットのみが再起動されるようにすることができます。

  • 近接通信配置グループ: VM 間の待機時間を最小限に抑える必要があるワークロードの場合は、 近接通信配置グループ を使用して、Azure が VM を物理的に近づけられるようにすることができます。 ただし、近接通信の配置は、データセンターの停止がグループ内のすべての VM に影響を与える可能性があることを意味します。 高い信頼性を実現するには、異なる可用性ゾーンに複数の近接配置グループをプロビジョニングすることが必要になる場合があります。

  • 専用ホスト:Azure Dedicated Hosts を使用して、厳密なコンプライアンス要件など、1 つ以上の VM を実行する独自の物理サーバーをプロビジョニングできます。 ただし、専用ホストをプロビジョニングすると、データセンターの停止がそのホスト上のすべての VM に影響を与える可能性があります。 高い信頼性を実現するには、異なる可用性ゾーンに複数の専用ホストをプロビジョニングすることが必要になる場合があります。

同様の機能を実行する VM のセットを作成する場合は、 仮想マシン スケール セット を使用して VM をグループとして作成および管理することを検討してください。 スケール セットには、VM を複数の可用性ゾーンに分散するなど、信頼性の高いオプションも用意されています。

VM の可用性の詳細については、 Azure Virtual Machines の可用性オプションに関するページを参照してください。

一時的な障害

一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。

クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。

VM で実行されているアプリケーションでは、サービスの一時的な中断がワークロードに影響を与えないように、適切な障害処理戦略を実装する必要があります。

可用性ゾーンのサポート

可用性ゾーン は、各 Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。

個々の VM は ゾーン 構成でデプロイできます。つまり、選択した単一の可用性ゾーンに固定されます。 ゾーン VM 自体では、ゾーンの停止に対する回復性はありません。 ただし、複数の VM を作成して異なる可用性ゾーンに配置し、VM インスタンス間でアプリケーションとデータを分散させることができます。 または、 仮想マシン スケール セット を使用して一連の仮想マシンを作成し、複数のゾーンに分散させることもできます。

ゾーンに合った VM を構成しない場合は、 非ゾーン または リージョンと見なされます。 非ゾーン VM は、リージョン内の任意の可用性ゾーンに配置される場合があります。 リージョン内の可用性ゾーンで障害が発生した場合、非ゾーン VM が影響を受けるゾーンに存在し、ダウンタイムが発生する可能性があります。

リージョンのサポート

ゾーン VM は、 可用性ゾーンをサポートする任意のリージョンにデプロイできます。

ただし、一部の VM の種類とサイズは、特定のリージョンまたはリージョン内の特定のゾーンでのみ使用できます。 必要な VM の種類をサポートするリージョンとゾーンを確認するには、次のリソースを使用します。

費用

ゾーン VM と非ゾーン VM の間にはコストの違いはありません。

可用性ゾーンのサポートを設定する

このセクションでは、仮想マシン インスタンスの可用性ゾーンのサポートを構成する方法について説明します。

注

使用する可用性ゾーンを選択した場合、実際には "論理可用性ゾーン" を選択していることになります。 別の Azure サブスクリプションの他のワークロード コンポーネントをデプロイした場合、別の "論理可用性ゾーン" 番号を使用して、同じ物理可用性ゾーンにアクセスできる場合があります。 詳細については、「物理ゾーンと可用性ゾーン」を参照してください。

通常の運用

このセクションでは、仮想マシン インスタンスが可用性ゾーンのサポートを使用して構成され、すべての可用性ゾーンが動作している場合に想定される内容について説明します。

  • ゾーン間のトラフィック ルーティング: 異なる可用性ゾーンにある VM を含め、VM 間でトラフィックをルーティングする責任があります。 一般的な方法としては、Azure Load Balancer と Azure Application Gateway があります。 Azure 負荷分散オプションの詳細については、「 Azure アーキテクチャ センター - 負荷分散オプション」を参照してください。

  • ゾーン間のデータ レプリケーション: 異なる可用性ゾーン内の VM 間を含め、VM 間で行う必要があるデータ レプリケーションは、ユーザーが担当します。 VM 上で実行されるデータベースやその他の同様のステートフル アプリケーションは、多くの場合、データをレプリケートする機能を提供します。

ゾーンダウン エクスペリエンス

このセクションでは、仮想マシン インスタンスが可用性ゾーンのサポートを使用して構成されていて、その可用性ゾーンで障害が発生した場合に想定される内容について説明します。

  • 検出と応答: 仮想マシンに影響を与えるゾーン障害を検出して対応する責任があります。

  • 通知: Azure Resource Health を 使用してゾーンの障害を検出し、フェールオーバー プロセスをトリガーします。

  • アクティブな要求: ゾーン障害時に VM で発生したアクティブな要求またはその他の作業が終了する可能性があります。

  • 予想されるデータ損失: ゾーン VM ディスクは、ゾーン障害時に使用できない可能性があります。

    ゾーン冗長ディスクを使用していて、VM が障害の影響を受ける場合は、障害が発生した VM から ZRS ディスクを 強制的にデタッチ し、ZRS ディスクを別の VM にアタッチできます。

  • 予想されるダウンタイム: VM は、可用性ゾーンが復旧するまでダウンしたままです。

  • トラフィックの再ルーティング: 正常なゾーン内の他の VM にトラフィックを再ルーティングする責任があります。

    ゾーン回復性の高いロード バランサーを構成し、正常性チェックを実行する場合、ロード バランサーは通常、失敗した VM を検出し、正常なゾーン内の他の VM インスタンスにトラフィックをルーティングできます。

ゾーンの回復

ゾーンが正常になると、ゾーン内の VM が再起動されます。 ワークロードで必要に応じて、ゾーンの回復手順とデータ同期を行う必要があります。

ゾーン障害を検出するためのテスト

Azure Chaos Studio を使用して、実験の一部として VM の損失をシミュレートできます。 Chaos Studio には、VM のシャットダウンなど、 VM に組み込みの障害が用意されています。 これらの機能を使用して、ゾーンの障害をシミュレートし、フェールオーバー プロセスをテストできます。

代替のマルチゾーン アプローチ

複数の VM を異なるゾーンにデプロイする場合、レプリケーション、負荷分散、フェールオーバー、フェールバック プロセスの構成と管理を行う必要があります。

一部のアプリケーションには、複数の VM にデプロイするときに役立つ組み込み機能が用意されています。 たとえば、 Azure VM 上の SQL Server には 、可用性ゾーン全体の構成と管理プロセスを簡略化するための一連の機能が用意されています。

アプリケーションが一度に 1 つのゾーンで実行され、ゾーン間でほぼ瞬時にフェールオーバーする必要がない場合は、 Azure Site Recovery のゾーン間ディザスター リカバリー の使用を検討できます。 ゾーン間のディザスター リカバリーには、注意すべき重要な制限事項がいくつかあります。そのため、要件を十分に確認してください。

マルチリージョン サポート

Azure Virtual Machines は単一リージョンのリソースです。 リージョンが使用できなくなった場合、VM も使用できなくなります。

代替のマルチリージョン アプローチ

複数の VM を異なるリージョンにデプロイできますが、レプリケーション、負荷分散、およびフェールオーバー プロセスを実装する必要があります。

Azure Site Recovery は、VM とそのデータをセカンダリ リージョンにレプリケートすることでディザスター リカバリーを可能にするサービスです。 詳細については、 Azure から Azure へのディザスター リカバリー アーキテクチャに関するページを参照してください。

一部のアプリケーションでは、データをレプリケートし、異なるリージョンを含む複数の VM に作業を分散するためのクラスターまたはその他のコンストラクトが作成されます。 これらのアプリケーションを使用すると、マルチリージョン ソリューションの構成を簡略化できます。

複数のリージョン間での VM の使用を示すアーキテクチャの例については、「 Traffic Manager、Azure Firewall、Application Gateway を使用した複数リージョンの負荷分散」を参照してください。

サービスメンテナンス中の信頼性

Azure は、信頼性を確保するために、VM に対して定期的なメンテナンスを実行します。 メンテナンス アクティビティ中にワークロードを確実に運用できる方法は複数あります。

  • 可用性セットまたは仮想マシン スケール セットを使用する場合は、更新ドメインを構成できます。 更新ドメインは、VM がすべて同時に再起動されないように、異なる VM 間でメンテナンス アクティビティを分散するのに役立ちます。

  • メンテナンス 制御を使用して、VM にメンテナンスが適用されるタイミングをカスタマイズできます。 メンテナンス構成を使用して、ワークロードに合ったタイミングでスケジュールを設定できます。

  • 今後のメンテナンス アクティビティの通知を受け取ることができます。

詳細については、「 ゲストの更新プログラムとホストのメンテナンスの概要」を参照してください。

Backup

Azure Virtual Machines は、Azure Backup サービスを介したバックアップをネイティブにサポートします。 Azure Backup は、バックアップを作成および管理することで Azure Virtual Machines を保護するためのネイティブ ソリューションを提供し、接続されているすべてのディスクを含む仮想マシン全体に対してアプリケーション整合性の保護を提供します。 この方法は、複数のディスクまたはアプリケーション対応バックアップの調整されたバックアップが必要な場合に最適です。 データベース ワークロードの場合は、トランザクション整合性保護と高速復旧オプションを提供するアプリケーション固有のバックアップ ソリューションを検討してください。

バックアップの取得頻度、バックアップの保持期間、バックアップの保存方法をカスタマイズできます。 詳細については、 VM の Azure Backup に関するページを参照してください。

Azure Backup では、VM に接続されているディスクもサポートされています。 詳細については、 Azure Disk Backup に関するページを参照してください。

サービス水準合意書

Azure Virutal Machines のサービス レベル アグリーメント (SLA) には、サービスの予想される可用性と、その可用性の期待を達成するために満たす必要がある条件が記述されています。

SLA は、VM の可用性の基本レベルを提供します。 SLA で定義されているアップタイムの割合は、2 つ以上の VM があり、次の場合に増加します。

  • これらの VM を 2 つ以上の可用性ゾーンにデプロイするように構成するか、または
  • 可用性セットにデプロイする VM を構成する

詳細については、 オンライン サービスの SLA を参照してください。

次のステップ