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をアップグレードする権限があること。
- 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インストーラーの場所として「Use local file share」を選択します。Windows UNC形式でパスを指定します (例: \\server\share\path)。
-
「Force logoff sessions」オプションは、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 (利用可能、最新、スケジュール済み、不明)、および StateId (アップグレードスケジュールのステータス) などのマシンの詳細を取得します。
-
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 で無効になっているオプションと「アップグレード不明」の状態に焦点を当てて説明します。
一般的な問題 1: 無効なアップグレードオプション
症状: 特定のカタログについて、Studio で「アップグレードタイプの構成」と「VDA のアップグレード」のオプションが無効 (グレー表示) になっています。
解決策: 使用しているカタログタイプで VDA Upgrade Service がサポートされているかどうかを確認します。サポートされていない場合、これらの自動アップグレード機能を使用することはできず、アップグレードを手動で管理する必要があります。
一般的な問題 2: 「アップグレード不明」の状態
症状: マシンカタログで VDA Upgrade Service を有効にした後、「アップグレード状態」が期待どおりに「利用可能」または「最新」に変わらず、「不明」のままになります。「アップグレード不明」は一時的な状態です。最終的には「利用可能」または「最新」のいずれかに更新されるはずです。
「アップグレード不明」のトラブルシューティング手順:
-
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 が同期するまでしばらく待ちます。その後、「アップグレードタイプ」が設定されていることを確認します。