XenApp / XenDesktop 7.12 Local Host Cache

Welcome Back - Local Host Cache

XenApp / XenDesktop 7.12 Local Host Cache

Am 07.12.2016 wurde das neue XenApp / XenDesktop Release 7.12 zum Download bereitgestellt.

Neu in dem Release ist die Rückkehr des Citrix Local Host Cache.

Was bedeutet der Local Host Cache in XenApp / XenDesktop 7:

Der Local Host Cache (LHC) lässt Brokering Operationen in der Citrix XenApp / XenDesktop Umgebung ohne Datenbank zu.
Das bedeutet das Benutzer sich anmelden können, sofern es zu einem Datenbankausfall kommen sollte.

LHC wird genutzt, wenn folgende Szenarien auftreten:

  • Die Verbindung zur Datenbank von einem Delivery Controller und der Site Datenbank geht verloren in einer on Premise Umgebung.
  • Der WAN Link zwischen der Site und der Controlplane in der Cloud geht verloren.

Der Local Host Cache kann den bisher eingesetzten Connection Leasing Mode, der mit XenApp 7.6 Released wurde, ersetzen.

Wie funktioniert nun der neu entwickelte Local Host Cache auf XenApp / XenDesktop 7.12

lhc-normal

 

 

 

 

 

 

Normale Operationen ohne Failover

  • Der Broker Services auf einem Controller akzeptiert Verbindungen von einem Storefrontserver und kommuniziert mit der Site Datenbank, um die Benutzer mit den Least Loaded VDAs zu verbinden die bei dem Controller registriert wurden.
  • Alle 2 Minuten wird die Verbindung zur Site Datenbank geprüft auf Änderungen in der Datenbank
  • Fanden Änderungen der Konfiguration statt, dann werden die über den Citrix Config Synchronizer Dienst (CSS) Synchronisiert mit dem zweiten Delivery Controller der Site.
    Der zweite Delivery Controller erhält die Änderungen und kopiert diese Daten über den Citrix High Availability Service in die Microsoft MS SQL Express Local DB (LHC DB) auf dem Controller. Der Citrix Config Synchronizer Service vergleicht dann die Daten der Site Datenbank mit den Daten in der Local DB des Secondary Brokers. Die Local DB wird mit jeder Synchronisation neu aufgebaut.
  • Fanden keine Änderungen statt seit dem letzten Check, werden auch keine Daten kopiert.

Kommunikationswege, wenn ein Outage (Datenbankverlust) des Principal Brokers beginnt:

lhc-outage

Bei Datenbankverlust:

  • Der Prinicipal Broker kann nicht länger mit der Datenbank kommunizieren. Sofern die Datenbank nicht mehr erreichbar ist, stoppt der Prinicpal Broker die Verbindung zum Storefrontservice und zu den VDAs. Der Principal Broker initiiert über den High Availability Service den Secondary Broker die Verbindungen aufzubauen und die Verbindungsversuche der Benutzer anzunehmen.
  • When ein Outage beginnt, dann hat der Secondary Broker keine aktuellen VDA Registrierungsdaten und triggert die VDAs an sich zu neu zu Registrieren.
    Über diesen Prozess erhält der Secondary Broker auch die Informationen über die aktuellen Sessioninformationen der VDAs.
  • Während nun der Secondary Broker die Sessions mit Hilfe des LHC bedient, versucht der Principal Broker die Site Datenbank wieder zu erreichen.
    Sobald die Verbindung zur Site Datenbank wieder aufgebaut wurde wird vom Principal Broker aus initiiert, das der Secondary Broker keine Verbindungen mehr annehmen darf und der Secondary Broker stoppt die Annahme von Verbindungen zu ihm. Beim nächsten Versuch des VDA den Principal Broker zu erreichen, wird eine Neu Registrierung angetriggert und der Secondary Broker löscht jede VDA Registrierung aus der LHC DB. Diese Aufforderung erhält der Secondary Broker über den Citrix Config Synchronizer Service, der dafür sorgt das die Local DB neu Synchronisiert wird.

Sollte in dem Fall das eine Outage beginnt, wenn gerade eine Synchronisation ansteht, wird die Synchronisation abgebrochen und die letzte bekannte Konfiguration wird genutzt.

Ein Outage und jegliche Operation wird im Eventlog gemonitort.

Besonderheiten des Local Host Cache:

Der Local Host Cache ist supportet in folgenden Umgebungen:

  • Server Hosted Applications and Desktops ( XenApp)
  • Static Assigned Desktops

Der Local Host Cache ist nicht Supportet in folgenden Umgebungen:

  • Pooled VDI Desktops and Server created with MCS or PVS

 

Was funktioniert nicht während eines Datenbankverlustes (Outage):

  • Consoleoperationen im Studio sind nicht möglich
  • Powershell cmdlets können nicht ausgeführt werden
  • Hypervisor Anmeldedaten können nicht verifiziert werden, die Maschinen stehen alle in einem unbekannten „Power-State“. Automatische Ein- und Ausschaltfunktionen zu den Desktops nach Abmeldung oder bei Anmeldung können nicht ausgeführt werden.
  • Anonymous Sessions können nicht aufgebaut werden
  • Eine zugewiesene Maschine kann nur genutzt werden, wenn die Zuweisung vor dem Outage im „Normalen Modus“ durchgeführt wurde.

Was ist zu beachten:

  • Ramsize
    • Der LocalDB Service kann ungefähr 1,2 GB RAM benutzen ( bis zu 1GB für den DB Cache und 200MB für den Service)
    • Der High Availability Service kann bis zu 1GB RAM benutzen (Bei einem extrem Ausfall über längeren Zeitraum mit vielen Anmeldungen (bsp.: 12 Stunden Aufall und 10.000 Anmeldungen))
    • Diese Anforderungen kommen zu der normalen RAM Anforderung eines Delivery Controllers dazu und sollten beim Planen berücksichtigt werden.
  • CPU Core and Socket Configuration
    • Die Local DB kann mehrere Cores verwenden (bis zu 4 Cores), ist aber limitiert auf einen Socket.
    • Mehrere Sockets werden die Performance nicht verbessern
    • Konfigurationsempfehlung von Citrix ist, den Servern eine CPU Konfiguration 2×4 zuzuordnen ( 2 Sockets – 4Cores). Diese Konfiguration ist performanter als eine 4×1 oder 6×1 Konfiguration.
  • SQL Server Express Local DB
    • Die MS SQL Express Local DB wird automatisch mitinstalliert bei der Installation eines Controllers oder beim Upgrade eines Controllers. Nur der Secondary Broker kommuniziert mit der Local DB, es ist nicht vorgesehen das die Datenbank per Powershell konfigurierbar ist.
      Die SQL Datenbank kann nicht über die Controller verteilt werden.
    • Die MS SQL Express Local DB wird immer installiert, egal ob der local Host Cache genutzt werden soll.

Standardeinstellungen nach Installation oder Upgrade XenApp / XenDesktop

Standardmäßig ist nach der Installation von XenApp / XenDesktop der Local Host Cache deaktiviert und Connection Leasing ist aktiviert.

Die folgende Tabelle zeigt die Einstellungen des Local Host Cache bei Neuinstallation oder nach Upgrade.

Operation Number of VDAs Connection leasing before operation Local Host Cache after operation Connection leasing  after operation
Install any Disabled Enabled
Upgrade < 5K Enabled Disabled Enabled
Upgrade < 5K Disabled Enabled Disabled
Upgrade > 5K Enabled Disabled Enabled
Upgrade > 5K Disabled Disabled Disabled