Azure での Windows 仮想マシンの可用性の管理

複数の仮想マシンを設定および管理して、Azure の Windows アプリケーションの高い可用性を確保する方法について説明します。 Linux 仮想マシンの可用性を管理することもできます。

メモ

Azure には、リソースの作成と操作に関して、Resource Manager とクラシックの 2 種類のデプロイメント モデルがあります。 この記事では、両方のモデルについて取り上げていますが、最新のデプロイではリソース マネージャー モデルの使用をお勧めします。

クラシック デプロイメント モデルを使用しているときに、可用性セットを作成および使用する方法については、 可用性セットの構成方法に関するページをご覧ください。

計画済み、または計画外メンテナンスについて理解する

仮想マシンの可用性に影響を与える可能性のある Microsoft Azure プラットフォーム イベントには、計画的なメンテナンスと計画外のメンテナンスの&2; 種類があります。

  • 計画済みメンテナンス イベント とは、仮想マシンを実行しているプラットフォーム インフラストラクチャの全体的な信頼性、パフォーマンス、セキュリティを向上させることを目的として、基板となる Azure プラットフォームに対して Microsoft が提供する定期的な更新を意味します。 これらの更新のほとんどは、仮想マシンやクラウド サービスに影響を及ぼすことなく実行されます。 ただし、プラットフォーム インフラストラクチャに必要な更新を適用するため、仮想マシンの再起動が求められる場合もあります。
  • 計画外メンテナンス イベント は、仮想マシンの基盤となっているハードウェや物理インフラストラクチャに何らかの不具合が発生した場合に行われます。 こうした不具合には、ネットワーク障害、ローカル ディスク障害、またはその他のラック レベルでの障害が挙げられます。 そのような障害が検知されると、Azure プラットフォームは、仮想マシンをホストしている異常な物理マシンから正常な物理マシンへと、仮想マシンを自動的に移行します。 このような例が発生することはまれですが、この場合も仮想マシンの再起動が求められる場合があります。

前述のようなイベントが&1; つ以上発生した場合にダウンタイムの影響を低減するため、下記のような高可用性のためのベスト プラクティスを仮想マシンに適用することをお勧めします。

冗長性実現のために複数の仮想マシンを可用性セット内に構成する

アプリケーションに冗長性をもたらすには、可用性セット内に&2; つ以上の仮想マシンをグループ化することをお勧めします。 このような構成により、計画済み、または計画外のメンテナンス イベント中に、少なくとも 1 つの仮想マシンが利用可能となり、99.95% の Azure SLA を満たします。 詳細については、「 Virtual Machines の SLA」を参照してください。

重要

可用性セット内の仮想マシンが&1; つだけにならないようにしてください。 この構成の VM は、SLA 保証の対象とはならず、単一の VM が Azure Premium Storage を使用している場合を除き、Azure の計画されたメンテナンス イベント時にダウンタイムが発生します。 Premium Storage を使用する単一 の VM では、Azure SLA が適用されます。

基盤となる Azure プラットフォームにより、可用性セット内の各仮想マシンに更新ドメイン障害ドメインが割り当てられます。 所定の可用性セットに対して、同時に再起動される仮想マシンのグループと物理ハードウェアを示す、ユーザーが構成できない 5 つの更新ドメインが既定で割り当てられます (その後、最大 20 の更新ドメインを提供できるように Resource Manager のデプロイを増やすことができます)。 1 つの可用性セット内に&5; つ以上の仮想マシンが構成されているとき、6 つ目の仮想マシンは&1; つ目の仮想マシンと同じ更新ドメイン内に配置され、7 つ目は&2; つ目の仮想マシンと同じ更新ドメイン内に配置されるという方法で処理されます。 計画済みメンテナンス中は、更新ドメインの再起動が順番に処理されない場合がありますが、一度に再起動される更新ドメインは&1; つのみです。

障害ドメインは電源とネットワーク スイッチを共有する仮想マシンのグループを定義します。 既定では、可用性セット内に構成された仮想マシンは、Resource Manager のデプロイ用に最大&3; つの障害ドメインに分けられます (クラシックの場合は&2; つの障害ドメイン)。 仮想マシンを可用性セットに配置しても、アプリケーションがオペレーティング システムやアプリケーションの障害から保護されるわけではありませんが、潜在的な物理ハードウェア障害、ネットワーク障害、または電力の中断の影響を低下させることができます。

更新ドメインと障害ドメインの構成の概念図

Managed Disk の障害ドメインと可用性セット

Azure Managed Disks を使用している VM の場合、VM は管理対象の可用性セットを使用している場合に管理ディスクの障害ドメインに合わせて配置されます。 この配置により、VM に接続されたすべての管理ディスクは必ず同じ管理ディスクの障害ドメイン内にあります。 管理対象の可用性セットには、管理ディスクを持つ VM だけを作成できます。 管理ディスクの障害ドメインの数はリージョンによって異なり、管理ディスクの障害ドメインはリージョンあたり&2; つまたは&3; つになります。

各アプリケーション層に対して別々の可用性セットを構成する

仮想マシンがすべてほぼ同一で、アプリケーションに対する役割が同じである場合は、アプリケーションの各層に対して別々の可用性セットを構成することをお勧めします。 同じ可用性セットの中に&2; つの異なる層を配置した場合、同じアプリケーション層内にあるすべての仮想マシンを一度に再起動できます。 各層に対する別々の可用性セット内に少なくとも&2; つの仮想マシンを構成することで、各層あたり&1; つ以上の仮想マシンの可用性が確保されます。

たとえば、ISS、Apache、Nginx を実行しているアプリケーションのフロントエンド内のすべての仮想マシンを、1 つの可用性セットに配置します。 このとき、フロントエンド仮想マシンのみが同じ可用性セット内に配置されるようにします。 同様に、別の可用性セットには、複製された SQL Server 仮想マシンまたは MySQL 仮想マシンのように、データ層の仮想マシンのみが配置されるようにします。

アプリケーション層

ロード バランサーと可用性セットを結合する

Azure ロード バランサー と可用性セットを結合することで、アプリケーションの復元性を最大化できます。 Azure ロード バランサーは、複数の仮想マシンにトラフィックを振り分けます。 当社の標準層の仮想マシンには Azure ロード バランサーが含まれています。 すべての仮想マシン層に Azure Load Balancer が含まれているわけではありません。 仮想マシンの負荷分散の詳細については、「 仮想マシンの負荷分散」を参照してください。

複数の仮想マシン間でトラフィックを分散するためのロード バランサーが構成されていない場合、計画済みメンテナンス イベントによって、トラフィックを提供している仮想マシンのみに影響が生じ、アプリケーション層の機能停止が生じます。 同じ層の複数の仮想マシンを、同じロード バランサーと可用性セット以下に配置することで、少なくとも&1; つのインスタンスによってトラフィックの提供を継続することができます。

各可用性セットに複数のストレージ アカウントを使用する

Azure Managed Disks を使用する場合は、次のガイダンスを省略できます。 ディスクが VM の可用性セットに合致する障害ドメインに格納されるため、Azure Managed Disks には高可用性と冗長性の特性があります。 詳しくは、「Azure Managed Disks overview」(Azure Managed Disks の概要) をご覧ください。

非管理対象ディスクを使用する場合は、VM 内の仮想ハード ディスク (VHD) で使用されるストレージ アカウントに関して、従うべきベスト プラクティスがあります。 各ディスク (VHD) は、Azure ストレージ アカウント内のページ BLOB です。 可用性セット内の VM の高可用性を実現するには、ストレージ アカウントに冗長性を持たせ、ストレージ アカウントを分離することが重要です。

  1. VM に関連付けられているすべてのディスク (OS とデータ) を同じストレージ アカウント内に保持する。
  2. ストレージ アカウントに VHD を追加する場合は、ストレージ アカウントの制限を考慮する。
  3. 可用性セット内の VM ごとに個別のストレージ アカウントを使用します。 同じ可用性セット内の複数の VM でストレージ アカウントを共有しないでください。 前述のベスト プラクティスに従っている限り、異なる可用性セットの VM でストレージ アカウントを共有してもかまいません

次のステップ

仮想マシンの負荷分散の詳細については、 仮想マシンの負荷分散に関するページをご覧ください。