中断を最小限に抑えるための実践的なガイド

Azure は、信頼性、パフォーマンス、セキュリティに重点を置き、仮想マシンのホスト インフラストラクチャを強化するためにプラットフォームを定期的に更新します。 アップデートの範囲は、オペレーティング システム、ハイパーバイザー、ホスト上に展開されたさまざまなネットワーク コンポーネント/エージェントから、ハードウェアの廃止まで多岐にわたります。

VM メンテナンスには 2 つのタイプがあります。

• 計画的なメンテナンス イベントは、基盤となる Azure プラットフォームに対して Microsoft によって行われる定期的な更新です。 これらの更新のほとんどは、顧客にとって完全に透過的です。 ただし、メンテナンスによっては短時間のフリーズやパフォーマンスの低下が発生する場合があり、非常にまれに再起動が必要になる場合があります。
• 計画外のメンテナンス イベントは、VM の基盤となるハードウェアまたは物理インフラストラクチャに何らかの障害が発生したときに発生します。 そんな失敗したとき 予測 ML のおかげで、Azure プラットフォームは、VM を異常な物理ホストから新しい正常な物理ホストに自動的に移行 (ライブ マイグレーション) します。

ライブ マイグレーションを使用できない場合、VM に予期しないダウンタイム (再起動) が発生します。

この記事では、計画メンテナンスを適用するために使用される手法、顧客が制御できることと制御できないことについて詳しく説明します。

Azure – 更新と制約に応じて更新を適用するための選択肢のパレット

さらに詳しく説明すると、Azure では以下を使用します。 さまざまなテクニック 更新の種類と、更新の影響を最小限に抑えるための制約に応じて、更新を実行します。

出典: Inside Azure Innovations with Mark Russinovich | BKR214H

• ホットパッチング – これにより、ダウンタイムなしで実行中のコードに対象を絞った変更を加えることができます。 ホスト上の関数の新しい呼び出しはすべて、その関数の更新されたバージョンにリダイレクトされます。
• ライブマイグレーション – これには、実行中の顧客 VM をあるホストから別のホストに移動することが含まれます。
• VM-PHU – ホスト更新を保持する仮想マシン
  • これにより、メモリ内の VM が一時停止され、OS がソフト リブートされ、VM が再開されます。
  • これは再起動を必要としない更新の中で最も影響力がありますが、幸いなことに、これは最も一般的ではありません。

Azure は、上記の手法のいずれかを使用して、実行中の影響を最小限に抑えることができます。 計画外のハードウェア メンテナンス、予期しないダウンタイム、および計画的なメンテナンス。

注: 再起動については上記では言及されていません。ゲスト VM は、以前の手法が使用できない場合にのみ再起動されます。

ホストの更新とメンテナンスを管理するために使用される手順の概要を次に示します。

ここで言及する重要な点は、今説明したこれらのメンテナンス操作はすべて Azure でいつでも発生する可能性があり、顧客はこの種の更新 (フリーズを引き起こす) がいつ発生するかを制御できないということです。

メンテナンス制御 – 共有ホストと専用ホスト

既定では、Azure で VM をプロビジョニングすると、VM は対象のリージョンと可用性ゾーン内のランダムなホストに配置され、このホストは複数の顧客の複数の VM によって共有されます。 これを私たちはそう呼んでいます 共有ホスト。

共有ホストを使用するデフォルトのホスティング モデルに加えて、Microsoft は、VM のみをホストできる専用ホストを持つ機能も提供します。 この特典の名前は、 Azure専用ホスト さまざまな利点があり、その中には次のようなものがあります。

• ワークロードを専用の物理サーバーに分離
• ワークロード配置の制御と可視性
• 共有ホストで利用できるものよりも優れたメンテナンス制御。

どちらのソリューションにも長所と短所がありますが、最後の項目であるメンテナンス管理に焦点を当てましょう。

上で説明したように、さまざまなインフラストラクチャ コンポーネントを更新するためにいくつかの手法を使用でき、影響は 2 つの主要なカテゴリに分類できます。

• 再起動不要 (別名フリーズ) アップデート
• 再起動によるアップデート

共有ホストでホストされている場合、顧客には VM の再起動をいつ行うかを計画できる 35 日間の期間が与えられ、この期間中に再起動による更新を制御できます。 有効期限が切れると、Microsoft が独自に再起動をスケジュールし、再起動が行われる数分前に顧客に通知されます。 予定されているイベント (このメカニズムについては次のセクションで説明します)。

前述したように、共有ホストでの再起動不要の更新の場合、お客様はそれらを制御できず、何もスケジュールすることもできません。 つまり、共有ホスト上で実行されている VM では、いつでもフリーズ (通常は数秒) が発生する可能性があります。

お客様のワークロードがこの種の制御不能なフリーズにさらされることが許容できない場合、Azure Ddedicate Host が非常に役立ちます。 これらのホストでは、Maintenance Control を使用して、顧客があらゆる種類の更新 (再起動なしおよび再起動あり) をスケジュールし、35 日以内の任意の時間に適用できるようにします。

メンテナンス制御に関するさまざまなオプションをよりよく理解できるようになったので、共有ホストでの更新を管理する方法を見てみましょう。

共有ホスト – VM のメンテナンスへの影響を最小限に抑えるには?

再起動が必要な場合は、顧客に通知され、緊急でない限り通常は 35 日以内にメンテナンスを開始するための期限が与えられます。 見る 計画メンテナンス通知の処理。

再起動が必要ない場合、VM は一時停止されるか、すでに更新されたホストにライブ マイグレーションされます。

アプリケーションによっては、たとえ数秒であっても一時停止を許容できない場合があります。 これらのアプリケーションでは、次のような代替案が可能です。

1) 一時停止の 15 分前にスケジュールされたイベントを視聴する

スケジュールイベント です Azure インスタンス メタデータ サービス (IMDS) アプリケーションに VM メンテナンスの準備時間を与える API。 メンテナンス イベント (再起動、再デプロイ、フリーズ、プリエンプト、終了) の最大 15 分前に通知されるため、アプリケーションはメンテナンス イベントに備えて中断を制限できます。

VM 上のサービスは、この API を監視して、イベントが実行される前に正常なシャットダウン (および接続のドレイン) を実行できます。

注: スケジュール イベントは、サービスが最初にイベントをクエリするリクエストを行ったときに有効になります。 最初の応答には多少の遅れがあります (約 1 分)。 24 時間エンドポイントへのリクエストがない場合は無効になります。

2) Azure Ddedicate Host へのオプトアウト

前に説明したように、Azure D dedicated Host は、メンテナンスがいつ適用されるかを制御し続けるためのソリューションとなります。

VM の可用性の中断を診断するにはどうすればよいですか?

プロジェクトフラッシュ これにより、Azure のお客様は、VM の劣化を含む、進行中および完了した可用性の中断を検出および診断できるようになります。

Azure VM の可用性は、以下を使用して監視できます。

• Azure リソース グラフ – 大規模な調査、一元化されたリソース リポジトリと履歴の検索用。
• Event Grid システムのトピック – 時間に敏感な重要な緩和策をトリガーする (VM の再起動アクションを再展開する)。
• Azure モニター – 傾向を追跡し、プラットフォーム メトリクス (CPU、ディスクなど) を集約し、正確なしきい値ベースのアラートを設定します。
• Azure リソースの健全性 – リソースごとに即時に便利なポータル UI ヘルスチェックを実行します。

Azure Resource Graph を使用すると、HealthResource テーブルに次の 2 種類のイベントが設定されます。

• リソースの健全性/可用性ステータス

仮想マシンの可用性状態を示します。

利用可能 | の間の値を想定できます。 利用不可 | 不明 | 劣化:

{
    "targetResourceType": "Microsoft.Compute/virtualMachines",
    "previousAvailabilityState": “Unavailable",
    "targetResourceId": ,
    "occurredTime": ,
    "availabilityState": "Available"
}

• リソース健康/リソース注釈

VM の可用性の変化が発生した理由を解釈し、必要に応じて明確なアクションを実行するためのコンテキストを提供します。

• 理由: VM の可用性が変化した理由についての簡単な説明
• コンテキスト: プラットフォームが開始されました | お客様が開始 | VM が開始されました | 不明 | 適用できない
• カテゴリー: 計画中 | 計画外 | 不明 | 適用できない
• 概要: VM の可用性が変化するアクティビティと原因に関する詳細ステートメント
• 影響の種類: ダウンタイム再起動 | ダウンタイムフリーズ | 劣化した | 情報提供

{
  "targetResourceType": "Microsoft.Compute/virtualMachines",
  "targetResourceId": ,
  "annotationName": "VirtualMachineHostRebootedForRepair",
  "occurredTime": "2022-09-25T20:21:37.5280000Z",
  "category": “Unplanned",
  "summary": "We're sorry, your virtual machine isn't available because an unexpected failure on the host server. Azure has begun the auto-recovery process and is currently rebooting the host server. No additional action is required from you at this time. The virtual machine will be back online after the reboot completes.",
  "context":  “Platform Initiated",
  "reason": "Unexpected host failure",
  "impactType”: “Downtime Reboot"
}

HealthResources テーブルでの有用な KQL リクエストの例は次のとおりです。 利用可能。

結論

この記事では、2 つのホスティング モデル (共有ホストと専用ホスト) と、計画メンテナンス、計画外メンテナンス、およびそれらのメンテナンス制御に関するそれぞれのオプションについて詳しく説明しました。

ワークロードが数秒程度のまれなフリーズを許容できる場合 (通常はこれに当てはまります)、またはこれらのフリーズを準備するのに 15 分で十分な場合 (現在の接続をドレインして新しい接続を拒否するなど)、デフォルトのホスティング モデルを使用します。共有ホストは、スケーラビリティと管理の容易さを提供するため、理想的です。

一方、ワークロードがたとえ数秒であってもフリーズに非常に敏感な場合は、メンテナンスを制御できる Azure D dedicated Host の使用を検討する必要があります。

Microsoft は、共有ホストでの保守管理エクスペリエンスの向上に引き続き取り組んでおり、共有ホスト モデルによって保守管理エクスペリエンスがさらに向上することは間違いありません。