18.01.2017

Citrix XenApp/XenDesktop 7.12 – Der Local Host Cache ist zurück

Lange hat es gedauert, aber mit der XenApp/XenDesktop-Version 7.12 wurde nun endlich der aus den Vorgängerversionen bekannte Local Host Cache wieder eingeführt. Dieser ermöglicht im Falle eines Datenbankausfalls einen nahezu unterbrechungsfreien Betrieb der eigenen Umgebung.

Mit dem Wechsel von der Independent-Management-Architektur (IMA) auf die Flexcast-Management-Architektur (FMA) sind viele nützliche Features weggefallen, wurden jedoch nach und nach wieder in das neue Produkt aufgenommen. Dies ist verständlich, da der Umstieg auf eine komplett neue Architektur enormen Aufwand bedeutet und schließlich wollte man alles besser machen als zuvor. 

Datenbanken – das Herzstück der Infrastruktur

Die Datenbank einer XenApp/XenDesktop-Umgebung ist das Herzstück der Infrastruktur. In dieser werden alle Site-Informationen, wie z.B. Maschinenkataloge, Bereitstellungsgruppen, Applikationen und Policies, gespeichert. Auch Verbindungsdaten und Informationen über die Auslastung sowie der Zustand der Worker-Systeme werden in die Datenbank geschrieben. Fällt nun die Datenbank aus, verweigern somit die Delivery Controllers den Betrieb und Neuanmeldungen werden abgelehnt. Bereits verbundene Sitzungen sind davon nicht betroffen, Wiederverbindungen allerdings schon.

Bei der Einführung von XenDesktop 7.0 gab es keinerlei Puffer dieser Informationen beim Ausfall der Datenbank. Seitdem auch nur noch SQL Server als Datenbank in Frage kommt, nannte Citrix als Best Practice einen SQL-Mirror oder einen SQL-Cluster. Die meisten Kunden verzichteten trotz des Risikos auf eine Redundanz ihrer Datenbank, da die Mehrkosten für den Aufbau für die wenigsten in Frage kam. Da die neue Flexcast-Management-Architektur in der ersten Version bereits ihre Zuverlässigkeit bewiesen hatte, gab es in diesem Zusammenhang keine nennenswerten Probleme bei unseren Kunden. Dennoch blieb der Betrieb eines einzelnen, nicht redundanten SQL-Servers immer ein Single Point of Failure.

Mit dem Release von XenApp/XenDesktop 7.6 stellte Citrix das Feature „Connection Leasing“ vor. Dem Unternehmen war bewusst, dass sie hier an einer Lösung arbeiten mussten, da es sehr viele Kundenstimmen gab, die nach erhöhter Ausfallsicherheit verlangten.

Funktionsweise Connection Leasing

Beim klassischen Verbindungsaufbau kontaktiert der Benutzer den StoreFront-Server und meldet sich dort an (1). Die Daten werden an den Delivery Controller weitergegeben (2). Der Benutzer wird authentifiziert und alle verfügbaren Applikationen und Desktops in der Site-Datenbank werden ermittelt (3). Anschließend erhält der User die Antwort via ICA-File und die Session wird aufgebaut (4).

Während des normalen Verbindungsaufbaus werden die Verbindungsdaten bzw. Informationen der Site-Datenbank in ein XML-File geschrieben. Dort werden alle verfügbaren Ressourcen für 14 Tage gespeichert. Beim Ausfall der Site-Datenbank sieht der Verbindungsaufbau wie folgt aus.

Der Benutzer kontaktiert den StoreFront-Server und meldet sich dort an (1). Die Daten werden an den Delivery Controller weitergegeben (2). Der Benutzer wird authentifiziert und der Controller greift bei Nichterreichen der Site-Datenbank auf sein lokales XML-File zu (3). Anschließend erhält der User im Idealfall die Antwort via ICA-File und die Session kann aufgebaut werden (4).

Auf den ersten Blick sieht das Feature vielversprechend aus. Für die meisten Fälle sollte diese Funktion auch ausreichen, um eine Downtime der Datenbank überbrücken zu können. Dennoch gibt es einige Einschränkungen:

  • Das Citrix Studio und der Director können beim Ausfall der Site-Datenbank nicht genutzt werden. Dies gilt auch für PowerShell-Befehle.
  • Connection Leasing funktioniert nur mit über XenApp veröffentlichten Applikationen oder Desktops und statischen Desktopbetriebssystemen (keine pooled Desktops).
  • Benutzer können nicht zwischen mehreren Arbeitsplätzen wechseln und dann die Sitzung übernehmen. Sie müssen sich neu anmelden und die Applikation manuell starten.
  • Keine Lastauswertung bzw. Lastverteilung verfügbar. Die Verbindungen werden statisch aufgebaut, da im XML-File nur erfolgreiche Verbindungen der letzten 14 Tage gespeichert werden und darauf zurückgegriffen wird.
  • Neue Benutzer oder Ressourcen, welche in den letzten 14 Tagen nicht verwendet wurden, stehen nicht im XML-File und können somit nicht geöffnet werden.
  • Ausgeschaltete Maschinen werden nicht erkannt oder automatisch hochgefahren, da das XML-File nur den letzten Zustand der Maschinen beinhaltet. Auch dies verhindert einen sauberen Verbindungsaufbau.

Im Dezember 2016 erschien die Version 7.12 von XenApp/XenDesktop. Zu den größten Neuerungen gehörte nun endlich der Local Host Cache (LHC). Citrix erwähnt hierbei, dass es sich um die erste Phase des Local Host Cache handelt und somit noch nicht das Ende der Entwicklung erreicht wurde. Im ersten Schritt wird nach und nach das Connection Leasing durch einen neuen Mechanismus ersetzt, welcher als Basis für die zukünftige Weiterentwicklung dienen soll. Dies wird deutlich, wenn man sich die Einschränkungen bei der Nutzung des Local Host Cache ansieht. Doch erst einmal etwas zur Funktionsweise des LHC.

Für die Local-Host-Cache-Funktion gibt es ab Version 7.12 nun zwei zusätzliche Dienste. Der eigentliche Broker Service ist nach wie vor für die Registrierung der VDA-Agents auf den XenApp- und XenDesktop-Maschinen zuständig. Fällt die Datenbank aus, werden alle Agents über den High Availability Service registriert. Der Configuration Sync Service sorgt für die Synchronisation zwischen der SQL-Datenbank und der lokalen Datenbank.

Configuration Sync Service

Der Configuration Sync Service gleicht sich regelmäßig mit der SQL-Datenbank ab. Sobald eine Änderung an der Site-Datenbank erkannt wurde, kopiert der Sync Service die Datenbank auf den Controller. Dies macht jeder Controller für sich. Die alte, lokal vorgehaltene Datenbank wird erst dann gelöscht, wenn die neue erfolgreich importiert und aktiv geschaltet wurde. Fällt die Datenbank während der Synchronisation aus, wird der gerade laufende Vorgang verworfen und die alte Kopie der Datenbank beibehalten.

High Availability Service

Neben der VDA-Registrierung bei Ausfall der Datenbank wählt der High-Availability-Dienst einen Controller als aktiven Controller aus, vorausgesetzt es befinden sich mindestens zwei Controller innerhalb der Site. Somit gibt es während der Downtime des SQL-Servers nur einen verfügbaren Controller, an dem sich alle VDA-Agents neu registrieren müssen. Eng wird es hier ab etwa 5.000 Registrierungen. Dieser Wert wurde von Citrix getestet und als Grenze für einen einzelnen Controller definiert. Der Zugriff auf die kopierte Datenbank ist nur im schreibgeschützten Modus möglich. Fällt während der Ausfallzeit der Datenbank einer der Controller aus, ernennt der High Availability Service einen neuen aktiven Controller, ähnlich wie damals bei den Zone Data Collectors unter der IMA-Architektur.

Der wesentliche Unterschied besteht im technischen Aufbau sowie in der Nutzung einer echten Datenbank gegenüber einem simplen XML-File. Die Einschränkungen in der Phase 1 des Local Host Cache sind sehr ähnlich wie beim Connection Leasing. Dennoch bietet die erste Version schon jetzt mehr als das alte Feature. Wir können zudem zuversichtlich sein, dass hier von Citrix in den nächsten Releases noch mehr angepasst wird.

  • Das Citrix Studio und PowerShell-Befehle können nicht genutzt werden.
  • Aktuell nur für veröffentlichte Anwendungen und Desktops via XenApp und statische Maschinen mit XenDesktop nutzbar.
  • Ausgeschaltete Maschinen werden nicht erkannt oder automatisch hochgefahren.
  • Benutzer können unter Umständen mehr Applikationen oder Desktops starten als erlaubt, obwohl Sitzungslimits definiert wurden, wenn der Benutzer Ressourcen aus verschiedenen Zonen abruft.

Wichtige Hinweise

Der Local Host Cache ist standardmäßig nicht aktiviert. Das Connection Leasing wird beim Upgrade oder bei einer Neuinstallation automatisch verwendet. Mit dem unten genannten Befehl deaktiviert man das Connection Leasing und aktiviert gleichzeitig den Local Host Cache via PowerShell:

Set-BrokerSite -LocalHostCacheEnabled $true -ConnectionLeasingEnabled $false

Möchte man einen Ausfall simulieren oder testen, kann man den LHC-Modus via Registry erzwingen:

HKLM\Software\Citrix\DesktopServer\LHC - den Wert OutageModeForced auf 1 setzen

Außerdem sollte man beachten, dass die Nutzung des LHC mehr Ressourcen am Controller benötigt. Der LHC kann unter Umständen mehr als 1 GB zusätzlichen Arbeitsspeicher benötigen.

Florian Scheler
Senior Consultant

Unsere Blogs