VDAアップグレード（プレビュー）
はじめに
-
これまで、VDAのアップグレードには完全な手動介入が必要でした。バージョン2503では、VDAアップグレードエージェントの導入により、DaaS展開におけるVDAアップグレードが簡素化されます。バージョン2503以降のアップグレードは、共有またはローカルのファイルパスから直接実行できるようになります。
-
VDAアップグレードエージェント ctxvua は、VDAアップグレードサービスとの通信を担当し、以下の機能を実行します。
- スケジュールされたチェック: VDAアップグレードエージェントは、15分ごとにVDAアップグレードサービスにスケジュールされたアップグレード情報を照会します
- 自動アップグレード: アップグレード指示を受信すると、VDAアップグレードエージェントはVDAを自動的にアップグレードします
- ステータスレポート: VDAアップグレードエージェントは、アップグレード結果（成功または失敗）をVDAアップグレードサービスに報告します
VDAアップグレードサービスの詳細については、「[Tech Brief: Citrix VDA Upgrade service](https://community.citrix.com/tech-zone/learn/tech-briefs/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バージョン」と「アップグレード状態」は無視してください。Linuxでは「VDAアップグレード状態」のみが関連します
-
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）で指定します
-
「セッションの強制ログオフ」オプションは、VDAアップグレード中にユーザーセッションがどのように処理されるかを制御します。Studio UIでは切断されたセッションのログオフのみが許可されますが、PowerShellではすべてのセッション（接続済みおよび切断済み）をログオフできます。ログオフは即時ではありません。VDAアップグレードエージェントがアップグレードスケジュールを照会しようとして切断されたセッションを見つけると、VDAアップグレードサービスがログオフを開始します。その後、エージェントは15分待ってから照会を再試行します
PowerShellを使用したVDAのアップグレード
WindowsでRemote PowerShell SDKを使用してVDAアップグレードを構成できます。Remote PowerShell SDKの詳細については、「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 (Available、UpToDate、Scheduled、Unknown)、およびStateId (「Upgrade scheduled」のステータス) など、マシンの詳細を取得します。
- Get-VusComponentVersion
このコマンドレットを使用して、VDA がコンポーネントバージョンを報告したかどうかを確認します。VDA をフィルタリングするには、MachineId を使用します。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 Upgrade Agent サービス (ctxvua) です。これは仲介役として機能し、VDA Upgrade Service と通信し、OS 関連の操作のために /opt/Citrix/VDA/sbin/update_helper.sh スクリプトを実行します。アップグレード中、プロセスに関する情報はレジストリに保存されます。
レジストリ
| VDA Upgrade Agent に関連するレジストリ設定を調べるには、コマンド **/opt/Citrix/VDA/bin/ctxreg dump | grep -i UpdateAgent** を使用します。これにより、構成の問題やアップグレードプロセス自体の問題が明らかになる場合があります。 |
- 構成の確認: 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 Upgrade Service がサポートされているかどうかを確認します。サポートされていない場合、これらの自動アップグレード機能を使用することはできず、アップグレードを手動で管理する必要があります。
一般的な問題 2: 「Upgrade Unknown」状態
症状: マシンカタログで VDA Upgrade Service を有効にした後、「Upgrade State」が期待どおりに「Available」または「UpToDate」に変わらず、「Unknown」のままになります。「Upgrade Unknown」は一時的な状態です。最終的には「Available」または「UpToDate」のいずれかに更新されるはずです。
「Upgrade Unknown」のトラブルシューティング手順:
-
VDA Upgrade Agent がバージョンを報告していることを確認します。
-
ステップ 1a: マシンの UUID を取得します。
Get-BrokerMachine -DNSName '<hostname>' <!--NeedCopy--> -
ステップ 1b: エージェントによって報告されたコンポーネントバージョンを確認します。
Get-VusComponentVersion -MachineId "<UUID>" <!--NeedCopy-->Get-VusComponentVersion コマンドが空白を返す場合、VDA Upgrade Agent がそのバージョンを報告していないことを意味します。これは、VDA が「ハード登録」されている (マシンカタログとデリバリーグループの両方の設定を確認してください) ことを示している可能性があります。また、VDA Upgrade Agent がターゲット VDA にインストールされていないか、実行されていない可能性も示しています。
-
-
VDA Upgrade Service の同期を確認します。
ステップ 2a: VDA Upgrade Service が Broker データベースからマシンを同期したかどうかを確認します。
``` Get-VusEntityUnit -EntityUUID "" <!--NeedCopy--> ```既知の場合は
""を実際の EntityUUID に置き換えるか、すべてを取得するために何も指定せずに実行します。これが空白である場合、マシンが VDA Upgrade Service サーバーと同期されていないことを示している可能性があります。ステップ 2b: マシンが同期されていない場合は、VDA Upgrade Service が同期するまでしばらく待機します。その後、「Upgrade Type」が設定されていることを確認します。