この記事では、サービスとしての Microsoft Azure プラットフォーム (PaaS) 仮想マシン (VM) 上の Windows オペレーティング システム (OS) へのアップグレードによって発生するロール インスタンスの再起動に関してよく寄せられる質問 (FAQ) に回答します。
オペレーティング システムの更新プログラムをオプトアウトするにはどうすればよいですか?
ホスト OS の更新プログラムをオプトアウトすることはできません。 Microsoft は、データセンター内で最新のホスト オペレーティング システムを維持する必要があります。 ゲスト OS のバージョンを指定することで、ゲスト OS の更新をオプトアウトできます。 ただし、これを行うと、サービスはセキュリティ更新プログラムを受信しなくなり、脆弱なままになる可能性があります。 詳細については、「 ゲスト OS バージョンの管理」を参照してください。
操作方法更新と再起動を強制的に実行するのは、営業時間以外の時間帯だけですか?
ホスト OS に対して 1 つのインスタンスまたはサービスをアップグレードするタイミングを制御することはできません。 アップグレードは、世界中のすべての Azure データセンターで同時に開始されます。 ファブリックは、各データセンターのアップグレードに継続的に機能します。 すべてのクラウド サービスに対してアップグレード ドメインルールが確実に従われるのは複雑であるため、このプロセスには数日かかります。 特定のインスタンスが影響を受けるタイミングを制御または決定する方法はありません。 ゲスト OS の更新を制御するには、固定のゲスト OS バージョンを指定し、準備ができたら常に更新します。
VM に何かをインストールしました。 しかし、今、VMが再起動され、私がインストールしたソフトウェアはなくなりました! ソフトウェアが消えたのはなぜですか?
リモート デスクトップ プロトコル (RDP) を使用して Azure PaaS VM に接続し、変更を加えたり、ソフトウェアをインストールしたりすることはできません。 VM はいつでも再構築され、行った変更はすべて失われます。 このシナリオは、ハードウェアが失敗し、新しいハードウェアで新しい VM を起動する必要がある場合に発生する可能性があります。 また、Windows パーティションが再構築されるときに、ゲスト OS の更新中にも発生します。 ソフトウェアをインストールするか、VM に変更を加える必要がある場合は、スタートアップ タスクを作成し、そこから作業を行います。 このプロセスにより、VM が再作成されると、構成が再度実行されます。
新しいゲスト OS バージョンの更新プログラムの 1 つがサービスを中断することはできますか?
新しいゲスト OS バージョンにインストールされた更新プログラムは、一般公開され、徹底的にテストされた修正プログラムです。 これらの修正プログラムは、Windows Updateを通じて世界中のサーバーにも展開されており、サービスに悪影響を及ぼす可能性は小さいです。 オンプレミス サービスについては、最初に更新プログラムをテストするステージング環境を使用して、Azure VM 上の OS パッチを管理する必要があります。
運用環境の前に更新プログラムをテストするようにステージング環境を設定する場合は、.cscfg ファイルで固定バージョンの OS 文字列を使用するように運用サービスを構成します。 次に、新しいゲスト OS が使用可能になったら、最新のゲスト OS バージョンを使用して、サービスをステージング スロットにデプロイできます。 最新のゲスト OS でサービスが正しく動作することを確認したら、VIP スワップを実行できます。 または、運用サービスのインプレース アップグレードを実行して、最新の OS を使用することもできます。
アップグレードにはどのくらいの時間がかかりますか? VM が停止する期間はどのくらいですか?
一般的な誤解は、適用されている更新プログラムが多いほど、プロセスにかかる時間が長くなるということです。 この前提は、アップグレードがローカル デスクトップ コンピューターでのWindows Updateアップグレードの実行方法と同様に機能するという考え方に基づいています。 Windows アップグレードでは、多くの更新プログラムが Windows にコピーされ、以降の再起動を含めてインストールされます。 ただし、そのプロセスは、Azure でのアップグレードのしくみではありません。
Azure で新しい OS バージョンがリリースされると、OS チームは最新のイメージを取得し、更新プログラムを適用してから、この新しい基本イメージを含む仮想ハード ディスク (VHD) を作成します。 この基本イメージは、Azure のリポジトリにコピーされます。 OS アップグレードを実行するようにファブリックに指示されると、最初にコピー パスが作成されます。 アップグレードするデータセンターで、ファブリックは、この新しい基本イメージ VHD を各サーバーのハード ディスクにコピーします。 このプロセスが完了すると、ファブリックは通常のアップグレード ドメイン 規則に従ってアップグレード プロセスを開始します。
ゲストが更新されると、ファブリックは OS の正常なシャットダウンを行い、新しい基本イメージを使用して新しい VM を開始します。 ゲスト OS の特定の VM をアップグレードするために必要な時間は、正常な Windows のシャットダウンと再起動にかかる時間とほぼ同じ時間です。
ホスト OS の更新のタイミングが異なります。 ホストがアップグレードされると、次のシーケンスが発生します。
ホストは、そのホストで実行されている各ゲスト OS にシャットダウン メッセージを送信します。
各ゲスト OS には、シャットダウンを完了するための標準
OnStopイベントと Windows シャットダウン時間が与えられます。すべてのゲスト OS がシャットダウンされると、ホスト OS は正常なシャットダウンを実行し、通常のシャットダウン手順を実行します。
ホスト OS がシャットダウンされると、新しい OS イメージを使用してホストが再起動されます。
ホストが起動して実行されると、各ゲスト OS が起動します。
このホスト OS の更新プロセスは、通常、15 分から 20 分かかります。 時間は、そのホスト上の他のゲストの数と、そのゲストを処理するために必要な時間によって異なる場合があります。 ただし、特定のノードで障害が発生し、そのノードのゲストを別のノードに移動する必要があると Azure ファブリックが判断した場合は、常に例外が発生します。
オペレーティング システムのシャットダウン操作方法処理しますか?
OS が更新されると、Azure Fabric によってロール インスタンスが正常にシャットダウンされます。 このプラクティスは、ASP.NET コードがイベントをApplication_End受け取り、Azure サービス ランタイムによって イベントと OnStop イベントがStopping発生することを意味します。 コードには、プロセスがシャットダウンされる前にクリーンアップ作業 OnStop が完了するまでに 5 分かかります。 Azure ホスト プロセスがシャットダウンされると、Windows は通常の正常なシャットダウンを実行します。これには、Windows サービスの標準 OnStop イベントと関連イベントの発生が含まれます。
インスタンスのシャットダウンを処理する方法の詳細については、「 Azure OnStop イベントを処理する正しい方法」、 .NET での Web ロールまたは Worker ロールのライフサイクルのカスタマイズ、 RoleEntryPoint.OnStop() メソッドに関するページを参照してください。
詳細
お問い合わせはこちらから
質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。