Mises à niveau VDA (préversion)
Introduction
-
Auparavant, la mise à niveau des VDA nécessitait une intervention manuelle complète. La version 2503 simplifie les mises à niveau des VDA pour les déploiements DaaS en introduisant l’agent de mise à niveau VDA. Les mises à niveau à partir de la version 2503 peuvent ensuite être effectuées directement à partir d’un chemin de fichier partagé ou local.
-
L’agent de mise à niveau VDA ctxvua est responsable de la communication avec le service de mise à niveau VDA et de l’exécution des fonctions suivantes :
- Vérifications planifiées : L’agent de mise à niveau VDA interroge le service de mise à niveau VDA pour obtenir des informations sur les mises à niveau planifiées toutes les 15 minutes.
- Mises à niveau automatisées : Dès réception des instructions de mise à niveau, l’agent de mise à niveau VDA met automatiquement à niveau le VDA.
- Rapports d’état : L’agent de mise à niveau VDA signale le résultat de la mise à niveau (succès ou échec) au service de mise à niveau VDA.
Pour en savoir plus sur le service de mise à niveau VDA, consultez le Tech Brief : Service de mise à niveau Citrix VDA. Vous y trouverez une présentation du service, des informations détaillées sur son fonctionnement et d’autres ressources utiles.
Considérations
-
Les VDA Linux sont mis à niveau à l’aide de commandes de gestion de paquets sous-jacentes (telles que rpm ou apt), reproduisant le processus de mise à niveau manuelle ; les fichiers de configuration sont automatiquement gérés pendant la mise à niveau en ligne de commande.
-
Contrairement à Windows, le VDA Linux inclut un agent de mise à niveau VDA intégré. Cela simplifie le processus de mise à niveau car l’agent est déjà présent. La version de l’agent de mise à niveau VDA est liée à la version du VDA.
-
Par défaut, l’agent de mise à niveau VDA est désactivé. Pour activer l’agent, exécutez les commandes suivantes :
- /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--> -
Le service de l’agent de mise à niveau VDA (ctxvua) est désactivé par défaut. Vous pouvez utiliser systemctl pour activer et démarrer ce service.
-
En tant que bonne pratique, nous vous recommandons de tester minutieusement les mises à niveau VDA avant de les déployer en production.
-
Contrairement à Windows, les mises à niveau des VDA Linux ne sont prises en charge qu’à partir d’un chemin de fichier. Cela signifie que vous ne pouvez pas utiliser directement les URL Azure CDN ou d’autres référentiels en ligne. Vous devez gérer vous-même les paquets VDA. Cela s’applique aux mises à niveau de versions majeures et mineures.
-
Ignorez « Latest VDA Version » et « Upgrade State » dans le service de mise à niveau VDA. Seul le « VDA Upgrade State » est pertinent pour Linux.
-
Le chemin de fichier du paquet VDA peut être local à la machine VDA ou un emplacement partagé (par exemple, un partage réseau monté sur le VDA). Le système n’est pas conçu pour télécharger automatiquement le paquet. Vous devez fournir le fichier de paquet complet.
-
Spécifiez le chemin au format de chemin UNC Windows (commençant par \\) pour passer la validation du chemin lors de l’utilisation de Studio ou du SDK PowerShell distant Citrix DaaS. Par exemple, /mnt/pkg\/<package-name> doit être saisi comme \\mnt\pkg\<package-name>.
-
La distinction entre les VDA « serveur » et « station de travail » ne s’applique pas à Linux. Vous pouvez utiliser l’une ou l’autre option dans Studio ou PowerShell sans affecter la mise à niveau.
-
La rétrogradation des VDA n’est pas prise en charge.
Prérequis
- Plan de contrôle : Citrix DaaS™
-
Version du VDA : 2503 ou ultérieure
Remarque :
Nous vous recommandons d’utiliser le dernier VDA CR.
- Les VDA doivent avoir l’agent de mise à niveau VDA installé et le service doit être en cours d’exécution.
- Vous disposez des autorisations nécessaires pour mettre à niveau les VDA.
- La mise à niveau VDA est configurée avec la bonne piste CR ou LTSR dans Studio.
- Les VDA ne sont pas utilisés. (Les utilisateurs doivent s’en déconnecter.)
- Les VDA ne sont pas en mode maintenance. (Un VDA peut être mis en mode maintenance par un administrateur. Un VDA peut également être automatiquement mis en mode maintenance s’il a dépassé le nombre maximal de tentatives d’enregistrement autorisées.)
- Les VDA doivent appartenir à un groupe de mise à disposition et être enregistrés auprès de DaaS.
-
Le VDA de destination prend en charge le système d’exploitation du VDA actuel.
-
Mettre à niveau les VDA à l’aide de Studio
-
Flux de travail général
Voici un flux de travail général pour mettre à niveau les VDA à l’aide de Studio :
-
Activer la mise à niveau VDA pour un catalogue.
- Vous pouvez activer la mise à niveau VDA lors de la création d’un catalogue.
- Vous pouvez activer la mise à niveau VDA lors de la modification d’un catalogue.
-
Mettre à niveau les VDA par catalogue. Les mises à niveau VDA par machine ne sont pas actuellement disponibles. Pour plus d’informations, consultez Configurer la mise à niveau automatique des VDA.
Remarque :
Lors de la planification des mises à niveau VDA pour un catalogue, toutes les machines du catalogue sont incluses dans le périmètre de la mise à niveau. Par conséquent, nous vous recommandons de sauvegarder ces machines avant d’initier la mise à niveau.
-
Le processus de mise à niveau VDA ne prend pas en charge la mise à niveau de composants supplémentaires ou l’utilisation de fonctionnalités telles que la restauration. Ignorez ces deux étapes.
-
- Configurez les options de planification, y compris l’heure de la mise à niveau et le seuil d’échec de la mise à niveau. Le seuil d’échec détermine probablement le nombre de mises à niveau échouées tolérées avant que le processus ne soit arrêté ou que des alertes ne soient déclenchées.
-
Sélectionnez « Utiliser un partage de fichiers local » pour l’emplacement de l’installateur VDA. Fournissez le chemin au format UNC Windows (par exemple, \\server\share\path).
-
L’option « Forcer la fermeture des sessions » contrôle la manière dont les sessions utilisateur sont gérées pendant les mises à niveau VDA. Bien que l’interface utilisateur de Studio ne permette que la déconnexion des sessions déconnectées, PowerShell peut déconnecter toutes les sessions (connectées et déconnectées). La déconnexion n’est pas immédiate. Le service de mise à niveau VDA initie la déconnexion après que l’agent de mise à niveau VDA tente d’interroger le calendrier de mise à niveau et trouve des sessions déconnectées. L’agent attend ensuite 15 minutes avant de relancer la requête.
Mettre à niveau les VDA à l’aide de PowerShell
Vous pouvez configurer les mises à niveau VDA à l’aide du SDK PowerShell distant sur Windows. Pour plus d’informations sur le SDK PowerShell distant, consultez le SDK PowerShell distant Citrix DaaS.
- Voici les cmdlets PowerShell :
- Get-VusCatalog
- Utilisez cette cmdlet pour obtenir les détails d'un catalogue tels que **Name**, **Uid**, **Uuid**, **UpgradeState** (**Available**, **UpToDate**, **Scheduled**, **Unknown**), **Upgrade scheduled** et **StateId** (état de **Upgrade scheduled**).
-
Get-VusMachine
Utilisez cette cmdlet pour obtenir les détails d’une machine tels que MachineName, Uid, Uuid, UpgradeState (Available, UpToDate, Scheduled, Unknown) et StateId (état de Upgrade scheduled).
-
Get-VusComponentVersion
Utilisez cette cmdlet pour vérifier si les VDA ont signalé les versions des composants. Utilisez le MachineId pour filtrer les VDA. MachineId est l’UUID de Get-BrokerMachine.
-
New-VusMachineUpgrade
Utilisez cette cmdlet pour configurer les mises à niveau de VDA au niveau de la machine.
-
New-VusCatalogSchedule
Utilisez cette cmdlet pour planifier les mises à niveau de VDA au niveau du catalogue de machines.
Exemple :
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-->
Dépannage
Le cœur du processus de mise à niveau repose sur le service VDA Upgrade Agent (ctxvua). Il agit comme intermédiaire, communiquant avec le service VDA Upgrade Service et exécutant le script /opt/Citrix/VDA/sbin/update_helper.sh pour les opérations liées au système d’exploitation. Pendant la mise à niveau, les informations relatives au processus sont stockées dans le registre.
Registre
| Utilisez la commande **/opt/Citrix/VDA/bin/ctxreg dump | grep -i UpdateAgent** pour examiner les paramètres du registre liés à l’agent de mise à niveau VDA. Cela peut révéler des problèmes de configuration ou des problèmes liés au processus de mise à niveau lui-même. |
- Vérifier la configuration : Le fichier de configuration du service ctxvua se trouve à l’emplacement /etc/xdl/updateagent.conf. L’examen de ce fichier peut aider à identifier les erreurs de configuration.
Journaux
Les fichiers journaux suivants sont essentiels pour le dépannage :
-
/var/log/xdl/vua.log : Fichier journal du service ctxvua. C’est le journal principal à consulter pour les problèmes liés au fonctionnement de l’agent de mise à niveau. Le fichier de configuration du service ctxvua se trouve à l’emplacement /etc/xdl/updateagent.conf. L’examen de ce fichier peut aider à identifier les erreurs de configuration.
-
/var/log/xdl/update_helper.log : Fichier journal du script update_helper.sh. Ce journal est essentiel pour diagnostiquer les problèmes liés aux tâches au niveau du système d’exploitation pendant la mise à niveau.
Problèmes courants
Cette section aborde les problèmes courants rencontrés lors des mises à niveau de VDA, en se concentrant spécifiquement sur les options désactivées dans Studio et l’état “Upgrade Unknown”.
Problème courant 1 : Options de mise à niveau désactivées
Symptôme : Les options “Définir le type de mise à niveau” et “Mettre à niveau les VDA” sont désactivées (grisées) dans Studio pour un catalogue donné.
Solution : Vérifiez si le service VDA Upgrade Service est pris en charge pour le type de catalogue que vous utilisez. Si ce n’est pas le cas, vous ne pouvez pas utiliser ces fonctionnalités de mise à niveau automatisées et devez gérer les mises à niveau manuellement.
Problème courant 2 : État “Upgrade Unknown”
Symptôme : Après avoir activé le service VDA Upgrade Service pour un catalogue de machines, l’« État de la mise à niveau » reste « Inconnu » au lieu de passer à « Disponible » ou « À jour » comme prévu. « Upgrade Unknown » est un état transitoire. Il devrait finalement passer à « Disponible » ou « À jour ».
Étapes de dépannage pour “Upgrade Unknown” :
-
Vérifiez que l’agent de mise à niveau VDA signale les versions.
-
Étape 1a : Obtenez l’UUID de la machine :
Get-BrokerMachine -DNSName '<hostname>' <!--NeedCopy--> -
Étape 1b : Vérifiez la version du composant signalée par l’agent :
Get-VusComponentVersion -MachineId "<UUID>" <!--NeedCopy-->Si la commande Get-VusComponentVersion renvoie une valeur vide, cela signifie que l’agent de mise à niveau VDA n’a pas signalé sa version. Cela pourrait indiquer que le VDA est « enregistré en dur » (vérifiez les paramètres du catalogue de machines et du groupe de mise à disposition). Cela indique également que l’agent de mise à niveau VDA pourrait ne pas être installé ou en cours d’exécution sur le VDA cible.
-
-
Vérifiez la synchronisation du service VDA Upgrade Service.
Étape 2a : Vérifiez si le service VDA Upgrade Service a synchronisé la machine à partir de la base de données du Broker :
``` Get-VusEntityUnit -EntityUUID "" <!--NeedCopy--> ```Remplacez
""par l’EntityUUID réel si connu, ou exécutez sans pour obtenir tous les éléments. Si vous constatez que ce champ est vide, cela peut indiquer que la machine n’a pas été synchronisée avec le serveur VDA Upgrade Service.Étape 2b : Si la machine n’a pas été synchronisée, laissez un certain temps au service VDA Upgrade Service pour se synchroniser. Ensuite, confirmez que le « Type de mise à niveau » a été défini.