次の方法で共有

Azure VM オペレーティング システムのアップグレードによって発生するロール インスタンスの再起動

  • [アーティクル]

この記事では、Microsoft Azure 仮想マシン (VM) オペレーティング システム (OS) のアップグレードがロール インスタンスの再起動に及ぼす影響について説明します。 OS とゲスト エージェントのアップグレード スケジュール、サービスへの影響と要件、通知、検出、一般的な問題を解決する方法の詳細が含まれています。

アップグレード スケジュール

Microsoft は、サービスとしての Azure プラットフォーム (PaaS) VM 用の新しいゲスト OS バージョンを約月単位でリリースします。 正確なスケジュールはさまざまであり、Azure ゲスト OS リリースと SDK 互換性マトリックスで履歴の傾向を確認できます。 このロールアウト中、 Azure Fabric コントローラー は、すべてのデータセンターを通じて 2 つのパス (ホスト OS パスとゲスト OS パス) を実行します。 Azure ゲスト エージェントの定期的な更新も VM 内で実行されます。

次のセクションでは、2 つのアップグレード パスとゲスト エージェントのアップグレードの詳細について説明します。

パス 1: ホスト OS

最初のパスでは、ホスト OS がアップグレードされます。 ホスト OS はロール インスタンスを再起動し、ファブリック コントローラーは一度に 1 つのアップグレード ドメインのインスタンスのみが再起動されるようにします。 この再起動中、ロール インスタンスは標準のシャットダウン プロセスを実行します。 次に、イベントが RoleEnvironment.OnStop 実行され、インスタンスを正常にシャットダウンする機会が与えます。

ホスト OS の更新には、ファブリックが、データセンター内のすべての異なるホステッド サービスとアップグレード ドメイン間でアップグレードを調整するのに数日かかる場合があります。 通常、デプロイの異なるインスタンスは数時間間隔で更新されます。

ホスト OS のアップグレード プロセスの詳細については、「 Azure ホストの更新プログラム: Azure の理由、タイミング、方法 」のブログ記事を参照してください。

パス 2: ゲスト OS

ホスト OS がデータセンター全体のアップグレードを完了すると、ゲスト OS は、自動ゲスト OS バージョンを使用するように構成されたサービス用にアップグレードされます。 このアップグレードは、サービスの標準アップグレード ドメイン 規則を使用して続行されます。 VM が再起動され、アップグレードされた OS を使用して Windows パーティション (D ドライブ) が再イメージ化されます。

ゲスト OS の更新プロセスは、ホスト OS の更新よりもはるかに高速です。 これは、ファブリックがホストされているサービスとアップグレード ドメイン内の更新のみを調整する必要があるためです。 サービスのゲスト OS 更新プロセスの期間は、主に次の要因によって異なります。

  • ロール インスタンスの数
  • アップグレード ドメインの数
  • サービスのシャットダウンにかかる時間 (Stopping および OnStop イベント)
  • サービスの起動にかかる時間 (スタートアップ タスクと OnStart イベント)

ゲスト エージェント

Azure ゲスト エージェントは、約 1 か月ごとに更新されます。 ゲスト エージェントが更新されると、次のアクションが発生します。

  • ロールを実行するホスト プロセス (通常は WaWorkerHost または WaWebHost) は正常にシャットダウンされます。
  • ゲスト エージェントはそれ自体を更新します。
  • ホスト プロセスが再び開始されます。

ゲスト エージェント プロセスとサービスとの対話方法の詳細については、「 Windows Azure クラシック VM アーキテクチャのワークフロー」を参照してください。

サービスの影響と要件

次の一覧では、クラウド サービスの影響と要件について説明します。

  • いずれかのロールにインスタンスが 1 つしかない場合、サービスでダウンタイムが発生する可能性があります。 サービス レベル アグリーメント (SLA) には 99.95% のアップタイムが必要であるため、各ロールのインスタンスは少なくとも 2 つ必要です。

  • 毎月約 1 回、ホスト OS の更新のためにロール インスタンスが再起動することを想定しています。 ゲスト OS の自動更新がある場合は、インスタンスが再び再起動することを想定してください。 通常、再起動は数時間離れています。 ただし、この期間は、データセンター内に存在するさまざまなサービスの構成によって変わる可能性があります。

  • ロールは、ホスト OS 更新プログラムを管理する規則に従う必要があります。 特に、ロール インスタンスは、スタートアップ タスクを Ready 開始してから 30 分以内に状態に達する必要があります。 この制限の詳細については、「 アップグレードの続行方法」を参照してください。

  • ホスト OS のアップグレードによってロール インスタンスが再起動され、ゲスト OS のアップグレードによってインスタンスの再イメージ化と同等になります。 これらのイベントのため、ロール インスタンスは次の手順を処理できる必要があります。

    • Restart
    • 再イメージ化
    • リサイクル

Notification

現時点では、OS のアップグレードが発生している場合、Azure プラットフォームではプロアクティブな通知は提供されません。 ロール インスタンスは、シャットダウンされる前にイベントを RoleEnvironment.Stopping 受け取ります。 このイベントを使用すると、ロール インスタンスが実行している作業を正常に終了したり、インスタンスがシャットダウンしていることを管理者に通知したりできます。

Azure OS Updates RSS フィードをサブスクライブできます。 このフィードは、OS の更新プログラムがデータセンターにロールアウトされるのと同じ日に更新する必要があります。 通常、フィードでは事前に事前に通知されませんが、更新プログラムが発生しているタイミングを特定するのに役立ちます。 更新プロセスが完了するまでに数日かかる場合があります。 そのため、RSS フィードが更新され、ホストされているサービスの更新が開始されるまで、1 日以上待つ必要がある場合があります。

Azure ゲスト OS リリース リストと、Azure portalで選択できる OS バージョンの一覧は、通常、ゲスト OS のロールアウトが完了した後に更新されます。 OS の更新が進行中のタイミングを示す、これらのリストの最新のエントリを使用しないでください。

検出

現時点では、ホスト OS のアップグレードを直接検出する方法はありません。 ただし、VM 上のログ内で再起動の証拠を確認できます。 これを行うには、以下のいずれかの操作を実行します。

  • イベント ビューアー アプリで、システム イベント ログでイベント ソース USER32 イベント ID 1074 を検索します。 このイベントには、次のメッセージが含まれています。

    プロセス D:\Packages\GuestAgent\WaAppAgent.exe (RD00155D50206D) は、ユーザー NT AUTHORITY\SYSTEM の代わりにコンピューター RD00155D50206Dのシャットダウンを開始しました。レガシ API のシャットダウン

    このメッセージは、Azure Fabric ゲスト エージェント (WaAppAgent.exe) が VM のシャットダウンを開始したことを示します。

  • テキスト エディターで、古い アプリ エージェント ランタイム ログ ファイル (AppAgentRuntime.log.old) _Context_Start で Context 、 が と等しいメッセージを StopContainer()検索します。 アプリ エージェント ランタイム ログのコンテキスト エントリを調べる方法の詳細については、「 トラブルシューティング シナリオ 6 – Azure ブログ アーカイブでしばらく実行した後のロールのリサイクル 」を参照してください。

共通の問題と解決策

次のセクションでは、ロール インスタンスの再起動に関連するいくつかの一般的な問題と、それらを解決する方法について説明します。 実行中のプロセスと、トラブルシューティングに使用できるログ ファイルの場所の詳細については、「 Windows Azure クラシック VM アーキテクチャのワークフロー」を参照してください。

問題 1: ホスト OS の再起動後にスタートアップ タスクまたはコードが 2 回目に実行されない

スタートアップ タスクまたは または 関数内のコードはOnStartRun、ホスト OS の再起動後に 2 回目に失敗する可能性があります。 再起動は、スタートアップ タスクを呼び出して再実行する必要があります。 このエラーにより、ロール インスタンスが状態に Ready 到達できなくなります。

スタートアップ タスクで何かを行い、2 回目の実行後にエラーを返すコマンドを実行した場合はどうでしょうか。 この場合、スタートアップ タスクは失敗し、ロール インスタンスがリサイクルを開始します。 たとえば、 APPCMD set config コマンドを使用して Internet Information Services (IIS) に構成セクションを追加すると、コマンドは 2 回目の実行で失敗します。 コマンドはエラー メッセージを生成します。"新しい追加オブジェクトに必要な属性がありません。 型の重複するコレクション エントリを追加できません。..その後、ロール インスタンスがリサイクルを開始します。

解決策 1: VM に接続し、スタートアップまたはコードエラーをリモートでデバッグする

この種のエラーのトラブルシューティングを行うには、リモート デスクトップ プロトコル (RDP) を使用して VM にリモートで接続します。 イベント ログでエラーがないか調べ、WaHostBootstrapper.log ファイルにチェックして、スタートアップ タスクの失敗を確認します。 一般的な開発およびテスト プロセスでは、Azure portalからロール インスタンスの再起動を事前に開始する必要があります。 この手順は、サービスをテストして、このシナリオで正しく動作することを確認するのに役立ちます。

スタートアップ タスクの失敗の一般的な修正は、スタートアップ タスク スクリプトの最後にコマンドを追加 exit /b 0 することです。 この 終了 コマンドは、成功を示す終了コードを使用してスクリプトを終了します。 このコマンドが必要な理由の詳細については、「 Azure Cloud Service (クラシック) のスタートアップ タスクを構成して実行する方法」を参照してください。

問題 2: Windows パーティションの再イメージ化後にスタートアップ タスクまたはコードが実行されない

Windows パーティション (D ドライブ) は、通常、プログラムのインストールとレジストリの変更が格納される場所です。 更新プログラムのゲスト OS 部分中に、Windows パーティションが再イメージ化されます。 これにより、これらのインストールと変更が失われる可能性があります。 Windows パーティションの再イメージ化後も特定のレジストリ変更がまだ存在するとスタートアップ コードが誤って想定している場合、ロール インスタンスが正しく動作しない可能性があります。 このエラーにより、ロール インスタンスが状態に Ready 到達できなくなります。

たとえば、スタートアップ タスクによってレジストリが変更される場合があります。 次に、その変更のレコードを C ドライブまたは E ドライブに格納して、レジストリの変更が 2 回目に実行されないようにします。 ただし、D ドライブのレジストリの変更は再イメージ化のために失われ、タスクが必要と思われないため、スタートアップ タスクはそのレジストリの変更を復元しません。 レジストリの変更が見つからないと、最終的にスタートアップ タスクの残りの部分が失敗する可能性があります。

解決策 2: Azure portalからのロール インスタンスの再イメージ化をテストする

一般的な開発およびテスト プロセスでは、Azure portalからロール インスタンスの再イメージ化を事前に開始する必要があります。 この手順は、サービスをテストし、このシナリオで正しく動作することを確認するのに役立ちます。

問題 3: スタートアップ コードの完了に 30 分以上かかります

スタートアップ コードの完了に 30 分以上かかる場合は、複数のロール インスタンスが同時にサービス外である可能性があります。 このシナリオは、最も一般的に、スタートアップ タスクが次のいずれかのアクションを実行するときに発生します。

  • プログラムまたは機能をインストールします
  • キャッシュ データをダウンロードする
  • Web サイト情報をダウンロードする

解決策 3: サービスの影響と要件を確認する

「 サービスの影響と要件 」セクションを確認して、何を期待するか、スタートアップの遅延を防止または軽減する方法を確認します。

問題 4: 更新後に Azure がホストまたはゲスト OS を再起動しない

まれに、更新後に Azure がホストまたはゲスト OS を再起動しないことがあります。 このシナリオでは、30 分以上経過しても変更されない "ホストの待機中" メッセージがポータルに表示される可能性があります。

解決策 4a: スタートアップ コードを修正する

リモート デスクトップ プロトコル (RDP) を使用してロール インスタンスに接続できる場合は、スタートアップ コードにエラーが発生して修正できる可能性があります。 スタートアップ コードを修正する方法の詳細については、「 解決策 1: VM に接続し、スタートアップまたはコードエラーをリモートでデバッグする」を参照してください。

解決策 4b: デプロイを削除する

RDP を使用してロール インスタンスに接続できない場合、おそらくインスタンスを復旧する唯一の方法は、デプロイを削除することです。

問題 5: OS のアップグレード中に 1 つ以上のロール インスタンスを使用できない

OS のアップグレード中にロール インスタンスが使用できない場合は、サービス容量が低下する可能性があります。 たとえば、Web ロールのインスタンスが 2 つあり、通常は両方のインスタンスが 75% の CPU 使用率で実行するとします。 アップグレード中に 1 つのインスタンスが再起動された場合、トラフィックは残りのインスタンスにリダイレクトされます。 そのインスタンスは、余分な負荷を処理できません。 これにより、サービスの可用性が低下します。

解決策 5: サービスに十分な余分な容量を保持する

サービスに十分な過剰な容量があることを確認して、使用できないロール インスタンスの一定の割合を吸収します。 使用可能にする必要がある余分な容量の量を計算するには、番号 1 をアップグレード ドメインの数で割ります。 たとえば、2 つのアップグレード ドメインがある場合は、アップグレード ドメインが使用できなくなるのを処理するために、1/2 = 50% の超過容量が必要です。 5 つのアップグレード ドメインがある場合は、5 つのアップグレード ドメインのいずれかで可用性の損失を処理するために、1/5 = 20% の超過容量が必要です。

問題 6: Web サイトのウォームアップに時間がかかりすぎるため、クライアントで停止またはタイムアウトが発生する

Web サイトのウォームアップには数分かかりますか? (たとえば、Web サイトのウォームアップは、標準の IIS または ASP.NET プリコンパイルとモジュールの読み込みで構成される場合や、キャッシュやその他のアプリ固有のタスクをウォームアップしている可能性があります)。この場合、クライアントで停止やランダムなタイムアウトが発生する可能性があります。

ロール インスタンスが再起動され OnStart 、コードの実行が完了すると、ロール インスタンスがロード バランサーのローテーションに復元されます。 その後、ロール インスタンスは受信要求の受信を開始します。 Web サイトがまだウォームアップしている場合、これらのすべての受信要求がキューに入り、タイムアウトします。Web ロールのインスタンスが 2 つしかないとします。 この場合、 IN_0 インスタンスは受信要求 IN_1 の 100% を受け取り、インスタンスはゲスト OS の更新のために再起動されます。 ただし、 IN_0 インスタンスはまだウォームアップしています。 このシナリオでは、両方のインスタンスで Web サイトのウォームアップが完了するまで、サービスが完全に停止する可能性があります。

解決策 6: ウォームアップが完了するまで、ロール インスタンスが受信要求を受け取るのを停止する

Web サイトのウォームアップが OnStart 完了するまで、ロール インスタンスのイベント処理コードを終了しないようにすることをお勧めします。 このイベント プロセスを実装するには、次のコード例を使用します。

public class WebRole : RoleEntryPoint {
    public override bool OnStart () {
        // For information about handling configuration changes, see the article
        // "Customize the Lifecycle of a Web or Worker role in .NET" at
        // https://learn.microsoft.com/azure/cloud-services/cloud-services-role-lifecycle-dotnet.
        IPHostEntry ipEntry = Dns.GetHostEntry (Dns.GetHostName ());
        string ip = null;
        foreach (IPAddress ipaddress in ipEntry.AddressList) {
            if (ipaddress.AddressFamily.ToString () == "InterNetwork") {
                ip = ipaddress.ToString ();
            }
        }
        string urlToPing = "https://" + ip;
        HttpWebRequest req = HttpWebRequest.Create (urlToPing) as HttpWebRequest;
        WebResponse resp = req.GetResponse ();
        return base.OnStart ();
    }
}

詳細

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

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