XenDesktop 7.x Datenbanken Best Practice

In diesem Blogartikel werden von Citrix empfohlene Szenarien für die Bereitstellung der hochverfügbaren Datenbanken beschrieben. Die beschriebenen Bereitstellungsoptionen entsprechen den aktuellen Citrix Best Practices aus dem letzten Citrix VDI Handbook - XenApp and XenDesktop 7.15 LTSR.

Hochverfügbarkeitslösungen für Citrix Datenbanken

Wir können die Hochverfügbarkeit der Citrix Datenbanken grob in zwei Arten unterteilen: interne (oder integrierte XenApp/XenDesktop-Funktionalität) und externe (in diesem Fall sprechen wir über die unterschiedlichen Methoden die SQL-Datenbanken ausfallsicher bereitzustellen).

Integrierten HA-Lösungen

Unter Interne Verfügbarkeit verstehe ich die Möglichkeit der Citrix Infrastruktur, nach einer Nichterreichbarkeit der Datenbanken die minimalen Basisfunktionen zu gewährleisten.

In diesem Fall handelt es sich um folgende zwei Methoden:

Connection Leasing - ermöglicht den Benutzern – eine Verbindung mit den zuletzt geöffneten Ressourcen (Published Application oder Published Desktop) herzustellen. Connection Leasing verwendet eine XML-Datei um die Verbindungsinformation zu speichern. Connection Leasing wird standardmäßig nicht mehr aktiviert und mit hoher Wahrscheinlichkeit bald nicht mehr existieren. Weitere Informationen können Sie in diesem Dokument finden: Design Considerations for XenDesktop 7.6 Connection Leasing White Paper | Download

Local Host Cache - ermöglicht die Zwischenspeicherung der Daten auf jedem Desktop Delivery Controller. Wenn die Site-Datenbank nicht mehr verfügbar ist, wird die Hauptfunktionalität (Anmelden/Abmelden von Benutzer) weiterhin gewährleistet. Die administrativen und Reporting-Funktionen sind nicht möglich. Local Host Cache basiert auf einer SQL Express LocalDB

Die beiden internen Lösungen bieten nur die rudimentäre Funktionalität, mit massiven Einschränkungen der Verwaltbarkeit.

SQL Hochverfügbarkeitslösungen

Die Wahl einer passenden HA-Lösung ist von vielen Faktoren abhängig. Wenn in Ihrer Umgebung eine bereits existierende SQL-Infrastruktur vorhanden ist, dann wäre es auch sinnvoll, diese zu verwenden. In einem anderen Fall spielen die Größe der geplanten Citrix Infrastruktur, die Kri­ti­ka­li­tät und das Budget eine wichtige Rolle.

Die folgende Tabelle beinhaltet alle möglichen Hochverfügbarkeitslösungen für Citrix Datenbanken:

Quelle: Citrix 

Möglicherweise ist diese Tabelle nicht mehr aktuell, hier können Sie die aktuelle Liste der Supporten Datenbanken finden: CTX114501 - Supported Databases for XenApp and XenDesktop Components

HA / Backup mit Hypervisor

Backups auf Hypervisor-Ebene: In einer kleinen Citrix Umgebung hat sich ein Backup auf Hypervisor-Ebene als eine ziemlich effiziente Methode erwiesen. In diesem Fall wird eine komplette virtuelle Maschine gesichert.

Hochverfügbarkeit auf VM-Ebene: Die andere Methode basiert auf der Cluster-Funktionalität eines Hypervisors. Die VM läuft dabei in einem Cluster. Bei Ausfall des einen Knotens wird die VM auf dem anderen gestartet.

Mit Hilfe der Backup-Software können die logischen Datenbanken einer Datenbankinstanz einzeln gesichert und wiederherstellt werden. 

Spiegelung (Mirroring)

Die Datenbankspiegelung bietet eine höhere Verfügbarkeit zu einem angemessenen Preis (Standard Edition).  Der Failover von der Prinzipal-DB zur Mirror-DB erfolgt völlig automatisch und für die Citrix User nicht sichtbar.

Die Umgebung besteht aus drei SQL-Servern: Prinzipal, Mirror und Witness (SQL Server Express). Der Witness-Server sorgt für den automatischen Failover, falls der Prinzipal-Server nicht mehr erreichbar ist. Nach einem Ausfall des Prinzipal-Servers übernimmt der Mirror-Server die Rolle eines Prinzipals.

Die Datenbankspiegelung kann in drei unterschiedlichen Modi laufen, wobei nur ein Modus von Citrix empfohlen wird (High Protection Mode, wird oft High Safety Mode genannt):

1.1. Der synchrone Hochsicherheitsmodus mit automatischem Failover. In diesem Modus werden die Transaktionen vom Prinzipal-Server an den Mirror-Server gesendet und der Prinzipal-Server wartet auf eine Bestätigung vom Mirror-Server, bevor die nächsten Transaktionen gesendet werden.

1.2. Der synchrone Hochsicherheitsmodus ohne automatischem Failover. Die zweite Option ist der ersten Option identisch, mit einem Unterschied, dass der Witness-Server nicht eingesetzt wird. Zum Umschwenken der Datenbanken wird der manuelle Failover benötigt.

2. Asynchronous Database Mirroring (High-Performance Mode) . Offizielle Microsoft Dokumentation zum Thema: Öffnen

3. Im dritten Modus werden Transaktionen vom Prinzipal-Server an den Mirror-Server gesendet, ohne auf die Bestätigung über den Erhalt der Transaktionen zu warten. In diesem Fall kann die Synchronität der Daten nicht mehr gewährleistet werden. Diese Option unterstützt nur einen erzwungenen Failover, wenn keine Verbindung zwischen den beiden SQL-Servern mehr besteht.

Obwohl SQL Mirroring aus Sicht von Microsoft als eine veraltete Funktion gilt, wird diese immer noch von Citrix empfohlen.

SQL Spiegelung zwischen den unterschiedlichen Versionen

Es wird oft gefragt, ob eine Spiegelung zwischen den unterschiedlichen SQL-Versionen zwecks Migration möglich ist. Die offizielle Antwort ist nein: For a mirroring session to be established, the partners and the witness, if any, must be running on the same version of SQL Server.

AllwaysOn

AlwaysOn ist mehr als eine Marketing-Strategie von Microsoft. AlwaysOn ist ein leistungsstarkes Tool, das mit Hilfe der Clustertechnologien eine sehr hohe Verfügbarkeit bietet. Ja nach Art der Implementierung wird auch ein gemeinsamer Dateispeicher (Shared Storage) vorausgesetzt.

AllwaysOn Failover Cluster Instances (FCI)

SQL Server AlwaysOn Failover Cluster basiert auf einer Windows Server Failover Clustering Technologie. Wir sprechen dabei von einer klassischen Cluster-Infrastruktur mit Shared Storage, Heartbeat-Netzwerk usw. Die Verfügbarkeit wird in diesem Fall auf der Instanzen-Ebene gewährleistet. Wenn ein Clusterknoten mit den installierten Datenbank-Instanzen plötzlich ausfällt, werden die Instanzen auf einem funktionierenden Clusterknoten gestartet. Erfahrungsgemäß dauert das Failover wenige Sekunden. Aus lizenztechnischer Sicht dürfen sowohl die Enterprise als auch die Standard Edition verwendet werden, wobei die Standard Edition auf zwei Cluster-Knoten beschränkt ist.

Der Storage wird in einem AllwaysOn FCI der Single Point of Failure sein. Wenn dieser offline geht, ist die Datenbank nicht mehr erreichbar. 

AllwaysOn Avalibility Groups

Der Hauptunterschied zwischen AlwaysOn AGs und AlwaysOn FCI besteht darin, dass die Informationen auf der Datenbank- und nicht auf der Instanz-Ebene geschützt werden. Analog zu AllwaysOn FCI benötigt AlwaysOn AGs ebenfalls die Windows Failover Clustering Services Technologie und zwar mit einem wesentlichen Unterschied, ein Shared Storage wird nicht mehr vorausgesetzt. AlwaysOn Availability Groups bildet eine instanzübergreifende logische Einheit, die die Datenbankanfragen entgegennimmt und bearbeitet.

In Always-On Verfügbarkeitsgruppen werden zwei Verfügbarkeitsmodi unterstützt: Synchron und Asynchron

Synchroner Modus:  In diesem Fall synchronisiert jede Replica-DB die Inhalte mit der primären DB. Die Datensynchronisierung (Status: Synchronized) wird erst dann abgeschlossen, wenn die Synchronisierung erfolgreich beendet ist. In diesem Fall werden die Replica-DBs auf Healthy geändert. Der Synchron Modus garantiert, dass die DBs immer den gleichen Stand haben und für den automatischen Failover bereit sind.

Asynchroner Modus:  In einem Asynchron Modus werden die Inhalte nicht synchron gehalten. In einem ernsthaften Systemausfall soll mit einem gewissen Datenverlust gerechnet werden. Der Asynchron Modus unterstützt nur einen erzwungenen (manuellen) Failover.

AllwaysOn Basic Avaliblity Groups

Der Hauptunterschied zwischen den AlwaysOn-Basis-Verfügbarkeitsgruppen und den AlwaysOn-Verfügbarkeitsgruppen besteht darin, dass jede Verfügbarkeitsgruppe nur eine Datenbank enthält.

Weitere Information:

• CTX216504 - How to Configure XenApp and XenDesktop 7.x for AlwaysOn configuration
• Konfiguration SQL Server 2017 Standard Basic Availability Groups für XenDesktop 7.x- Teil 1, Teil 2

SQL Express

Der Einsatz von SQL Express in einer produktiven (nicht kritischen) Umgebung ist durchaus möglich. Dabei sollte Folgendes berücksichtigt werden:  SQL Express sollte auf einem separaten Server installiert werden, nicht auf dem Delivery Controller selbst. Dies ermöglicht ein regelmäßiges Backup der kompletten VM. Folgende Begrenzungen sollten beachtet werden:

- maximale Datenbankgröße ist auf 10 GB begrenzt.

- maximale Anzahl von Kernen innerhalb der VM:  4 Kerne

Vergleich der Hochverfügbarkeit-Optionen SQL Server 2017:

Hier finden Sie eine vollständige Liste der Funktionen:  Editionen und unterstützten Funktionen von SQL Server 2017

Citrix-Datenbanken

Site

Die Site-Datenbank ist die wichtigste Datenbank. Die Site DB beinhaltet sowohl statische, als auch dynamische Informationen. Die statischen Informationen sind alle Daten, die eine Farm ausmachen, z.B. Maschinenkataloge, Bereitstellungsgruppen, Anwendungen, User usw. Unter dynamischen Informationen sind folgenden Daten zu verstehen: Sessions, registrierte VDAs usw.  Die Größe der Site-DB ist von der Anzahl der VDAs und den aktiven Sitzungen abhängig. Auch die Häufigkeit der Anmeldung spielt eine Rolle, da die Session-Information 48 Stunden in der Datenbank aufbewahrt wird.

Wenn die Site DB nicht erreichbar ist, lässt sich die Infrastruktur nicht mehr verwalten, bleibt aber dank Local Host Cache weiterhin eingeschränkt funktionsfähig. In diesem Fall ist die Wiederverbindung zu einem Hosted Shared Desktop, Personal Desktop  oder zu den Publisched Applications möglich. Eine Wiederverbindung zu einem VDI-Desktop ist nicht möglich (Stand 7.15).

Monitoring

Die Monitoring-Datenbank ist die größte Datenbank von allen drei DBs. Die Monitoring-DB beinhaltet alle historischen Daten, die eine Grundlage für den Citrix Director bilden. Im Grunde genommen handelt es sich um diese markierten Daten:

Die Größe der Datenbank ist von mehreren Faktoren abhängig, welche die Fähigkeit zum Wachstum massiv beeinflussen können. Der wichtigste Faktor ist die Konfiguration der Aufbewahrungsrichtlinien. Je nach Lizenzedition werden die Information unterschiedlich lange gespeichert. Standardmäßig werden die Daten zwischen 7 bis 90 Tage aufbewahrt. Die glücklichen Besitzer einer Platinum Edition können sich über längere Zeiträume (bis zu 365 Tage rückwirkend) freuen. Alle Daten die außerhalb der Aufbewahrungsfrist liegen, werden automatisch entfernt.

Director Monitoring Database Retention Policy

Die Aufbewahrungsfristen lassen sich nach Bedarf anpassen (vergrößern oder verkleinern). Der zweite entscheidende Faktor ist die Anzahl der Benutzer und der Verbindungen. Der Verlust der Monitoring-Datenbank ist nicht kritisch. Im Falle eines kompletten Datenbankverlustes, werden nur die historischen Daten nicht mehr abrufbar sein.

Der Befehl Get-MonitorConfiguration zeigt die aktuelle Konfiguration.

Mit dem Befehl Set-MonitorConfiguration können Sie festlegen, wie lange die historischen Daten aufbewahrt werden. (z.B. Set-MonitorConfiguration -GroomResourceUsageRawDataRetentionDays 7)

Nutzliche Information zum Thema:

• Data granularity and retention
• Detaillierte Beschreibung aller Parameter des Befehls Set-MonitorConfiguration

Configuration Logging (Konfigurationsprotokollierung)

Die Configuration Logging-DB ist die kleinste Datenbank von allen. Hier werden alle administrativen System-Änderungen (initiiert aus Studio, Director oder PowerShell) gespeichert. Die in der Datenbank aufbewahrten Informationen dienen  gewissermaßen zur Feststellung, wer, wann und welche Änderungen am System vorgenommen hat. Je öfter die  Konfigurationsänderungen durchgeführt werden, desto größer wird die Datenbank sein. Da die Configuration Logging-DB nie sehr groß werden kann, gibt es auch keine auf der Konsole konfigurierbare Aufbewahrungsrichtlinien. Sie können jedoch bei Bedarf die Aufbewahrungsfristen mit dem mit dem folgenden Befehl konfigurieren:

Set-LogSite -LoggingDBPurgeDurationDays „AnzahlTagen“

Die fertige Konfiguration lässt sich mit dem Befehl Get-LogSite überprüfen.

Aus der Citrix Studio können Sie:

- die Protokollierung jederzeit aktivieren / deaktivieren
- die bereits geschriebenen Protokolle löschen
- die Datenbank ändern

Die Protokollierung lässt sich ebenfalls per PowerShell aktivieren / deaktivieren.

Deaktivieren: Set-LogSite -State "Disabled"
Aktivieren: Set-LogSite -State "Enabled"

Temporary Database

Bei der Temp-DB handelt es sich um eine zusätzliche Datenbank, die als eine Basis für Read-Committed Snapshot Isolation agiert. Die Größe der DB ist von der Anzahl der Transaktionen abhängig und bleibt erfahrungsgemäß ziemlich klein (nur wenige MBs). 

Weitere Information zum Thema finden Sie hier:

Snapshot Isolation in SQL Server

Platzierung der Datenbanken

Standardmäßig werden alle Datenbanken auf derselben SQL-Instanz gehostet. Diese vordefinierte DB-Platzierung lässt sich ändern. Es ist empfehlenswert, die Monitoring-Datenbank von den anderen Datenbanken zu trennen und auf einen anderen SQL-Server zu hosten. Für eine solche Entscheidung sprechen zwei Gründe: die Datenbank kann im Vergleich zu den anderen DBs ziemlich groß werden, und die darin enthaltenen Informationen sind nicht kritisch.

Service Account für die Citrix Datenbanken

Es existieren zwei Arten die notwendigen Datenbanken für die Citrix-Infrastruktur anzulegen.

1. Die Datenbanken können durch den Wizard automatisch erstellt werden. Der Benutzer, der die Installation durchführt, soll aber wie folgt berechtigt sein:

• dbcreator
• securityadmin

2. Wenn Sie nicht über die entsprechenden Berechtigungen verfügen, sollen Sie zu einer Alternative zugreifen. Der Wizard ist in der Lage, die DB-Konfiguration-Skripte zu generieren, die von DB-Administratoren ausgeführt werden sollen.

Nach dem die Datenbanken erstellt sind, soll der Service User, der für die Kommunikation mit den Datenbanken verwendet wird, über die folgenden Rollen und Berechtigungen verfügen:

• db_owner
• securityadmin

Die gleiche Rechte werden benötigt, wenn Sie den zweiten (weiteren Controller) zu einer bestehenden Farm hinzufügen möchten

3. Abweichende Berechtigung für den PVS Service Account, wenn die Datenbank durch den DB-Admins erstellt wird:

• db_datareader
• db_datawriter
• execute permissions on stored procedures

Offizielle Dokumentation: CTX127998 - Database Access and Permission Model for XenDesktop

Lizenzierung von Microsoft SQL Server 

Für die produktive Citrix Bereitstellung kommen nur zwei mögliche Editionen in Frage: Standard und Enterprise. Bei der Standard Edition haben Sie eine Wahl zwischen Lizenzierung pro CPU-Kern sowie Server + CAL Lizenzierung. Die Enterprise Edition wird ausschließlich pro CPU-Kern lizenziert.

Die SQL-Lizenzen werden ausschließlich als zwei-Core-Lizenz angeboten, dabei ist die Mindestlizenzierung 4 Kerne. Ein Unterschied zwischen einer vCPU und einem physischen Core gibt es nicht.

Berechnungsbeispiel: für unsere Infrastruktur planen wir den Einsatz der SQL-Spiegelung (Standard Edition). Es werden zwei virtuelle Maschinen mit jeweils vier vCPU zum Einsatz kommen.
Preis pro SQL Server: 2 x zwei-Core-Lizenz (3.577 x 2 = 7154 Euro pro Server)
Die geplante gespiegelte Infrastruktur kosten 14308 Euro. (Stand: März 2018)

Vergleich der Versionen SQL Server 2017:

Hardware-Sizing

Folgende Tabellen beinhalten von Citrix / Microsoft empfohlene Sizing-Werte:

Hardwareanforderung (Microsoft) SQL Server 2017:

Citrix-Empfehlung:

Disks / Partitionierung des SQL-Servers

Ein SQL-Server stellt hohe Ansprüche an Storage. Die virtuelle (oder physische) Maschine, die eine SQL-Instanz hostet, sollte über möglichst schnelle Datenträger (vorzugsweise SSD) verfügen.

Wenn Sie den DB-Server in einem produktiven Betrieb verwenden, sollten mehrere Partitionen zwecks Performance einrichten:

1. System Windows 2016 Betriebssystem
2. SQL DB (für Datenbanken)
3. DB-Logs (für Transactions-Logs) 
4. DB-Temp (für temporäre Datenbanken)

Verwenden Sie keine Dynamische Partitionen (Thin Provisioning), da diese negative Auswirkungen auf die Performance haben können. Die Verwendung von separaten Datenträgern (RAIDs, z.B. RAID10) pro Workload ist zu empfehlen.

Speicheranforderungen

Wie wir bereits wissen, ist der erforderliche Speicherbedarf für Citrix Datenbanken von mehreren Faktoren abhängig. Die Faktoren, die die erforderliche Datenbankgröße beeinflussen können, sind folgende: Anzahl der Sessions, VDAs, Intensität der Nutzung (Logon/Logoff), konfigurierte Aufbewahrungsrichtlinien usw.
Wenn wir mal realistisch bleiben, sprechen wir nur über Hunderte von Megabytes für eine Umgebung mit mehreren Tausend Benutzern. 

Die folgenden Tabellen geben einen groben Überblick über die möglichen Größen der Datenbanken:

Site DB 

 Quelle: Citrix

Monitoring DB

 Quelle: Citrix

Database Sizing Tool

XenDesktop 7.x: Database Sizing Tool (CTX209080). Es handelt sich dabei um eine kleine, intuitiv bedienbare Anwendung.

Unter diesem Link können Sie das Tool herunterladen | Download

Offizielle Informationen

• Eine vollständige und immer aktuelle Liste der supporteten Datenbanken finden Sie hier |  Supported Databases for XenApp and XenDesktop Components
  
• How to use PowerShell to Change XenDesktop SQL Connection Strings (CTX140319) | Öffnen
• Database Access and Permission Model for XenDesktop (CTX127998) | Öffnen 
• SQL Server Ports | Öffnen 
• XenApp/XenDesktop 7.X : Basic Powershell Cmdlets for Delivery Controller's Health Check

• Zurück
• Weiter