Leitfaden zur Datenbankgröße für XenApp- und XenDesktop-Versionen 7.6 bis zum aktuellen Release

Haftungsausschluss

Dieses Dokument enthält Links zu Websites, die von anderen Parteien als Citrix kontrolliert werden. Citrix ist nicht verantwortlich für den Inhalt oder die Nutzung dieser Websites Dritter und unterstützt oder übernimmt keine Verantwortung dafür. Citrix stellt Ihnen diese Links nur aus Gründen der Benutzerfreundlichkeit zur Verfügung, und die Aufnahme eines Links bedeutet nicht, dass Citrix die verlinkte Website befürwortet. Es liegt in Ihrer Verantwortung, Vorkehrungen zu treffen, um sicherzustellen, dass alles, was Sie für Ihre Verwendung auswählen, frei von Viren oder anderen zerstörerischen Elementen ist.

Überblick

Eine typische XenDesktop 7-Bereitstellung besteht wie folgt aus drei Datenbanken:

• Site-Konfigurationsdatenbank
  Speichert die aktuelle Konfiguration und den Status der XenDesktop-Bereitstellung
• Überwachungsdatenbank
  Speichert historische Daten zur Anzeige in Director
• Datenbank für Konfigurationsprotokollierung
  Verfolgt die an der XenDesktop-Bereitstellung vorgenommenen Konfigurationsänderungen

Standardmäßig befinden sich die Datenbanken für die Konfigurationsprotokollierung und Überwachung (die sekundären Datenbanken) auf demselben Server wie die Standortkonfigurationsdatenbank. Anfänglich haben alle drei Datenbanken den gleichen Namen. Citrix empfiehlt, den Speicherort der sekundären Datenbanken zu ändern, nachdem Sie eine Site erstellt haben.

Eine typische Bereitstellung verwendet auch die temporäre Datenbank TempDB, die von SQL Server bereitgestellt wird.

Jede Datenbank dient einem anderen Zweck und wächst mit einer anderen Geschwindigkeit.

Dieses Dokument enthält Informationen zu den einzelnen Datenbanken und hebt die wichtigsten Überlegungen hervor, die bei der Dimensionierung von Datenbanken zur Unterstützung von XenDesktop 7 zu berücksichtigen sind.

Hinweis: Alle angegebenen Zahlen sind Schätzungen. Es ist mit Abweichungen zwischen den Bereitstellungen zu rechnen.

In diesem Dokument werden auch Größenunterschiede zwischen Hosted Shared Desktops (HSD) und Virtual Desktop Infrastructure (VDI) erwähnt. In gemischten Umgebungen müssen die Schätzungen der beiden Desktoptypen kombiniert werden, um eine Schätzung der Gesamtdatenbankgröße zu erhalten.

Dokumentänderungen für XenDesktop 7.6

Dieses Dokument wurde auf Version 7.6 XenDesktop erweitert. Dies diente dazu, Updates zu den Größenänderungen für Funktionen zu ermöglichen, die in 7.6 hinzugefügt wurden. Die drei neuen Funktionen, die sich auf die Datenbankgröße auswirken, sind:

• Verbindungsleasing — Die komprimierten Leasingdateien werden in der Site-Datenbank gespeichert.
• Überwachung der App-Nutzung — Details aller in der Umgebung verwendeten Apps werden in der Monitor-Datenbank gespeichert
• Hotfix Inventory Monitoring — Details zu Citrix-Hotfixes, die auf die Controller, VDAs und VDA-Images in der Umgebung angewendet wurden

Die Informationen zur Tabellengröße wurden unten aktualisiert. Die Anzahl der Transaktionen pro Sekunde und das Wachstum der Transaktionsprotokolle waren in den Jahren 7,6 bis 7,5 ähnlich, sodass an diesen Abschnitten keine Aktualisierungen vorgenommen wurden.

Überlegungen auf hoher Ebene

Site-Datenbank

Die Standortdatenbank enthält Konfigurationsinformationen für den Betrieb des Systems.

Ihre Verwendung ist gekennzeichnet durch:

• Die maximale Größe wird zu Spitzenzeiten erreicht, da Benutzeranmeldungen Sitzungs- und Verbindungsinformationen generieren, die nachverfolgt werden müssen.
• Die Mindestgröße ist erreicht, wenn keine aktiven Sitzungen vorhanden sind und alle VDAs heruntergefahren und nicht registriert sind.
• Die Spitzengröße wird nach 48 Stunden erreicht, da die Datenbank nur sehr wenige persistente Informationen speichert. Dies ist darauf zurückzuführen, dass ein kleines Verbindungsprotokoll in der Site-Datenbank 48 Stunden lang aufbewahrt wird.
• Die Basisgröße der Datenbank wächst, wenn die Konfigurationsinformationen für eine Site wachsen. Das heißt, mehr Mitarbeiter und Benutzer verbrauchen mehr Datenbankspeicher.
• Während der Anmeldung kommt es zu einer hohen Anzahl von Transaktionen pro Sekunde, da für jede Benutzeranmeldung mehrere einzelne Transaktionen ausgeführt werden müssen. Diese Transaktionen werden auf der Grundlage der gleichzeitigen Startrate skaliert.
• Niedriges Hintergrundrauschen von VDA-Heartbeat-Transaktionen. Jeder VDA gibt alle 5 Minuten einen Heartbeat aus, und dieses Update löst eine Transaktion in der Datenbank aus.

Auswirkungen des Fehlers

Bei einem Ausfall der Standortdatenbank kann das System nicht verwaltet und überwacht werden. Bestehende Verbindungen werden beibehalten. In XenDesktop 7.6 ermöglicht Connection Leasing das Herstellen neuer Verbindungen und Wiederverbindungen. In früheren Versionen waren neue Verbindungen und Wiederverbindungen nicht möglich.

Überwachungsdatenbank

Die Monitoring-Datenbank enthält historische Informationen über die Site. Diese Informationen werden von Director verwendet, um historische Informationen anzuzeigen.

Ihre Verwendung ist gekennzeichnet durch:

• Die maximale Größe wird durch den konfigurierten Aufbewahrungszeitraum wie folgt gesteuert:
  • Für Nicht-Platin-Kunden ist die Standardeinstellung 7 Tage, mit einem Höchstzeitraum von 7 Tagen.
  • Für Platinum-Kunden beträgt die Standardeinstellung 90 Tage, ohne Höchstdauer.
• Es kann einige Zeit dauern, bis die Spitzengröße erreicht ist, da das System den konfigurierten Aufbewahrungszeitraum erreichen muss.
• Die Anzahl der Transaktionen pro Sekunde ist auf die Stapelverarbeitung der Aktualisierungen durch den Monitoring Service zurückzuführen. Es kommt selten vor, dass Transaktionen pro Sekunde die Marke von 20 Transaktionen pro Sekunde überschreiten.
• Einige Hintergrundtransaktionen, die durch regelmäßige Konsolidierungsanrufe des Monitoring Service verursacht wurden.
• Die Verarbeitung erfolgt über Nacht, um Daten außerhalb des konfigurierten Aufbewahrungszeitraums zu entfernen.

Auswirkungen des Fehlers

Ein Ausfall der Monitoring-Datenbank verhindert, dass Daten für die Site gesammelt werden, was bedeutet, dass Daten in Director nicht sichtbar sind.

Datenbank für die Konfigurationsprotokollierung

Die Datenbank für die Konfigurationsprotokollierung enthält ein historisches Protokoll aller Konfigurationsänderungen an der Site. Diese Informationen werden verwendet, um Berichte zu generieren oder in Studio angezeigt zu werden.

Ihre Verwendung ist gekennzeichnet durch:

• Die maximale Größe ist schwer vorherzusagen, da sie davon abhängt, wie viele Konfigurationsaktivitäten es gibt.
• Alle Aktionen von Director, z. B. das Zurücksetzen der Sitzung, werden in dieser Datenbank protokolliert, sodass es zu einem langsamen Wachstum kommen kann, wenn Administratoren Director verwenden.
• Minimale Transaktionen, die in der Datenbank auftreten, wenn keine Konfigurationsänderungen vorgenommen werden.
• Eine niedrige Transaktionsrate bei Updates, da Updates nach Möglichkeit gestapelt werden.
• Das manuelle Entfernen von Daten. Daten in der Datenbank für die Konfigurationsprotokollierung unterliegen keiner Aufbewahrungsrichtlinie und werden nur entfernt, wenn dies manuell von einem Administrator vorgenommen wird.

Auswirkungen des Fehlers

Die Auswirkungen eines Ausfalls der Configuration Logging-Datenbank hängen wie folgt von der Standortkonfiguration ab:

• Wenn die Site keine Änderungen zulässt, obwohl die Konfigurationsprotokollierungsdatenbank nicht verfügbar ist, ist es nicht möglich, die XenDesktop-Bereitstellung neu zu konfigurieren.
• Wenn die Site Änderungen zulässt, obwohl die Konfigurationsprotokollierungsdatenbank nicht verfügbar ist, können nicht verfolgte Konfigurationsänderungen an der XenDesktop-Bereitstellung vorgenommen werden.

Temporäre Datenbank

Die temporäre Datenbank ist eine systemweite Datenbank, die von SQL Server bereitgestellt wird. Es wird als Versionsspeicher für Read-Committed Snapshot Isolation verwendet. XenDesktop 7 verwendet dieses SQL Server-Feature, um Sperrkonflikte in den XenDesktop-Datenbanken zu reduzieren.

Die Größe des Versionsspeichers hängt von der Anzahl der aktiven Transaktionen ab. In der Regel sind es jedoch nicht mehr als ein paar MB.

Die Leistung von TempDB wirkt sich auf die Leistung von XenDesktop Brokering aus, da alle Transaktionen, die neue Daten generieren, TempDB-Speicherplatz benötigen. XenDesktop hat jedoch in der Regel kurzlebige Transaktionen, was dazu beiträgt, die Größe des Versionsspeichers klein zu halten.

Die temporäre Datenbank wird auch verwendet, wenn Abfragen große Zwischenergebnismengen generieren.

Hinweise zur Dimensionierung und Konfiguration der TempDB finden Sie in der Produktdokumentation von Microsoft:

https://docs.microsoft.com/en-us/sql/relational-databases/databases/tempdb-database?view=sql-server-ver15

Der Hauptstreitpunkt liegt in der Anzahl der zu verwendenden Dateien. Ältere Versionen von SQL Server, wie SQL Server 2000, benötigen mehr Dateien als neuere Versionen. Weitere Informationen zur Anzahl der zu verwendenden Dateien finden Sie unter:

http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-1230-tempdb-should-alwayshave-one-data-file-per-processor-core/

Snapshot-Isolierung mit Lesezugriff

Citrix empfiehlt, dass alle XenDesktop 7-Datenbanken Read-Committed Snapshot Isolation verwenden. Weitere Informationen finden Sie unter How to Enable Read-Committed Snapshot in XenDesktop.

Dimensionierung der Datenbanken

Die Datenbankgröße hängt von einer Reihe von Schlüsselfaktoren ab, einschließlich der Anzahl der Sitzungen und Verbindungen, die an einem Arbeitstag hergestellt wurden.

Eine Sitzung ist ein Desktop oder eine Anwendung, die über einen bestimmten Zeitraum ausgeführt wird und getrennt und erneut verbunden werden kann.

Eine Verbindung ist jedes Mal, wenn ein Benutzer eine Verbindung zu einer Sitzung herstellt. Beim Trennen der Verbindung wird die Verbindung geschlossen, aber nicht die Sitzung. Wenn ein Benutzer erneut eine Verbindung herstellt, wird eine neue Verbindung zu einer vorhandenen Sitzung hergestellt.

Site-Datenbank

Die maximale Größe der Site-Datenbank basiert wie folgt auf der Anzahl der VDAs und aktiven Sitzungen:

Jede veröffentlichte Anwendung fügt der Datenbank 110 KB hinzu, um jedes eindeutige Symbol zu speichern.

Hinweis:

Die erhöhte Größe für 7.6 ist darauf zurückzuführen, dass Verbindungsleases im Rahmen der Replikation zwischen Controllern in der Datenbank gespeichert werden.

Überwachungsdatenbank

Von den drei Datenbanken wird die Monitoring-Datenbank voraussichtlich im Laufe der Zeit zur größten werden.

Ihre Größe hängt von vielen Faktoren ab, darunter den folgenden:

• Anzahl der Nutzer
• Anzahl der Sitzungen
• Anzahl der Verbindungen
• VDI- oder HSD-Mitarbeiter
• Aufbewahrungszeitraum konfiguriert

Im Folgenden finden Sie Schätzungen für die Größe der Datenbank an einer Reihe von Datenpunkten. Bei diesen Daten handelt es sich um eine Schätzung, die auf Daten basiert, die beim Skalentest von XenDesktop ermittelt wurden. Die Schätzungen werden als realistisch angesehen.

Kunden, die ihre Datenbank verwalten, stellen jedoch möglicherweise fest, dass ihre Datenbank kleiner ist als die Schätzungen.

HSD-Benutzer basieren auf 100 Benutzern pro HSD-Server.

Maximale Aufbewahrungsfristen

Die maximale Menge der gespeicherten Daten wird per Lizenz wie folgt gesteuert:

• Kunden ohne Platinum-Mitgliedschaft können Daten für bis zu 1 Woche (7 Tage) aufbewahren.
• Platinum-Kunden können unbegrenzt viele Daten behalten; die Standardeinstellung ist 3 Monate (90 Tage).

Die Aufbewahrungsfristen können mithilfe des Cmdlets Set-MonitorConfiguration angepasst werden.

Wenn Daten älter als die konfigurierte Aufbewahrungsfrist sind, werden sie aus der Datenbank entfernt.

XenDesktop 7.5 Überwachung der Datenbankgröße

Schätzungen mit 1 Verbindung und 1 Sitzung pro Benutzer bei einer 5-tägigen Arbeitswoche

Schätzungen mit 2 Verbindungen und 1 Sitzung pro Benutzer bei einer 5-tägigen Arbeitswoche

Beachten Sie, dass HSDs im Laufe der Zeit aufgrund der Protokollierung von Lastausgleichsinformationen mehr Daten generieren, aber anfangs eine ähnliche Größe wie VDI-Desktops haben.

XenDesktop 7.6 Überwachung der Datenbankgröße

Die wichtigsten Änderungen gegenüber 7.5 sind:

• Hotfix-Informationen
  Die folgenden Daten basieren auf 3 Hotfixes pro Worker (VDI oder HSD)
• Nutzungsverlauf der Anwendung
  Dies ist hauptsächlich für HSD-Systeme relevant.

Schätzungen mit 1 Verbindung und 1 Sitzung pro Benutzer bei einer 5-tägigen Arbeitswoche

Schätzungen mit 2 Verbindungen und 1 Sitzung pro Benutzer bei einer 5-tägigen Arbeitswoche

Datenbank für die Konfigurationsprotokollierung

Die Bereitstellung von Leitlinien für die Dimensionierung der Datenbank für die Konfigurationsprotokollierung ist viel schwieriger, da sie je nach der täglichen Director-Aktivität und der Größe der konfigurierten Site stark variiert.

Aktivitäten, die sich auf Sitzungen oder Benutzer auswirken, werden protokolliert und beinhalten beispielsweise das Abmelden und Zurücksetzen der Sitzung. Passive Aktivitäten, wie das Auflisten der Sitzungen eines Benutzers, sind dies nicht.

Der für die Bereitstellung von Desktops verwendete Mechanismus wirkt sich auch auf die Größe der protokollierten Daten aus.

In HSD-Umgebungen, die MCS nicht verwenden, liegt die Datenbankgröße in der Regel zwischen 30 MB und 40 MB.

In MCS-Umgebungen kann die Datenbankgröße aufgrund der Protokollierung aller VM-Build-Daten leicht 200 MB überschreiten.

Für Version 7.6 wurden keine wesentlichen Änderungen an der Konfigurationsprotokollierungsdatenbank vorgenommen.

Datenbankaktivität bei der Anmeldung von 100.000 HSD-Sitzungen

Während des Skalierbarkeitstests, bei dem 100.000 HSD-Sitzungsanmeldungen simuliert wurden, wurde das Wachstum des Transaktionsprotokolls bei zwei Anmelderaten gemessen, und zwar wie folgt:

• 100.000 Benutzer melden sich über 1 Stunde an
• 100.000 Benutzer melden sich über 2 Stunden an

Diese Raten wurden ausgewählt, um Beispieldatenpunkte bereitzustellen.

Die Umgebung bestand aus:

• 2 Delivery Controller
• 43 HSD VDA-Mitarbeiter
• 3 SQL-Server, die mit den Datenbanken konfiguriert sind und sich in einer Always-On-Verfügbarkeitsgruppe befinden

Einzelheiten zu Serverkonfigurationen finden Sie am Ende dieses Dokuments.

Wachstum des Transaktionsprotokolls

Das Wachstum des Transaktionsprotokolls für alle Datenbanken wurde mithilfe des Leistungsmonitors SQLServer:Databases — Log File (s) Used Size (KB) überwacht.

Site-Datenbank

Wenn das System inaktiv ist, wächst das Transaktionslog um 3,5 MB pro Stunde. Dies ist eine Kombination aus VDA- und Broker Service-Heartbeats.

Das Wachstum des Baumstamms verläuft über den gemessenen Zeitraum linear. Diese Daten deuten darauf hin, dass das Transaktionsprotokoll pro Benutzeranmeldung um 20 KB wächst. Pro Benutzerabmeldung wächst das Transaktionslog um 12 KB.

Daher beträgt das Wachstum pro Tag 32 KB pro Benutzeranmelde-/Abmeldezyklus.

Überwachungsdatenbank

Wenn das System inaktiv ist, wächst das Transaktionslog um 30,5 MB pro Stunde. Dies ist eine Kombination aus gespeicherten Konsolidierungsprozeduren und HSD VDA-Lastindexaktualisierungen.

Das Logwachstum ist über den gemessenen Zeitraum linear. Diese Daten deuten darauf hin, dass das Transaktionsprotokoll pro Benutzeranmeldung um 7 KB wächst. Pro Benutzerabmeldung wächst das Transaktionslog um 2 KB.

Daher beträgt das Wachstum pro Tag 9 KB pro Benutzeranmelde-/Abmeldezyklus.

Transaktionen pro Sekunde

Das Wachstum des Transaktionsprotokolls für alle Datenbanken wurde mithilfe der folgenden Leistungsindikatoren überwacht:

• SQLServer:Datenbanken — Transaktionen/Sekunde
• SQLServer:Databases — Transaktionen schreiben/Sekunde

Site-Datenbank

Wenn sich das System im Leerlauf befindet, gibt es 5 Transaktionen/Sekunde, von denen 1 Schreibtransaktion/Sekunde die VDA- und Broker-Heartbeats aufrechterhält.

Hinweis: Bei diesen Zahlen handelt es sich um Schätzungen, die aus den angegebenen Zeiträumen stammen. Die genaue Auslastung hängt von der Anzahl der gleichzeitigen Starts pro Sekunde ab.

Überwachungsdatenbank

Wenn das System inaktiv ist, werden gespeicherte Konsolidierungsprozeduren einmal pro Minute ausgeführt und generieren Transaktionen. Das Niveau der Transaktionen ist jedoch gering. Im Allgemeinen gibt es 2—3 Transaktionen und eine Schreibtransaktion für jede gespeicherte Konsolidierungsprozedur, und es werden 3 gespeicherte Konsolidierungsprozeduren ausgeführt. In aktiven Zeiten steigt der Overhead, je mehr Arbeit ausgeführt wird.

Hinweis: Bei diesen Zahlen handelt es sich um Schätzungen, die aus den angegebenen Zeiträumen stammen.

CPU-Auslastung

Alle für diesen Test verwendeten SQL-Server waren Dual-Hexcore-Server mit aktiviertem Hyper-Threading. Die genauen Hardwarespezifikationen finden Sie am Ende dieses Dokuments.

Es war bekannt, dass die Server für die ausgeführte Last überdimensioniert waren. Auf diese Weise konnten wir die Einschränkungen und Höchstwerte der Hardware identifizieren. Es wird erwartet, dass die SQL-CPU-Last tatsächlich von einem SQL-Server mit einem einzigen Quad-Core-System hätte bewältigt werden können, und nicht von einem Dual-Hexcore-System.

Während der Tests wurde die System-CPU mithilfe des Leistungsmonitor-Zählers überwacht. Prozessor –% Prozessorzeit –\ _Total.

Primäres Replikat

Im Leerlauf lief die CPU mit 0-2% der verfügbaren CPU. Die gespeicherten Konsolidierungsprozeduren verursachten jede Minute für ~1 s Spitzenwerte auf 8-10% der System-CPU. Es wird erwartet, dass dies je nach Menge der verarbeiteten Daten skaliert wird.

Bei der Anmeldung von 100.000 Benutzern innerhalb einer Stunde stieg die CPU-Auslastung auf 7% und stieg linear auf 11%, da mehr Sitzungen und Benutzer in der Umgebung anwesend waren. Beachten Sie, dass die Spitzen der gespeicherten Konsolidierungsprozeduren die CPU-Gesamtleistung um 7% erhöhten, sodass die Spitzen 18% der CPU erreichten.

Während der Abmeldung lief die CPU mit 3,5%, wobei 7% zusätzliche CPU für die gespeicherten Konsolidierungsprozeduren hinzukamen. Insgesamt deutet dies darauf hin, dass<20% eines Dual-Hex-Core benötigt wurden, um die An- und Abmelderate aufrechtzuerhalten.

Hinweis: Der Windows Server 2012 Scheduler ist so voreingenommen, dass er Hyperthreads nur verwendet, wenn dies erforderlich ist. Das heißt, bis das System eine Auslastung von 50% erreicht hat, führt es, wenn möglich, nur einen Thread pro Kern aus, sodass eine 20% -Last von 24 Hyperthreads auf 4,8 Kernen ausgeführt wird.

Angesichts der Arbeitslast wird davon ausgegangen, dass dies ein schwerer Stresstest ist und dass ein einzelner Quad-Core-SQL-Server für XenDesktop-Bereitstellungen ausreichend wäre.

Sekundäre Replikate

Es wurde festgestellt, dass sekundäre Replikate bei der Anmeldung 2% der CPU konfigurieren und bei der Abmeldung 1,5%. Dies ist zu erwarten, da Replikate in den meisten Fällen Daten vom Primärreplikat auf ihren Festplatten speichern und nur das synchrone Replikat an Transaktionen beteiligt ist, da das Prinzipalreplikat eine Transaktion erst festschreibt, wenn das sekundäre Replikat sie bestätigt.

Basierend auf Empfehlungen für HA-Hardware, die dem primären Replikat entspricht, würde diese Last von einem ähnlich spezifizierten Server sehr einfach bewältigt werden.

Temporäre Datenbanknutzung

Die TempDB wird für viele Zwecke verwendet, einschließlich Versionsspeicher, Speicherplatz für große Abfragesätze und andere temporäre Tabellennutzung.

TempDB-Dimensionierung

In dieser SQL-Konfiguration wurde TempDB so konfiguriert, dass es 8 Datenbankdateien mit einer festen Größe von 5 GB hat. Dies ermöglicht eine bessere gleichzeitige Nutzung von TempDB, bietet aber auch viel Speicherplatz und löst keine Autogrow-Ereignisse aus. Aufgrund der erfassten Daten war es für diesen Einsatz überdimensioniert. Es war jedoch ausreichend Speicherplatz verfügbar.

Es entspricht auch den allgemeinen Richtlinien, nach denen die Anzahl der TempDB-Datenbankdateien zwischen einem Viertel und der Hälfte der Anzahl der verfügbaren CPUs liegt, aber nicht mehr als 8 beträgt, ohne zu wissen, dass tatsächlich ein Konflikt besteht.

Beachten Sie, dass nur eine TempDB-Protokolldatei verwendet wird, da SQL Server nicht von mehreren Protokolldateien profitiert.

Versionsspeicher

TempDB enthält einen Versionsspeicher für Zeilenversionen, die sich auf die Read Committed Snapshot Isolation beziehen, die von XenDesktop-Datenbanken verwendet wird.

Die Nutzung kann anhand der folgenden Leistungsindikatoren gemessen werden:

• SQLServer:Transactions — Größe des Versionsspeichers (KB)
• SQLServer:Transactions — Versionsbereinigungsrate (KB/s)
• SQLServer:Transactions — Versionsgenerierungsrate (KB/s)

Bei einer Anmeldung von 100.000 Personen über einen Zeitraum von 1 Stunde blieb die Größe des Versionsspeichers im Bereich von 10 MB bis 30 MB, was bei der Erstellung und anschließenden Bereinigung der Versionen zu einem Sägezahneffekt führte. Bei der Abmeldung lag der Bereich zwischen 10 MB und 21 MB. Im Leerlauf lag die Größe des Versionsspeichers zwischen 1 MB und 4 MB.

Die Versionsgenerierungsrate lag bei der Anmeldung im Bereich von 250—500 KB, bei der Abmeldung zwischen 150—400 KB/s und im Leerlauf zwischen 0—250 KB/s.

Die Versionsbereinigung wird einmal pro Minute ausgeführt und erreichte 2.500 KB/s bei der Anmeldung, 1.750 KB/s bei der Abmeldung und 400 KB/s während Leerlaufzeiten.

Festplatten-I/O

Während der Anmeldetests wurde die Festplatten-I/O mit den folgenden Leistungsindikatoren gemessen:

• PhysicalDisk — Festplattenlesebytes/Sekunde
• PhysicalDisk — Festplattenschreibbytes/Sekunde
• PhysicalDisk — Festplattenlese/Sekunde
• PhysicalDisk — Schreibvorgänge auf der Festplatte pro Sekunde

Es wurde festgestellt, dass die Lese-I/O minimal war, da der SQL-Server in der Lage war, alle Daten im Speicher zu halten, was zu einer sehr geringen Leseaktivität auf dem System führte.

Aufgrund des Layouts der Datenbanken und des Speichersystems wurden die Volumes aufgeteilt, wobei ein Volume alle Datendateien und ein zweites Volume alle Transaktionslogdateien enthielt.

Die Daten zeigen ein Muster, das sich nur schwer in eine Tabelle einfügen lässt. Im Allgemeinen hatte das Transaktionslog eine Schreibbyte/Sekunde von 800 KB/s für den 1-stündigen Test und 400 KB/s für den 2-stündigen Test. Einmal pro Minute, wenn die gespeicherten Konsolidierungsprozeduren ausgeführt wurden, wies das Transaktionslog Spitzenwerte von bis zu 30 MB/s auf.

Die Analyse der gespeicherten Konsolidierungsprozeduren zeigt, dass der Abfrageplan manchmal aufgrund der Statistiken suboptimal ist und eine temporäre Tabelle in TempDB übergeht. Dadurch werden Schreibvorgänge in das Transaktionslog für TempDB ausgelöst.

Diese Datenübertragung entspricht einem stetigen Zustand von 300 Schreib-IOPS (Input/Output Operations Per Second) für den einstündigen Test und 200 Schreib-IOPS für den 2-stündigen Test. Die Spitzen für die gespeicherten Konsolidierungsprozeduren fügen während der Ausführung weitere 2—300 Schreib-IOPS hinzu. Beachten Sie, dass die gespeicherten Konsolidierungsprozeduren in einer großen Umgebung weniger als eine Sekunde lang ausgeführt werden.

Wenn jede Datenbank überprüft wird, werden Daten aus den In-Memory-Tabellen mit Datendateien auf dem Datenvolume synchronisiert.

Weitere Informationen zu SQL-Prüfpunkten finden Sie unter http://technet.microsoft.com/enus/.

Bei diesen Checkpoints handelt es sich um sehr kurze Aktivitätsperioden, in der Regel weniger als 1 Sekunde.

Während der Anmeldung verbrauchten die Checkpoints 6—7 MB/s und 500 Schreib-IOPS. Während der Abmeldung verbrauchten die Checkpoints 7 MB/s, was zwischen 200 und 700 IOPS lag. Die Zahlen variieren, da die Site- und Monitoring-Datenbanken unterschiedliche Datenmengen für den Checkpoint enthalten.

Wartung der Datenbank

Die Datenbankwartung in einer großen Bereitstellung ist wichtig. Wenn die Datenbank nicht ordnungsgemäß verwaltet wird, kann es aufgrund von fehlendem Datenbankspeicherplatz zu Datenbankausfällen kommen, z. B. wenn das Transaktionslog auf automatische Vergrößerung eingestellt ist und die Festplatte füllt, oder wenn das Transaktionslog eine feste Größe hat und voll wird.

Verwaltung des Transaktionsprotokolls

Wenn Sie SQL Server-Funktionen für hohe Verfügbarkeit verwenden, z. B. AlwaysOn-Verfügbarkeitsgruppen oder Datenbankspiegelung, werden die XenDesktop-Datenbanken im Modus Vollständige Transaktionsprotokollierung ausgeführt.

Wenn das Transaktionslog im Modus Vollständige Transaktionsprotokollierung ausgeführt wird, wächst das Transaktionslog weiter, bis eine Datenbank- oder Transaktionslog-Backup erstellt wird.

Dies kann zu Problemen führen, wenn die Transaktionsprotokolldateien nicht überwacht werden, da SQL Server die Protokolldateien standardmäßig so konfiguriert, dass sie automatisch vergrößert werden. Dies verursacht 2 Probleme:

1. Die Transaktionsprotokolldateien können viel Speicherplatz beanspruchen.
2. Jedes Mal, wenn das Transaktionslog wächst, werden alle Transaktionen angehalten, bis der Protokollspeicher auf Null gesetzt wurde.

Citrix empfiehlt, die Protokolldateien regelmäßig zu sichern. Dies kann mit geplanten Aufträgen oder Wartungsplänen geschehen.

Verwenden Sie alternativ den SQL Server-Agenten, um zu überwachen, wann die verwendete Protokollgröße einen Schwellenwert überschreitet, und führen Sie einen Sicherungsauftrag aus.

Beim Skalentest wurde ein Protokoll mit fester Größe von 4 GB verwendet, und es wurde eine Warnung eingerichtet, um das Protokoll in einer anderen Datei zu sichern, wenn die Protokolldatei zu 80% voll war. Dadurch wurde verhindert, dass das Protokoll wuchs und den gesamten Speicherplatz beanspruchte. Außerdem wurde der Speicherplatz nicht auf Null gesetzt und die Datenbank ins Stocken geraten.

Ein Beispieljob würde ein Skript wie das Folgende ausführen:

  BACKUP LOG [CitrixXenDesktop-SiteDB] TO DISK = N'D:\LogBackup\CitrixXenDesktopSiteDB.bak' WITH NOFORMAT, NOINIT, COMPRESSION, NAME = N'Site-Transaction Log Backup', SKIP, NOREWIND, NOUNLOAD

Der für die Warnung zu verwendende SQL-Leistungsindikator lautet:

SQLServer:Datenbanken — Verwendetes Protokoll in Prozent — CitrixxenDesktopSiteDB

Wiederholen Sie dies für jede der 3 Datenbanken.

Es wurde festgestellt, dass das Backup der Protokolldatei nur minimale Auswirkungen auf eine laufende XenDesktop-Umgebung hat. Die Brokering-Zeiten haben geringfügig zugenommen, aber wir glauben nicht, dass dies signifikant ist.

Weitere Informationen zur Konfiguration von Jobs finden Sie unter: https://docs.microsoft.com/en-us/sql/ssms/agent/create-a-job?view=sql-server-ver15

Weitere Informationen zur Konfiguration von Warnmeldungen finden Sie unter: https://docs.microsoft.com/en-us/sql/ssms/agent/alerts?view=sql-server-ver15

Pflege des Indexes

Wenn mehr Daten in die Datenbank eingegeben werden, werden einige der Indizes weniger voll, das heißt, auf jeder SQL-Seite werden weniger Datensätze gespeichert. Eine SQL-Seite ist 8 KB groß. Dies führt dazu, dass die Datenbank ihren Speicherbedarf erhöht, sowohl im Arbeitsspeicher als auch auf der Festplatte. Durch die Beibehaltung der Indizes kann die Seitenfülle erhöht werden, was den Speicherbedarf der Datenbank reduziert.

Citrix empfiehlt den Kunden, Wartungspläne so einzurichten, dass sie jede Nacht und jede Woche ausgeführt werden, um die Indizes zu verwalten. Die Wartungspläne können einfach darin bestehen, die Indizes während der Woche über Nacht neu zu organisieren und die Indizes am Wochenende neu zu erstellen.

Mit dieser Empfehlung 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, Indizes neu zu erstellen, wenn sie zu mehr als 30% fragmentiert sind, und neu zu organisieren, wenn sie zu weniger als 30% fragmentiert sind. Weitere Informationen finden Sie unter der Microsoft-Dokumentation.

Nach der Neuorganisation der Indizes sollten auch die Statistiken aktualisiert werden. Dies ist besonders wichtig, wenn die Datenbank wächst. Andernfalls sind einige Statistiken möglicherweise schlecht und SQL generiert möglicherweise suboptimale SQL-Abfragepläne.

In Bezug auf den eingesparten Speicherplatz wurde das unten stehende Microsoft-Skript mit einer 1,2 GB großen Monitoring-Datenbank ausgeführt. Es verbesserte die Seitenfüllung und gab 300 MB Speicherplatz frei.

Skripte von Drittanbietern

Microsoft

Microsoft empfiehlt, die Indizes für ihre WSUS-SQL-Datenbanken mithilfe des Skripts zu aktualisieren, das unter folgender Adresse verfügbar ist:

https://learn.microsoft.com/en-us/troubleshoot/mem/configmgr/update-management/reindex-the-wsus-database

Durch Ändern von „USE SUSDB“ kann dieses Skript auch für XenDesktop-Datenbanken ausgeführt werden. Dieses Skript folgt der bewährten Methode von Microsoft, Indizes, die zu über 30% fragmentiert sind, neu zu erstellen und Indizes unter 30% neu zu organisieren. Anschließend werden die Statistiken für die Datenbank aktualisiert.

Ola Hallengren

Fortgeschrittenere Skripte sind auch erhältlich bei:

http://ola.hallengren.com/

Diese Skripts werden in der SQL Server-Community sehr geschätzt. Insbesondere die Index-Skripte sind verfügbar unter:

http://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html

Diese Skripte können für eine genauere Steuerung der Ebenen verwendet werden, um Indizes neu zu organisieren oder neu zu erstellen.

Serverkonfiguration testen

Konfiguration des SQL-Servers

Die SQL Availability Group bestand aus 3 identisch spezifizierten Dell R720XD Servern.

Systemspezifikation:

• 2-Hexcore-Intel-Xeon-CPU E5-2630 mit 2,30 GHz und aktiviertem Hyperthreading
• 64 GB ECC-RAM
• PERC H710P Mini mit 1 GB batteriegepuffertem Cache
• 26 SAS-Laufwerke mit 300 GB und 10.000 U/min

Die Festplatten wurden in die folgenden Volumes aufgeteilt:

• Systemlautstärke
  • Enthält das Betriebssystem und die Seitendatei
  • 2 Festplatten als RAID 1-Spiegel
  • Gesamtkapazität 278 GB
• Datenbank-Volume
  • Enthält die SQL Server-Instanz und die Datenbankdatendateien
  • 16 Festplatten als gespiegelter RAID 10-Stripe
  • Gesamtkapazität 2.231 GB
• Volumen protokollieren
  • Enthält die Datenbank-Logdateien
  • 8 Festplatten als gespiegelter RAID 10-Stripe
  • Gesamtkapazität 1.115 GB
• Software:
  • Windows Server 2012 R2 Standard Edition, mit aktuellen Windows-Updates zum Zeitpunkt des Tests (August 2014)
  • SQL Server Enterprise 2012 SP2 mit kumulativem Update 1
• Änderungen an der Konfiguration
  • SQL Server wurde für die Verwendung von maximal 61.440 MB konfiguriert
  • Die Datenbankeindämmung wurde auf allen SQL-Instanzen aktiviert
  • Der SQL Server Agent-Dienst wurde so konfiguriert, dass er automatisch gestartet wird
• Einrichtung der Verfügbarkeitsgruppe:
  • Alle Server wurden in einem Windows-Failovercluster platziert
  • Eine AlwaysOn-Verfügbarkeitsgruppe wurde innerhalb des Clusters konfiguriert
  • Die sekundären Replikate wurden als synchrones Commit konfiguriert, sodass die Transaktionen auf beiden Replikaten festgeschrieben werden müssen, bevor die Transaktion abgeschlossen wird.
  • Schreibgeschütztes Replikatrouting wurde für die Verfügbarkeitsgruppe konfiguriert und aktiviert

Delivery Controller und HSD Testserver

Der Delivery Controller und der HSD Testserver liefen auf derselben Hardwarekonfiguration und verwendeten HP BL460c G1 Blades. Für die Delivery Controller wurden 2 Server verwendet, und 43 Server stellten den simulierten HSD-Workload bereit.

Hinweis: Obwohl diese Server relativ alt sind, ist die Arbeitslast auf den HSD-Servern gering, da sich die Sitzungssimulation hauptsächlich darauf konzentriert, die Delivery Controller und nicht die HSD-Server zu belasten.

Systemspezifikation:

• 2 Quad-Core-Intel Xeon L5320 mit 1,86 GHz, nicht Hyperthread-fähig
• 16 GB ECC-RAM
• HP Smart Array E200I Raid-Karte (kein batteriegepufferter Cache)
• Eine 36 GB oder 72 GB SAS-Festplatte

Software:

• Windows Server 2012 R2 Standard Edition, mit aktuellen Windows-Updates zum Zeitpunkt des Tests (August 2014)
• Citrix XenDesktop 7.6