Leitfaden zur Datenbankdimensionierung für XenApp- und XenDesktop-Versionen 7.6 bis zur aktuellen Version

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 befürwortet oder übernimmt keine Verantwortung dafür. Citrix stellt Ihnen diese Links lediglich als Annehmlichkeit zur Verfügung, und die Aufnahme eines Links bedeutet keine Billigung der verlinkten Website durch Citrix. Es liegt in Ihrer Verantwortung, Vorkehrungen zu treffen, um sicherzustellen, dass alles, was Sie für Ihre Nutzung auswählen, frei von Viren oder anderen schädlichen Elementen ist.

Übersicht

Eine typische XenDesktop® 7-Bereitstellung besteht aus drei Datenbanken, und zwar:

• Site-Konfigurationsdatenbank Speichert die aktuelle Konfiguration und den Status der XenDesktop-Bereitstellung
• Überwachungsdatenbank Speichert Verlaufsdaten zur Anzeige in Director
• Konfigurationsprotokollierungsdatenbank Verfolgt Konfigurationsänderungen, die an der XenDesktop-Bereitstellung vorgenommen wurden

Standardmäßig befinden sich die Konfigurationsprotokollierungs- und Überwachungsdatenbanken (die sekundären Datenbanken) auf demselben Server wie die Site-Konfigurationsdatenbank. Anfänglich haben alle drei Datenbanken denselben 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 Rate.

Dieses Dokument enthält Informationen zu jeder Datenbank 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ätzwerte. Abweichungen zwischen Bereitstellungen sind zu erwarten.

Unterschiede in der Dimensionierung zwischen Hosted Shared Desktops (HSD) und Virtual Desktop Infrastructure (VDI) werden in diesem Dokument ebenfalls erwähnt. Gemischte Umgebungen müssen die Schätzungen der beiden Desktop-Typen kombinieren, um eine Schätzung der gesamten Datenbankgröße zu erstellen.

Dokumentänderungen für XenDesktop 7.6

Dieses Dokument wurde erweitert, um XenDesktop 7.6 abzudecken. Dies ermöglichte Aktualisierungen der Größenänderungen für in 7.6 hinzugefügte Funktionen. Die drei neuen Funktionen, die sich auf die Datenbankgröße auswirken, sind:

• Verbindungsleasing – die komprimierten Lease-Dateien werden in der Site-Datenbank gespeichert
• App-Nutzungsüberwachung – Details aller in der Umgebung verwendeten Apps werden in der Überwachungsdatenbank gespeichert
• Hotfix-Bestandsüberwachung – Details zu Citrix-Hotfixes, die auf die Controller, VDAs und VDA-Images in der Umgebung angewendet wurden

Informationen zur Tabellengröße wurden unten aktualisiert. Transaktionen pro Sekunde und das Wachstum des Transaktionsprotokolls waren in 7.6 ähnlich wie in 7.5, daher wurden diese Abschnitte nicht aktualisiert.

Wichtige Überlegungen

Site-Datenbank

Die Site-Datenbank enthält Konfigurationsinformationen für den Betrieb des Systems.

Ihre Nutzung ist gekennzeichnet durch:

• Die maximale Größe wird während der Spitzenzeiten erreicht, da Benutzeranmeldungen Sitzungs- und Verbindungsinformationen generieren, die verfolgt werden müssen.
• Die minimale Größe wird erreicht, wenn keine aktiven Sitzungen vorhanden sind und alle VDAs heruntergefahren und abgemeldet sind.
• Die Spitzengröße wird nach 48 Stunden erreicht, da die Datenbank nur sehr wenige persistente Informationen speichert. Dies liegt daran, dass ein kleines Protokoll von Verbindungen für 48 Stunden in der Site-Datenbank geführt wird.
• Die Basisgröße der Datenbank wächst mit den Konfigurationsinformationen für eine Site. Das heißt, mehr Worker und Benutzer verbrauchen mehr Datenbankspeicherplatz.
• Hohe Transaktionsraten pro Sekunde treten während der Anmeldung auf, da jede Benutzeranmeldung mehrere einzelne Transaktionen erfordert und sich nach der gleichzeitigen Startrate skaliert.
• Geringes Hintergrundrauschen von VDA-Heartbeat-Transaktionen. Jeder VDA sendet alle 5 Minuten einen Heartbeat, und diese Aktualisierung löst eine Transaktion in der Datenbank aus.

Auswirkungen eines Ausfalls

Ein Ausfall der Site-Datenbank macht das System unmöglich zu verwalten und zu überwachen. Bestehende Verbindungen bleiben erhalten. In XenDesktop 7.6 ermöglicht Connection Leasing neue Verbindungen und Wiederverbindungen. In früheren Versionen sind neue Verbindungen und Wiederverbindungen nicht möglich.

Überwachungsdatenbank

Die Überwachungsdatenbank enthält historische Informationen über die Site. Diese Informationen werden von Director verwendet, um historische Informationen anzuzeigen.

Ihre Nutzung ist gekennzeichnet durch:

• Die maximale Größe wird durch den konfigurierten Aufbewahrungszeitraum gesteuert, wie folgt:
  • Für Nicht-Platinum-Kunden beträgt der Standard 7 Tage, mit einem maximalen Zeitraum von 7 Tagen.
  • Für Platinum-Kunden beträgt der Standard 90 Tage, ohne maximalen Zeitraum.
• Die Spitzengröße kann einige Zeit in Anspruch nehmen, da das System den konfigurierten Aufbewahrungszeitraum erreichen muss.
• Niedrige Transaktionsraten pro Sekunde treten aufgrund der Batch-Verarbeitung von Updates durch den Überwachungsdienst auf. Es ist selten, dass die Transaktionen pro Sekunde die Marke von 20 Transaktionen pro Sekunde überschreiten.
• Einige Hintergrundtransaktionen, die durch regelmäßige Konsolidierungsaufrufe vom Überwachungsdienst verursacht werden.
• Die nächtliche Verarbeitung wird durchgeführt, um Daten außerhalb des konfigurierten Aufbewahrungszeitraums zu entfernen.

Auswirkungen eines Ausfalls

Ein Ausfall der Überwachungsdatenbank verhindert die Datenerfassung für die Site, was bedeutet, dass die Daten in Director nicht sichtbar sind.

Konfigurationsprotokollierungsdatenbank

Die Konfigurationsprotokollierungsdatenbank enthält ein historisches Protokoll aller Konfigurationsänderungen an der Site. Diese Informationen werden verwendet, um Berichte zu erstellen oder in Studio angezeigt zu werden.

Ihre Nutzung zeichnet sich aus durch:

• Die maximale Größe ist schwer vorherzusagen, da sie davon abhängt, wie viele Konfigurationsaktivitäten stattfinden.
• Alle Aktionen, z. B. das Zurücksetzen von Sitzungen, von Director werden in dieser Datenbank protokolliert, sodass es zu einem langsamen Wachstum kommen kann, wenn Administratoren Director verwenden.
• Minimale Transaktionen in der Datenbank, wenn keine Konfigurationsänderungen vorgenommen werden.
• Eine niedrige Transaktionsrate während Updates, da Updates, wo möglich, stapelweise verarbeitet werden.
• Die manuelle Entfernung von Daten. Daten in der Konfigurationsprotokollierungsdatenbank unterliegen keiner Aufbewahrungsrichtlinie und werden nur manuell von einem Administrator entfernt.

Auswirkungen eines Ausfalls

Die Auswirkungen eines Ausfalls der Konfigurationsprotokollierungsdatenbank hängen von der Site-Konfiguration ab, und zwar wie folgt:

• Wenn die Site keine Änderungen zulässt, während die Konfigurationsprotokollierungsdatenbank nicht verfügbar ist, ist es nicht möglich, die XenDesktop-Bereitstellung neu zu konfigurieren.
• Wenn die Site Änderungen zulässt, während die Konfigurationsprotokollierungsdatenbank nicht verfügbar ist, können nicht nachverfolgte 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. Sie wird als Versionsspeicher für die Read-Committed Snapshot Isolation verwendet. XenDesktop 7 nutzt diese SQL Server-Funktion, um Sperrkonflikte in den XenDesktop-Datenbanken zu reduzieren.

Die Größe des Versionsspeichers hängt von der Anzahl der aktiven Transaktionen ab. Im Allgemeinen beträgt sie jedoch nicht mehr als wenige MB.

Die Leistung von TempDB beeinflusst die Leistung des XenDesktop-Brokerings, da alle Transaktionen, die neue Daten generieren, TempDB-Speicherplatz benötigen. XenDesktop neigt jedoch zu kurzlebigen Transaktionen, was dazu beiträgt, die Größe des Versionsspeichers gering zu halten.

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

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

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

Der Hauptstreitpunkt konzentriert sich auf die Anzahl der zu verwendenden Dateien. Ältere Versionen von SQL Server, wie SQL Server 2000, erfordern 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/

Read-Committed-Snapshot-Isolation

Citrix empfiehlt, dass alle XenDesktop 7-Datenbanken die Read-Committed-Snapshot-Isolation verwenden. Weitere Informationen finden Sie unter Aktivieren von Read-Committed Snapshot in XenDesktop.

Dimensionierung der Datenbanken

Die Datenbankgrößen hängen von einer Reihe wichtiger Faktoren ab, einschließlich der Anzahl der Sitzungen und Verbindungen, die während eines Arbeitstages erstellt werden.

Eine Sitzung ist jeder Desktop oder jede Anwendung, die für einen bestimmten Zeitraum ausgeführt wird und von der die Verbindung getrennt und wiederhergestellt werden kann.

Eine Verbindung ist jeder Zeitpunkt, zu dem ein Benutzer eine Verbindung zu einer Sitzung herstellt. Das Trennen der Verbindung schließt die Verbindung, aber nicht die Sitzung. Wenn ein Benutzer die Verbindung wiederherstellt, wird eine neue Verbindung zu einer bestehenden Sitzung hergestellt.

Sitedatenbank

Die maximale Größe der Sitedatenbank basiert auf der Anzahl der VDAs und aktiven Sitzungen, wie folgt:

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 Verbindungspachtverträge als Teil der Replikation zwischen Controllern in der Datenbank gespeichert werden.

Überwachungsdatenbank

Von den drei Datenbanken wird erwartet, dass die Überwachungsdatenbank im Laufe der Zeit am größten wird.

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

• Anzahl der Benutzer
• Anzahl der Sitzungen
• Anzahl der Verbindungen
• VDI- oder HSD-Worker
• Konfigurierte Aufbewahrungsfrist

Nachfolgend finden Sie Schätzungen für die Größe der Datenbank an verschiedenen Datenpunkten. Diese Daten sind eine Schätzung, die auf bei Skalierungstests von XenDesktop gewonnenen Daten basiert. Die Schätzungen gelten als realistisch.

Kunden, die ihre Datenbank pflegen, 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 maximal aufbewahrte Datenmenge wird durch die Lizenz wie folgt gesteuert:

• Nicht-Platinum-Kunden können Daten bis zu 1 Woche (7 Tage) aufbewahren.
• Platinum-Kunden können unbegrenzt Daten aufbewahren; die Standardeinstellung sind 3 Monate (90 Tage).

Aufbewahrungsfristen können mit dem Cmdlet Set-MonitorConfiguration angepasst werden.

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

XenDesktop 7.5 Überwachungsdatenbank-Dimensionierung

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

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

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

XenDesktop 7.6: Dimensionierung der Überwachungsdatenbank

Die wichtigsten Änderungen gegenüber 7.5 sind:

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

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

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

Konfigurationsprotokollierungsdatenbank

Eine Anleitung zur Größenbestimmung der Konfigurationsprotokollierungsdatenbank ist wesentlich schwieriger, da sie stark von der täglichen Director-Aktivität und der Größe der konfigurierten Site abhängt.

Aktivitäten, die sich auf Sitzungen oder Benutzer auswirken, werden protokolliert und umfassen beispielsweise die Abmeldung und das Zurücksetzen von Sitzungen. Passive Aktivitäten, wie das Auflisten der Sitzungen eines Benutzers, werden nicht protokolliert.

Der Mechanismus zur Bereitstellung von Desktops beeinflusst ebenfalls die Größe der protokollierten Daten.

In HSD-Umgebungen, die kein MCS verwenden, liegt die Datenbankgröße tendenziell 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 während der Anmeldung von 100.000 HSD-Sitzungen

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

• 100.000 Benutzer melden sich innerhalb von 1 Stunde an
• 100.000 Benutzer melden sich innerhalb von 2 Stunden an

Diese Raten wurden gewählt, um Beispieldatenpunkte bereitzustellen.

Die Umgebung umfasste:

• 2 Delivery Controller
• 43 HSD VDA Worker
• 3 SQL Server, konfiguriert mit den Datenbanken, die in einer Always On Availability Group enthalten sind

Details zu den Serverkonfigurationen finden Sie am Ende dieses Dokuments.

Transaktionsprotokoll-Wachstum

Das Wachstum des Transaktionsprotokolls für alle Datenbanken wurde mithilfe des Leistungsüberwachungszählers SqlServer:Databases – Log File(s) Used Size (KB) überwacht.

Sitedatenbank

Wenn das System im Leerlauf ist, wächst das Transaktionsprotokoll um 3,5 MB pro Stunde. Dies ist eine Kombination aus VDA- und Broker-Dienst-Heartbeats.

Das Protokollwachstum ist ü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 Transaktionsprotokoll um 12 KB.

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

Überwachungsdatenbank

Wenn das System im Leerlauf ist, wächst das Transaktionsprotokoll um 30,5 MB pro Stunde. Dies ist eine Kombination aus Konsolidierungs-Stored-Procedures und HSD VDA-Lastindex-Updates.

Das Protokollwachstum 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 Transaktionsprotokoll um 2 KB.

Daher beträgt das Wachstum pro Tag 9 KB pro An-/Abmeldezyklus des Benutzers.

Transaktionen pro Sekunde

Das Transaktionsprotokollwachstum für alle Datenbanken wurde mithilfe der folgenden Leistungsüberwachungsindikatoren überwacht:

• SqlServer:Databases – Transaktionen/Sekunde
• SqlServer:Databases – Schreibtransaktionen/Sekunde

Site-Datenbank

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

Hinweis: Diese Zahlen sind Schätzwerte aus den angegebenen Zeiträumen. Die genaue Last variiert je nach Anzahl der gleichzeitigen Starts pro Sekunde.

Überwachungsdatenbank

Wenn das System im Leerlauf ist, werden Konsolidierungs-Stored Procedures einmal pro Minute ausgeführt und generieren Transaktionen. Das Transaktionsvolumen ist jedoch gering. Im Allgemeinen gibt es 2–3 Transaktionen und 1 Schreibtransaktion für jede Konsolidierungs-Stored Procedure, und es werden 3 Konsolidierungs-Stored Procedures ausgeführt. In aktiven Perioden steigt der Overhead, da mehr Arbeit ausgeführt wird.

Hinweis: Diese Zahlen sind Schätzwerte aus den angegebenen Zeiträumen.

CPU-Auslastung

Alle für diesen Test verwendeten SQL-Server waren Dual-Hexa-Core-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. Dies ermöglichte es uns, die Einschränkungen und Maximalwerte der Hardware zu identifizieren. Es wird erwartet, dass die SQL-CPU-Last tatsächlich von einem SQL-Server mit einem einzelnen Quad-Core-System anstatt eines Dual-Hexa-Core-Systems hätte bewältigt werden können.

Während der Tests wurde die System-CPU mit dem Leistungsüberwachungszähler Prozessor – % Prozessorzeit – _Gesamt überwacht.

Primäres Replikat

Im Leerlauf lag die CPU-Auslastung bei 0-2 % der verfügbaren CPU. Die Konsolidierungs-Stored-Procedures verursachten jede Minute für ca. 1 Sekunde Spitzenwerte von 8-10 % der System-CPU. Es wird erwartet, dass dies je nach der Menge der verarbeiteten Daten skaliert.

Während der Anmeldung von 100.000 Benutzern innerhalb einer Stunde sprang die CPU auf 7 % und stieg linear auf 11 % an, je mehr Sitzungen und Benutzer in der Umgebung vorhanden waren. Beachten Sie, dass die Spitzen der Konsolidierungs-Stored-Procedures die Gesamt-CPU um 7 % erhöhten, wodurch die Spitzen 18 % der CPU erreichten.

Während der Abmeldung lag die CPU-Auslastung bei 3,5 %, mit zusätzlichen 7 % CPU für die Konsolidierungs-Stored-Procedures. Insgesamt deutet dies darauf hin, dass <20 % eines Dual-Hexa-Core-Systems erforderlich waren, um die An- und Abmelderate aufrechtzuerhalten.

Hinweis: Der Windows Server 2012 Scheduler ist darauf ausgelegt, Hyper-Threads nur bei Bedarf zu verwenden, d.h. bis das System 50 % Last erreicht, läuft er, wo möglich, nur einen Thread pro Kern, sodass eine 20 %ige Last auf 24 Hyper-Threads auf 4,8 Kernen läuft.

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

Sekundäre Replikate

Sekundäre Replikate konfigurierten 2 % CPU während der Anmeldung und 1,5 % während der Abmeldung. Dies ist zu erwarten, da Replikate größtenteils Daten vom primären Replikat auf ihren Festplatten speichern und nur das synchrone Replikat an Transaktionen beteiligt ist, da das primäre Replikat eine Transaktion erst festschreibt, wenn das sekundäre Replikat dies 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 leicht bewältigt werden.

Nutzung temporärer Datenbanken

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

TempDB-Dimensionierung

In dieser SQL-Konfiguration wurde die TempDB so konfiguriert, dass sie 8 Datenbankdateien hat, jede mit einer festen Größe von 5 GB. Dies ermöglicht eine bessere gleichzeitige Nutzung der TempDB, bietet aber auch viel Platz und löst keine Autogrow-Ereignisse aus. Basierend auf den erfassten Daten war sie für diese Bereitstellung überdimensioniert. Es war jedoch ausreichend Speicherplatz vorhanden.

Es entspricht auch der allgemeinen Empfehlung, dass die Anzahl der TempDB-Datenbankdateien zwischen einem Viertel und der Hälfte der verfügbaren CPUs liegen sollte, aber 8 nicht überschreiten sollte, ohne dass eine tatsächliche Konfliktsituation bekannt ist.

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

Versionsspeicher

Die TempDB enthält einen Versionsspeicher für Zeilenversionen im Zusammenhang mit der Read Committed Snapshot Isolation, die von XenDesktop-Datenbanken verwendet wird.

Die Nutzung kann mit den folgenden Leistungsindikatoren gemessen werden:

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

Während 100.000 Anmeldungen über 1 Stunde blieb die Größe des Versionsspeichers im Bereich von 10 MB bis 30 MB, mit einem Sägezahneffekt, da Versionen erstellt und dann bereinigt wurden. Während der Abmeldung lag der Bereich bei 10 MB bis 21 MB. Im Leerlauf lag die Größe des Versionsspeichers zwischen 1 MB und 4 MB.

Die Versionsgenerierungsrate lag während der Anmeldung im Bereich von 250–500 KB; 150–400 KB/s während der Abmeldung und 0–250 KB/s im Leerlauf.

Die Versionsbereinigung läuft einmal pro Minute und erreichte 2.500 KB/s während der Anmeldung, 1.750 KB/s während der Abmeldung und 400 KB/s in Leerlaufzeiten.

Datenträger-I/O

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

• PhysicalDisk – Festplattenlesebytes/Sekunde
• PhysicalDisk – Festplattenschreibbytes/Sekunde
• PhysicalDisk – Festplattenlesevorgänge/Sekunde
• PhysicalDisk – Festplattenschreibvorgänge/Sekunde

Die Lese-E/A erwies sich als minimal, da der SQL-Server alle Daten im Speicher halten konnte, was zu sehr geringer 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 Transaktionsprotokolldateien enthielt.

Die Daten zeigen ein Muster, das sich schwer in eine Tabelle einordnen lässt. Im Allgemeinen hatte das Transaktionsprotokoll eine Schreibbyte-Rate von 800 KB/s für den 1-Stunden-Test und 400 KB/s für den 2-Stunden-Test. Einmal pro Minute, wenn die Konsolidierungs-Stored Procedures ausgeführt wurden, zeigte das Transaktionsprotokoll Spitzenwerte von 30 MB/s.

Die Analyse der Konsolidierungs-Stored Procedures zeigt, dass die Statistiken manchmal den Abfrageplan suboptimal machen und eine temporäre Tabelle in TempDB überläuft. Dies löst Schreibvorgänge in das Transaktionsprotokoll für TempDB aus.

Diese Datenübertragung entspricht einem stabilen Zustand von 300 Schreib-Input/Output Operations Per Second (IOPS) für den 1-Stunden-Test und 200 Schreib-IOPS für den 2-Stunden-Test. Die Spitzenwerte für die Konsolidierungs-Stored Procedures fügen während der Ausführung weitere 2–300 Schreib-IOPS hinzu. Beachten Sie, dass in einer großen Umgebung die Konsolidierungs-Stored Procedures weniger als eine Sekunde lang ausgeführt werden.

Wenn jede Datenbank einen Checkpoint durchläuft, werden Daten von den In-Memory-Tabellen in Datendateien auf dem Datenvolume synchronisiert.

Weitere Informationen zum SQL-Checkpointing finden Sie unter weitere Informationen.

Diese Checkpoints sind sehr kurze Aktivitätsperioden, im Allgemeinen 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, im Bereich von 200–700 IOPS. Die Zahlen variieren, da die Site- und Monitoring-Datenbanken unterschiedliche Datenmengen zum Checkpointen haben.

Datenbankwartung

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

Wartung des Transaktionsprotokolls

Bei der Verwendung von SQL Server Hochverfügbarkeitsfunktionen, z. B. Always On-Verfügbarkeitsgruppen oder Datenbankspiegelung, werden die XenDesktop-Datenbanken im Modus für vollständige Transaktionsprotokollierung ausgeführt.

Durch den Betrieb im Modus für vollständige Transaktionsprotokollierung wächst das Transaktionsprotokoll weiter, bis eine Datenbank- oder Transaktionsprotokollsicherung durchgeführt 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 wachsen. Dies verursacht zwei Probleme:

1. Die Transaktionsprotokolldateien können viel Speicherplatz belegen.
2. Jedes Mal, wenn das Transaktionsprotokoll 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 erfolgen.

Alternativ können Sie den SQL Server Agent verwenden, um zu überwachen, wann die genutzte Protokollgröße einen Schwellenwert überschreitet, und einen Sicherungsauftrag ausführen.

Bei Skalierungstests wurde ein Protokoll mit fester Größe von 4 GB verwendet, und es wurde ein Alarm eingestellt, um das Protokoll in eine andere Datei zu sichern, wenn die Protokolldatei zu 80 % voll war. Dies verhinderte, dass das Protokoll wuchs und den gesamten Speicherplatz belegte, und verhinderte auch, dass es den Speicherplatz auf Null setzte und die Datenbank zum Stillstand brachte.

Ein Beispielauftrag würde ein Skript wie dieses 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 den Alarm zu verwendende SQL-Leistungsindikator ist:

SQLServer:Databases - Percent Log Used - CitrixXenDesktopSiteDB

Wiederholen Sie dies für jede der 3 Datenbanken.

Es wurde festgestellt, dass die Sicherung der Protokolldatei nur minimale Auswirkungen auf eine laufende XenDesktop-Umgebung hatte; es gab eine geringfügige Zunahme der Brokerzeiten, die wir jedoch nicht als signifikant erachten.

Weitere Informationen zum Konfigurieren von Aufträgen finden Sie unter: https://docs.microsoft.com/de-de/sql/ssms/agent/create-a-job?view=sql-server-ver15

Weitere Informationen zum Konfigurieren von Warnungen finden Sie unter: https://docs.microsoft.com/de-de/sql/ssms/agent/alerts?view=sql-server-ver15

Indexwartung

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

Citrix empfiehlt Kunden, Wartungspläne einzurichten, die nächtlich und wöchentlich ausgeführt werden, um die Indizes zu warten. Die Wartungspläne können einfach darin bestehen, die Indizes unter der Woche nachts zu reorganisieren und am Wochenende neu zu erstellen.

Diese Empfehlung vermeidet Leistungseinbußen durch das Neuerstellen großer Indizes während des täglichen Betriebs, insbesondere bei einer großen Überwachungsdatenbank.

Microsoft empfiehlt, Indizes neu zu erstellen, wenn sie zu mehr als 30 % fragmentiert sind, und sie zu reorganisieren, wenn sie weniger als 30 % fragmentiert sind. Weitere Informationen finden Sie in der Microsoft-Dokumentation.

Nach der Reorganisation von Indizes sollten auch die Statistiken aktualisiert werden. Dies ist besonders wichtig, wenn die Datenbank wächst; andernfalls könnten einige Statistiken schlecht sein und SQL könnte suboptimale SQL-Abfragepläne generieren.

In Bezug auf den eingesparten Speicherplatz wurde das unten stehende Microsoft-Skript für eine 1,2 GB große Überwachungsdatenbank 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 mit dem Skript zu aktualisieren, das unter folgender Adresse verfügbar ist:

https://learn.microsoft.com/de-de/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 Best Practice von Microsoft, Indizes, die zu mehr als 30 % fragmentiert sind, neu zu erstellen und diejenigen, die zu weniger als 30 % fragmentiert sind, zu reorganisieren. Anschließend werden die Statistiken für die Datenbank aktualisiert.

Ola Hallengren

Fortgeschrittenere Skripte sind auch verfügbar unter:

http://ola.hallengren.com/

Diese Skripte sind in der SQL Server-Community hoch angesehen. Insbesondere die Index-Skripte, die verfügbar sind unter:

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

Diese Skripte können für eine feinere Kontrolle über die Ebenen zur Reorganisation oder Neuerstellung von Indizes verwendet werden.

Testserver-Konfiguration

SQL Server-Konfiguration

Die SQL-Verfügbarkeitsgruppe bestand aus 3 identisch spezifizierten Dell R720XD-Servern.

Systemspezifikation:

• 2 Hexa-Core Intel Xeon CPU E5-2630 mit 2,30 GHz und aktiviertem Hyper-Threading
• 64 GB ECC RAM
• PERC H710P Mini mit 1 GB batteriegestütztem Cache
• 26 300 GB 10.000 U/min SAS-Laufwerke

Die Festplatten wurden in folgende Volumes aufgeteilt:

• Systemvolume
  • Enthält das Betriebssystem und die Auslagerungsdatei
  • 2 Festplatten als RAID 1-Spiegel
  • Gesamtkapazität 278 GB
• Datenbank-Volume
  • Enthält die SQL Server-Instanz und Datenbankdatendateien
  • 16 Festplatten als RAID 10-Spiegel-Stripe
  • Gesamtkapazität 2.231 GB
• Protokoll-Volume
  • Enthält die Datenbankprotokolldateien
  • 8 Festplatten als RAID 10-Spiegel-Stripe
  • Gesamtkapazität 1.115 GB
• Software:
  • Windows Server 2012 R2 Standard Edition, mit aktuellen Windows-Updates zum Zeitpunkt der Tests (August 2014)
  • SQL Server Enterprise 2012 SP2 mit kumulativem Update 1
• Konfigurationsänderungen
  • SQL Server wurde so konfiguriert, dass es maximal 61.440 MB verwendet.
  • Datenbank-Containment wurde auf allen SQL-Instanzen aktiviert.
  • Der SQL Server Agent-Dienst wurde so konfiguriert, dass er automatisch startet.
• Einrichtung der Verfügbarkeitsgruppe:
  • Alle Server wurden in einem Windows-Failovercluster platziert.
  • Eine Always On-Verfügbarkeitsgruppe wurde innerhalb des Clusters konfiguriert.
  • Die sekundären Replikate wurden für synchrones Commit konfiguriert, was erforderte, dass die Transaktionen auf beiden Replikaten committet werden, bevor die Transaktion abgeschlossen wird.
  • Routing für schreibgeschützte Replikate wurde für die Verfügbarkeitsgruppe konfiguriert und aktiviert.

Delivery Controller™ und HSD-Testserver

Die Delivery Controller und HSD-Testserver liefen auf der gleichen Hardwarekonfiguration, unter Verwendung von HP BL460c G1 Blades. 2 Server wurden für die Delivery Controller verwendet, und 43 Server stellten die simulierte HSD-Arbeitslast 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 zu belasten, und nicht die HSD-Server.

Systemspezifikation:

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

Software:

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