計画メンテナンスの通知の処理

  • [アーティクル]

適用対象: ✔️ Linux VM ✔️ Windows VM ✔️ フレキシブル スケール セット ✔️ 均一スケール セット

Azure は、定期的に更新を行い、仮想マシンのホスト インフラストラクチャの信頼性、パフォーマンス、セキュリティの向上に努めています。 更新とは、ホスティング環境の修正、ハードウェアのアップグレードや使用停止などの変更のことです。 これらの更新について、ほとんどはホストされている仮想マシンに影響を及ぼすことなく終了になります。 ただし、更新による影響が生じる場合もあります。

  • 再起動を伴わないメンテナンスの場合、ホストの更新中、VM は Azure によって数秒間停止されます。 これらの種類のメンテナンス操作は、障害ドメインごとに適用されます。 警告の正常性シグナルを受信した場合は、操作が停止されます。

  • 再起動を伴うメンテナンスの場合は、メンテナンスの予定日時が知らされます。 都合に応じて自分自身でメンテナンスを開始できる、約 35 日間の時間枠が与えられます。

再起動が必要な計画メンテナンスは、段階的にスケジュールされます。 各段階のスコープ (リージョン) はそれぞれ異なります。

  • 段階はお客様への通知で始まります。 仮想マシン関連のメンテナンス通知は、Azure portal の [サービスの正常性] で使用できます。 一部の特定の仮想マシンの計画メンテナンス シナリオでは、Azure が従来のサブスクリプション管理者、共同管理者、およびサブスクリプション所有者グループに追加のメールを送信して、スケジュールを通知する場合もあります。 Azure Service Health を使用すると、ユーザーは計画メンテナンス カテゴリに対して独自のカスタム アラートを構成できます。 Azure Service Health アラートでは、アクティビティ ログ アラートを使用して、通知の受信者や、メール、SMS、Webhook などのメッセージング オプションを追加できます。
  • 通知が送信されたら、セルフサービス期間を確認できます。 この期間中、どの仮想マシンが影響を受けるかを照会し、独自のスケジュールのニーズに基づいてメンテナンスを開始することができます。 セルフサービス期間は通常、約 35 日間です。
  • セルフサービス期間が過ぎると、"予定メンテナンス期間" が始まります。 この期間のある時点で、Azure は、仮想マシンに対して必要なメンテナンスをスケジュールし、適用します。

2 つの期間を用意した目的は、Azure によってメンテナンスが自動的に開始される時期を把握した上で、メンテナンスを開始して仮想マシンを再起動するのに必要な時間を十分に確保できるようにすることにあります。

Azure ポータル、PowerShell、REST API、CLI を使用して、VM のメンテナンス期間のクエリを実行し、セルフサービス メンテナンスを開始することができます。

セルフ サービス期間中にメンテナンスを開始する必要があるかどうか

次のガイドラインは、この機能を使用して、ご自身のタイミングでメンテナンスを開始する必要があるかどうかを判断するうえで役立ちます。

注意

セルフサービス メンテナンスは、一部の VM には使用できない場合があります。 ご自身の VM にプロアクティブな再デプロイを使用できるかどうかを確認するには、メンテナンス状態で [今すぐ開始] を探します。 セルフサービス メンテナンスは、現在、Cloud Services (Web/worker ロール)、および Service Fabric では使用できません。

可用性セットを使用しているデプロイについては、セルフサービス メンテナンスをお勧めしません。 可用性セットは、一度に 1 つの更新ドメインに対してのみ更新されます。

  • Azure がメンテナンスをトリガーします。 再起動が必要なメンテナンスの場合、メンテナンスは更新ドメインごとに実行されます。 更新ドメインは、必ずしもメンテナンスを順番に受け取るとは限らず、更新ドメイン間には 30 分間の一時停止があります。
  • 一部の容量 (1 つの更新ドメイン) の一時的な喪失が問題になる場合は、メンテナンス期間中にインスタンスを追加できます。
  • 再起動が不要なメンテナンスの場合、更新プログラムは障害ドメイン レベルで適用されます。

セルフサービス メンテナンスは、次のシナリオでは使用しないでください。

  • 手動で、DevTest Labs を使用して、自動シャットダウンを使用して、またはスケジュールに従って、VM を頻繁にシャットダウンする場合。これにより、メンテナンス状態が元に戻り、追加のダウンタイムが発生する可能性があります。
  • VM の有効期間が短く、メンテナンス段階の終了前に削除されることがわかっている場合。
  • ワークロードの状態の多くが、更新時に保持する必要があるローカル (一時) ディスクに格納されている場合。
  • VM のサイズを頻繁に変更する場合。変更により、メンテナンス状態が元に戻る可能性があります。
  • メンテナンス シャットダウンの開始 15 分前に、ワークロードのプロアクティブなフェールオーバーやグレースフル シャットダウンを有効にする、スケジュールされたイベントを使用している場合。

予定メンテナンス フェーズ中に中断なく VM を実行する場合、また、上記の使用しないシナリオの説明に該当するものがない場合は、セルフサービス メンテナンスを使用します。

セルフサービス メンテナンスは、次の場合に使用することをお勧めします。

  • 正確なメンテナンス期間を、管理担当またはエンド ユーザーのお客様に伝える必要がある。
  • 日時を指定して、メンテナンスを完了する必要がある。
  • メンテナンスのシーケンスを制御する必要がある (安全な復旧を保証する多層アプリケーションなど)。
  • 2 つの更新ドメイン (UD) の間に 30 分を超える VM 復旧時間が必要である。 更新ドメイン間の時間を制御するには、一度に 1 つの更新ドメイン (UD) で、VM に対してメンテナンスをトリガーする必要があります。

よく寄せられる質問

Q:仮想マシンを今すぐ再起動する必要があるのはなぜですか?

A: Azure プラットフォームの更新とアップグレードの大半は仮想マシンの可用性に影響を及ぼしませんが、Azure でホストされている仮想マシンの再起動を避けられない場合があります。 累積された複数の変更があり、サーバーを再起動する必要がある場合、仮想マシンを再起動することになります。

Q:可用性セットを使用して高可用性に関する推奨事項に従えば安全ですか?

A: 可用性セットまたは仮想マシン スケール セットにデプロイされた仮想マシンには、更新ドメイン (UD) の概念があります。 メンテナンスを実行するときに、Azure では UD の制約が遵守され、(同じ可用性セット内の) 別の UD の仮想マシンは再起動されません。 また、Azure は仮想マシンの次のグループに移行する前に少なくとも 30 分待機します。

高可用性の詳細については、Azure の仮想マシンの可用性に関するページを参照してください。

Q:計画メンテナンスに関する通知を受け取るにはどうすればよいですか?

A: 計画済みメンテナンス ウェーブは、1 つ以上の Azure リージョンにスケジュールを設定することで開始されます。 仮想マシン関連のメンテナンス通知は、Azure portal の [サービスの正常性] で使用できます。 一部の特定の仮想マシンの計画メンテナンス シナリオでは、Azure が従来のサブスクリプション管理者、共同管理者、およびサブスクリプション所有者グループに追加のメール (すべての受信者が追加されたサブスクリプションごとに 1 通のメール) を送信して、スケジュールを通知する場合もあります。

Azure Service Health を使用すると、ユーザーは計画メンテナンス カテゴリに対して独自のカスタム アラートを構成できます。 Azure Service Health アラートでは、アクティビティ ログ アラートを使用して、通知の受信者や、メール、SMS、Webhook などのメッセージング オプションを追加できます。

計画済みメンテナンスが既にスケジュールされているリージョンに仮想マシンをデプロイした場合、通知を受け取ることはできないため、その VM のメンテナンスの状態を確認する必要があります。

Q: ポータル、PowerShell、または CLI に計画済みメンテナンスの情報が表示されません。 どのような問題がありますか?

A: 計画メンテナンスに関する情報は、計画メンテナンス ウェーブ中にのみ、影響を受ける VM に提供されます。 つまり、データが表示されない場合、メンテナンス ウェーブが既に完了している (または、まだ開始されていない) か、更新されたサーバーで仮想マシンが既にホストされていると考えられます。

Q:仮想マシンが影響を受けるタイミングを正確に把握する方法はありますか?

A: スケジュールを設定するときに、数日間の時間枠が設けられています。 ただし、この時間枠内でのサーバー (および VM) の正確な優先順位付けは不明です。 VM の正確な時間を把握したいお客様は、仮想マシン内からスケジュールされたイベントとクエリを使用し、VM が再起動される 15 分前に通知を受け取ることができます。

Q:仮想マシンの再起動にはどれくらいの時間がかかりますか?

A: セルフサービス メンテナンス期間中、VM のサイズによっては、再起動に最大数分かかることがあります。 予定メンテナンス期間中の Azure によって開始される再起動の場合は、再起動に通常約 25 分かかります。 Cloud Services (Web/worker ロール)、VM Scale Sets、または可用性セットを使用している場合、予定メンテナンス期間中は VM の各グループ (UD) 間に 30 分の間隔が空けられます。

Q:Virtual Machine Scale Sets ではどのようになりますか?

A: Virtual Machine Scale Sets で計画メンテナンスが使用できるようになりました。 セルフサービス メンテナンスを開始する方法については、仮想マシン スケール セットに対する計画メンテナンスに関するドキュメントを参照してください。

Q:Cloud Services (Web/worker ロール)、および Service Fabric ではどのようになりますか?

A: これらのプラットフォームは計画済みメンテナンスの影響を受けますが、影響を受けるのは、常に 1 つのアップグレード ドメイン (UD) の VM だけであることから、これらのプラットフォームを使用しているお客様は安全とみなされます。 セルフサービス メンテナンスは、現在、Cloud Services (Web/worker ロール)、および Service Fabric では使用できません。

Q: VM のメンテナンス情報が表示されません。 問題の原因

A: VM のメンテナンス情報が表示されない理由はいくつかあります。

  1. Microsoft 社内としてマークされたサブスクリプションを使用している。
  2. VM のメンテナンスがスケジュールされていない。 メンテナンス ウェーブが終了しているか、取り消しまたは変更が行われたため、VM が影響を受けなくなっていると考えられます。
  3. あなたは VM の割り当てを解除し、その後、VM を起動しました。 それを行うと、メンテナンス ウェーブを計画していない場所に VM が移動する可能性があります。 そのため、VM にはメンテナンス情報が表示されません。
  4. VM リスト ビューに [メンテナンス] 列が追加されていない。 この列は既定のビューに追加されていますが、既定以外の列を表示するように構成しているお客様は、VM リスト ビューに [メンテナンス] 列を手動で追加する必要があります。

Q: VM の 2 回目のメンテナンスがスケジュールされています。 なぜでしょうか。

A: メンテナンスの再デプロイが既に完了した後に、VM のメンテナンスがスケジュールされるユース ケースがいくつかあります。

  1. メンテナンス ウェーブが取り消され、別のペイロードで再開された場合。 エラーが発生したペイロードが検出されたため、Microsoft が追加のペイロードをデプロイする必要があったと考えられます。
  2. ハードウェア障害により、VM が別のノードに "サービス復旧" された場合。
  3. お客様が VM を停止 (割り当てを解除) し、再起動することを選択した場合。
  4. お客様が VM の自動シャットダウンを有効にした場合。

次のステップ

Azure CLI、Azure PowerShell、またはポータルを使用して計画メンテナンスを処理できます。