計画メンテナンスの通知の処理Handling planned maintenance notifications

Azure は、定期的に更新を行い、仮想マシンのホスト インフラストラクチャの信頼性、パフォーマンス、セキュリティの向上に努めています。Azure periodically performs updates to improve the reliability, performance, and security of the host infrastructure for virtual machines. 更新とは、ホスティング環境の修正、ハードウェアのアップグレードや使用停止などの変更のことです。Updates are changes like patching the hosting environment or upgrading and decommissioning hardware. これらの更新のほとんどは、ホストされている仮想マシンに影響を及ぼすことなく完了します。A majority of these updates are completed without any impact to the hosted virtual machines. ただし、更新による影響が生じる場合もあります。However, there are cases where updates do have an impact:

  • Azure では、再起動を伴わないメンテナンスの場合、インプレース移行を使用して、ホストの更新中に VM を一時的に停止させます。If the maintenance does not require a reboot, Azure uses in-place migration to pause the VM while the host is updated. これらの種類のメンテナンス操作は、障害ドメインごとに適用されます。These types maintenance operations are applied fault domain by fault domain. 警告の正常性シグナルを受信した場合は、操作が停止されます。Progress is stopped if any warning health signals are received.

  • 再起動を伴うメンテナンスの場合は、メンテナンスの予定日時が知らされます。If maintenance requires a reboot, you get a notice of when the maintenance is planned. 都合に応じて自分自身でメンテナンスを開始できる、約 35 日間の時間枠が与えられます。You are given a time window of about 35 days where you can start the maintenance yourself, when it works for you.

再起動が必要な計画メンテナンスは、段階的にスケジュールされます。Planned maintenance that requires a reboot is scheduled in waves. 各段階のスコープ (リージョン) はそれぞれ異なります。Each wave has different scope (regions).

  • 段階はお客様への通知で始まります。A wave starts with a notification to customers. 既定では、通知はサービス管理者と共同管理者に送信されます。By default, notification is sent to the Service Administrator and Co-Administrators. アクティビティ ログ アラートを使用して、通知の受信者や、電子メール、SMS、Webhook などのメッセージング オプションを追加できます。You can add more recipients and messaging options like email, SMS, and webhooks, using Activity Log Alerts.
  • 通知が送信されたら、セルフサービス期間を確認できます。Once a notification goes out, a self-service window is made available. この期間中、どの仮想マシンが影響を受けるかを照会し、独自のスケジュールのニーズに基づいてメンテナンスを開始することができます。During this window, you can query which of your virtual machines are affected and start maintenance based on your own scheduling needs. セルフサービス期間は通常、約 35 日間です。The self-service window is typically about 35 days.
  • セルフサービス期間が過ぎると、"予定メンテナンス期間" が始まります。After the self-service window, a scheduled maintenance window begins. この期間のある時点で、Azure は、仮想マシンに対して必要なメンテナンスをスケジュールし、適用します。At some point during this window, Azure schedules and applies the required maintenance to your virtual machine.

2 つの期間を用意した目的は、Azure によってメンテナンスが自動的に開始される時期を把握した上で、メンテナンスを開始して仮想マシンを再起動するのに必要な時間を十分に確保できるようにすることにあります。The goal in having two windows is to give you enough time to start maintenance and reboot your virtual machine while knowing when Azure will automatically start maintenance.

Azure ポータル、PowerShell、REST API、CLI を使用して、VM のメンテナンス期間のクエリを実行し、セルフサービス メンテナンスを開始することができます。You can use the Azure portal, PowerShell, REST API, and CLI to query for the maintenance windows for your VMs and start self-service maintenance.

セルフ サービス期間中にメンテナンスを開始する必要があるかどうかShould you start maintenance using during the self-service window?

次のガイドラインは、この機能を使用して、ご自身のタイミングでメンテナンスを開始する必要があるかどうかを判断するうえで役立ちます。The following guidelines should help you decide whether to use this capability and start maintenance at your own time.

注意

セルフサービス メンテナンスは、一部の VM には使用できない場合があります。Self-service maintenance might not be available for all of your VMs. ご自身の VM にプロアクティブな再デプロイを使用できるかどうかを確認するには、メンテナンス状態で [今すぐ開始] を探します。To determine if proactive redeploy is available for your VM, look for the Start now in the maintenance status. セルフサービス メンテナンスは、現在、Cloud Services (Web/worker ロール)、および Service Fabric では使用できません。Self-service maintenance is currently not available for Cloud Services (Web/Worker Role) and Service Fabric.

可用性セットを使用しているデプロイについては、セルフサービス メンテナンスをお勧めしません。Self-service maintenance is not recommended for deployments using availability sets. 可用性セットは、一度に 1 つの更新ドメインに対してのみ更新されます。Availability sets are already only updated one update domain at a time.

  • Azure がメンテナンスをトリガーします。Let Azure trigger the maintenance. 再起動が必要なメンテナンスの場合、メンテナンスは更新ドメインごとに実行されます。For maintenance that requires reboot, maintenance will be done update domain by update domain. 更新ドメインは、必ずしもメンテナンスを順番に受け取るとは限らず、更新ドメイン間には 30 分間の一時停止があります。The update domains do not necessarily receive the maintenance sequentially, and that there is a 30-minute pause between update domains.
  • 一部の容量 (1 つの更新ドメイン) の一時的な喪失が問題になる場合は、メンテナンス期間中にインスタンスを追加できます。If a temporary loss of some capacity (1 update domain) is a concern, you can add instances during the maintenance period.
  • 再起動が不要なメンテナンスの場合、更新プログラムは障害ドメイン レベルで適用されます。For maintenance that does not require reboot, updates are applied at the fault domain level.

セルフサービス メンテナンスは、次のシナリオでは使用しないでください。Don't use self-service maintenance in the following scenarios:

  • 手動で、DevTest Labs を使用して、自動シャットダウンを使用して、またはスケジュールに従って、VM を頻繁にシャットダウンする場合。これにより、メンテナンス状態が元に戻り、追加のダウンタイムが発生する可能性があります。If you shut down your VMs frequently, either manually, using DevTest Labs, using auto-shutdown, or following a schedule, it could revert the maintenance status and therefore cause additional downtime.
  • VM の有効期間が短く、メンテナンス段階の終了前に削除されることがわかっている場合。On short-lived VMs that you know will be deleted before the end of the maintenance wave.
  • ワークロードの状態の多くが、更新時に保持する必要があるローカル (一時) ディスクに格納されている場合。For workloads with a large state stored in the local (ephemeral) disk that is desired to be maintained upon update.
  • VM のサイズを頻繁に変更する場合。変更により、メンテナンス状態が元に戻る可能性があります。For cases where you resize your VM often, as it could revert the maintenance status.
  • メンテナンス シャットダウンの開始 15 分前に、ワークロードのプロアクティブなフェールオーバーやグレースフル シャットダウンを有効にする、スケジュールされたイベントを使用している場合。If you have adopted scheduled events that enable proactive failover or graceful shutdown of your workload, 15 minutes before start of maintenance shutdown

予定メンテナンス フェーズ中に中断なく VM を実行する場合、また、上記の使用しないシナリオの説明に該当するものがない場合は、セルフサービス メンテナンスを使用しますUse self-service maintenance, if you are planning to run your VM uninterrupted during the scheduled maintenance phase and none of the counter-indications mentioned above are applicable.

セルフサービス メンテナンスは、次の場合に使用することをお勧めします。It is best to use self-service maintenance in the following cases:

  • 正確なメンテナンス期間を、管理担当またはエンド ユーザーのお客様に伝える必要がある。You need to communicate an exact maintenance window to your management or end-customer.
  • 日時を指定して、メンテナンスを完了する必要がある。You need to complete the maintenance by a given date.
  • メンテナンスのシーケンスを制御する必要がある (安全な復旧を保証する多層アプリケーションなど)。You need to control the sequence of maintenance, for example, multi-tier application to guarantee safe recovery.
  • 2 つの更新ドメイン (UD) の間に 30 分を超える VM 復旧時間が必要である。More than 30 minutes of VM recovery time is needed between two update domains (UDs). 更新ドメイン間の時間を制御するには、一度に 1 つの更新ドメイン (UD) で、VM に対してメンテナンスをトリガーする必要があります。To control the time between update domains, you must trigger maintenance on your VMs one update domain (UD) at a time.

よく寄せられる質問FAQ

Q:仮想マシンを今すぐ再起動する必要があるのはなぜですか?Q: Why do you need to reboot my virtual machines now?

A: Azure プラットフォームの更新とアップグレードの大半は仮想マシンの可用性に影響を及ぼしませんが、Azure でホストされている仮想マシンの再起動を避けられない場合があります。A: While the majority of updates and upgrades to the Azure platform do not impact virtual machine's availability, there are cases where we can't avoid rebooting virtual machines hosted in Azure. 累積された複数の変更があり、サーバーを再起動する必要がある場合、仮想マシンを再起動することになります。We have accumulated several changes that require us to restart our servers that will result in virtual machines reboot.

Q:可用性セットを使用して高可用性に関する推奨事項に従えば安全ですか?Q: If I follow your recommendations for High Availability by using an Availability Set, am I safe?

A: 可用性セットまたは仮想マシン スケール セットにデプロイされた仮想マシンには、更新ドメイン (UD) の概念があります。A: Virtual machines deployed in an availability set or virtual machine scale sets have the notion of Update Domains (UD). メンテナンスを実行するときに、Azure では UD の制約が遵守され、(同じ可用性セット内の) 別の UD の仮想マシンは再起動されません。When performing maintenance, Azure honors the UD constraint and will not reboot virtual machines from different UD (within the same availability set). また、Azure は仮想マシンの次のグループに移行する前に少なくとも 30 分待機します。Azure also waits for at least 30 minutes before moving to the next group of virtual machines.

高可用性の詳細については、Azure の仮想マシンの可用性に関するページを参照してください。For more information about high availability, see Availability for virtual machines in Azure.

Q:計画メンテナンスに関する通知を受け取るにはどうすればよいですか?Q: How do I get notified about planned maintenance?

A: 計画済みメンテナンス ウェーブは、1 つ以上の Azure リージョンにスケジュールを設定することで開始されます。A: A planned maintenance wave starts by setting a schedule to one or more Azure regions. 開始直後に、電子メール通知がサブスクリプションの管理者に送信されます (サブスクリプションごとに 1 メール)。Soon after, an email notification is sent to the subscription Admins (one email per subscription). この通知の追加のチャネルと受信者は、アクティビティ ログ アラートを使用して構成できます。Additional channels and recipients for this notification could be configured using Activity Log Alerts. 計画済みメンテナンスが既にスケジュールされているリージョンに仮想マシンをデプロイした場合、通知を受け取ることはできないため、その VM のメンテナンスの状態を確認する必要があります。In case you deploy a virtual machine to a region where planned maintenance is already scheduled, you will not receive the notification but rather need to check the maintenance state of the VM.

Q:ポータル、PowerShell、または CLI に計画メンテナンスの情報が表示されません。何がおかしいのでしょうか?Q: I don't see any indication of planned maintenance in the portal, Powershell, or CLI. What is wrong?

A: 計画メンテナンスに関する情報は、計画メンテナンス ウェーブ中にのみ、影響を受ける VM に提供されます。A: Information related to planned maintenance is available during a planned maintenance wave only for the VMs that are going to be impacted by it. つまり、データが表示されない場合、メンテナンス ウェーブが既に完了している (または、まだ開始されていない) か、更新されたサーバーで仮想マシンが既にホストされていると考えられます。In other words, if you see not data, it could be that the maintenance wave has already completed (or not started) or that your virtual machine is already hosted in an updated server.

Q:仮想マシンが影響を受けるタイミングを正確に把握する方法はありますか?Q: Is there a way to know exactly when my virtual machine will be impacted?

A: スケジュールを設定するときに、数日間の時間枠が設けられています。A: When setting the schedule, we define a time window of several days. ただし、この時間枠内でのサーバー (および VM) の正確な優先順位付けは不明です。However, the exact sequencing of servers (and VMs) within this window is unknown. VM の正確な時間を把握したいお客様は、仮想マシン内からスケジュールされたイベントとクエリを使用し、VM が再起動される 15 分前に通知を受け取ることができます。Customers who would like to know the exact time for their VMs can use scheduled events and query from within the virtual machine and receive a 15-minute notification before a VM reboot.

Q:仮想マシンの再起動にはどれくらいの時間がかかりますか?Q: How long will it take you to reboot my virtual machine?

A: セルフサービス メンテナンス期間中、VM のサイズによっては、再起動に最大数分かかることがあります。A: Depending on the size of your VM, reboot may take up to several minutes during the self-service maintenance window. 予定メンテナンス期間中の Azure によって開始される再起動の場合は、再起動に通常約 25 分かかります。During the Azure initiated reboots in the scheduled maintenance window, the reboot will typically take about 25 minutes. Cloud Services (Web/worker ロール)、VM Scale Sets、または可用性セットを使用している場合、予定メンテナンス期間中は VM の各グループ (UD) 間に 30 分の間隔が空けられます。Note that in case you use Cloud Services (Web/Worker Role), Virtual Machine Scale Sets, or availability sets, you will be given 30 minutes between each group of VMs (UD) during the scheduled maintenance window.

Q:Virtual Machine Scale Sets ではどのようになりますか?Q: What is the experience in the case of Virtual Machine Scale Sets?

A: Virtual Machine Scale Sets で計画メンテナンスが使用できるようになりました。A: Planned maintenance is now available for Virtual Machine Scale Sets. セルフサービス メンテナンスを開始する方法については、仮想マシン スケール セットに対する計画メンテナンスに関するドキュメントを参照してください。For instructions on how to initiate self-service maintenance refer planned maintenance for virtual machine scale sets document.

Q:Cloud Services (Web/worker ロール)、および Service Fabric ではどのようになりますか?Q: What is the experience in the case of Cloud Services (Web/Worker Role) and Service Fabric?

A: これらのプラットフォームは計画済みメンテナンスの影響を受けますが、影響を受けるのは、常に 1 つのアップグレード ドメイン (UD) の VM だけであることから、これらのプラットフォームを使用しているお客様は安全とみなされます。A: While these platforms are impacted by planned maintenance, customers using these platforms are considered safe given that only VMs in a single Upgrade Domain (UD) will be impacted at any given time. セルフサービス メンテナンスは、現在、Cloud Services (Web/worker ロール)、および Service Fabric では使用できません。Self-service maintenance is currently not available for Cloud Services (Web/Worker Role) and Service Fabric.

Q:VM のメンテナンス情報が表示されません。何が問題だったのでしょうか?Q: I don’t see any maintenance information on my VMs. What went wrong?

A: VM のメンテナンス情報が表示されない理由はいくつかあります。A: There are several reasons why you’re not seeing any maintenance information on your VMs:

  1. Microsoft 社内としてマークされたサブスクリプションを使用している。You are using a subscription marked as Microsoft internal.
  2. VM のメンテナンスがスケジュールされていない。Your VMs are not scheduled for maintenance. メンテナンス ウェーブが終了しているか、取り消しまたは変更が行われたため、VM が影響を受けなくなっていると考えられます。It could be that the maintenance wave has ended, canceled, or modified so that your VMs are no longer impacted by it.
  3. VM リスト ビューに [メンテナンス] 列が追加されていない。You don’t have the Maintenance column added to your VM list view. この列は既定のビューに追加されていますが、既定以外の列を表示するように構成しているお客様は、VM リスト ビューに [メンテナンス] 列を手動で追加する必要があります。While we have added this column to the default view, customers who configured to see non-default columns must manually add the Maintenance column to their VM list view.

Q:VM の 2 回目のメンテナンスがスケジュールされています。なぜですか?Q: My VM is scheduled for maintenance for the second time. Why?

A: メンテナンスの再デプロイが既に完了した後に、VM のメンテナンスがスケジュールされるユース ケースがいくつかあります。A: There are several use cases where you will see your VM scheduled for maintenance after you have already completed your maintenance-redeploy:

  1. メンテナンス ウェーブが取り消され、別のペイロードで再開された場合。We have canceled the maintenance wave and restarted it with a different payload. エラーが発生したペイロードが検出されたため、Microsoft が追加のペイロードをデプロイする必要があったと考えられます。It could be that we've detected faulted payload and we simply need to deploy an additional payload.
  2. ハードウェア障害により、VM が別のノードに "サービス復旧" された場合。Your VM was service healed to another node due to a hardware fault.
  3. お客様が VM を停止 (割り当てを解除) し、再起動することを選択した場合。You have selected to stop (deallocate) and restart the VM.
  4. お客様が VM の自動シャットダウンを有効にした場合。You have auto shutdown turned on for the VM.

次のステップNext steps

Azure CLIAzure PowerShell、またはポータルを使用して計画メンテナンスを処理できます。You can handle planned maintenance using the Azure CLI, Azure PowerShell or portal.