SQL Server- und Citrix Virtual Apps and Desktops-Datenbanken

Microsoft SQL Server ist eine wichtige Komponente jeder Citrix Virtual Apps and Desktops (CVAD) -Bereitstellung.
Das Planen und Verstehen von Citrix SQL-Interaktionen ist für Sie und Ihr Unternehmen von großem Vorteil, wenn es darum geht, eine gesunde und leistungsstarke Citrix-Umgebung aufrechtzuerhalten.
Fehlende Hochverfügbarkeit von SQL Server und ausreichend Rechenressourcen wirken sich negativ auf die Benutzererfahrung und die Verfügbarkeit der Citrix-Infrastruktur aus.

Zusammenfassung der Datenbank

Es gibt 3 Datenbanken, die während der Bereitstellung von Citrix Virtual Apps and Desktops erforderlich und erstellt werden müssen:

Standort:(auch bekannt als Site-Konfiguration) Speichert die aktuelle Site-Konfiguration sowie dynamische Daten im Zusammenhang mit Brokering-Aktivitäten, wie z. B. aktueller Sitzungsstatus, Verbindung, Auslastung und VDA-Statusinformationen (Virtually Delivery Agent).

Konfigurationsprotokollierung:(auch als Protokollierung bezeichnet) Speichert Informationen über Änderungen der Site-Konfiguration und administrative Aktivitäten. Diese Datenbank wird verwendet, wenn die Konfigurationsprotokollierung aktiviert ist (diese ist standardmäßig aktiviert).

Überwachung:Speichert von Director verwendete Daten wie Sitzungs- und Verbindungsinformationen.

Bei der Erstkonfiguration von Citrix Virtual Apps and Desktops werden drei separate Datenbanken erstellt — entweder über Studio oder durch Ausführen von Skripten auf dem SQL Server.

Für Umgebungen mit großen Monitoring-Datenbanken besteht eine ideale Konfiguration darin, die Monitoring-Datenbank auf einem anderen Server als die Datenbanken Site Configuration und Configuration Logging zu hosten.
Es zeichnet mehr Daten auf, Änderungen treten häufiger auf, und die Daten werden nicht als so kritisch angesehen wie die anderen Datenbanken.
Weitere Informationen finden Sie im Artikel How to Change Database Locations of Monitoring and Configuration Logging Database.

Stellen Sie sicher, dass eine angemessene SQL-Server- und Datenbanküberwachung vorhanden ist, um Fehlerereignisse und Probleme zu erkennen.

Citrix-Interaktion mit SQL

Die Delivery Controller verwenden die Datenbank als Nachrichtenbus für die Broker-Kommunikation und speichern Konfigurations-, Überwachungs- und Auditdaten.
Die Datenbanken werden ständig verwendet und können erhebliche Rechenressourcen auf dem SQL-Server beanspruchen.

Bei der Ressourcenaufzählung (Ressourcen, die dem Benutzer identifiziert und präsentiert werden), beim Ressourcenstart und beim Sitzungsstart muss der Citrix Delivery Controller mit dem SQL-Server interagieren.

Aufzählung:
Nach erfolgreicher Authentifizierung über NetScaler und StoreFront kontaktiert der Delivery Controller die Citrix-Site-Datenbank, um anhand der AD-Anmeldeinformationen zu überprüfen, welche Anwendungen für den Benutzer verfügbar sind. Wenn Ressourcen identifiziert werden, werden zusätzliche Informationen (wie Namen von Apps, Desktops, Symbolen) aus der Datenbank abgerufen.

Start:
Wenn der Benutzer die zu startende Anwendung oder den Desktop auswählt, sendet StoreFront eine Startanforderung an den Delivery Controller. Der Delivery Controller kontaktiert die Site-Datenbank auf dem SQL-Server, um den entsprechenden VDA auszuwählen, an den der Benutzer gesendet werden soll.

Sitzungsinitialisierung:
Nach dem Sitzungsstart kontaktiert der VDA den Delivery Controller, um Sitzungsinformationen in die Site-Datenbank zu schreiben.

Datenbanken-Empfehlungen

Um sicherzustellen, dass ein SQL-Serverausfall nur minimale Auswirkungen auf die Citrix Virtual Apps and Desktops-Infrastruktur hat, können Kunden aus den folgenden Hochverfügbarkeitsdatenbankoptionen wählen:

  • SQL Server AlwaysOn-Failoverclusterinstanzen
  • SQL Server AlwaysOn-Verfügbarkeitsgruppen (einschließlich Basisverfügbarkeitsgruppen)
  • SQL Server-Datenbankspiegelung

Citrix empfiehlt, für alle drei Datenbanken den gleichen Hochverfügbarkeitsansatz zu verwenden.
Wenn Sie beispielsweise planen, SQL AlwaysOn-Verfügbarkeitsgruppen als Ihre HA-Strategie zu verwenden, verwenden Sie sie für alle drei Datenbankobjekte.

Wir empfehlen außerdem, täglich eine vollständige Backup der Citrix-Datenbanken selbst zu erstellen, insbesondere der Standortdatenbank.

Die Aufbewahrungsfristen variieren je nach organisatorischen Anforderungen. In der Regel werden vollständige Backups jedoch sieben Tage lang und wöchentliche Backups mindestens einen Monat lang aufbewahrt.
Die Zeitpläne für die Backup von Transaktionsprotokollen müssen auf einer Kombination aus den Standards Ihres Unternehmens und der Wachstumsrate des Transaktionsprotokolls basieren.
Stellen Sie sicher, dass Sie den verfügbaren Speicherplatz auf Ihrem SQL-Server überwachen.

Passen Sie Ihr Wiederherstellungsmodell für die Citrix-Datenbanken an die Anforderungen des von Ihnen gewählten Hochverfügbarkeitsansatzes an.

Gemäß einer Empfehlung von Microsoft richten Kunden Wartungspläne ein, die jede Nacht und jede Woche ausgeführt werden, um die Datenbankindizes zu verwalten. Die Wartungspläne können die Indizes einfach über Nacht während der Woche neu organisieren und die Indizes am Wochenende neu erstellen.

Dadurch werden Leistungseinbußen vermieden, die sich aus der Neuerstellung großer Indizes während des täglichen Betriebs ergeben, insbesondere bei einer großen Monitoring-Datenbank.
Microsoft empfiehlt, dass Indizes neu erstellt werden, wenn sie mehr als 30% fragmentiert sind, und wenn weniger als 30% neu organisiert werden.

Lokaler Hostcache

Um Szenarien zu berücksichtigen, in denen die Datenbank nicht mehr verfügbar ist, stellt Citrix die Funktion Local Host Cache (LHC) mit Citrix Virtual Apps and Desktops bereit.

Mit dieser Option können Benutzer veröffentlichter Anwendungen und Desktops eine Verbindung herstellen, wenn die Kommunikation zwischen Delivery Controllern und der Citrix Site Configuration-Datenbank unterbrochen wird.
Wenn SQL in einer hochverfügbaren Architektur wie AlwaysOn oder Mirroring konfiguriert ist, bietet diese Funktion zusätzliche Fehlertoleranz, wenn ein vollständiger SQL-Ausfall auftritt oder die Netzwerkkonnektivität unterbrochen wird.

Dies sollte nicht als Alternative zur SQL-Hochverfügbarkeit betrachtet werden, da die Site-Verwaltungsfunktionen während eines SQL-Ausfalls nicht verfügbar sind und der Failover-Prozess nicht sofort erfolgt.

Im Falle eines SQL-Ausfalls geht die Brokering-Funktionalität verloren, bis sie auf den LHC umgestellt wurde und die VDAs erneut registriert wurden.
Dieses Szenario tritt auch auf, wenn Sie in den normalen Betriebsmodus zurückkehren, wenn die SQL-Konnektivität/Verfügbarkeit wiederhergestellt ist.

Local Host Cache speichert eine Kopie der statischen Site-Daten in einer lokalen SQL Express LocalDB-Datenbank auf jedem Delivery Controller. Es stützt sich bei einem Datenbankausfall auf diese Daten, um VDA-Registrierungen und Sitzungsvermittlungsanfragen kontinuierlich zu unterstützen.

Für Citrix Virtual Apps and Desktops-Sites mit mehreren Zonen ist für jede Zone ein separater LHC vorhanden.
Delivery Controller innerhalb der Zone speichern dynamische Daten, die für ihre Zone spezifisch sind, in der lokalen SQL Express-Datenbank.

Überlegungen zum Design des lokalen Hostcaches

Aufgrund vieler Variablen in Unternehmensbereitstellungen wird empfohlen, eng mit Citrix zusammenzuarbeiten, um die zusätzlichen Ressourcen zu ermitteln, die für die Verwendung von LHC erforderlich sind.
In einer Citrix Virtual Apps and Desktops-Umgebung hängen LHC und Zonenskalierbarkeit von der Anmelderate und der Benutzeranzahl ab.

  • Überlegungen zur Skalierbarkeit
    • Die Höchstgrenzen für den LHC von Citrix Virtual Apps and Desktops 2203 LTSR sind 10.000 VDAs in einer Einzelzone und 40.000 VDAs in einer Mehrzonenbereitstellung.
    • Die tatsächliche Skalierbarkeit kann unter den veröffentlichten Höchstwerten liegen. Wir empfehlen, zusätzliche Zonen in Betracht zu ziehen, wenn Ihre erwartete Sitzungsanzahl 10.000 übersteigt oder Ihre Anmelderate mehr als 10 Benutzer pro Sekunde beträgt.
  • Größe des Delivery Controller
    • Wenn LHC aktiv ist, verarbeitet der gewählte primäre Delivery Controller (DC) pro Zone alle VDA-Registrierungen, Aufzählungen, Starts und Updates.
    • RAM: Die LHC-Dienste können je nach Dauer des Ausfalls und Anzahl der Benutzerstarts mehr als 2 GB RAM verbrauchen.
    • CPU: Aufgrund der zusätzlichen CPU-Last auf dem ausgewählten DC sollten Sie zusätzliche Kerne als Ausgleich in Betracht ziehen.

    Die CPU-Konfiguration eines Controllers, insbesondere die Anzahl der Kerne, die der SQL Server Express LocalDB zur Verfügung stehen, wirkt sich direkt auf die Leistung des lokalen Hostcaches aus.
    CPU-Overhead wird nur während der Ausfallzeit beobachtet, wenn die Datenbank nicht erreichbar ist und der High Availability Service aktiv ist.

    Die LocalDB kann zwar mehrere Kerne (bis zu 4) verwenden, ist jedoch auf nur einen einzigen Socket beschränkt.
    Das Hinzufügen weiterer Sockets verbessert die Leistung nicht. Stattdessen empfiehlt Citrix die Verwendung von mehreren Sockets mit mehreren Kernen.
    In Citrix-Tests bot eine 2x3-Konfiguration (2 Sockets, 3 Kerne) eine bessere Leistung als 4x1- und 6x1-Konfigurationen.

  • Speicher: Im LHC-Modus steigt die Speichernutzung alle 2—3 Minuten um etwa 1 MB, wobei von durchschnittlich 10 Anmeldungen pro Sekunde ausgegangen wird.

Weitere Informationen finden Sie im Artikel Lokaler Hostcache .

Auswirkungen eines Datenbankausbruchs

Im Falle eines vollständigen Datenbankausfalls sind fast alle wichtigen Delivery Controller-Funktionen betroffen, was die Notwendigkeit unterstreicht, eine der empfohlenen SQL-HA-Strategien zu implementieren.
In der folgenden Tabelle sind diese Auswirkungen aufgeführt:

Komponente Auswirkungen eines Datenbankausfalls
Sitekonfigurationsdatenbank Benutzer können keine Verbindung zu einer virtuellen App oder einem virtuellen Desktop herstellen oder erneut eine Verbindung herstellen.
Überwachungsdatenbank Director zeigt keine historischen Daten an und Studio kann nicht gestartet werden. Die Vermittlung eingehender Benutzeranfragen und bestehender Benutzersitzungen ist nicht betroffen.
Konfigurationsprotokollierungsdatenbank Wenn „ Änderungen zulassen, wenn die Datenbank getrennt ist “ in den Protokollierungseinstellungen von Citrix Virtual Apps and Desktops aktiviert wurde, hat ein Ausfall der Datenbank für die Konfigurationsprotokollierung keine Auswirkungen (außer dass Konfigurationsänderungen nicht protokolliert werden). Andernfalls können Administratoren keine Änderungen an der Citrix Virtual Apps and Desktops-Umgebung vornehmen.

Hinweis: Weitere Informationen zu diesem Thema finden Sie unter Was ist bei einem Ausfall nicht verfügbar und andere Unterschiede .

Empfehlung zur SQL-Größenbestimmung

Der SQL-Server muss korrekt dimensioniert sein, um die Leistung und Stabilität einer Umgebung zu gewährleisten. Da jedes Citrix-Produkt den SQL-Server auf unterschiedliche Weise verwendet und jeder Kunde unterschiedliche Nutzungsmuster hat, können keine generischen Größenempfehlungen gegeben werden.
Stattdessen werden später produktspezifische Empfehlungen zur Größe des SQL-Servers gegeben, und die Leistung muss während der Bereitstellung sorgfältig überwacht werden, um die Annahmen zur Größenbestimmung zu überprüfen.

Für eine SQL-Umgebung, in der nur Datenbanken mit Citrix-Bezug gehostet werden, sollten die SQL-Server mit mindestens 4 vCPUs und 8 GB RAM für bis zu 10.000 Benutzer bereitgestellt werden.
Für größere Bereitstellungen oder Bereitstellungen mit hohen Anmelderaten empfehlen wir mindestens 8 vCPUs und 16 GB RAM.

Weitere Informationen zu Konzepten zur Dimensionierung von SQL-Datenbanken finden Sie unter Citrix XenDesktop 7.x Database Sizing. Dieser Artikel enthält auch Informationen zu Arbeitsauslastungsmerkmalen, wie z. B. geschätzte Wachstumsrate des Transaktionsprotokolls.

Beachten Sie, dass die Monitoring Database je nach Datenspeicherungseinstellungen unterschiedlich groß ist.
Neuere Produktversionen verfügen außerdem über mehr Optionen und Datenpunkte, die mehr Speicherplatz beanspruchen (z. B. LTSR 2203 im Vergleich zu LTSR 1912).
Weitere Informationen zur Konfiguration dieser Einstellungen finden Sie unter Richtlinieneinstellungen überwachen.

CU Updates und Fixes

Mehrmals im Jahr veröffentlicht Citrix Cumulative Updates (CUs) für Citrix Virtual Apps and Desktops LTSRs. Diese CUs enthalten nur Sicherheitsupdates und Bugfixes, ohne dass neue Funktionen eingeführt wurden.

Citrix empfiehlt, die neuesten CUs auszuführen, da sie Probleme beheben, die im Produkt identifiziert wurden. Einige dieser Korrekturen beziehen sich auf SQL. Sie behandeln die von Citrix oder unseren Kunden identifizierten Probleme (Beispiele können Sperren, Deadlocks oder gespeicherte Prozeduren sein).

Wir sind uns bewusst, dass die Installation umfassender Updates für Citrix Virtual Apps and Desktops-Umgebungen Zeit und eine angemessene Planung erfordert (insbesondere für unternehmenskritische Situationen rund um die Uhr), aber Citrix empfiehlt dringend, die CUs so aktuell wie möglich zu halten, um einen optimalen Gesamtzustand und eine optimale Leistung zu erzielen.

Aktuelle Dokumentation

In diesem Dokument wird die Bedeutung von SQL für Citrix Virtual Apps and Desktops-Umgebungen hervorgehoben, einschließlich der HA-Strategie und verschiedener Überlegungen. Es ist nicht als umfassende Literatur zu Citrix- und SQL-Empfehlungen gedacht. Weitere Einzelheiten und aktuelle Informationen finden Sie in diesen Dokumenten:

Citrix Virtual Apps and Desktops-Datenbanken

Lokaler Citrix Hostcache

Dimensionierung der Citrix XenDesktop 7.x-Datenbank

SQL Server- und Citrix Virtual Apps and Desktops-Datenbanken