次の方法で共有

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

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

    • Restart
    • 再イメージ化
    • Recycle

通知

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

Azure OS 更新プログラムの 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 ファブリック ゲスト エージェント (WaAppAgent.exe) が VM のシャットダウンを開始したことを示します。

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

一般的な問題と解決方法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

サービスの影響と要件セクションを確認して、想定される内容と、スタートアップの遅延を回避または軽減する方法を確認します。

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

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

解決策 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 インスタンスは、ゲスト OS 更新プログラムの IN_1 インスタンスの再起動中に、受信要求の 100% を受け取ります。 ただし、 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 フィードバック コミュニティに製品フィードバックを送信することもできます。