VDA-Upgrades (Preview)
Einführung
Bisher war für die Aktualisierung von VDAs ein vollständig manueller Eingriff erforderlich. Version 2503 vereinfacht VDA-Upgrades für DaaS-Bereitstellungen durch die Einführung des VDA-Upgrade-Agents. Upgrades ab Version 2503 können später direkt von einem freigegebenen oder lokalen Dateipfad durchgeführt werden.
Der VDA Upgradeagent ctxvua ist für die Kommunikation mit dem VDA-Upgradedienst und die Ausführung der folgenden Funktionen verantwortlich:
- Geplante Prüfungen: Der VDA-Upgradeagent fragt den VDA-Upgrade-Dienst alle 15 Minuten nach Informationen zu geplanten Upgrades ab.
- Automatisierte Upgrades: Nach Erhalt der Upgradeanweisungen aktualisiert der VDA-Upgrade-Agent den VDA automatisch.
- Statusberichterstattung: Der VDA-Upgradeagent meldet das Upgradeergebnis (Erfolg oder Fehler) an den VDA-Upgradedienst zurück.
Weitere Informationen zum VDA-Upgradedienst finden Sie unter Tech Brief: Citrix VDA Upgrade service. Dort finden Sie eine Übersicht über den Dienst, detaillierte Informationen zur Funktionsweise und andere nützliche Ressourcen.
Überlegungen
-
Linux VDAs werden mit zugrunde liegenden Paketverwaltungsbefehlen (wie rpm oder apt) aktualisiert. Dabei wird der manuelle Aktualisierungsprozess gespiegelt. Konfigurationsdateien werden während der Aktualisierung über die Befehlszeile automatisch verarbeitet.
-
Im Gegensatz zu Windows enthält der Linux VDA einen integrierten VDA-Upgradeagent. Dies vereinfacht den Upgradeprozess, da der Agent bereits vorhanden ist. Die Version des VDA-Upgradeagents ist an die VDA-Version gebunden.
-
Standardmäßig ist der VDA-Upgradeagent deaktiviert. Um den Agent zu aktivieren, führen Sie die folgenden Befehle aus:
/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--> -
Der VDA Upgrade Agent-Dienst (ctxvua) ist standardmäßig deaktiviert. Sie können systemctl verwenden, um diesen Dienst zu aktivieren und zu starten.
-
Als bewährte Methode empfehlen wir, VDA-Upgrades gründlich zu testen, bevor sie in die Produktion übernommen werden.
-
Im Gegensatz zu Windows werden Linux VDA-Upgrades nur von einem Dateipfad aus unterstützt. Dies bedeutet, dass Sie Azure CDN-URLs oder andere Onlinerepositorys nicht direkt verwenden können. Sie müssen die VDA-Pakete selbst verwalten. Dies gilt sowohl für Haupt- als auch für Nebenversionsupgrades.
-
Ignorieren Sie “Neueste VDA-Version” und “Upgradestatus” im VDA-Upgradedienst. Für Linux ist nur der “VDA Upgrade State” relevant.
-
Der Dateipfad für das VDA-Paket kann lokal auf der VDA-Maschine oder an einem freigegebenen Speicherort (z. B. einer auf dem VDA bereitgestellten Netzwerkfreigabe) liegen. Das System ist nicht darauf ausgelegt, das Paket automatisch herunterzuladen. Sie müssen die vollständige Paketdatei bereitstellen.
-
Geben Sie den Pfad im Windows UNC-Pfadformat an (beginnend mit \\), um die Pfadvalidierung bei Verwendung von Studio oder Citrix DaaS Remote PowerShell SDK zu bestehen. Beispielsweise muss /mnt/pkg\/<package-name> als \\mnt\pkg\<package-name> eingegeben werden.
-
Die Unterscheidung zwischen “Server”- und “Workstation”-VDAs gilt für Linux nicht. Sie können beide Optionen in Studio oder PowerShell verwenden, ohne dass das Upgrade dadurch beeinträchtigt wird.
-
Das Downgrade von VDAs wird nicht unterstützt.
Voraussetzungen
- Steuerungsebene: Citrix DaaS
-
VDA-Version: 2503 oder höher
Hinweis
Wir empfehlen die Verwendung des neuesten CR VDA.
- Auf den VDAs muss der VDA-Upgrade Agent installiert sein und der Dienst muss ausgeführt werden.
- Sie vefügen über Berechtigungen zum Upgrade von VDAs.
- Das VDA-Upgrade wird mit dem richtigen CR- oder LTSR-Track in Studio konfiguriert.
- Die VDAs werden nicht verwendet. (Die Benutzer müssen sich von ihnen abmelden.)
- Die VDAs sind nicht im Wartungsmodus. (Ein VDA kann von einem Administrator in den Wartungsmodus versetzt werden. Ein VDA kann auch automatisch in den Wartungsmodus versetzt werden, wenn er die maximal zulässigen Registrierungsversuche überschritten hat.)
- Die VDAs müssen zu einer Bereitstellungsgruppe gehören und bei DaaS registriert sein.
- Der Ziel-VDA unterstützt das Betriebssystem des aktuellen VDAs.
Upgrade von VDAs mit Studio
Allgemeiner Arbeitsablauf
Ein allgemeiner Workflow zum Upgrade von VDAs mit Studio sieht wie folgt aus:
-
Aktivieren Sie das VDA-Upgrade für einen Katalog.
- Sie können das VDA-Upgrade aktivieren, wenn ein Katalog erstellt wird.
- Sie können das VDA-Upgrade aktivieren, wenn Sie einen Katalog bearbeiten.
-
Upgrade von VDAs auf Katalogbasis. VDA-Upgrades pro Maschine sind derzeit nicht verfügbar. Weitere Informationen finden Sie unter Automatisches Upgrade für VDAs konfigurieren.
Hinweis
Beim Planen von VDA-Upgrades für einen Katalog werden alle Maschinen im Katalog in den Upgradeumfang einbezogen. Daher empfehlen wir, diese Maschinen zu sichern, bevor Sie das Upgrade starten.
-
Der VDA-Upgradeprozess unterstützt keine Upgrades zusätzlicher Komponenten oder die Verwendung von Features wie “Wiederherstellen”. Überspringen Sie diese beiden Schritte.
-
Konfigurieren Sie die Planungsoptionen, einschließlich der Upgradezeit und des Upgradefehlerschwellenwerts. Der Fehlerschwellenwert bestimmt wahrscheinlich, wie viele fehlgeschlagene Upgrades toleriert werden, bevor der Prozess gestoppt oder Warnungen ausgelöst werden.
-
Wählen Sie “Lokale Dateifreigabe verwenden” als Speicherort des VDA-Installationsprogramms. Geben Sie den Pfad im Windows UNC-Format an (z. B. \\server\share\path).
-
Die Option “Abmeldung von Sitzungen erzwingen” steuert, wie Benutzersitzungen während VDA-Upgrades behandelt werden. Während die Studio-Benutzeroberfläche nur das Abmelden getrennter Sitzungen zulässt, kann PowerShell alle Sitzungen (verbunden und getrennt) abmelden. Die Abmeldung erfolgt nicht sofort. Der VDA-Upgradedienst leitet die Abmeldung ein, nachdem der VDA-Upgradeagent versucht hat, den Upgradezeitplan abzufragen und getrennte Sitzungen findet. Der Agent wartet dann 15 Minuten, bevor er die Abfrage wiederholt.
VDAs mit PowerShell aktualisieren
Sie können VDA-Upgrades mit dem Remote PowerShell SDK unter Windows konfigurieren. Weitere Informationen zum Remote PowerShell SDK finden Sie unter Citrix DaaS Remote PowerShell SDK.
Im Folgenden sind die PowerShell-Cmdlets aufgeführt:
-
Get-VusCatalog
Verwenden Sie dieses Cmdlet, um Details eines Katalogs abzurufen, wie etwa Name, Uid, Uuid, UpgradeState (Verfügbar, Aktuell, Geplant, Unbekannt), Upgrade geplant und StateId (Status von Upgrade geplant).
-
Get-VusMachine
Verwenden Sie dieses Cmdlet, um Details zu einer Maschine abzurufen, wie etwa MachineName, Uid, Uuid, UpgradeState (Available, UpToDate, Scheduled, Unknown), und StateId (Status von Upgrade geplant).
-
Get-VusComponentVersion
Verwenden Sie dieses Cmdlet, um zu überprüfen, ob VDAs die Komponentenversionen gemeldet haben. Verwenden Sie die MachineId , um die VDAs zu filtern. MachineId ist die UUID von Get-BrokerMachine.
-
New-VusMachineUpgrade
Verwenden Sie dieses Cmdlet, um VDA-Upgrades auf Maschinenebene zu konfigurieren.
-
New-VusCatalogSchedule
Verwenden Sie dieses Cmdlet, um VDA-Upgrades auf Maschinenkatalogebene zu planen.
Beispiel
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-->
Problembehandlung
Der Kern des Upgradeprozesses dreht sich um den VDA Upgrade Agent-Dienst (ctxvua). Er fungiert als Vermittler, kommuniziert mit dem VDA-Upgradedienst und führt das Skript /opt/Citrix/VDA/sbin/update_helper.sh für betriebssystembezogene Vorgänge aus. Während des Upgrades werden Informationen zum Vorgang in der Registrierung gespeichert.
Registrierung
| Verwenden Sie den Befehl **/opt/Citrix/VDA/bin/ctxreg dump | grep -i UpdateAgent**, um die Registrierungseinstellungen im Zusammenhang mit dem VDA-Upgradeagent zu überprüfen. Dies kann auf Konfigurationsprobleme oder Probleme mit dem Upgradeprozess selbst hinweisen. |
- Konfiguration prüfen: Die Konfigurationsdatei für den ctxvua-Dienst befindet sich unter /etc/xdl/updateagent.conf. Durch die Überprüfung dieser Datei können Fehlkonfigurationen identifiziert werden.
Protokolle
Die folgenden Protokolldateien sind für die Fehlerbehebung von entscheidender Bedeutung:
-
/var/log/xdl/vua.log: Protokolldatei für den ctxvua-Dienst. Dies ist das primäre Protokoll zur Überprüfung auf Probleme im Zusammenhang mit dem Betrieb des Upgradeagents. Die Konfigurationsdatei für den Dienst ctxvua befindet sich unter /etc/xdl/updateagent.conf. Durch die Überprüfung dieser Datei können Fehlkonfigurationen identifiziert werden.
-
/var/log/xdl/update_helper.log: Protokolldatei für das Skript update_helper.sh. Dieses Protokoll ist für die Diagnose von Problemen im Zusammenhang mit Aufgaben auf Betriebssystemebene während des Upgrades von entscheidender Bedeutung.
Häufige Probleme
In diesem Abschnitt werden häufige Probleme behandelt, die bei VDA-Upgrades auftreten. Der Schwerpunkt liegt dabei auf deaktivierten Optionen in Studio und dem Status”„Upgrade unbekannt”.
Häufiges Problem 1: Deaktivierte Upgradeoptionen
Symptom: Die Optionen “Upgradetyp festlegen” und “VDAs aktualisieren” sind in Studio für einen bestimmten Katalog deaktiviert (ausgegraut).
Lösung: Überprüfen Sie, ob der VDA-Upgradedienst für den von Ihnen verwendeten Katalogtyp unterstützt wird. Wenn dies nicht der Fall ist, können Sie diese automatischen Upgradefeatures nicht verwenden und müssen die Upgrades manuell verwalten.
Häufiges Problem 2: Status “Upgrade unbekannt”
Symptom: Nach der Aktivierung des VDA-Upgradedienstes für einen Maschinenkatalog bleibt der Upgradestatus “Unbekannt”, anstatt sich wie erwartet in “Verfügbar” oder “Aktuell” zu ändern. “Upgrade unbekannt” ist ein vorübergehender Zustand. Es sollte schließlich entweder auf “Verfügbar” oder “Aktuell” aktualisiert werden.
Schritte zur Fehlerbehebung für “Upgrade unbekannt”:
-
Überprüfen Sie, ob der VDA-Upgradeagent Versionen meldet.
-
Schritt 1a: Holen Sie sich die UUID der Maschine:
Get-BrokerMachine -DNSName '<hostname>' <!--NeedCopy--> -
Schritt 1b: Überprüfen Sie die vom Agenten gemeldete Komponentenversion:
Get-VusComponentVersion -MachineId "<UUID>" <!--NeedCopy-->Wenn der Befehl Get-VusComponentVersion leer ist, bedeutet dies, dass der VDA-Upgradeagent seine Version nicht gemeldet hat. Dies könnte darauf hinweisen, dass der VDA “hart registriert” ist (überprüfen Sie sowohl den Maschinenkatalog als auch die Bereitstellungsgruppeneinstellungen). Es weist auch darauf hin, dass der VDA-Upgradeagent möglicherweise nicht auf dem Ziel-VDA installiert ist oder nicht ausgeführt wird.
-
-
Überprüfen Sie die Synchronisierung des VDA-Upgradedienstes.
Schritt 2a: Überprüfen Sie, ob der VDA-Upgradedienst die Maschine aus der Brokerdatenbank synchronisiert hat:
``` Get-VusEntityUnit -EntityUUID "" <!--NeedCopy--> ```Ersetzen Sie
""durch die tatsächliche EntityUUID, falls bekannt, oder führen Sie es ohne aus, um alles zu erhalten. Wenn Sie feststellen, dass dieses Feld leer ist, kann dies darauf hinweisen, dass die Maschine nicht mit dem VDA-Upgradedienstserver synchronisiert wurde.Schritt 2b: Wenn die Maschine nicht synchronisiert wurde, warten Sie etwas, bis der VDA-Upgradedienst die Synchronisierung durchgeführt hat. Bestätigen Sie anschließend, dass der “Upgradetyp” festgelegt wurde.