Azure での Windows 仮想マシンの可用性の管理Manage the availability of Windows virtual machines in Azure

複数の仮想マシンを設定および管理して、Azure の Windows アプリケーションの高い可用性を確保する方法について説明します。Learn ways to set up and manage multiple virtual machines to ensure high availability for your Windows application in Azure. Linux 仮想マシンの可用性を管理することもできます。You can also manage the availability of Linux virtual machines.

VM の再起動について - メンテナンスとダウンタイムUnderstand VM Reboots - maintenance vs. downtime

Azure の仮想マシンに影響する可能性のあるシナリオには、計画外のハードウェア メンテナンス、予期しないダウンタイム、および計画メンテナンスの 3 つがあります。There are three scenarios that can lead to virtual machine in Azure being impacted: unplanned hardware maintenance, unexpected downtime, and planned maintenance.

  • 計画外のハードウェア メンテナンス イベントは、物理マシンに関連するハードウェアまたはプラットフォーム コンポーネントの故障が起こることを Azure プラットフォームが予測した場合に発生します。Unplanned Hardware Maintenance Event occurs when the Azure platform predicts that the hardware or any platform component associated to a physical machine, is about to fail. プラットフォームが故障を予測すると、そのハードウェアでホストされている仮想マシンへの影響を軽減するために、計画外のハードウェア メンテナンス イベントが発生します。When the platform predicts a failure, it will issue an unplanned hardware maintenance event to reduce the impact to the virtual machines hosted on that hardware. Azure では、ライブ マイグレーション テクノロジを使用して、障害が発生したハードウェアから正常な物理マシンに仮想マシンを移行します。Azure uses Live Migration technology to migrate the Virtual Machines from the failing hardware to a healthy physical machine. ライブ マイグレーションは、仮想マシンを短時間一時停止するだけの VM 保持操作です。Live Migration is a VM preserving operation that only pauses the Virtual Machine for a short time. メモリ、開いているファイル、ネットワーク接続は保持されますが、イベントの前後にパフォーマンスが低下する可能性があります。Memory, open files, and network connections are maintained, but performance might be reduced before and/or after the event. ライブ マイグレーションを使用できない場合、以下で説明する VM で予期しないダウンタイムが発生します。In cases where Live Migration cannot be used, the VM will experience Unexpected Downtime, as described below.

  • 予期しないダウンタイムは、ハードウェアまたは仮想マシンの物理インフラストラクチャが予期せず失敗した場合に発生します。An Unexpected Downtime is when the hardware or the physical infrastructure for the virtual machine fails unexpectedly. こうした不具合には、ネットワーク障害、ローカル ディスク障害、またはその他のラック レベルでの障害が挙げられます。This can include local network failures, local disk failures, or other rack level failures. 障害が検知されると、Azure プラットフォームは、同じデータセンター内の正常な物理マシンに仮想マシンを自動的に移行 (復旧) します。When detected, the Azure platform automatically migrates (heals) your virtual machine to a healthy physical machine in the same datacenter. 復旧中に、仮想マシンでダウンタイム (再起動) が発生し、場合によっては一時ドライブが失われることがあります。During the healing procedure, virtual machines experience downtime (reboot) and in some cases loss of the temporary drive. 接続されている OS とデータ ディスクは常に保持されます。The attached OS and data disks are always preserved.

    仮想マシンでも、データセンター全体やリージョン全体に影響する停電や災害といった予期しない事象によってダウンタイムが発生することがあります。Virtual machines can also experience downtime in the unlikely event of an outage or disaster that affects an entire datacenter, or even an entire region. こうしたシナリオにおいて、Azure は可用性ゾーンリージョン ペアといった保護オプションを提供します。For these scenarios, Azure provides protection options including availability zones and paired regions.

  • 計画メンテナンス イベントは、仮想マシンを実行しているプラットフォーム インフラストラクチャの全体的な信頼性、パフォーマンス、セキュリティを向上させるために、基盤となる Azure プラットフォームに対して Microsoft が実行する定期的な更新です。Planned Maintenance events are periodic updates made by Microsoft to the underlying Azure platform to improve overall reliability, performance, and security of the platform infrastructure that your virtual machines run on. これらの更新のほとんどは、仮想マシンや Cloud Services に影響を及ぼすことなく実行されます (VM 保持メンテナンスに関する記事を参照してください)。Most of these updates are performed without any impact upon your Virtual Machines or Cloud Services (see VM Preserving Maintenance). Azure プラットフォームでは、可能な限り VM 保持メンテナンスを使用しようとしますが、基盤となるインフラストラクチャに必要な更新を適用するために、仮想マシンの再起動が必要になる場合もまれにあります。While the Azure platform attempts to use VM Preserving Maintenance in all possible occasions, there are rare instances when these updates require a reboot of your virtual machine to apply the required updates to the underlying infrastructure. この場合、適切な時間帯に VM のメンテナンスを開始することで、メンテナンスによる再デプロイ操作を伴う Azure の計画メンテナンスを実行できます。In this case, you can perform Azure Planned Maintenance with Maintenance-Redeploy operation by initiating the maintenance for their VMs in the suitable time window. 詳細については、仮想マシンの計画メンテナンスに関する記事を参照してください。For more information, see Planned Maintenance for Virtual Machines.

前述のようなイベントが 1 つ以上発生した場合にダウンタイムの影響を低減するため、下記のような高可用性のためのベスト プラクティスを仮想マシンに適用することをお勧めします。To reduce the impact of downtime due to one or more of these events, we recommend the following high availability best practices for your virtual machines:

可用性ゾーンを使ってデータセンター レベルの障害から保護するUse availability zones to protect from datacenter level failures

可用性ゾーンは、VM 上のアプリケーションとデータの可用性を維持するための制御レベルを拡張します。Availability zones expand the level of control you have to maintain the availability of the applications and data on your VMs. Availability Zones は、Azure リージョン内の一意の物理的な場所です。Availability Zones are unique physical locations within an Azure region. それぞれのゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータセンターで構成されています。Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking. 回復性を確保するため、有効になっているリージョンにはいずれも最低 3 つのゾーンが別個に存在しています。To ensure resiliency, there are a minimum of three separate zones in all enabled regions. Availability Zones は 1 リージョン内で物理的に分離されているため、データセンターで障害が発生した場合でもアプリケーションとデータを保護できます。The physical separation of Availability Zones within a region protects applications and data from datacenter failures. ゾーン冗長サービスによって、単一障害点から保護されるように Availability Zones 全体でアプリケーションとデータがレプリケートされます。Zone-redundant services replicate your applications and data across Availability Zones to protect from single-points-of-failure.

Azure リージョン内の可用性ゾーンは、障害ドメイン更新ドメインを組み合わせたものです。An Availability Zone in an Azure region is a combination of a fault domain and an update domain. たとえば、Azure リージョンの 3 つのゾーンに 3 つ以上の VM を作成する場合、VM は実際には 3 つの障害ドメインと 3 つの更新ドメインに分散されます。For example, if you create three or more VMs across three zones in an Azure region, your VMs are effectively distributed across three fault domains and three update domains. Azure プラットフォームは更新ドメインへのこの分散を認識し、異なるゾーン内の VM が同時に更新されないようにします。The Azure platform recognizes this distribution across update domains to make sure that VMs in different zones are not updated at the same time.

Availability Zones では、Azure によって業界最高の 99.99% VM アップタイム SLA が実現されます。With Availability Zones, Azure offers industry best 99.99% VM uptime SLA. 複数のゾーンにレプリケートされた VM を使用するソリューションを構築することで、1 つのデータセンターで障害が発生してもアプリケーションとデータを保護することができます。By architecting your solutions to use replicated VMs in zones, you can protect your applications and data from the loss of a datacenter. 1 つのゾーンが侵害された場合、レプリケートされたアプリとデータが別のゾーンですぐに利用可能になります。If one zone is compromised, then replicated apps and data are instantly available in another zone.

可用性ゾーン

可用性ゾーンに Windows または Linux の VM をデプロイする方法の詳細をご覧ください。Learn more about deploying a Windows or Linux VM in an Availability Zone.

冗長性実現のために複数の仮想マシンを可用性セット内に構成するConfigure multiple virtual machines in an availability set for redundancy

可用性セットは、VM の冗長性と可用性を提供するもう 1 つのデータセンター構成です。Availability sets are another datacenter configuration to provide VM redundancy and availability. データセンター内のこのような構成により、計画的または計画外のメンテナンス イベント中に、少なくとも 1 つの仮想マシンが利用可能となり、99.95% の Azure SLA を満たします。This configuration within a datacenter ensures that during either a planned or unplanned maintenance event, at least one virtual machine is available and meets the 99.95% Azure SLA. 詳細については、「 Virtual Machines の SLA」を参照してください。For more information, see the SLA for Virtual Machines.

重要

可用性セット内の単一インスタンスの仮想マシンは、仮想マシン接続について少なくとも 99.9% の SLA の資格を得るために、すべてのオペレーティング システム ディスクとデータ ディスクに Premium SSD または Ultra ディスクを使用する必要があります。A single instance virtual machine in an availability set by itself should use Premium SSD or Ultra Disk for all operating system disks and data disks in order to qualify for the SLA for Virtual Machine connectivity of at least 99.9%.

基盤となる Azure プラットフォームにより、可用性セット内の各仮想マシンに更新ドメイン障害ドメインが割り当てられます。Each virtual machine in your availability set is assigned an update domain and a fault domain by the underlying Azure platform. 所定の可用性セットに対して、同時に再起動される仮想マシンのグループと物理ハードウェアを示す、ユーザーが構成できない 5 つの更新ドメインが既定で割り当てられます (その後、最大 20 の更新ドメインを提供できるように Resource Manager のデプロイを増やすことができます)。For a given availability set, five non-user-configurable update domains are assigned by default (Resource Manager deployments can then be increased to provide up to 20 update domains) to indicate groups of virtual machines and underlying physical hardware that can be rebooted at the same time. 1 つの可用性セット内に 5 つ以上の仮想マシンが構成されているとき、6 つ目の仮想マシンは 1 つ目の仮想マシンと同じ更新ドメイン内に配置され、7 つ目は 2 つ目の仮想マシンと同じ更新ドメイン内に配置されるという方法で処理されます。When more than five virtual machines are configured within a single availability set, the sixth virtual machine is placed into the same update domain as the first virtual machine, the seventh in the same update domain as the second virtual machine, and so on. 計画的メンテナンス中は、更新ドメインの再起動が順番に処理されない場合がありますが、一度に再起動される更新ドメインは 1 つのみです。The order of update domains being rebooted may not proceed sequentially during planned maintenance, but only one update domain is rebooted at a time. 再起動された更新ドメインには、別の更新ドメインでメンテナンスが開始されるまでに、復旧するための時間として 30 分が与えられます。A rebooted update domain is given 30 minutes to recover before maintenance is initiated on a different update domain.

障害ドメインは電源とネットワーク スイッチを共有する仮想マシンのグループを定義します。Fault domains define the group of virtual machines that share a common power source and network switch. 既定では、可用性セット内に構成された仮想マシンは、Resource Manager のデプロイ用に最大 3 つの障害ドメインに分けられます (クラシックの場合は 2 つの障害ドメイン)。By default, the virtual machines configured within your availability set are separated across up to three fault domains for Resource Manager deployments (two fault domains for Classic). 仮想マシンを可用性セットに配置しても、アプリケーションがオペレーティング システムやアプリケーションの障害から保護されるわけではありませんが、潜在的な物理ハードウェア障害、ネットワーク障害、または電力の中断の影響を低下させることができます。While placing your virtual machines into an availability set does not protect your application from operating system or application-specific failures, it does limit the impact of potential physical hardware failures, network outages, or power interruptions.

更新ドメインと障害ドメインの構成の概念図Conceptual drawing of the update domain and fault domain configuration

可用性セット内の VM にマネージド ディスクを使用するUse managed disks for VMs in an availability set

現在、管理されていないディスクを持つ VM を使用している場合は、可用性セット内の VM を Managed Disks を使用するように変換することを強くお勧めします。If you are currently using VMs with unmanaged disks, we highly recommend you convert VMs in Availability Set to use Managed Disks.

管理ディスクでは、可用性セットの VM のディスクが、単一障害点にならないように相互に十分に分離されるため、可用性セットの信頼性が向上します。Managed disks provide better reliability for Availability Sets by ensuring that the disks of VMs in an Availability Set are sufficiently isolated from each other to avoid single points of failure. これは、ディスクをさまざまなストレージ障害ドメイン (記憶域クラスター) に自動的に配置し、VM 障害ドメインに合わせて調整することによって実現されます。It does this by automatically placing the disks in different storage fault domains (storage clusters) and aligning them with the VM fault domain. ストレージ障害ドメインが、ハードウェアまたはソフトウェアの障害によって機能しなくなった場合は、そのストレージ障害ドメイン上のディスクを含む VM インスタンスだけが機能しなくなります。If a storage fault domain fails due to hardware or software failure, only the VM instance with disks on the storage fault domain fails. マネージド ディスク FDManaged disks FDs

重要

管理対象の可用性セットに使用される障害ドメインの数は、リージョンによって異なります (リージョンあたり 2 つまたは 3 つになります)。The number of fault domains for managed availability sets varies by region - either two or three per region. 次のスクリプトを実行して、各リージョンの障害ドメインを確認できます。You can see the fault domain for each region by running the following scripts.

Get-AzComputeResourceSku | where{$_.ResourceType -eq 'availabilitySets' -and $_.Name -eq 'Aligned'}
az vm list-skus --resource-type availabilitySets --query '[?name==`Aligned`].{Location:locationInfo[0].location, MaximumFaultDomainCount:capabilities[0].value}' -o Table

注意

特定の状況では、同じ AvailabilitySet の 2 つの VM が同じ FaultDomain を共有している場合があります。Under certain circumstances, 2 VMs in the same AvailabilitySet could shared the same FaultDomain. これを確認するには、可用性セットに移動し、 [障害ドメイン] 列を確認します。This can be confirmed by going into your availability set and checking the Fault Domain column. この動作は、VM のデプロイ中に次のシーケンスで発生する可能性があります。This can be cause from the following sequence while deploying the VMs:

  • 最初の VM をデプロイしますDeploy the 1st VM
  • 最初の VM を停止/割り当て解除しますStop/Deallocate the 1st VM
  • 2番目の VM をデプロイします。このような状況では、最初の VM と同じ障害ドメインに 2 番目の VM の OS ディスクが作成される可能性があるため、2 番目の VM も同じ障害ドメインに配置されます。Deploy the 2nd VM Under these circumstances, the OS Disk of the 2nd VM might be created on the same Fault Domain as the 1st VM, and so the 2nd VM will also land on the same FaultDomain. この問題を回避するために、これらのデプロイ間で VM を停止または割り当て解除しないことをお勧めします。To avoid this issue, it's recommended to not stop/deallocate the VMs between deployments.

アンマネージド ディスクを持つ VM を使用する計画がある場合は、VM の仮想ハード ディスク (VHD) がページ BLOB として格納されているストレージ アカウント用の、以下のベスト プラクティスに従います。If you plan to use VMs with unmanaged disks, follow below best practices for Storage accounts where virtual hard disks (VHDs) of VMs are stored as page blobs.

  1. VM に関連付けられているすべてのディスク (OS とデータ) を同じストレージ アカウント内に保持する。Keep all disks (OS and data) associated with a VM in the same storage account
  2. ストレージ アカウントにさらに VHD を追加する前に、Azure Storage アカウント内の管理されていないディスクの数に関する制限を確認する。Review the limits on the number of unmanaged disks in an Azure Storage account before adding more VHDs to a storage account
  3. 可用性セット内の VM ごとに個別のストレージ アカウントを使用する。Use a separate storage account for each VM in an Availability Set. 同じ可用性セット内の複数の VM でストレージ アカウントを共有しないでください。Do not share Storage accounts with multiple VMs in the same Availability Set. 上のベスト プラクティスに従っていれば、異なる可用性セットの VM でストレージ アカウントを共有してもかまいません非管理対象ディスク FDIt is acceptable for VMs across different Availability Sets to share storage accounts if above best practices are followed Unmanaged disks FDs

VM に影響するイベントにプロアクティブに応答するスケジュール化されたイベントを使用するUse scheduled events to proactively respond to VM impacting events

スケジュール化されたイベントをサブスクライブすると、VM に影響する可能性のある将来のメンテナンス イベントについて VM に通知されます。When you subscribe to scheduled events, your VM is notified about upcoming maintenance events that can impact your VM. スケジュール化されたイベントを有効にすると、仮想マシンでメンテナンス アクティビティが実行されるまでの時間が最小限になります。When scheduled events are enabled, your virtual machine is given a minimum amount of time before the maintenance activity is performed. たとえば、VM に影響を与える可能性があるホスト OS の更新プログラムは、影響と、アクションが何も行われない場合にメンテナンスが実行される日時が指定されたイベントとして、キューに登録されます。For example, Host OS updates that might impact your VM are queued up as events that specify the impact, as well as a time at which the maintenance will be performed if no action is taken. スケジュール化されたイベントは、VM に影響を与える可能性がある差し迫ったハードウェア障害が Azure で検出されたときも、キューに登録されます。これにより、復旧をいつ実行するかを決定できます。Schedule events are also queued up when Azure detects imminent hardware failure that might impact your VM, which allows you to decide when the healing should be performed. お客様は、イベントを使用して、状態の保存やセカンダリへのフェールオーバーなどのタスクを、メンテナンスの前に実行できます。Customers can use the event to perform tasks prior to the maintenance, such as saving state, failing over to the secondary, and so on. メンテナンス イベントを適切に処理するロジックを完了した後、未処理のスケジュール化されたイベントを承認して、プラットフォームによるメンテナンスを続行させることができます。After you complete your logic for gracefully handling the maintenance event, you can approve the outstanding scheduled event to allow the platform to proceed with maintenance.

ロード バランサーと可用性ゾーンまたはセットを結合するCombine a load balancer with availability zones or sets

Azure Load Balancer と可用性ゾーンまたはセットを結合することで、アプリケーションの回復性を最大化できます。Combine the Azure Load Balancer with an availability zone or set to get the most application resiliency. Azure Load Balanceは、複数の仮想マシンにトラフィックを振り分けます。The Azure Load Balancer distributes traffic between multiple virtual machines. 当社の標準層の仮想マシンには Azure Load Balanceが含まれています。For our Standard tier virtual machines, the Azure Load Balancer is included. すべての仮想マシン層に Azure Load Balancer が含まれているわけではありません。Not all virtual machine tiers include the Azure Load Balancer. 仮想マシンの負荷分散の詳細については、「 仮想マシンの負荷分散」を参照してください。For more information about load balancing your virtual machines, see Load Balancing virtual machines.

複数の仮想マシン間でトラフィックを分散するためのロード バランサーが構成されていない場合、計画的メンテナンス イベントによって、トラフィックを提供している仮想マシンのみに影響が生じ、アプリケーション層の機能停止が生じます。If the load balancer is not configured to balance traffic across multiple virtual machines, then any planned maintenance event affects the only traffic-serving virtual machine, causing an outage to your application tier. 同じ層の複数の仮想マシンを、同じロード バランサーと可用性セット以下に配置することで、少なくとも 1 つのインスタンスによってトラフィックの提供を継続することができます。Placing multiple virtual machines of the same tier under the same load balancer and availability set enables traffic to be continuously served by at least one instance.

可用性ゾーン間で負荷を分散する方法のチュートリアルについては、「Azure CLI を使用してすべての可用性ゾーン間で VM の負荷を分散する」を参照してください。For a tutorial on how to load balance across availability zones, see Load balance VMs across all availability zones by using the Azure CLI.

次のステップNext steps

仮想マシンの負荷分散の詳細については、 仮想マシンの負荷分散に関するページをご覧ください。To learn more about load balancing your virtual machines, see Load Balancing virtual machines.

IaaS の SQL Server で N 層アプリケーションを実行するための参照アーキテクチャを表示するView Reference Architectures for running N-tier applications on SQL Server in IaaS