VDA-Upgrades (Vorschau)
Einführung
-
Bisher erforderte die Aktualisierung von VDAs einen vollständig manuellen Eingriff. Version 2503 vereinfacht VDA-Upgrades für DaaS-Bereitstellungen durch die Einführung des VDA Upgrade Agent. Upgrades ab Version 2503 können später direkt von einem freigegebenen oder lokalen Dateipfad aus durchgeführt werden.
-
Der VDA Upgrade Agent ctxvua ist für die Kommunikation mit dem VDA Upgrade Service und die Ausführung der folgenden Funktionen verantwortlich:
- Geplante Prüfungen: Der VDA Upgrade Agent fragt den VDA Upgrade Service alle 15 Minuten nach Informationen zu geplanten Upgrades ab.
- Automatisierte Upgrades: Nach Erhalt von Upgrade-Anweisungen aktualisiert der VDA Upgrade Agent den VDA automatisch.
- Statusberichte: Der VDA Upgrade Agent meldet das Upgrade-Ergebnis (Erfolg oder Fehler) an den VDA Upgrade Service zurück.
Weitere Informationen zum VDA Upgrade Service finden Sie unter Tech Brief: Citrix VDA Upgrade Service. Dort finden Sie eine Übersicht über den Dienst, detaillierte Informationen zur Funktionsweise und weitere nützliche Ressourcen.
Überlegungen
-
Linux-VDAs werden mithilfe zugrunde liegender Paketverwaltungsbefehle (wie rpm oder apt) aktualisiert, was den manuellen Upgrade-Prozess widerspiegelt; Konfigurationsdateien werden während des Befehlszeilen-Upgrades automatisch verarbeitet.
-
Im Gegensatz zu Windows enthält der Linux-VDA einen integrierten VDA Upgrade Agent. Dies vereinfacht den Upgrade-Prozess, da der Agent bereits vorhanden ist. Die Version des VDA Upgrade Agent ist an die VDA-Version gebunden.
-
Standardmäßig ist der VDA Upgrade Agent 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 Best Practice empfehlen wir Ihnen, VDA-Upgrades gründlich zu testen, bevor Sie sie in die Produktion übernehmen.
-
Im Gegensatz zu Windows werden Linux-VDA-Upgrades nur über einen Dateipfad unterstützt. Das bedeutet, dass Sie Azure CDN-URLs oder andere Online-Repositorys nicht direkt verwenden können. Sie müssen die VDA-Pakete selbst verwalten. Dies gilt sowohl für Haupt- als auch für Nebenversions-Upgrades.
-
Ignorieren Sie “Latest VDA Version” und “Upgrade State” im VDA Upgrade Service. Nur der “VDA Upgrade State” ist für Linux 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 gemounteten Netzwerkfreigabe) liegen. Das System ist nicht dafür ausgelegt, das Paket automatisch herunterzuladen. Sie müssen die vollständige Paketdatei bereitstellen.
-
Geben Sie den Pfad im Windows-UNC-Pfadformat (beginnend mit \\) an, um die Pfadvalidierung bei der Verwendung von Studio oder dem Citrix DaaS Remote PowerShell SDK zu bestehen. Zum Beispiel muss /mnt/pkg\/<package-name> als \\mnt\pkg\<package-name> eingegeben werden.
-
Die Unterscheidung zwischen “Server”- und “Workstation”-VDAs trifft auf Linux nicht zu. Sie können beide Optionen in Studio oder PowerShell verwenden, ohne das Upgrade zu beeinträchtigen.
-
Ein 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.
- Die VDAs müssen den VDA Upgrade Agent installiert haben und der Dienst muss ausgeführt werden.
- Sie verfügen über die Berechtigungen zum Upgrade von VDAs.
- Das VDA-Upgrade ist mit dem entsprechenden CR- oder LTSR-Track in Studio konfiguriert.
- Die VDAs sind nicht in Gebrauch. (Benutzer müssen sich von ihnen abmelden.)
- Die VDAs befinden sich 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ässige Anzahl von Registrierungsversuchen ü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 VDA.
VDAs mit Studio aktualisieren
Allgemeiner Workflow
Ein allgemeiner Workflow zum Upgrade von VDAs mit Studio ist wie folgt:
-
Aktivieren Sie das VDA-Upgrade für einen Katalog.
- Sie können das VDA-Upgrade beim Erstellen eines Katalogs aktivieren.
- Sie können das VDA-Upgrade beim Bearbeiten eines Katalogs aktivieren.
-
Führen Sie VDA-Upgrades katalogweise durch. 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 sind alle Maschinen im Katalog im Upgrade-Umfang enthalten. Daher empfehlen wir, diese Maschinen vor dem Start des Upgrades zu sichern.
-
- Der VDA-Upgrade-Prozess unterstützt weder das Upgrade zusätzlicher Komponenten noch die Verwendung von Funktionen wie der Wiederherstellung. Überspringen Sie diese beiden Schritte.
-
Konfigurieren Sie die Planungsoptionen, einschließlich der Upgrade-Zeit und des Schwellenwerts für Upgrade-Fehler. 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” für den Speicherort des VDA-Installationsprogramms. Geben Sie den Pfad im Windows-UNC-Format an (z. B. \\server\share\path).
-
Die Option “Sitzungen abmelden 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 Upgrade Service initiiert die Abmeldung, nachdem der VDA Upgrade Agent versucht hat, den Upgrade-Zeitplan 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.
Die folgenden PowerShell-Cmdlets sind verfügbar:
-
Get-VusCatalog
Verwenden Sie dieses Cmdlet, um Details eines Katalogs abzurufen, wie z. B. 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 einer Maschine abzurufen, wie z. B. MachineName, Uid, Uuid, UpgradeState (Verfügbar, Aktuell, Geplant, Unbekannt) 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-->
Fehlerbehebung
Der Kern des Upgrade-Prozesses dreht sich um den VDA Upgrade Agent-Dienst (ctxvua). Er fungiert als Vermittler, kommuniziert mit dem VDA Upgrade Service und führt das Skript /opt/Citrix/VDA/sbin/update_helper.sh für OS-bezogene Operationen aus. Während des Upgrades werden Informationen über den Prozess 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 Upgrade Agent zu überprüfen. Dies kann Konfigurationsprobleme oder Probleme mit dem Upgrade-Prozess selbst aufdecken. |
- Konfiguration prüfen: Die Konfigurationsdatei für den Dienst ctxvua befindet sich unter /etc/xdl/updateagent.conf. Die Überprüfung dieser Datei kann helfen, Fehlkonfigurationen zu identifizieren.
Protokolle
Die folgenden Protokolldateien sind für die Fehlerbehebung entscheidend:
-
/var/log/xdl/vua.log: Protokolldatei für den Dienst ctxvua. Dies ist das primäre Protokoll zur Überprüfung von Problemen im Zusammenhang mit dem Betrieb des Upgrade-Agenten. Die Konfigurationsdatei für den Dienst ctxvua befindet sich unter /etc/xdl/updateagent.conf. Die Überprüfung dieser Datei kann helfen, Fehlkonfigurationen zu identifizieren.
-
/var/log/xdl/update_helper.log: Protokolldatei für das Skript update_helper.sh. Dieses Protokoll ist unerlässlich für die Diagnose von Problemen im Zusammenhang mit OS-Ebene-Aufgaben während des Upgrades.
Häufige Probleme
Dieser Abschnitt behandelt häufige Probleme, die bei VDA-Upgrades auftreten, insbesondere die deaktivierten Optionen in Studio und den Status “Upgrade unbekannt”.
Häufiges Problem 1: Deaktivierte Upgrade-Optionen
Symptom: Die Optionen “Upgradetyp festlegen” und “VDAs upgraden” sind in Studio für einen bestimmten Katalog deaktiviert (ausgegraut).
Lösung: Überprüfen Sie, ob der VDA Upgrade Service für den von Ihnen verwendeten Katalogtyp unterstützt wird. Ist dies nicht der Fall, können Sie diese automatisierten Upgrade-Funktionen nicht nutzen und müssen Upgrades manuell verwalten.
Häufiges Problem 2: Status “Upgrade unbekannt”
Symptom: Nach der Aktivierung des VDA Upgrade Service für einen Maschinenkatalog bleibt der “Upgrade-Status” “Unbekannt”, anstatt wie erwartet zu “Verfügbar” oder “Aktuell” zu wechseln. “Upgrade unbekannt” ist ein transienter Status. Er sollte sich schließlich auf “Verfügbar” oder “Aktuell” aktualisieren.
Schritte zur Fehlerbehebung für “Upgrade unbekannt”:
-
Überprüfen Sie, ob der VDA Upgrade Agent Versionen meldet.
-
Schritt 1a: Rufen Sie die UUID der Maschine ab:
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 zurückgibt, bedeutet dies, dass der VDA Upgrade Agent seine Version nicht gemeldet hat. Dies könnte darauf hindeuten, dass der VDA “hart registriert” ist (überprüfen Sie sowohl die Einstellungen des Maschinenkatalogs als auch der Bereitstellungsgruppe). Es deutet auch darauf hin, dass der VDA Upgrade Agent möglicherweise nicht auf dem Ziel-VDA installiert oder ausgeführt wird.
-
-
Überprüfen Sie die Synchronisierung des VDA Upgrade Service.
Schritt 2a: Überprüfen Sie, ob der VDA Upgrade Service die Maschine aus der Broker-Datenbank synchronisiert hat:
``` Get-VusEntityUnit -EntityUUID "" <!--NeedCopy--> ```Ersetzen Sie
""durch die tatsächliche EntityUUID, falls bekannt, oder führen Sie den Befehl ohne aus, um alle abzurufen. Wenn Sie feststellen, dass dies leer ist, kann dies darauf hindeuten, dass die Maschine nicht mit dem VDA Upgrade Service-Server synchronisiert wurde.Schritt 2b: Wenn die Maschine nicht synchronisiert wurde, geben Sie dem VDA Upgrade Service etwas Zeit zur Synchronisierung. Bestätigen Sie dann, dass der “Upgradetyp” festgelegt wurde.