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 時間後に Resource Health に投稿される可能性があります。
アクティビティ ログに 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) から利用可能なセキュリティ更新プログラムと重要な更新プログラムの一覧を取得します。 また、Linux システムの最新の更新プログラムについてもチェックしています。 VM でシステムの更新プログラムが不足している場合、Defender for Cloud は、システムの更新プログラムを適用することを推奨します。 これらのシステムの更新プログラムの適用は、Azure portal で Defender for Cloud を通して制御されます。 一部の更新プログラムでは、その適用後に VM の再起動が必要になります。 詳細については、「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 のパフォーマンスへの影響を最小限に抑えながら、ホスト ノードの問題を処理するように設計されています。 ホスト ノードで問題が発生した場合、Azure は最初に最も中断の少ない復旧方法を試みます。これは、ホストを再起動することです。 ホストを再起動できない場合、または元の問題がハードウェアに関連している場合、プラットフォーム サービスは影響を受けるホスト上のすべての VM を正常なノードに回復します。 一般に、ホストの再起動の影響は低くなりますが、VM の数、デプロイの制約、ローカル リソースの可用性によっては、サービス復旧 VM の複雑さと時間がかかる場合があります。 通常、サービス復旧は、VM が大幅なダウンタイムなしで動作し続けるので、ハードウェア障害の最後の手段として使用されます。
ホスト サーバーを再起動できない場合、Azure は自動復旧アクションを開始して、問題のあるホストをローテーションから外してさらに調査します。 この自動復旧プロセス中に、ホスト上のすべての VM が別の正常なホスト サーバーに自動的に再配置されます。 通常、このプロセスは 15 分以内に完了しますが、回復時間は、ホストのメモリ サイズや使用される回復方法などの要因によって異なる場合があります。 Azure でのこれらのシナリオの処理方法の詳細については、「 Service Healing – Auto-recovery of Virtual Machines」を参照してください。
未計画の保守
まれなことではありますが、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 フィードバック コミュニティに製品フィードバックを送信することもできます。