Citrix Cloud Resilienz Teil 1 – Local Host Cache

Citrix drückt auf die Tube. Nicht erst seit der Veröffentlichung der erweiterten Partnerschaft zwischen Citrix und Microsoft ist klar, wohin die Reise aus Citrix Sicht gehen soll. Nämlich in die Cloud!! (Wohin auch sonst)

Wenn man sich dafür entscheidet, der Citrix Empfehlung zu folgen, dann sollte man sich über einige Dinge Gedanken machen.

Was passiert, wenn ich die Citrix Cloud aus irgendwelchen Gründen nicht erreichen kann? Sei es durch ein Problem mit der eigenen Internetverbindung, oder auch eine Störung auf Citrix Seite.

Ein Feature, das bei einem solchen Szenario unter Umständen helfen kann ist der Local Host Cache auf den Cloud Connectoren.

Aktiviert wird das Feature, wenn der Cloud Connector für 60 Sekunden nicht mit der Cloud kommunizieren kann. Jeder Cloud Connector hält dafür in einer lokalen SQL Express Datenbank einen Teil der zentralen Datenbank aus der Cloud.

Folgende Informationen sind hauptsächlich darin enthalten:

• Benutzer und Gruppen mit Rechten auf veröffentlichte Ressourcen
• Benutzer die Ressourcen momentan verwenden oder verwendet haben
• Namen und IP der VDA’s in der Site

Im Normalbetrieb wird der aktuelle Stand minütlich durch den „Citrix Config Sync Dienst“ auf dem Cloud Connector synchronisiert.

Während eines Ausfalls sind bestimmte Funktionen nicht verfügbar, allerdings ist es auch nicht empfehlenswert während eines Ausfalls Änderungen vorzunehmen:

• Citrix Studio kann nicht verwendet werden
• Eingeschränkter Powershell Zugriff
• Kein Power Management der VM’s
  • Momentan in TP Tech Preview: Power operations during Local Host Cache (LHC) mode | Citrix Blogs
• Keine Neuzuweisungen von Usern zu VDA’s

Ein fast normales Weiterarbeiten ist mit dieser Lösung auf Serverbasierten veröffentlichten Anwendungen und Desktops, sowie auf statisch zugewiesenen Desktops möglich

VDI Umgebungen mit gepoolten Maschinen können per Default während einem Ausfall nicht verwendet werden, da sie sich im Wartungsmodus befinden. Das liegt an der Standardkonfiguration „ShutdowndesktopafterUse“ bei einer solchen Bereitstellungsgruppe. Dieser Shutdown kann durch fehlendes Power Management nicht durchgeführt werden -> Daher Wartungsmodus!!

Wenn ich schreibe „Standardverhalten“, dann bedeutet das auch, dass man das anpassen kann. Zunächst muss man folgenden Befehl absetzen:

Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true

Damit wird verhindert, dass gepoolte VDI Maschinen nach der Abmeldung eines Users heruntergefahren werden. Somit stehen Sie für die Anmeldung eines anderen Users bereit. Wie man dem Befehl entnehmen kann, gilt das nur während des Ausfalls. Im Normalbetrieb werden die Maschinen nach Benutzung wieder heruntergefahren.

Setzt man im Anschluss noch folgenden Befehl ab, so sind zukünftig angelegt Bereitstellungsgruppen direkt dafür aktiviert:

Set-BrokerSite -DefaultReuseMachinesWithoutShutdownInOutage $true

Bereits existierende Bereitstellungsgruppen müssen einzeln mit folgendem Befehl aktiviert werden.

Set-BrokerDesktopGroup -Name „name“ -ReuseMachinesWithoutShutdownInOutage $true

Ausfall testen:

Es ist möglich einen Ausfall und den Einsatz von Local Host Cache zu simulieren. Dafür muss auf allen Cloud Connectoren der Site ein Regkey gesetzt werden:

HKLM\Software\Citrix\DesktopServer\LHC

OutageModeForced (REG_DWORD) = 1

Nach dem Test nicht vergessen den Wert auf 0 zu setzen.

Nachteile:

Die Nutzung von Local Host Cache erfordert On-Premise Ressourcen beim Kunden. Es muss ein Storefront Server für interne Verbindungen sowie ein Citrix Gateway für externe Verbindungen vorhanden sein.

Auch verliert man dadurch die wirklich schöne Workspace Experience aus der Cloud

Empfehlung:

Speziell Kunden aus dem produzierenden Gewerbe oder aus dem Healthcare Sektor haben einen hohen Anteil an internen Benutzern. Hier ist es extrem wichtig, die Auswirkungen einer Störung der Cloud Control Plane oder der Kommunikation damit so gering wie möglich zu halten. Local Host Cache hilft hier dabei im Fall der Fälle weiterhin einsatzfähig zu sein.

In Teil 2 reden wir dann über eine andere Möglichkeit während einer Störung bestmöglich weiterzuarbeiten