SQL Server- und Citrix-Datenbanken
Microsoft SQL Server ist eine wichtige Komponente jeder Citrix Virtual Apps and Desktops Bereitstellung. Das Planen und Verstehen von Citrix SQL-Interaktionen ist für Sie und Ihr Unternehmen von großem Vorteil, wenn Sie eine gesunde und leistungsfähige Citrix Umgebung pflegen. Die fehlende Hochverfügbarkeit von SQL Server und ausreichend Rechenressourcen wirkt sich negativ auf die Benutzererfahrung und die Verfügbarkeit der Citrix Infrastructure aus.
Datenbankübersicht
Es gibt drei Datenbanken, die während der Bereitstellung von Citrix Virtual Apps and Desktops erforderlich bzw. erstellt werden:
Site: (auch als Standortkonfiguration bezeichnet) speichert die ausgeführte Standortkonfiguration sowie dynamische Daten im Zusammenhang mit Brokering, wie aktuelle Sitzungsstatus, Verbindungs-, Lade- und VDA-Statusinformationen.
Konfigurationsprotokollierung: (auch Protokollierung genannt) speichert Informationen zu Änderungen der Standortkonfiguration und administrativen Aktivitäten. Diese Datenbank wird verwendet, wenn die Konfigurationsprotokollierung aktiviert ist (diese ist standardmäßig aktiviert).
Überwachung: enthält von Director genutzte Daten, z. B. Sitzungs- und Verbindungsinformationen.
In früheren Versionen von Citrix Virtual Apps and Desktops, wie XenApp und XenDesktop 7.6, wurde die für Citrix Virtual Apps and Desktops erforderliche Datenbank während der ersten Site-Konfiguration als eine Datenbank erstellt (über Studio oder durch Ausführen von Skripts auf dem SQL Server). Nach der Installation kann der Administrator sie in verschiedene Datenbanken aufteilen, um die Leistung zu verbessern oder die Sicherungs- und Sicherheitsrichtlinien einzuhalten.
Mit neueren Versionen von Citrix Virtual Apps and Desktops können Sie die Datenbanken während der ersten Site-Konfiguration sowie über Studio oder durch Ausführen von Skripts auf dem SQL Server erstellen. Ihre Datenbank wird automatisch in drei separate Datenbanken aufgeteilt.
Für Umgebungen mit großen Überwachungsdatenbanken wäre eine ideale Konfiguration, die Überwachungsdatenbank auf einem anderen Server als den Datenbanken für die Standortkonfiguration und Konfigurationsprotokollierung 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 unter Database Sizing Guidance oder Seite 97 im VDI-Handbuch.
Jedes kumulative Update (CU) für die Langzeitdienstversion (LTSR) enthält Korrekturen für das SQL-Datenbankschema. Siehe zum Beispiel CTX230536. Um Ihre Umgebung optimal vor unerwarteten Problemen zu schützen, stellen Sie sicher, dass Sie über einen Prozess verfügen, mit dem Sie Ihre Umgebung regelmäßig auf die neueste CU aktualisieren können. Stellen Sie außerdem sicher, dass geeignete SQL-Server- und Datenbanküberwachung vorhanden sind, um Fehlerereignisse und Probleme mit hoher Ressourcenauslastung und freiem Speicherplatz zu erfassen.
Citrix Interaktion mit SQL
Citrix Virtual Apps and Desktops Broker verwenden die Datenbank als Nachrichtenbus für Broker-Kommunikation, Speicherung von Konfigurations-, Überwachungs- und Überwachungsdaten. Die Datenbanken werden ständig verwendet und können erhebliche Rechenressourcen auf dem SQL-Server verbrauchen.
Beispielsweise erfordern die Ressourcenaufzählung (Ressourcen, die dem Benutzer identifiziert und präsentiert wurden), den Start von Ressourcen und den Start von Sitzungen, dass der Citrix Delivery Controller mit dem SQL-Server interagiert.
Aufzählung: Nach erfolgreicher Authentifizierung über Citrix ADC und StoreFront kontaktiert der Delivery Controller die Citrix Site-Datenbank, um zu überprüfen, welche Anwendungen für den Benutzer verfügbar sind, basierend auf AD-Anmeldeinformationen. Wenn Ressourcen identifiziert werden, werden zusätzliche Informationen wie Namen von Apps, Desktops und Symbolen aus der Datenbank abgeleitet.
Starten: Wenn der Benutzer die zu startende Anwendung oder den zu startenden Desktop auswählt, initiiert StoreFront eine Startanforderung an den Delivery Controller. Anschließend kontaktiert der Delivery Controller die Standortdatenbank auf dem SQL-Server, um den entsprechenden VDA auszuwählen, an den der Benutzer gesendet werden soll.
Sitzungsinitialisierung: Nach dem Starten der Sitzung steht der VDA in Kontakt mit Delivery Controller, um Sitzungsinformationen in die Standortdatenbank zu schreiben.
Datenbank-Empfehlungen
Um sicherzustellen, dass ein SQL Server-Ausfall eine minimale Auswirkung auf die Citrix Virtual Apps and Desktops Infrastruktur hat, können Kunden aus den folgenden Hochverfügbarkeitsoptionen wählen, die von Citrix unterstützt werden:
- AlwaysOn-Verfügbarkeitsgruppen
- AlwaysOn-Failoverclustering
- Grundlegende Verfügbarkeitsgruppen
- Hypervisor HA *
Hinweis:
Obwohl Citrix Hypervisor HA unterstützt, wird es nicht empfohlen, ihn in Umgebungen zu verwenden, in denen EHR-Apps gehostet werden, in denen die Verfügbarkeit von größter Bedeutung ist.
Citrix und Epic empfehlen die Verwendung des gleichen Hochverfügbarkeitsansatzes für alle drei Datenbanken, auch wenn die Konfigurationsprotokollierung und die Überwachung der Datenbankverfügbarkeit für die Einrichtung von Endbenutzersitzungen nicht erforderlich sind. Wenn Sie beispielsweise die SQL Always-On-Verfügbarkeitsgruppe als HA-Strategie verwenden möchten, verwenden Sie sie für alle drei Datenbankobjekte.
Es wird außerdem empfohlen, eine vollständige tägliche Sicherung der Citrix Datenbanken selbst zu erstellen, insbesondere der Standortdatenbank. Die Aufbewahrungsfristen variieren je nach organisatorischen Anforderungen, aber es ist typisch, dass sieben Tage vollständige Backups und mindestens einen Monat wöchentliche Backups aufrechterhalten werden. Die Sicherungszeitpläne für Transaktionsprotokolle sollten auf einer Kombination der Standards Ihrer Organisation und der Wachstumsrate des Transaktionsprotokolls in Bezug auf die Menge des verfügbaren Speichers basieren, die Sie zuweisen müssen. Stellen Sie sicher, dass der verfügbare Speicher auf Ihrem SQL-Server überwacht wird.
Richten Sie Ihr Wiederherstellungsmodell für die Citrix Datenbanken an die Anforderungen des Hochverfügbarkeitsansatzes aus, den Sie verwenden.
Gemäß der Empfehlung von Microsoft sollten Kunden Wartungspläne einrichten, die täglich und wöchentlich ausgeführt werden, um die Datenbankindizes zu pflegen. Die Wartungspläne können einfach darin liegen, die Indizes über Nacht während der Woche neu zu organisieren und die Indizes am Wochenende neu aufzubauen.
Diese Empfehlung vermeidet jegliche Performance-Auswirkungen beim Neuaufbau großer Indizes während des täglichen Betriebs, insbesondere für eine große Überwachungsdatenbank.
Microsoft empfiehlt, dass Indizes neu erstellt werden, wenn sie mehr als 30% fragmentiert sind, und wenn weniger als 30% neu organisiert werden. Weitere Informationen finden Sie im Abschnitt Datenbankwartung .
Lokaler Hostcache
Um Szenarien zu berücksichtigen, in denen die Datenbank nicht verfügbar ist, hat Citrix die Funktion Local Host Cache (LHC) zur Citrix Virtual Apps and Desktops 7.x-Plattform hinzugefügt (7.12 und höher, einschließlich XenApp und XenDesktop 7.15 LTSR). Durch Aktivieren dieser Option können Benutzer von Published Applications eine Verbindung herstellen, wenn die Kommunikation zwischen Delivery Controllern und der Citrix Standortkonfigurationsdatenbank unterbrochen wird. Wenn SQL in einer hochverfügbaren Architektur wie Always On, Mirroring oder Clustering konfiguriert ist, bietet diese Funktion zusätzliche Fehlertoleranz, wenn ein vollständiger SQL-Ausfall auftritt oder die Netzwerkverbindung unterbrochen wird.
Dies sollte nicht als Alternative zur Hochverfügbarkeit von SQL betrachtet werden, da Standortverwaltungsfunktionen während eines SQL-Ausfalls nicht verfügbar sind und der Failoverprozess 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 beim Übergang zum normalen Betriebsmodus auf, wenn SQL-Konnektivität/Verfügbarkeit wiederhergestellt wird.
Der lokale Hostcache speichert eine Kopie der statischen Standortdaten in einer lokalen SQL Express LocalDB-Datenbank auf jedem Delivery Controller und stützt sich auf diese Daten während eines Datenbankausbruchs, um VDA-Registrierungen und Sitzungsbrokering-Anforderungen kontinuierlich zu unterstützen.
Überlegungen zum Entwurf des lokalen Hostcaches
Aufgrund der unterschiedlichen Größe der Bereitstellungen von Epic Community Member empfiehlt es sich, eng mit Citrix zusammenzuarbeiten, um zusätzliche Ressourcen zu ermitteln, die für die Nutzung von LHC erforderlich sind.
- Überlegungen zur Skalierbarkeit
- Die dokumentierten Höchstgrenzen für den LHC in XenApp und Xendesktop 7.15 betragen 10.000 VDAs in einer Einzelzone und 40.000 VDAs in einer Multi-Zonen-Bereitstellung. In einer Citrix Virtual Apps-Umgebung ist die Skalierbarkeit von LHC und Zonen abhängig von Anmeldungsrate und Benutzeranzahl. Daher kann die tatsächliche Skalierbarkeit, die in Ihrer Umgebung beobachtet wird niedriger als die veröffentlichten Maximen sein. Für diese Architektur empfehlen wir, zusätzliche Zonen zu berücksichtigen, wenn Ihre erwartete Sitzungsanzahl 10.000 überschreitet und/oder Ihre Anmelderate größer als 10 Benutzer pro Sekunde ist.
- Delivery Controller-Größe: Wenn LHC aktiv ist, verarbeitet der gewählte primäre Delivery Controller (DC) pro Zone alle VDA-Registrierungen, Aufzählungen, Starts und Aktualisierungen.
- RAM: Die lokalen Host-Cache-Dienste können 2 plus GB RAM in Abhängigkeit von der Dauer des Ausbruchs und der Anzahl der Benutzerstarts während des Ausbruchs belegen.
- CPU: Aufgrund der zusätzlichen CPU-Auslastung des gewählten DC sollten zusätzliche Kerne als kompensiert betrachtet werden.
Die CPU-Konfiguration eines Controllers, insbesondere die Anzahl der Kerne, die für die SQL Server Express LocalDB verfügbar sind, wirkt sich direkt auf die Leistung des lokalen Hostcache aus, noch mehr als auf die Speicherzuweisung. Der CPU-Mehraufwand tritt nur während eines Ausfalls auf, wenn die Datenbank nicht erreichbar und der Dienst für hohe Verfügbarkeit aktiv ist.
Die LocalDB kann zwar bis zu 4 Kerne verwenden, ist aber auf ein einziges Socket beschränkt. Das Hinzufügen von mehr Sockets, zum Beispiel mit 4 Sockets mit jeweils 1 Kern, verbessert die Leistung nicht. Stattdessen empfiehlt Citrix die Verwendung von mehreren Sockets mit mehreren Kernen. Bei von Citrix durchgeführten Tests lieferte eine 2x3-Konfiguration (2 Sockets, 3 Kerne) eine bessere Leistung als eine 4x1- oder 6x1-Konfiguration.
- Speicher: Im lokalen Host-Cache-Modus erhöht sich die Speicherauslastung alle 2 bis 3 Minuten um etwa 1 MB, wobei durchschnittlich 10 Anmeldungen pro Sekunde vorausgesetzt werden. Der Speicherverbrauch steigt relativ zur Anmelderate. Weitere Informationen finden Sie im Artikel Lokaler Hostcache .
Auswirkungen eines Datenbankausbruchs
Im Falle eines vollständigen Datenbankausfalls sind fast alle kritischen Delivery Controller-Funktionen betroffen, was die Bedeutung des Entwerfen und Implementierens einer der empfohlenen SQL-HA-Strategien hervorhebt. Die folgende Tabelle ruft diese Effekte auf:
| Komponente | Auswirkungen eines Datenbankausfalls |
|---|---|
| Sitekonfigurationsdatenbank | Benutzer können keine Verbindung zu einem virtuellen Desktop herstellen oder erneut herstellen. Hinweis: Mit Local Host Cache (LHC) können Benutzer mit gehosteten freigegebenen Desktops, gehosteten Windows- und Browseranwendungen und Personal Desktops erneut eine Verbindung zu ihren Anwendungen und Desktops herstellen, selbst wenn die Standortdatenbank nicht verfügbar ist. Im LHC-Modus werden keine Überwachungsdaten erfasst, und Konfigurationsänderungen an der Site können nicht vorgenommen werden. |
| Überwachungsdatenbank | Director zeigt keine historischen Daten an, und Studio kann nicht gestartet werden. Das Brokering eingehender Benutzeranforderungen und bestehender Benutzersitzungen ist nicht betroffen. |
| Konfigurationsprotokollierungsdatenbank | Wenn Änderungen beim Trennen der Datenbank zulassen in den Citrix Virtual Apps and Desktops Protokollierungseinstellungen aktiviert wurde, hat ein Ausfall der Konfigurationsprotokollierungsdatenbank keine Auswirkungen (außer Konfigurationsänderungen werden nicht protokolliert). Andernfalls können Administratoren keine Änderungen an Citrix Virtual Apps and Desktops vornehmen. |
SQL-Größenempfehlung
Der SQL-Server muss korrekt dimensioniert sein, um die Leistung und Stabilität einer Umgebung zu gewährleisten. Da jedes Citrix Produkt SQL Server auf andere Weise verwendet und jeder Kunde unterschiedliche Verwendungsmuster hat, können keine generischen, allumfassenden Größenempfehlungen bereitgestellt werden. Stattdessen werden im Folgenden Empfehlungen für die SQL Server-Größe pro Produkt bereitgestellt, und die Leistung sollte während der Bereitstellung sorgfältig überwacht werden, um Annahmen zur Größenänderung zu überprüfen.
Für eine SQL-Umgebung, die nur mit Citrix zusammenhängende Datenbanken hostet, sollten die SQL-Server mit mindestens 4 vCPU 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 vCPU und 16 GB RAM. Weitere Informationen zu den Konzepten der SQL-Datenbankdimensionierung für Citrix Virtual Apps and Desktops 7.x-Bereitstellungen finden Sie in der 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 Überwachungsdatenbank je nach Datenspeicherungseinstellungen in der Größe variiert. XenApp und XenDesktop 7.15 LTSR verfügt über mehr Optionen als 7.6 LTSR, nachdem dem Produkt die Möglichkeit hinzugefügt wurde, granulare VDA-Leistungsdaten zu erfassen. Weitere Informationen zum Konfigurieren dieser Einstellungen finden Sie unter Überwachen von Richtlinieneinstellungen und berücksichtigen Sie dies bei den Berechnungen zur Datenbankgröße.
CU Updates und Fixes
Mehrmals im Jahr veröffentlicht Citrix CUs für Citrix Virtual Apps and Desktops LTSRs. Diese CUs enthalten nur Sicherheitsupdates und Fehlerbehebungen, 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 sind SQL-bezogen. Sie befassen sich mit Problemen wie Sperren, Deadlocks, Store-Prozeduren, die von Citrix oder unseren Kunden identifiziert wurden. Beispielsweise gibt es in den XenApp 7.6 CUs eine Reihe von SQL-bezogenen Korrekturen bis hin zu CU5. Die Empfehlung wäre, den Abschnitt “ Behobene Probleme “ für jede CU zu überprüfen und auf der Seite nach SQL zu suchen.
Hinweis:
LC8477 wurde in 7.6 CU5 und 7.17 veröffentlicht
Zusätzliche Referenzen
Beitrag von Henry Vernov, Principal System Engineer.