VDA-Upgrades (Vorschau)

Einführung

Bisher erforderte das Upgrade 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 geplanten Upgrade-Informationen ab.
• Automatisierte Upgrades: Nach Erhalt von Upgrade-Anweisungen aktualisiert der VDA Upgrade Agent den VDA automatisch.
• Statusberichterstattung: 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 von einem Dateipfad aus 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 “Neueste VDA-Version” und “Upgrade-Status” im VDA-Upgrade-Dienst. Nur der “VDA-Upgrade-Status” ist für Linux relevant.

• Der Dateipfad für das VDA-Paket kann lokal auf der VDA-Maschine liegen oder an einem freigegebenen Speicherort (z. B. eine auf dem VDA bereitgestellte Netzwerkfreigabe). 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 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 gilt nicht für Linux. Sie können beide Optionen in Studio oder PowerShell verwenden, ohne das Upgrade zu beeinträchtigen.

• 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.

• Die VDAs müssen den VDA-Upgrade-Agent installiert haben und der Dienst muss ausgeführt werden.
• Sie haben 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 die maximal zulässige Anzahl von Registrierungsversuchen überschritten wurde.)
• Die VDAs müssen zu einer Bereitstellungsgruppe gehören und bei DaaS registriert sein.
• Der Ziel-VDA unterstützt das Betriebssystem des aktuellen VDAs.

VDAs mit Studio aktualisieren

Allgemeiner Workflow

Ein allgemeiner Workflow zum Aktualisieren von VDAs mit Studio ist wie folgt:

1. VDA-Upgrade für einen Katalog aktivieren.

   • Sie können das VDA-Upgrade beim Erstellen eines Katalogs aktivieren.
   • Sie können das VDA-Upgrade beim Bearbeiten eines Katalogs aktivieren.

2. Aktualisieren Sie VDAs katalogweise. 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.

3. 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.

4. 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.

5. Wählen Sie „Lokale Dateifreigabe verwenden“ für den Speicherort des VDA-Installers. Geben Sie den Pfad im Windows UNC-Format an (z. B. \\server\share\path).

6. 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-Dienst initiiert die Abmeldung, nachdem der VDA-Upgrade-Agent versucht hat, den Upgrade-Zeitplan abzufragen und getrennte Sitzungen gefunden hat. Der Agent wartet dann 15 Minuten, bevor er die Abfrage wiederholt.

VDAs mit PowerShell upgraden

Sie können VDA-Upgrades mithilfe des Remote PowerShell SDK unter Windows konfigurieren. Weitere Informationen zum Remote PowerShell SDK finden Sie unter Citrix DaaS Remote PowerShell SDK.

Dies sind die PowerShell-Cmdlets:

• Get-VusCatalog

  Verwenden Sie dieses Cmdlet, um Details eines Katalogs abzurufen, wie z. B. Name, Uid, Uuid, UpgradeState (Available, UpToDate, Scheduled, Unknown), Upgrade scheduled und StateId (Status von Upgrade scheduled).

• Get-VusMachine

  Verwenden Sie dieses Cmdlet, um Details einer Maschine abzurufen, wie z. B. MachineName, Uid, Uuid, UpgradeState (Available, UpToDate, Scheduled, Unknown) und StateId (Status von Upgrade scheduled).

• 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

1. 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, das auf Probleme im Zusammenhang mit dem Betrieb des Upgrade-Agenten überprüft werden sollte. 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 Aufgaben auf Betriebssystemebene während des Upgrades.

Häufige Probleme

Dieser Abschnitt behandelt häufige Probleme, die bei VDA-Upgrades auftreten, wobei der Schwerpunkt auf deaktivierten Optionen in Studio und dem Status „Upgrade Unknown“ liegt.

Häufiges Problem 1: Deaktivierte Upgrade-Optionen

Symptom: Die Optionen „Set Upgrade Type“ und „Upgrade VDAs“ sind in Studio für einen bestimmten Katalog deaktiviert (ausgegraut).

Lösung: Prü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 Unknown“

Symptom: Nachdem der VDA Upgrade Service für einen Maschinenkatalog aktiviert wurde, bleibt der „Upgrade State“ auf „Unknown“ anstatt wie erwartet auf „Available“ oder „UpToDate“ zu wechseln. „Upgrade Unknown“ ist ein vorübergehender Zustand. Er sollte sich schließlich auf „Available“ oder „UpToDate“ aktualisieren.

Schritte zur Fehlerbehebung für „Upgrade unbekannt“:

1. Überprüfen Sie, ob der VDA-Upgrade-Agent Versionen meldet.

   • Schritt 1a: UUID des Computers abrufen:

        Get-BrokerMachine -DNSName '<hostname>'
      <!--NeedCopy-->
     

   • Schritt 1b: Überprüfen Sie die Komponentenversion, die vom Agenten gemeldet wird:

      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 weist auch darauf hin, dass der VDA-Upgrade-Agent möglicherweise nicht auf dem Ziel-VDA installiert oder ausgeführt wird.

2. Überprüfen Sie die Synchronisierung des VDA-Upgrade-Dienstes.

   Schritt 2a: Überprüfen Sie, ob der VDA-Upgrade-Dienst den Computer 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 Parameter aus, um alle abzurufen. Wenn Sie feststellen, dass dies leer ist, kann dies darauf hindeuten, dass der Computer nicht mit dem VDA-Upgrade-Dienstserver synchronisiert wurde.

   Schritt 2b: Wenn der Computer nicht synchronisiert wurde, geben Sie dem VDA-Upgrade-Dienst etwas Zeit zur Synchronisierung. Bestätigen Sie anschließend, dass der „Upgradetyp“ festgelegt wurde.

Referenzen

• Tech Brief: Citrix VDA-Upgradedienst
• VDAs aktualisieren