VDA アップグレード (プレビュー)
はじめに
以前は、VDA のアップグレードには完全な手動介入が必要でした。バージョン 2503 では、VDA アップグレードエージェントを導入することで、DaaS 展開における VDA アップグレードを簡素化します。バージョン 2503 以降のアップグレードは、共有またはローカルのファイルパスから直接実行できます。
VDA アップグレードエージェント ctxvua は、VDA アップグレードサービスとの通信と、以下の機能の実行を担当します。
- スケジュールされたチェック: VDA アップグレードエージェントは、15 分ごとに VDA アップグレードサービスにスケジュールされたアップグレード情報を照会します。
- 自動アップグレード: アップグレード指示を受信すると、VDA アップグレードエージェントは VDA を自動的にアップグレードします。
- ステータスレポート: VDA アップグレードエージェントは、アップグレード結果 (成功または失敗) を VDA アップグレードサービスに報告します。
VDA アップグレードサービスの詳細については、「Tech Brief: Citrix VDA Upgrade service」を参照してください。そこには、サービスの概要、動作に関する詳細情報、およびその他の役立つリソースが記載されています。
考慮事項
-
Linux VDA は、手動アップグレードプロセスを模倣して、基盤となるパッケージ管理コマンド (rpm や apt など) を使用してアップグレードされます。コマンドラインアップグレード中に構成ファイルは自動的に処理されます。
-
Windows とは異なり、Linux VDA には組み込みの VDA アップグレードエージェントが含まれています。エージェントがすでに存在するため、アップグレードプロセスが簡素化されます。VDA アップグレードエージェントのバージョンは VDA のバージョンに紐付けられています。
-
デフォルトでは、VDA アップグレードエージェントは無効になっています。エージェントを有効にするには、次のコマンドを実行します。
/opt/Citrix/VDA/bin/ctxreg create -k "HKLM\Software\Citrix\UpdateServices\UpdateAgent" -t "REG_DWORD" -v "fEnabled" -d "0x00000001" --force systemctl start ctxvua.service <!--NeedCopy--> -
VDA アップグレードエージェントサービス (ctxvua) はデフォルトで無効になっています。systemctl を使用して、このサービスを有効にして開始できます。
-
ベストプラクティスとして、本番環境に移行する前に VDA アップグレードを徹底的にテストすることをお勧めします。
-
Windows とは異なり、Linux VDA のアップグレードはファイルパスからのみサポートされます。これは、Azure CDN URL やその他のオンラインリポジトリを直接使用できないことを意味します。VDA パッケージは自分で管理する必要があります。これは、メジャーバージョンとマイナーバージョンの両方のアップグレードに適用されます。
-
VDAアップグレードサービスにおける「最新VDAバージョン」と「アップグレード状態」は無視してください。「VDAアップグレード状態」のみがLinuxに関連します。
-
VDAパッケージのファイルパスは、VDAマシンにローカルな場所、または共有場所(たとえば、VDAにマウントされたネットワーク共有)にすることができます。システムはパッケージを自動的にダウンロードするようには設計されていません。完全なパッケージファイルを提供する必要があります。
-
StudioまたはCitrix DaaS Remote PowerShell SDKを使用する際にパス検証を通過させるには、Windows UNCパス形式(\\で始まる)でパスを指定します。たとえば、/mnt/pkg\/<package-name> は \\mnt\pkg\<package-name> と入力する必要があります。
-
「サーバー」VDAと「ワークステーション」VDAの区別はLinuxには適用されません。StudioまたはPowerShellでどちらのオプションを使用しても、アップグレードに影響はありません。
-
VDAのダウングレードはサポートされていません。
前提条件
- コントロールプレーン: Citrix DaaS™
-
VDAバージョン: 2503以降
注:
最新のCR VDAを使用することをお勧めします。
- VDAにはVDAアップグレードエージェントがインストールされており、サービスが実行されている必要があります。
- VDAをアップグレードする権限があること。
- VDAアップグレードがStudioで適切なCRまたはLTSRトラックで構成されていること。
- VDAが使用中でないこと。(ユーザーはVDAからサインオフする必要があります。)
- VDAがメンテナンスモードでないこと。(VDAは管理者によってメンテナンスモードに設定できます。また、最大許容登録試行回数を超えた場合、VDAは自動的にメンテナンスモードになることもあります。)
- VDAはデリバリーグループに属し、DaaSに登録されている必要があります。
- 移行先のVDAは、現在のVDAのオペレーティングシステムをサポートしている必要があります。
Studioを使用してVDAをアップグレードする
一般的なワークフロー
Studioを使用してVDAをアップグレードする一般的なワークフローは次のとおりです。
-
カタログのVDAアップグレードを有効にします。
-
VDAはカタログごとにアップグレードします。マシンごとのVDAアップグレードは現在利用できません。詳細については、「VDAの自動アップグレードを構成する」を参照してください。
注:
カタログのVDAアップグレードをスケジュールする場合、カタログ内のすべてのマシンがアップグレードの対象に含まれます。そのため、アップグレードを開始する前にこれらのマシンをバックアップすることをお勧めします。
-
VDAアップグレードプロセスは、追加コンポーネントのアップグレードや、復元などの機能の使用をサポートしていません。これらの2つの手順はスキップしてください。
-
アップグレード時間やアップグレード失敗しきい値など、スケジューリングオプションを構成します。失敗しきい値は、プロセスが停止されるかアラートがトリガーされるまでに許容される失敗したアップグレードの数を決定する可能性があります。
-
VDAインストーラーの場所として「ローカルファイル共有を使用」を選択します。パスをWindows UNC形式で指定します(例:\\server\share\path)。
-
「Force logoff sessions」オプションは、VDAアップグレード中にユーザーセッションがどのように処理されるかを制御します。Studio UIでは切断されたセッションのみログオフできますが、PowerShellではすべてのセッション(接続済みおよび切断済み)をログオフできます。ログオフは即座には行われません。VDAアップグレードサービスは、VDAアップグレードエージェントがアップグレードスケジュールを照会しようとして切断されたセッションを見つけた後にログオフを開始します。その後、エージェントは照会を再試行する前に15分間待機します。
PowerShellを使用したVDAのアップグレード
You can configure VDA upgrades using the Remote PowerShell SDK on Windows. For more information about the Remote PowerShell SDK, see Citrix DaaS Remote PowerShell SDK.
以下はPowerShellのコマンドレットです。
-
Get-VusCatalog
このコマンドレットを実行すると、カタログに関する詳細な情報を取得することが可能です。取得できる情報には、Name、Uid、Uuid、UpgradeState(Available、UpToDate、Scheduled、Unknown)、Upgrade scheduled、そしてStateId(これはUpgrade scheduledの現在の状態を示します)といった項目が含まれます。
-
Get-VusMachine
このコマンドレットを使用して、MachineName、Uid、Uuid、UpgradeState(利用可能、最新、スケジュール済み、不明)、およびStateId(アップグレードがスケジュール済みのステータス)などのマシンの詳細を取得します。
-
Get-VusComponentVersion
このコマンドレットを使用して、VDAがコンポーネントバージョンを報告したかどうかを確認します。MachineIdを使用してVDAをフィルタリングします。MachineIdはGet-BrokerMachineからのUUIDです。
-
New-VusMachineUpgrade
このコマンドレットを使用して、マシンレベルでVDAアップグレードを構成します。
-
New-VusCatalogSchedule
このコマンドレットを使用して、マシンカタログレベルでVDAアップグレードをスケジュールします。
例:
Get-BrokerMachine -DNSName 'u22-test*'
New-VusCatalogSchedule -CatalogName "test-catalog" -UpgradeNow -DurationInHours 2 -LogoffOption ActiveAndDisconnectedSessions -VdaServerPackageUri "\\root\xendesktopvda_24.11.0.1-1.ubuntu22.04_amd64.deb"
Get-VusComponent -CatalogName 'test-catalog'
Get-VusCatalog -Name 'test-catalog'
<!--NeedCopy-->
トラブルシューティング
アップグレードプロセスの核は、VDAアップグレードエージェントサービス(ctxvua)を中心に展開されます。これは仲介役として機能し、VDAアップグレードサービスと通信し、OS関連の操作のために/opt/Citrix/VDA/sbin/update_helper.shスクリプトを実行します。アップグレード中、プロセスに関する情報はレジストリに保存されます。
レジストリ
| コマンド**/opt/Citrix/VDA/bin/ctxreg dump | grep -i UpdateAgent**を使用して、VDAアップグレードエージェントに関連するレジストリ設定を調べます。これにより、構成の問題やアップグレードプロセス自体の問題が明らかになることがあります。 |
- 構成の確認: ctxvuaサービスの構成ファイルは/etc/xdl/updateagent.confにあります。このファイルを確認することで、誤った構成を特定するのに役立ちます。
ログ
トラブルシューティングには、以下のログファイルが重要です。
-
/var/log/xdl/vua.log: ctxvuaサービスのログファイル。これは、アップグレードエージェントの操作に関連する問題を確認するための主要なログです。ctxvuaサービスの構成ファイルは/etc/xdl/updateagent.confにあります。このファイルを確認することで、誤った構成を特定するのに役立ちます。
-
/var/log/xdl/update_helper.log: update_helper.shスクリプトのログファイル。このログは、アップグレード中のOSレベルのタスクに関連する問題を診断するために不可欠です。
一般的な問題
このセクションでは、VDAアップグレード中に発生する一般的な問題について説明します。特に、Studioで無効になっているオプションと「Upgrade Unknown」の状態に焦点を当てます。
一般的な問題1:無効なアップグレードオプション
症状: 特定のカタログについて、Studioで「Set Upgrade Type」と「Upgrade VDAs」のオプションが無効(グレー表示)になっています。
解決策: 使用しているカタログタイプでVDAアップグレードサービスがサポートされているかどうかを確認してください。サポートされていない場合、これらの自動アップグレード機能を使用することはできず、アップグレードを手動で管理する必要があります。
一般的な問題2:「アップグレード不明」状態
症状: マシンカタログでVDAアップグレードサービスを有効にした後、「Upgrade State」が期待どおりに「Available」または「UpToDate」に変わらず、「Unknown」のままになります。「Upgrade Unknown」は一時的な状態です。最終的には「Available」または「UpToDate」のいずれかに更新されるはずです。
「アップグレード不明」のトラブルシューティング手順:
-
VDAアップグレードエージェントがバージョンを報告していることを確認します。
-
ステップ1a: マシンのUUIDを取得します:
Get-BrokerMachine -DNSName '<hostname>' <!--NeedCopy--> -
ステップ1b: エージェントによって報告されたコンポーネントバージョンを確認します:
Get-VusComponentVersion -MachineId "<UUID>" <!--NeedCopy-->Get-VusComponentVersionコマンドが空白を返す場合、VDAアップグレードエージェントがバージョンを報告していないことを意味します。これは、VDAが「ハード登録」されている可能性があることを示しています (マシンカタログとデリバリーグループの両方の設定を確認してください)。また、VDAアップグレードエージェントがターゲットVDAにインストールされていないか、実行されていない可能性も示しています。
-
-
VDAアップグレードサービスの同期を確認します。
ステップ2a: VDAアップグレードサービスがBrokerデータベースからマシンを同期したかどうかを確認します:
``` Get-VusEntityUnit -EntityUUID "" <!--NeedCopy--> ```既知の場合は、
""を実際のEntityUUIDに置き換えるか、すべて取得するために指定せずに実行します。これが空白であると確認された場合、マシンがVDAアップグレードサービスサーバーと同期していないことを示している可能性があります。ステップ2b: マシンが同期されていない場合、VDAアップグレードサービスが同期するまでしばらく待ちます。その後、「アップグレードタイプ」が設定されていることを確認します。