次の方法で共有

Azure VM のシステム再起動について

  • [アーティクル]

適用対象: ✔️ Linux VM ✔️ Windows VM

Azure 仮想マシン (VM) は、ユーザーが再起動操作を開始した事実も、はっきりした理由もないのに再起動することがあります。 この記事では、VM の再起動を発生させる可能性がある操作とイベントを示し、予期しない再起動の問題を回避する方法、またはそのような問題の影響を軽減する方法について洞察します。

仮想マシンを高可用性を実現するように構成する

Azure で実行中のアプリケーションを VM の再起動とダウンタイムから保護する最善の方法は、高可用性を実現するよう仮想マシンを構成することです。

このレベルの冗長性をアプリケーションに提供するには、2 台以上の VM を可用性セットにグループ化することをお勧めします。 このような構成により、計画的または計画外のメンテナンス イベント中に、少なくとも 1 つの VM が利用可能となり、99.95% の Azure SLA が満たされます。

可用性セットの詳細については、VM の可用性の管理に関する記事を参照してください。

Resource Health の情報

Azure Resource Health は個々の Azure リソースの正常性を明らかにし、問題をトラブルシューティングするために実行できる操作をアドバイスするサービスです。 サーバーやインフラストラクチャ要素に直接アクセスできないクラウド環境では、Resource Health の目標は、トラブルシューティングに費やす時間を短縮することです。 特に、問題の原因がアプリケーションにあるのか、Azure プラットフォームの内部で発生したイベントにあるのかを判別するために費やされる時間を短縮することが目標となります。 詳細については、Resource Health の概要と使用方法に関するページを参照してください。

プラットフォームが開始した仮想マシンの使用不能の根本原因に関する詳細情報が Azure にある場合、その情報は、最初の使用不能から最大 72 時間後にリソース正常性に投稿される可能性があります。

アクティビティ ログに VM のダウンタイムがない

Resource Health アラート は、 アクティビティ ログ 情報に基づいて送信されます。 場合によっては、VM のダウンタイムがアクティビティ ログに表示されないことがあります。 ダウンタイムがアクティビティ ログに表示されない場合、ダウンタイムに対して Resource Health アラートは送信されません。 ダウンタイムは Resource Health に引き続き表示されます。

VM のダウンタイムがアクティビティ ログに表示されない場合を次に示します。

  • VM が作成または新しいホストに移行されると、Azure プラットフォームに VM の状態が正しく表示され、状態が [不明] に変わります。 すべてのネットワーク接続とノード プロセスが確立された後にのみ、VM の状態が [使用可能] に変わります。 不明な状態の長期間は、アクティビティ ログから除外されます。
  • VM の可用性状態が [利用可能] から [利用不可] に変わり、35 秒以内に [使用可能] に戻った場合、ダウンタイムはアクティビティ ログに表示されません。 このケースは、最初の遷移が発生する 15 分以内に関連付けられたダウンタイムが送信された場合には発生しません。
  • VM の正常性が状態から不明に変わり、元の状態に戻ると、断続的な不明な状態と関連する遷移がアクティビティ ログから除外されます。

アクティビティ ログに表示されない VM のダウンタイムは、Azure プラットフォーム側でフィルター処理され、一時的なエラーによって顧客に不適切なダウンタイムが表示されないようにします。 VM の正常性品質への継続的な投資により、フィルターは不要になり、VM の正常性をすばやく変更しても報告されない可能性があります。 Microsoft は、最適なカスタマー エクスペリエンスを提供するための段階的な計画に取り組んでいます。

VM の再起動の原因となる可能性がある操作とイベント

定期的なメンテナンス

Microsoft Azure は、世界各地で定期的に更新を行い、VM の基盤となるホスト インフラストラクチャの信頼性、パフォーマンス、セキュリティの向上に努めています。 これらの更新の多くは、VM やクラウド サービスに影響を及ぼさずに実行されます (メモリ保護更新など)。

ただし、再起動が必要な更新があります。 そのようなケースでは、インフラストラクチャに修正プログラムが適用されている間、VM はシャットダウンされ、その後再起動されます。

Azure の計画的メンテナンスの概要と、それが Linux VM の可用性に及ぼす影響については、次の記事を参照してください。 これらの記事は、Azure の計画的メンテナンス プロセスの背景と、影響を軽減するために計画的メンテナンスのスケジュールを設定する方法を示しています。

メモリ保護更新

Microsoft Azure のこのクラスの更新では、実行中の VM に関して、ユーザーが気付くほどの影響が生じることはありません。 これらの更新の多くは、実行中のインスタンスに干渉することがなく更新可能なコンポーネントまたはサービスを対象にしています。 一部はホスト オペレーティング システムのプラットフォーム インフラストラクチャの更新であり、VM の再起動を必要とせずに適用できます。

これらのメモリ保護更新は、インプレース ライブ マイグレーションを実現するテクノロジによって完了します。 更新中は、VM の状態が "一時停止" になります。 この状態で、RAM 内のメモリが保護され、基礎となるホスト オペレーティング システムが必要な更新プログラムと修正プログラムを受信します。 VM は通常、一時停止してから 30 秒以内に再開されます。 再開後、VM のクロックは自動的に同期されます。

一時停止の期間が短いことを考えると、このメカニズムによる更新のデプロイは、VM への影響を大幅に軽減します。 ただし、この方法ですべての更新をデプロイできるわけではありません。

複数インスタンスの更新 (可用性セット内の VM) は、一度に 1 つの更新ドメインに適用されます。

Note

カーネルのバージョンが古い Linux マシンでは、この更新方法では、カーネル パニックによる影響が発生します。 この問題を回避するには、カーネルのバージョンを 3.10.0-327.10.1 以降に更新します。 詳細については、3.10 ベースのカーネルで実行中の Azure Linux VM でホスト ノードのアップグレード後に発生するパニックに関するページを参照してください。

ユーザーが開始した再起動/シャットダウン アクション

再起動を Azure portal、Azure PowerShell、コマンド ライン インターフェイス、または REST API から実行した場合は、Azure アクティビティ ログでそのイベントを見つけることができます。

VM のオペレーティング システムから操作を実行した場合は、システム ログでそのイベントを見つけることができます。

VM の再起動の原因となる一般的なその他のシナリオとして、複数の構成を変更する操作があります。 通常、特定の操作を実行すると VM の再起動が発生することを示す警告メッセージが表示されます。 たとえば、VM のサイズ変更操作、管理アカウントのパスワードの変更、静的 IP アドレスの設定などの操作があります。

Microsoft Defender for Cloud と Windows Update

Microsoft Defender for Cloud は、オペレーティング システムの更新プログラムがない場合に、Windows および Linux VM を毎日監視します。 Defender for Cloud は、Windows VM で構成されているサービスに応じて、Windows Update または Windows Server Update Services (WSUS) から利用可能なセキュリティおよび重要な更新プログラムの一覧を取得します。 Defender for Cloud では、Linux システムの最新の更新プログラムもチェックされます。 VM にシステム更新プログラムがない場合は、システム更新プログラムを適用することをお勧めします。 これらのシステム更新プログラムの適用は、Azure portal の Defender for Cloud を使用して制御されます。 一部の更新プログラムでは、その適用後に VM の再起動が必要になります。 詳細については、「 Apply system updates in Microsoft Defender for Cloud」を参照してください。

Windows VM は、オンプレミスのサーバーと同じように、ユーザーによって管理されることを想定しているため、Azure 側からそれらの VM に Windows の更新プログラムをプッシュすることはありません。 ただし、自動 Windows Update の設定は有効のままにしておくことをお勧めします。 Windows Update による更新プログラムの自動インストールでも、更新プログラムの適用後に再起動が発生する可能性があります。 詳細については、「Windows Update: FAQ」を参照してください。

VM の可用性に影響するその他の状況

Azure によって VM の使用が能動的に停止される場合があります。 ユーザーは、この操作が行われる前に電子メール通知を受信するため、基になる問題を解決するチャンスがあります。 VM の可用性に影響する問題の例としては、セキュリティ違反や、支払いの有効期限切れがあります。

ホスト サーバー エラー

VM は、Azure データセンター内で稼働している物理サーバーでホストされています。 物理サーバーでは、ホスト エージェントと呼ばれるエージェントと、他のいくつかの Azure コンポーネントが実行されています。 物理サーバー上のこれらの Azure ソフトウェア コンポーネントが応答しなくなると、復旧を試行するために、監視システムによってホスト サーバーの再起動がトリガーされます。 多くの場合、VM は 10 ~ 15 分以内に再び使用可能になり、以前と同じホストで引き続き使用できます。

サーバー エラーは通常、ハード ディスクやソリッドステート ドライブの障害など、ハードウェアの障害によって発生します。 Azure は、これらの発生を継続的に監視し、基になるバグが特定し、軽減策を実装してテストした後、更新をロールアウトします。

一部のホスト サーバー エラーはサーバー固有のエラーである可能性があるため、VM の再起動が繰り返し発生する場合は、別のホスト サーバーに VM を手動で再デプロイすると状況が改善することがあります。 この操作は、VM の詳細ページで [再デプロイ] オプションを使用するか、Azure Portal で VM を停止して再起動することでトリガーできます。

自動復旧

ホスト サーバーが何らかの理由で再起動できない場合、Azure プラットフォームは、詳細な調査を行うために、障害のあるホスト サーバーをローテーションから除外する自動復旧操作を開始します。

ホスト上のすべての VM は、正常に稼働している別のホスト サーバーに自動的に再配置されます。 通常、このプロセスは 15 分以内に完了しますが、復旧に必要な時間は、ホスト メモリのサイズや使用される回復方法など、いくつかの要因によって異なる場合があります。 自動復旧プロセスの詳細については、VM の自動復旧に関するページを参照してください。

未計画の保守

まれなことではありますが、Azure の運用チームが、Azure プラットフォームの全体的な正常性を保証するために、メンテナンス アクティビティを実施しなければならないことがあります。 この行動が VM の可用性に影響を与える場合があります。通常は、前述と同じ自動復旧操作が発生します。

計画外のメンテナンスには、次のものがあります。

  • 緊急のノードの最適化
  • 緊急のネットワーク スイッチの更新

VM のクラッシュ

VM は、VM 自体の問題が原因で再起動することがあります。 VM で実行中のワークロードまたはロールによって、ゲスト オペレーティング システム内のバグ チェックがトリガーされる場合があります。 クラッシュの原因を判断する手掛かりとしては、Windows VM のアプリケーション ログや Linux VM のシリアル ログを参照してください。

Azure の VM は、オペレーティング システムの仮想ディスクと Azure Storage インフラストラクチャでホストされているデータ ストレージに依存しています。 VM と関連する仮想ディスクとの間の可用性または接続が 120 秒を超えて影響を受けた場合、Azure プラットフォームは、データの破損を回避するために、常に VM の強制シャットダウンを実行します。 ストレージの接続が回復すると、VM は自動的に復旧します。 シャットダウンの期間は 5 分ほどですが、大幅に長くなる可能性があります。

その他のインシデント

まれな状況ですが、拡散する問題によって、Azure データセンターの複数のサーバーが影響を受けることがあります。 このような問題が発生した場合、Azure チームは、影響を受けるサブスクリプションに電子メール通知を送信します。 Azure サービス正常性ダッシュボードと Azure Portal で、継続中の停止と過去のインシデントをチェックすることができます。

VM の再起動を診断する

VM ブレードの [診断と解決] ブレードを使用して、追加の診断を実行できます。 これにより、最近の VM 再起動のより具体的な理由が明らかになる場合があります。 ゲスト OS の問題がある場合は、メモリ ダンプを収集し、サポートにお問い合わせください。

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。