Virtual Machine Scale Sets に対する計画メンテナンスの通知

Azure は、定期的に更新を行い、仮想マシン (VM) のホスト インフラストラクチャの信頼性、パフォーマンス、セキュリティの向上に努めています。 更新には、ホスティング環境の修正や、ハードウェアのアップグレードおよび使用停止が含まれる場合があります。 更新の多くは、ホストされている VM には影響しません。 ただし、次のシナリオでは、更新によって VM に影響が及びます。

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

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

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

• 段階はお客様への通知で始まります。 既定では、サブスクリプションの所有者と共同所有者に通知が送信されます。 Azure アクティビティ ログ アラートを使用して、通知の受信者、および電子メール、SMS、webhook などのメッセージング オプションを通知に追加できます。
• 通知では、"セルフサービス期間" を確認できます。 この期間中 (通常 35 日) は、どの VM がその段階に含まれているかを確認できます。 スケジュールの都合に応じて、メンテナンスを事前に開始することができます。
• セルフサービス期間が過ぎると、"予定メンテナンス期間" が始まります。 この期間のある時点で、Azure は、VM に対して必要なメンテナンスをスケジュールし、適用します。

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

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

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

次のガイドラインは、メンテナンスの開始時刻をお客様自身が選択するべきかどうかを判断するうえで役立ちます。

可用性セットを使用するデプロイについては、セルフサービス メンテナンスをお勧めしません。 可用性セットは、一度に 1 つの更新ドメインだけが影響を受ける、可用性の高いセットアップです。 可用性セットについては、次の点に留意してください。

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

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

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

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

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

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

ポータルでメンテナンスの影響を受ける Virtual Machine Scale Sets を表示する

計画メンテナンスのウェーブをスケジュールする際、Azure portal を使って今後のメンテナンス ウェーブの影響を受ける Virtual Machine Scale Sets の一覧を表示できます。

1. Azure portal にサインインします。

2. 左側のメニューで [すべてのサービス] を選択し、[Virtual Machine Scale Sets] を選択します。

3. [Virtual Machine Scale Sets] の [列の編集] を選択して、使用可能な列の一覧を開きます。

4. [利用可能な列] セクションで [セルフサービス メンテナンス] を選択し、 [選択された列] リストに移動します。 [適用] を選択します。

   [利用可能な列] セクションのドロップダウン リストを [すべて] から [プロパティ] に切り替えると、 [セルフサービス メンテナンス] 項目を簡単に見つけることができます。

これで、Virtual Machine Scale Sets の一覧に [セルフサービス メンテナンス] 列が表示されます。 各 Virtual Machine Scale Set のセルフサービス メンテナンスの列の値は、次のいずれかを取ることができます。

ポータルの通知とアラート

Azure は、サブスクリプション所有者と共同所有者グループに電子メールを送信することで、計画メンテナンスのスケジュールを伝えます。 アクティビティ ログ アラートを作成して、この通信にその他の受信者とチャネルを追加することができます。 詳しくは、「Azure アクティビティ ログでサブスクリプション アクティビティを監視する」をご覧ください。

1. Azure portal にサインインします。

2. 左側のメニューで [モニター] を選択します。

3. [モニター] メニューで、[サービス正常性] を選択します。

   

4. [サービス正常性] で、[+ サービス正常性アラートの作成] を選択します。

   

5. [アラート ルールの作成] ページで、次の手順を実行します。

   1. 計画メンテナンス イベントをモニターするリソースを含む関連する [サブスクリプション] と [リージョン] を選択します。
   2. 次の情報を指定します。
      • サービス: Virtual Machine Scale Sets および仮想マシン
      • イベント タイプ: 計画メンテナンス

6. [アクション] で、計画メンテナンス イベントの受信時に通知を送信したりアクションを呼び出したりするために、アクション グループをアラート ルールに追加します。

7. [アラート ルールの詳細] に詳細を入力します。

8. [アラート ルールの作成] を選択します。

アクティビティ ログ アラートの構成方法については、「アクティビティ ログ アラートの作成」をご覧ください

ポータルから Virtual Machine Scale Set のメンテナンスを開始する

Virtual Machine Scale Sets の概要では、メンテナンスに関連する詳細情報をさらに表示できます。 Virtual Machine Scale Sets 内の少なくとも 1 つの VM が計画メンテナンスのウェーブに含まれる場合は、ページの上部近くに新しい通知リボンが追加されます。 通知リボンを選択すると、 [メンテナンス] ページに移動します。

[メンテナンス] ページでは、計画メンテナンスの影響を受ける VM インスタンスを確認できます。 メンテナンスを開始するには、影響を受ける VM に対応するチェック ボックスを選択します。 次に、[メンテナンスを開始する] を選択します。

メンテナンスを開始すると、Virtual Machine Scale Set 内の影響を受ける VM がメンテナンス中になり、一時的に利用できなくなります。 セルフサービス期間を過ぎても、Virtual Machine Scale Set のメンテナンスが Azure によって実行される時間帯を表示できます。

PowerShell を使用してメンテナンスの状態を確認する

Azure PowerShell を使用して、Virtual Machine Scale Sets 内の VM のメンテナンスの予定を確認することができます。 計画メンテナンスに関する情報は、Get-AzVmssVM コマンドレットと -InstanceView パラメーターを使用することで取得できます。

メンテナンス情報は、計画済みのメンテナンスがある場合にのみ返されます。 VM インスタンスに影響を及ぼすメンテナンスがスケジュールされていない場合、コマンドレットはメンテナンス情報を返しません。

Get-AzVmssVm -ResourceGroupName rgName -VMScaleSetName vmssName -InstanceId id -InstanceView

MaintenanceRedeployStatus では、次のプロパティが返されます。

PowerShell を使用して VM インスタンスに対するメンテナンスを開始する

IsCustomerInitiatedMaintenanceAllowed が true に設定されている場合は、VM のメンテナンスを開始できます。 Set-AzVmssVM コマンドレットと -PerformMaintenance パラメーターを使用します。

Set-AzVmssVM -ResourceGroupName rgName -VMScaleSetName vmssName -InstanceId id -PerformMaintenance 

CLI を使用してメンテナンスの状態を確認する

計画メンテナンスの情報は、az vmss list-instances を使用して確認できます。

メンテナンス情報は、計画済みのメンテナンスがある場合にのみ返されます。 VM インスタンスに影響を及ぼすメンテナンスがスケジュールされていない場合、コマンドはメンテナンス情報を返しません。

az vmss list-instances -g rgName -n vmssName --expand instanceView

MaintenanceRedeployStatus では、各 VM インスタンスについて次のプロパティが返されます。

CLI を使用して VM インスタンスに対するメンテナンスを開始する

IsCustomerInitiatedMaintenanceAllowed が true に設定されている場合は、次の呼び出しによって、VM インスタンスに対するメンテナンスを開始できます。

az vmss perform-maintenance -g rgName -n vmssName --instance-ids id

よく寄せられる質問

Q:VM を今すぐ再起動する必要があるのはなぜですか?

A: 多くの場合、Azure プラットフォームに対する更新やアップグレードによって VM の可用性が影響を受けることはありませんが、状況によっては、Azure でホストされている VM を再起動しなければならない場合があります。 累積された複数の変更があり、サーバーを再起動する必要がある場合、VM を再起動することになります。

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

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

高可用性の詳細については、「Azure の仮想マシンのリージョンと可用性について」を参照してください。

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

A: 計画済みメンテナンス ウェーブは、1 つ以上の Azure リージョンにスケジュールを設定することで開始されます。 開始直後に、メール通知がサブスクリプションの管理者、共同管理者、所有者、および共同作成者に送信されます (サブスクリプションごとに 1 メール)。 この通知の追加のチャネルと受信者は、アクティビティ ログ アラートを使用して構成できます。 計画メンテナンスが既にスケジュールされているリージョンに仮想マシンをデプロイした場合、通知を受け取ることはありません。 その場合は、VM のメンテナンス状態を確認してください。

Q: ポータル、PowerShell、または CLI に計画メンテナンスの情報が表示されません。 理由

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

Q:VM が影響を受けるのはいつであるかを正確に把握する方法はありますか?

A: スケジュールを設定するときに、数日間の時間枠が設けられています。 この期間内でのサーバー (および VM) の正確な優先順位付けは不明です。 VM が更新される時刻を厳密に把握する必要がある場合は、スケジュール化されたイベントを使用できます。 スケジュール化されたイベントを使用すると、VM 内からクエリを実行して、VM が再起動される 15 分前に通知を受信することができます。

Q:VM の再起動にはどれくらいの時間がかかりますか?

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

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

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

• Microsoft 社内としてマークされたサブスクリプションを使用している。
• VM のメンテナンスがスケジュールされていない。 メンテナンス ウェーブが終了しているか、取り消しまたは変更が行われたため、VM が影響を受けなくなっていると考えられます。
• VM リスト ビューに [メンテナンス] 列が追加されていない。 この列は既定のビューに追加されていますが、既定以外の列を表示するようにビューを構成しているお客様は、VM リスト ビューに [メンテナンス] 列を手動で追加する必要があります。

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

A: 場合によっては、メンテナンスを完了して再デプロイを行った後に、VM のメンテナンスがスケジュールされることがあります。

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

次のステップ

スケジュール化されたイベントを使用して VM でメンテナンス イベントを登録する方法を説明します。