Azure Local 23H2 に、10.2503.0.13 の更新プログラムを適用する際に、更新プログラムの適用が長時間経過しても完了しないという事象が発生しました。
Azure Local 23H2 の更新をする際に確認しておきたい情報 で、更新プログラムの適用で使用するコマンドレットをいくつか記載しましたが、SR でトラブルシューティングを進める中で他のコマンドレットの情報も教えていただきましたので、情報を残しておきたいと思います。
Contents
発生していた事象
今回の環境は、シングルノード構成の Intel NUC を使用した構成を使用しています。
23H2 の更新プログラムの適用は クラウドベースの更新 となっており、Azure から更新プログラムの適用を実施したところ、12 時間以上時間が経過しても更新プログラムの適用が完了しないという事象が発生していました。
この状態では PowerShell を使用して Azure Local を更新する に記載されている Get-SolutionUpdateEnvironment / Get-SolutionUpdate を実行しても、300 秒のタイムアウトに達してエラーとなってしまい、更新プログラムの適用状況を把握することができませんでした。
具体的には、コマンドレットを実行し、300 秒経過後に次のようなエラーが発生していました。
Get-SolutionUpdate : A RestResponse of GatewayTimeout was received calling GET on https://xxxxx:4900/prov
iders/Microsoft.Update.Admin/updateLocations/redmond/updates?api-version=2022-08-01.
At line:1 char:1
+ Get-SolutionUpdate
+ ~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-SolutionUpdate], TransientException
+ FullyQualifiedErrorId : Microsoft.AzureStack.Common.Infrastructure.Http.Client.ErrorModel.TransientException,Mic
rosoft.AzureStack.Lcm.PowerShell.GetSolutionUpdateCmdlet
この際の GET の要求は Azure Local のホストに対して実行されており、ホスト上では TCP:4900 が実行されていることは確認ができていました。
netstat -anot | findstr 4900
TCP 0.0.0.0:4900 0.0.0.0:0 LISTENING 4 InHost
TCP [::]:4900 [::]:0 LISTENING 4 InHost
再起動を行えば解消できる可能性が高かったのですが、再起動せずに事象を解決する方法がないかを SR で確認を行い、対応として次のような内容を提案されました。
事象発生時に確認を行う情報
Get-SolutionDiscoveryDiagnosticInfo の実行
Azure Local には、ソフトウェアベンダーによって公開された Solution Builder Extension (SBE) の更新マニフェストファイルを確認するための、コマンドレットとして 「Microsoft.AzureStack.Lcm.PowerShell」モジュールで、「Get-SolutionDiscoveryDiagnosticInfo」が提供されており、このコマンドレットの使用方法は次のドキュメントで公開されています。
BIOS から製造元を取得して、ベンダー固有のリダイレクト URI にアクセスを行い、更新マニフェストファイルを取得するというものとなっているようですが、今回の事象が発生している場合には、このコマンドレットもタイムアウトをしてしまい、実行結果を取得することができない状態となっていました。
Azure Local 診断ログの収集
Azure Local には診断ログを収集し Microsoft に送信する方法が提供されており、SR で取得の指示があった場合、情報の取得を実施することになります。
コマンドレットで取得する場合には「Send-DiagnosticData」を実行します。
このコマンドレットでは From / To を 24 時間分の範囲で指定することができ、指定した期間の 1 日分の情報を Microsoft に送信することができます。複数日の情報を取得するためには、複数回、コマンドレットの実行を行います。
私が取得した際には、1 日分の取得で 4 時間程度、実行に時間がかかったので、コマンドを実行しても結果の取得が完了するまでには数時間単位で時間が必要となるようです。(1 日分のログで、5GB / 1,700 程度のファイルの出力が行われていたようです)
このコマンドレットの実行結果は「Get-LogCollectionHistory」で取得することができますので、SR で取得の依頼があった場合には、このコマンドレットの情報も連携をするとよいかと思います。
LCM Controller サービスの再起動
今回の事象ではこの対応が効果あったように思えます。
Update-Hangs-after-Secret-Rotation.md に、LcmController サービスを再起動するスクリプト (Restart-LCM) が公開されています。
このスクリプトを使用して、LCM Controller サービスを再起動し、Application のイベントログにイベントソース「.NET」または「Application Error」の「Microsoft.AzureStack.HciOrchestratorService.WinSvcHost.exe」のエラー情報が継続して出力されていないかを確認し、出力されていないようであれば、しばらく時間をおいて更新の適用が進んでいるかを確認します。
Get-ActionPlanInstances を使用した進捗状況の確認
今回私が遭遇した事象では、Get-SolutionUpdate は反応が無かったのですが、「Get-ActionPlanInstances」については、情報の取得が実行できる状態となっていたようでした。
このコマンドレットを使用し、次のようなコマンドを実行することで進捗状況をファイルに出力することができました。
$latestUpdateActionPlanId = (Get-ActionPlanInstances | ? ActionPlanName -like "MAS Update*" | sort startdatetime -Descending | Select-Object -First 1).InstanceID.Guid Get-ActionPlanInstance -actionPlanInstanceID $latestUpdateActionPlanId | % ProgressAsXml > C:\ap1.xml
このファイルを確認することでどこまで処理が進んでいるかを確認することができる可能性があるため、更新プログラムの進捗が無くなった場合には、ファイルの出力を実行してみるとよいかもしれません。
まとめ
私の環境では、更新プログラムの適用が完了するのには、問題が発生しないケースでも、シングルノード構成で 4 時間程度時間がかかっていました。
Azure Local の更新プログラムの適用は、通常の Windows Server OS と比較して時間がかかる傾向があるようです。
更新の適用を実施して、Azure Portal で進捗が無いように見えたときは、以下の実施の検討をするのが良いかもしれませんね。
- Get-ActionPlanInstances で進捗を確認
- アプリケーションのイベントログを確認
- LCM Controller サービスの再起動