VDAアップグレード（プレビュー）
はじめに
-
以前は、VDAのアップグレードには完全な手動介入が必要でした。バージョン2503では、VDAアップグレードエージェントの導入により、DaaS展開におけるVDAアップグレードが簡素化されます。バージョン2503以降のアップグレードは、共有またはローカルのファイルパスから直接実行できるようになります。
-
VDAアップグレードエージェント ctxvua は、VDAアップグレードサービスとの通信を担当し、以下の機能を実行します。
- スケジュールされたチェック: VDAアップグレードエージェントは、15分ごとにVDAアップグレードサービスにスケジュールされたアップグレード情報を照会します。
- 自動アップグレード: アップグレード指示を受信すると、VDAアップグレードエージェントはVDAを自動的にアップグレードします。
- ステータスレポート: VDAアップグレードエージェントは、アップグレード結果（成功または失敗）をVDAアップグレードサービスに報告します。
VDAアップグレードサービスの詳細については、技術概要：Citrix VDAアップグレードサービスを参照してください。そこでは、サービスの概要、その仕組みに関する詳細情報、およびその他の役立つリソースを見つけることができます。
考慮事項
-
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をアップグレードする権限があること。
- StudioでVDAアップグレードが適切な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アップグレードエージェントサービス（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: 「Upgrade Unknown」状態
症状: マシンカタログでVDAアップグレードサービスを有効にした後、「Upgrade State」が期待される「Available」または「UpToDate」に変わらず、「Unknown」のままになります。「Upgrade Unknown」は一時的な状態です。最終的には「Available」または「UpToDate」に更新されるはずです。
「Upgrade Unknown」のトラブルシューティング手順:
-
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アップグレードサービスが同期するまでしばらく待ちます。その後、「Upgrade Type」が設定されていることを確認します。