Anleitung zur Datenbankgrößenbestimmung 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 gesteuert werden. Citrix ist nicht verantwortlich und übernimmt keine Verantwortung für den Inhalt oder die Nutzung dieser Websites Dritter. Citrix stellt Ihnen diese Links nur zur Verfügung, und die Aufnahme eines Links bedeutet nicht, dass Citrix die verlinkte Website unterstützt. Es liegt in Ihrer Verantwortung, Vorkehrungen zu treffen, um sicherzustellen, dass das, was Sie für Ihre Verwendung auswählen, frei von Viren oder anderen zerstörerischen Elementen ist.

Übersicht

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

• Standortkonfigurationsdatenbank
  Speichert die aktuelle Konfiguration und den aktuellen Status der XenDesktop-Bereitstellung
• Monitoring Database
  Speichert historische Daten 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 Standortkonfigurationsdatenbank. Zunächst haben alle drei Datenbanken denselben Namen. Citrix empfiehlt, den Speicherort der sekundären Datenbanken nach dem Erstellen einer Site zu ändern.

Bei einer typischen Bereitstellung wird auch die temporäre Datenbank TempDB verwendet, 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 jeder Datenbank und hebt die wichtigsten Überlegungen hervor, die bei der Dimensionierung von Datenbanken zur Unterstützung von XenDesktop 7 berücksichtigt werden müssen.

Hinweis: Alle angegebenen Zahlen sind Schätzungen. Abweichungen zwischen Bereitstellungen sind zu erwarten.

Unterschiede in der Größenbestimmung zwischen Hosted Shared Desktops (HSD) und Virtual Desktop Infrastructure (VDI) werden ebenfalls in diesem Dokument vermerkt. Gemischte Umgebungen müssen die Schätzungen der beiden Desktop-Typen kombinieren, um eine Schätzung der Gesamtgröße der Datenbank zu generieren.

Dokumentänderungen für XenDesktop 7.6

Dieses Dokument wurde auf 7.6 XenDesktop erweitert. Dies sollte Updates über die Größenänderungen für Features in 7.6 ermöglichen. Die drei neuen Funktionen, die sich auf die Datenbankgröße auswirken, sind:

• Connection Leasing — die komprimierten Leasing-Dateien werden in der Site-Datenbank gespeichert
• Überwachung der App-Nutzung — Details aller Apps, die in der Umgebung verwendet werden, werden in der Monitordatenbank gespeichert.
• Überwachung der Hotfix-Bestandsliste — Details zu Citrix Hotfixes, die auf die Controller, VDAs und VDA-Images in der Umgebung angewendet werden

Die Informationen zur Tabellengröße wurden unten aktualisiert. Die Transaktionen pro Sekunde und das Wachstum des Transaktionsprotokolls waren in 7.6 bis 7.5 ähnlich, so dass keine Aktualisierungen an diesen Abschnitten vorgenommen wurden.

Überlegungen auf hoher Ebene

Sitedatenbank

Die Standortdatenbank enthält Konfigurationsinformationen für das Ausführen des Systems.

Die Verwendung zeichnet sich aus durch:

• Die maximale Größe wird während der Spitzenzeiten erreicht, da Benutzeranmeldungen Sitzungs- und Verbindungsinformationen generieren, die nachverfolgt werden sollen.
• Die Mindestgröße wird erreicht, wenn keine aktiven Sitzungen vorhanden sind und VDAs alle heruntergefahren und aufgehoben werden.
• Die Spitzengröße wird nach 48 Stunden erreicht, da die Datenbank nur sehr wenig persistente Informationen speichert. Dies ist darauf zurückzuführen, dass ein kleines Protokoll von Verbindungen innerhalb der Site-Datenbank 48 Stunden lang aufrechterhalten wird.
• Die Baseline-Größe der Datenbank wächst mit zunehmender Konfigurationsinformationen für eine Site. Das heißt, mehr Mitarbeiter und Benutzer verbrauchen mehr Datenbankspeicher.
• Bei der Anmeldung treten hohe Transaktionsstufen pro Sekunde auf, da bei jeder Benutzeranmeldung mehrere einzelne Transaktionen durchgeführt werden müssen und auf der Grundlage der gleichzeitigen Startrate skaliert werden müssen.
• Niedriges Hintergrundrauschen von VDA-Heartbeat-Transaktionen. Jeder VDA stellt einmal alle 5 Minuten einen Heartbeat bereit, und dieses Update löst eine Transaktion in der Datenbank aus.

Auswirkung des Ausfalls

Durch einen Ausfall der Standortdatenbank kann das System nicht verwaltet und überwacht werden. Vorhandene Verbindungen werden beibehalten. In XenDesktop 7.6 ermöglicht Connection Leasing neue Verbindungen und Wiederverbindungen herzustellen. 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.

Die Verwendung zeichnet sich aus durch:

• Die maximale Größe wird wie folgt vom konfigurierten Aufbewahrungszeitraum gesteuert:
  • Für Nicht-Platinum-Kunden beträgt der Standardwert 7 Tage, mit einer maximalen Laufzeit von 7 Tagen.
  • Für Platinum-Kunden beträgt der Standardwert 90 Tage, ohne maximale Zeitspanne.
• Die maximale Größe kann einige Zeit dauern, da das System den konfigurierten Aufbewahrungszeitraum erreichen muss.
• Geringe Transaktionen pro Sekunde treten aufgrund der Stapelart von Aktualisierungen durch den Überwachungsdienst auf. Es ist selten zu sehen, dass Transaktionen pro Sekunde die 20 Transaktionen pro Sekunde passieren.
• Einige Hintergrundtransaktionen, die durch regelmäßige Konsolidierungsaufrufe vom Überwachungsdienst verursacht werden.
• Die Nacht-Verarbeitung erfolgt, um Daten außerhalb des konfigurierten Aufbewahrungszeitraums zu entfernen.

Auswirkung des Ausfalls

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

Konfigurationsprotokollierungsdatenbank

Die Konfigurationsprotokolldatenbank 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.

Die Verwendung zeichnet sich aus durch:

• Die maximale Größe ist schwer vorherzusagen, da sie davon abhängt, wie viel Konfigurationsaktivität vorhanden ist.
• Alle Aktionen, z. B. das Zurücksetzen der Sitzung von Director, 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 während der Aktualisierungen, da Aktualisierungen, wenn möglich, in Batches ausgeführt werden.
• Die manuelle Entfernung von Daten. Daten in der Konfigurationsprotokollierungsdatenbank unterliegen keiner Aufbewahrungsrichtlinie und werden nur entfernt, wenn dies von einem Administrator manuell durchgeführt wird.

Auswirkung des Ausfalls

Die Auswirkungen eines Ausbruchs der Konfigurationsprotokollierungsdatenbank hängen von der Standortkonfiguration wie folgt ab:

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

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 diese SQL Server-Funktion, um Sperrenkonflikte in den XenDesktop-Datenbanken zu reduzieren.

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

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 tendenziell kurzlebige Transaktionen, wodurch die Größe des Versionsspeichers klein bleibt.

Die Temporäre Datenbank wird auch verwendet, wenn Abfragen große Zwischenergebnissätze generieren.

Anleitungen 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 Hauptbereich des Konflikts konzentriert sich auf die Anzahl der zu verwendenden Dateien. Ältere Versionen von SQL Server, z. B. 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/

Snapshot-Isolation mit Lesezugriff

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

Dimensionieren der Datenbanken

Die Datenbankgrößen hängen von einer Reihe von Schlüsselfaktoren ab, einschließlich der Anzahl der Sitzungen und Verbindungen, die während eines Arbeitstages erstellt wurden.

Bei einer Sitzung handelt es sich um einen beliebigen Desktop oder eine Anwendung, der für einen bestimmten Zeitraum ausgeführt wird, der getrennt und erneut verbunden werden kann.

Eine Verbindung ist jedes Mal, wenn ein Benutzer eine Verbindung zu einer Sitzung herstellt. Durch das Trennen der Verbindung wird die Verbindung geschlossen, jedoch nicht die Sitzung. Wenn ein Benutzer erneut eine Verbindung herstellt, wird eine neue Verbindung zu einer vorhandenen Sitzung erstellt.

Sitedatenbank

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

Jede veröffentlichte Anwendung fügt 110 KB zur Datenbank 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 erwartet, dass die Überwachungsdatenbank im Laufe der Zeit auf die größte wächst.

Seine Größe hängt von vielen Faktoren ab, einschließlich der folgenden:

• Benutzerzahl
• Anzahl Sitzungen
• Anzahl der Verbindungen
• VDI- oder HSD-Arbeitnehmer
• Aufbewahrungszeitraum konfiguriert

Im Folgenden finden Sie Schätzungen für die Größe der Datenbank an einer Reihe von Datenpunkten. Diese Daten sind eine Schätzung basierend auf Daten, die beim Skalierungstest von XenDesktop angezeigt werden. Die Schätzungen werden als realistisch angesehen.

Kunden, die ihre Datenbank pflegen, können jedoch feststellen, dass ihre Datenbank kleiner ist als die Schätzungen.

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

Maximale Aufbewahrungsfristen

Die maximale Datenmenge wird wie folgt durch eine Lizenz gesteuert:

• Nicht-Platinum-Kunden können Daten bis zu einer Woche (7 Tage) aufbewahren.
• Platinum-Kunden können unbegrenzte Daten speichern; die Standardeinstellung beträgt 3 Monate (90 Tage).

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

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

XenDesktop 7.5 Monitoring Datenbankgröße

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

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

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

XenDesktop 7.6 Überwachung der Datenbankgröße

Die wichtigsten Änderungen von 7.5 sind:

• Hotfix-Informationen
  Die folgenden Daten basieren auf 3 Hotfixes pro Worker (VDI oder HSD)
• Anwendungsverwendungshistorie
  Dies ist vor allem für HSD-Systeme relevant.

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

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

Konfigurationsprotokollierungsdatenbank

Die Bereitstellung von Anleitungen für die Dimensionierung der Konfigurationsprotokollierungsdatenbank ist viel schwieriger, da sie aufgrund der täglichen Director-Aktivität und der Größe der konfigurierten Site stark variiert.

Aktivitäten, die Auswirkungen auf Sitzungen oder Benutzer haben, werden protokolliert und umfassen beispielsweise die Sitzungsabmeldung und das Zurücksetzen. Passive Aktivitäten, z. B. die Auflistung der Sitzungen eines Benutzers, sind 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.

Für MCS-Umgebungen kann die Datenbankgröße aufgrund der Protokollierung aller VM-Build-Daten leicht über 200 MB liegen.

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

Datenbankaktivität während der Anmeldung von 100k HSD-Sitzungen

Während der Skalierbarkeitstests bei der Simulation von 100.000 HSD-Sitzungsanmeldungen wurde das Wachstum des Transaktionsprotokolls unter zwei Anmelderaten wie folgt gemessen:

• 100.000 Benutzer, die sich über 1 Stunde anmelden
• 100.000 Benutzer, die sich über 2 Stunden anmelden

Diese Raten wurden ausgewählt, um Beispieldatenpunkte bereitzustellen.

Die Umwelt umfasste:

• 2 Delivery Controllern
• 43 HSD-VDA-Mitarbeiter
• 3 SQL Server, konfiguriert mit den Datenbanken, in einer Always On-Verfügbarkeitsgruppe

Details zu Serverkonfigurationen finden Sie am Ende dieses Dokuments.

Wachstum des Transaktionsprotokolls

Das Wachstum des Transaktionsprotokolls für alle Datenbanken wurde mithilfe des Leistungsmonitorzählers SQLServer: Datenbanken — Protokolldatei (en) Verwendete Größe (KB) überwacht.

Sitedatenbank

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

Das Wachstum des Protokolls ist über den zu messenden Zeitraum linear. Diese Daten deuten darauf hin, dass pro Benutzeranmeldung das Transaktionsprotokoll 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 sich das System im Leerlauf befindet, wächst das Transaktionsprotokoll um 30,5 MB pro Stunde. Dies ist eine Kombination aus gespeicherten Konsolidierungsprozeduren und HSD-VDA-Lastindexaktualisierungen.

Das Protokollwachstum ist über den zu messenden Zeitraum linear. Diese Daten deuten darauf hin, dass pro Benutzeranmeldung das Transaktionsprotokoll um 7 KB wächst. Pro Benutzerabmeldung wächst das Transaktionsprotokoll 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 mit den folgenden Leistungsmonitorindikatoren überwacht:

• SQLServer: Datenbanken — Transaktionen/Sekunde
• SQLServer: Datenbanken — Schreiben von Transaktionen/Sekunde

Sitedatenbank

Wenn das System im Leerlauf ist, gibt es 5 Transaktionen/Sekunde, von denen 1 Write Transaction/Second VDA- und Broker-Heartbeats verwaltet.

Anmerkung: Diese Zahlen sind Schätzungen aus den angegebenen Zeiträumen. Die exakte Last hängt von der Anzahl der gleichzeitigen Starts pro Sekunde ab.

Überwachungsdatenbank

Wenn sich das System im Leerlauf befindet, werden die gespeicherten Konsolidierungsprozeduren einmal pro Minute ausgeführt und Transaktionen generiert. Die Höhe der Transaktionen ist jedoch gering. Im Allgemeinen gibt es 2 — 3 Transaktionen und 1 Schreibtransaktion für jede gespeicherte Konsolidierungsprozedur, und 3 gespeicherte Konsolidierungsprozeduren werden ausgeführt. In aktiven Perioden erhöht sich der Overhead, wenn mehr Arbeit ausgeführt wird.

Anmerkung: Diese Zahlen sind Schätzungen aus den angegebenen Zeiträumen.

CPU-Nutzung

Alle SQL-Server, die für diese Tests verwendet wurden, waren Dual-Hex-Core Server mit aktiviertem Hyper-Threading. Die genauen Hardwarespezifikationen finden Sie am Ende dieses Dokuments.

Die Server waren bekannt, dass sie für die ausgeführten Last überdimensioniert waren. Dadurch konnten wir die Beschränkungen und Maximalwerte der Hardware identifizieren. Es wird erwartet, dass die SQL CPU-Last tatsächlich von einem SQL Server mit einem einzelnen Quad-Core-System und nicht von einem Dual-Hex-Core-System behandelt werden könnte.

Während der Tests wurde die System-CPU mit dem Leistungsmonitor Zähler Prozessor —% Prozessorzeit —_Total überwacht.

Primäres Replikat

Im Leerlauf lief die CPU bei 0- 2% der verfügbaren CPU. Die gespeicherten Konsolidierungsprozeduren verursachten Spikes pro Minute für ~ 1s bis 8- 10% der System-CPU. Es wird erwartet, dass diese Skalierung basierend auf der Menge der zu verarbeitenden Daten skaliert wird.

Während der Anmeldung von 100.000 Benutzern in einer Stunde sprang die CPU auf 7% und stieg linear auf 11% an, da mehr Sitzungen und Benutzer in der Umgebung vorhanden waren. Beachten Sie, dass die gespeicherten Konsolidierungsprozeduren um 7% zur gesamten CPU hinzugefügt wurden, wodurch die Spitzen 18% der CPU erreichen.

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

Hinweis: Der Windows Server 2012 Scheduler ist bias, Hyper-Threads nur zu verwenden, wenn dies erforderlich ist, dh bis das System 50% Last erreicht, wird nur ein Thread pro Kern, wenn möglich, ausgeführt, so dass eine 20% Last auf 24 Hyper-Threads auf 4.8-Kernen ausgeführt wird.

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

Sekundäre Replikate

Sekundäre Replikate wurden gefunden, um 2% CPU während der Anmeldung und 1,5% während der Abmeldung zu konfigurieren. Dies ist zu erwarten, da Replikate in den meisten Fällen Daten vom primären Datenträger speichern und nur das synchrone Replikat an Transaktionen beteiligt ist, da das Hauptreplikat eine Transaktion erst festsetzt, wenn die sekundäre Bestätigung erfolgt.

Basierend auf Empfehlungen für HA-Hardware, die mit dem primären Replikat übereinstimmt, würde diese Last sehr einfach von einem ähnlich spezifizierten Server verarbeitet 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 Tabellenverwendung.

TempDB-Größe

In dieser SQL-Konfiguration wurde TempDB für 8 Datenbankdateien mit einer festen Größe von 5 GB konfiguriert. Dies ermöglicht eine bessere gleichzeitige Nutzung von TempDB, bietet aber auch viel Platz und löst keine automatischen Grow-Events aus. Basierend auf den erfassten Daten war es für diese Bereitstellung überdimensioniert. Es war jedoch ausreichend Speicherplatz verfügbar.

Es hält auch eine allgemeine Anleitung für die Anzahl der TempDB-Datenbankdateien zwischen einem Viertel und einer Hälfte der verfügbaren CPUs, jedoch nicht mehr als 8, ohne zu wissen, dass es tatsächlich Konflikte gibt.

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 im Zusammenhang mit der von XenDesktop-Datenbanken verwendeten Read Commitated Snapshot Isolation.

Die Nutzung kann an folgenden Leistungsindikatoren gemessen werden:

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

Während einer 100.000 Anmeldung über eine Stunde blieb die Größe des Versionsspeichers im Bereich von 10 MB bis 30 MB, mit einem Sägezahneffekt, wenn Versionen erstellt und dann bereinigt wurden. Während der Abmeldung betrug der Bereich 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, während der Abmeldung 150 — 400 KB/s und im Leerlauf 0 — 250 KB/s.

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

Festplatten-E/A

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

• PhysicalDisk — Lese-Byte/Sekunde
• PhysicalDisk — Festplattenschreibbytes/Sekunde
• PhysicalDisk — Festplattenlese/Sekunde
• PhysicalDisk — Plattenschreiben/Sekunde

Lese-E/A wurde als minimal befunden, da der SQL-Server in der Lage war, alle Daten im Speicher zu speichern, was sehr wenig Leseaktivität auf dem System verursachte.

Aufgrund des Layouts der Datenbanken und des Speichersystems wurden die Volumes aufgeteilt, wobei ein Volume alle Datendateien und ein zweites Volume alle Transaktionsprotokolldateien enthält.

Die Daten zeigen ein Muster, das schwer in eine Tabelle zu platzieren ist. Im Allgemeinen hatte das Transaktionslog eine Schreibbytes/Sekunde 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 gespeicherten Konsolidierungsprozeduren ausgeführt werden, zeigte das Transaktionslog Spikes auf 30 MB/s.

Die Analyse der gespeicherten Konsolidierungsprozeduren zeigt, dass die Statistiken manchmal den Abfrageplan suboptimal machen und eine temporäre Tabelle in TempDB überlaufen. Dies löst Schreibvorgänge in das Transaktionslog für TempDB aus.

Diese Datenübertragung bedeutet einen stabilen Status von 300 Schreibein-/Ausgabeoperationen pro Sekunde (IOPS) für den 1-Stunden-Test und 200 IOPS für den 2-Stunden-Test. Die Spitzen für die gespeicherten Konsolidierungsprozeduren fügen weitere 2 — 300 IOPS hinzu, während das Ausführen ausgeführt wird. Beachten Sie, dass in einer großen Umgebung die gespeicherten Konsolidierungsprozeduren weniger als eine Sekunde ausgeführt werden.

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

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

Diese Checkpoints sind sehr kurze Aktivitätszeiten, in der Regel weniger als 1s.

Während der Anmeldung verbraucht die Checkpoints 6 — 7 MB/s und 500 Schreib-IOPS. Während der Abmeldung verbraucht die Checkpoints 7 MB/s, zwischen 200 und 700 IOPS. Die Zahlen variieren, da die Site- und Überwachungsdatenbanken unterschiedliche Datenmengen aufweisen.

Datenbankpflege

Die Datenbankwartung in einer großen Bereitstellung ist wichtig. Wenn die Datenbank nicht ordnungsgemäß verwaltet wird, können Datenbankausfälle aufgrund fehlender Datenbankspeicherkapazität auftreten, z. B. wenn das Transaktionsprotokoll automatisch vergrößert ist und den Datenträger füllt oder das Transaktionslog eine feste Größe hat und voll wird.

Verwaltung des Transaktionsprotokolls

Bei Verwendung von SQL Server-Hochverfügbarkeitsfeatures, z. B. Always On-Verfügbarkeitsgruppen oder Datenbankspiegelung, werden die XenDesktop-Datenbanken im Modus “Vollständige Transaktionsprotokollierung” ausgeführt.

Durch das Ausführen im Modus 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 standardmäßig die Protokolldateien automatisch vergrößert. Dies verursacht 2 Probleme:

1. Die Transaktionsprotokolldateien können viel Speicherplatz belegen.
2. Jedes Mal, wenn das Transaktionsprotokoll vergrößert wird, 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 überwachen, wenn die verwendete Protokollgröße einen Schwellenwert überschreitet und einen Sicherungsauftrag ausführen.

Beim Skalierungstest wurde ein Protokoll mit fester Größe von 4 GB verwendet, und eine Warnung wurde festgelegt, um das Protokoll in einer anderen Datei zu sichern, wenn die Protokolldatei 80% voll ist. Dadurch wurde das Protokoll nicht mehr vergrößert und der gesamte Speicherplatz belegt, und es hat auch gestoppt, den Speicherplatz auf Null zu setzen und die Datenbank zu stoppen.

Ein Beispielauftrag würde ein Skript ausführen wie:

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 SQL-Leistungsindikator, der für die Warnung verwendet werden soll, lautet:

SQLServer: Datenbanken - Verwendetes Prozentprotokoll - CitrixXenDesktopSiteDB

Wiederholen Sie dies für jede der drei Datenbanken.

Die Sicherung der Protokolldatei hat nur minimale Auswirkungen auf eine ausgeführte XenDesktop-Umgebung. Die Broker-Zeiten erhöhen sich nur geringfügig, aber wir glauben nicht, dass sie signifikant sind.

Weitere Informationen zum Konfigurieren von Aufträgen 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

Indexpflege

Wenn mehr Daten in die Datenbank eingegeben werden, beginnen einige der Indizes weniger voll zu werden, dh weniger Datensätze werden auf jeder SQL-Seite gespeichert. Eine SQL-Seite ist 8 KB. Dies bewirkt, dass die Datenbank ihren Speicherbedarf sowohl im Arbeitsspeicher als auch auf der Festplatte erhöht. Durch die Beibehaltung der Indizes kann die Seitenfülle erhöht werden, wodurch der Speicherbedarf der Datenbank reduziert wird.

Citrix empfiehlt, dass die Wartungspläne des Kunden täglich und wöchentlich ausgeführt werden, um die Indizes zu verwalten. 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 in der Microsoft-Dokumentation.

Nach der Neuorganisation von Indizes sollten auch Statistiken aktualisiert werden. Dies ist besonders wichtig, da die Datenbank wächst. Andernfalls können einige Statistiken schlecht sein und SQL möglicherweise suboptimale SQL-Abfragepläne generieren.

Hinsichtlich des Speicherplatzes wurde das folgende Microsoft-Skript für eine 1,2-GB-Überwachungsdatenbank ausgeführt. Es verbesserte die Seitenfüllung und Freigabe 300 MB Speicherplatz.

Skripts von Drittanbietern

Microsoft

Microsoft empfiehlt, die Indizes für ihre WSUS SQL-Datenbanken mit dem Skript zu aktualisieren, das verfügbar ist unter:

http://gallery.technet.microsoft.com/scriptcenter/6f8cde49-5c52-4abd-9820-f1d270ddea61

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

Ola Hallengren

Weitere fortgeschrittene Skripte sind auch verfügbar unter:

http://ola.hallengren.com/

Diese Skripts werden in der SQL Server-Community gut angesehen. Insbesondere sind die Index-Skripte verfügbar von:

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

Diese Skripte können für eine feinere Kontrolle über die Ebenen verwendet werden, um Indizes neu zu organisieren oder neu zu erstellen.

Testserverkonfiguration

SQL Server-Konfiguration

Die SQL-Verfügbarkeitsgruppe besteht aus 3 identisch festgelegten Dell R720XD-Servern.

Systemspezifikation:

• 2 Hex-Core Intel Xeon CPU E5-2630 mit 2,30 GHz und Hyper-Threading aktiviert
• 64 GB ECC RAM
• PERC H710P Mini mit 1 GB batteriegesicherten Cache
• 26 SAS-Laufwerke mit 300 GB und 10.000 1/min

Die Datenträger wurden in folgende Volumes aufgeteilt:

• System-Volume
  • Enthält das Betriebssystem und die Auslagerungsdatei
  • 2 Festplatten als RAID 1-Spiegel
  • Gesamtkapazität 278 GB
• Datenbankvolume
  • Enthält die SQL Server-Instanz und Datenbankdatendateien
  • 16 Festplatten als RAID 10-Spiegelstreifen
  • Gesamtkapazität 2.231 GB
• Protokolldatenträger
  • Enthält die Datenbankprotokolldateien
  • 8 Festplatten als RAID 10-Spiegelstreifen
  • Gesamtkapazität 1.115 GB
• Software:
  • Windows Server 2012 R2 Standardedition mit aktuellen Windows-Updates zum Testzeitpunkt (August 2014)
  • SQL Server Enterprise 2012 SP2 mit kumulativem Update 1
• Konfigurationsänderungen
  • SQL Server wurde für die Verwendung von maximal 61.440 MB konfiguriert
  • Datenbankbeschränkung wurde für alle 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 Always On-Verfügbarkeitsgruppe wurde im Cluster konfiguriert
  • Die sekundären Replikate wurden als Synchronous Commit konfiguriert, sodass die Transaktionen für beide Replikate festgeschrieben werden müssen, bevor die Transaktion abgeschlossen ist.
  • Schreibgeschütztes Replikatrouting wurde für die Verfügbarkeitsgruppe konfiguriert und aktiviert

Delivery Controller und HSD Testserver

Der Delivery Controller und die HSD Testserver wurden mit HP BL460c G1-Blades auf derselben Hardwarekonfiguration ausgeführt. Für die Delivery Controller wurden 2 Server verwendet, und 43 Server lieferten die simulierte HSD-Arbeitslast.

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 Hyper-Thread-fähig
• 16 GB ECC RAM
• HP Smart Array E200I Raid-Karte (kein batteriegedeckter Cache)
• Eine 36 GB oder 72 GB SAS-Festplatte

Software:

• Windows Server 2012 R2 Standardedition mit aktuellen Windows-Updates zum Testzeitpunkt (August 2014)
• Citrix XenDesktop 7.6