Überlegungen zur Skalierbarkeit

Die Sitzungsaufzeichnung ist ein hochskalierbares System, das zehntausende Sitzungen verarbeiten kann. Zum Installieren und Ausführen der Sitzungsaufzeichnung sind nur wenige Ressourcen erforderlich, die nicht schon für Citrix Virtual Apps and Desktops oder Citrix DaaS (früher Citrix Virtual Apps and Desktops Service) gebraucht werden. Wir empfehlen Ihnen jedoch, die Leistung Ihres Systems zu berücksichtigen, wenn Sie viele Sitzungen aufzeichnen möchten. Dasselbe gilt, wenn die Sitzungen, die Sie aufzeichnen möchten, zu großen Sitzungsdateien führen können (z. B. durch grafikintensive Anwendungen).

In diesem Artikel werden die Grundlagen der hohen Skalierbarkeit der Sitzungsaufzeichnung behandelt und es wird erläutert, wie Sie das System mit möglichst geringem Kostenaufwand optimal nutzen können.

Faktoren für die gute Skalierbarkeit der Sitzungsaufzeichnung

Es gibt zwei Hauptgründe für die im Vergleich zu Produkten von Mitbewerbern gute Skalierbarkeit der Sitzungsaufzeichnung:

• Kleine Dateigröße

  Mit der Sitzungsaufzeichnung erstellte Aufzeichnungsdateien sind extrem kompakt. Sie sind um ein Vielfaches kleiner als äquivalente Videoaufnahmen, die von auf Screen Scraping basierenden Lösungen erstellt werden. Für die Übermittlung und Speicherung einer Sitzungsaufzeichnungsdatei ist der Bedarf an Netzwerkbandbreite, Speicherplatz und Datenträger-IOPS in der Regel mindestens zehnmal geringer als bei einer äquivalenten Videodatei.

  Die geringe Größe von Sitzungsaufzeichnungsdateien sorgt für eine schnellere und nahtlosere Wiedergabe von Videobildern. Die Aufzeichnung ist zudem verlustfrei und weist im Gegensatz zu den meisten kompakten Videoformaten keinerlei Pixelierung auf. Text in Aufzeichnungen ist bei der Wiedergabe genauso leicht zu lesen wie in der ursprünglichen Sitzung. Zur Minimierung der Dateigrößen werden bei der Sitzungsaufzeichnung keine Keyframes innerhalb von Dateien aufgezeichnet. Beim Aufzeichnen von Sitzungen mit Videowiedergabe können H.264-Pakete verworfen werden, um die Dateigröße der Aufzeichnung zu reduzieren. Zum Verwenden dieser Funktionalität legen Sie im Sitzungsaufzeichnungsagent HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\SmartAuditor\Agent\DropH264Enabled auf 1 fest und wählen für Videocodec zur Komprimierung verwenden die Einstellung Für aktive Änderungsbereiche.

  

• Geringer Verarbeitungsaufwand zum Generieren von Dateien

  Eine Sitzungsaufzeichnungsdatei enthält die ICA-Protokolldaten für eine Sitzung, die virtuell im nativen Format extrahiert werden. Die Datei erfasst den ICA-Protokolldatenstrom, der für die Kommunikation mit der Citrix Workspace-App verwendet wird. Es müssen keine teuren Transcodierer oder Encoder zur Formatumwandlung in Echtzeit ausgeführt werden. Der geringe Verarbeitungsaufwand ist auch für die VDA-Skalierbarkeit wichtig. Er gewährleistet eine gute Benutzererfahrung, wenn ein VDA viele Sitzungen aufzeichnet.

  Darüber hinaus werden nur die virtuellen ICA-Kanäle aufgezeichnet, die wiedergegeben werden können – eine weitere Optimierung. Beispielsweise werden der Drucker- und Clientlaufwerkzuordnungskanal nicht aufgezeichnet. Die Kanäle können hohe Datenmengen erzeugen, ohne von Vorteil für die Videowiedergabe zu sein.

Schätzung der Dateneingabe- und Verarbeitungsraten

Der Sitzungsaufzeichnungsserver ist der zentrale Sammelpunkt für Sitzungsaufzeichnungsdateien. Jede Maschine mit Multisitzungs-OS-VDA und aktivierter Sitzungsaufzeichnung sendet Sitzungsaufzeichnungsdaten an den Sitzungsaufzeichnungsserver. Die Sitzungsaufzeichnung kann große Datenmengen verarbeiten und ist burst- und fehlertolerant. Es gibt jedoch physische Limits für die Datenmenge, die einzelne Server verarbeiten können.

Berücksichtigen Sie, wie viele Daten an jeden Sitzungsaufzeichnungsserver gesendet werden. Schätzen Sie ab, wie schnell die Server diese Daten verarbeiten und speichern können. Die Rate, mit der das System die eingehenden Daten speichern kann, muss größer als die Dateneingaberate sein.

Schrittfolge zur Schätzung der Dateneingaberate:

1. Multiplizieren Sie die Anzahl der aufgezeichneten Sitzungen mit der durchschnittlichen Größe jeder Sitzungsaufzeichnung.
2. Dividieren Sie das Produkt durch die Länge der Sitzungsaufzeichnungen.

Beispiel: An einem 8-stündigen Arbeitstag zeichnen Sie 5000 Microsoft Outlook-Sitzungen auf, deren Größe 20 MB ist. Die Dateneingaberate beträgt dann ungefähr 3,5 MBit/s (5.000 Sitzungen multipliziert mit 20 MB und dividiert durch 8 Stunden, dividiert durch 3.600 Sekunden pro Stunde.) Ein an ein 100-MBit/s-LAN angeschlossener Sitzungsaufzeichnungsserver mit ausreichend Speicherplatz für die aufgezeichneten Daten kann in der Regel rund 5,0 MBit Daten pro Sekunde verarbeiten. Diese Rate ist die Verarbeitungsrate, die auf den physischen Limits durch Datenträger- und Netzwerk-IOPS basiert. In diesem Beispiel ist die Verarbeitungsrate (5,0 MBit/s) höher als die Eingaberate (3,5 MBit/s) und die Aufzeichnung der 5.000 Outlook-Sitzungen ist somit möglich.

Die pro Sitzung entstehenden Datenmengen können je nach aufgezeichneten Inhalten stark variieren. Weitere Faktoren wie Bildschirmauflösung, Farbtiefe und Grafikmodus wirken sich ebenfalls aus. Eine Sitzung, in der eine CAD-Anwendung ausgeführt wird, generiert wesentlich mehr Aufzeichnungsdaten als eine Sitzung, in der E-Mail in Microsoft Outlook gesendet und empfangen wird. Daher kann die Aufzeichnung einer identischen Anzahl CAD-Sitzungen eine hohe Eingaberate aufweisen und die Verwendung zusätzlicher Sitzungsaufzeichnungsserver erfordern.

Bursts und Fehler

Das obige Beispiel basiert auf einem einfachen und konstanten Datendurchsatz und berücksichtigt keine Bursts – kurze Zeiträume mit höherer Aktivität. Ein Burst kann beispielsweise morgens auftreten, wenn sich alle Benutzer zur gleichen Zeit anmelden. Er kann auch auftreten, wenn sie die gleiche E-Mail im Outlook-Posteingang erhalten. Die Verarbeitungsrate des Sitzungsaufzeichnungsservers von 5,0 MBit/s ist zur Bewältigung eines solchen Bursts äußerst unzureichend.

Der auf jedem VDA ausgeführte Sitzungsaufzeichnungsagent sendet aufgezeichnete Daten unter Einsatz von Microsoft Message Queuing (MSMQ) an den Speichermanager, der auf dem zentralen Sitzungsaufzeichnungsserver ausgeführt wird. Die Daten werden im Teilstreckenverfahren (store and forward) gesendet, ähnlich wie E-Mail, die vom Absender über einen Mailserver an den Empfänger gesendet wird. Wenn der Sitzungsaufzeichnungsserver oder das Netzwerk die hohe Datenrate eines Bursts nicht verarbeiten kann, werden die aufgezeichneten Sitzungsdaten vorübergehend gespeichert. Die Datennachricht kann bei Überlastung des Netzwerks in der Ausgangswarteschlange auf dem VDA zwischengespeichert werden. In einem anderen Szenario haben die Daten das Netzwerk bereits durchlaufen, während der Speichermanager noch andere Nachrichten verarbeitet. In diesem Fall wird die Datennachricht in der Eingangswarteschlange des Sitzungsaufzeichnungsservers gespeichert.

MSMQ dient auch als Fehlertoleranzmechanismus. Fällt der Sitzungsaufzeichnungsserver aus oder wird die Verbindung unterbrochen, verbleiben aufgezeichnete Daten in der Ausgangswarteschlange auf den VDAs. Nach Beseitigung des Fehlers werden alle Daten in den Warteschlangen zusammen gesendet. MSMQ ermöglicht außerdem das Offlineschalten eines Servers für Upgrades oder Wartungszwecke, ohne dass die Sitzungsaufzeichnung unterbrochen wird und Daten verloren gehen.

Die Haupteinschränkung von MSMQ besteht darin, dass der Speicherplatz für die temporäre Speicherung von Datennachrichten begrenzt ist. Diese Einschränkung bestimmt, wie lange ein Burst-, Fehler- oder Wartungsereignis dauern kann, bis Daten verloren gehen. Das Gesamtsystem kann nach Datenverlust weiter ausgeführt werden, doch fehlen in diesem Fall Datenblöcke in einzelnen Aufzeichnungen. Eine Datei mit fehlenden Daten kann zwar wiedergegeben werden, doch nur bis zu dem Punkt des ersten Datenverlusts. Beachten Sie Folgendes:

• Die Ausstattung aller Server und insbesondere des Sitzungsaufzeichnungsservers mit mehr Speicherplatz und dessen Bereitstellung für MSMQ kann die Burst- und Fehlertoleranz erhöhen.

• Es ist wichtig, die Einstellung “Nachrichtenlebensdauer” (auf der Registerkarte Verbindungen unter “Sitzungsaufzeichnungsagent - Eigenschaften”) für jeden Sitzungsaufzeichnungsagent auf einen geeigneten Wert festzulegen. Der Standardwert ist 7.200 Sekunden (zwei Stunden). Dies bedeutet, dass aufgezeichnete Datennachrichten zwei Stunden haben, um den Speichermanager zu erreichen. Nach Ablauf dieses Zeitraums werden sie verworfen und die Aufzeichnungsdateien werden beschädigt. Wenn mehr Speicherplatz verfügbar ist (oder weniger Sitzungen aufgezeichnet werden), können Sie diesen Wert erhöhen. Der maximale Wert beträgt 365 Tage.

Die andere Einschränkung bei MSMQ besteht darin, dass es bei einem Auflaufen von Daten in der Warteschlange zu zusätzlichen IOPS für das Lesen und Schreiben von Datennachrichten kommt. In der Regel empfängt und verarbeitet der Speichermanager Daten direkt aus dem Netzwerk, ohne dass Datennachrichten auf den Datenträger geschrieben werden. Das Speichern der Daten erfordert einen Schreibvorgang auf dem Datenträger, der die Sitzungsaufzeichnungsdatei anfügt. Bei einem Auflaufen von Daten verdreifachen sich die Datenträger-IOPS: Jede Nachricht muss auf den Datenträger geschrieben, von diesem gelesen und in eine Datei geschrieben werden. Da der Speichermanager sehr IOPS-gebunden ist, sinkt die Verarbeitungsrate des Sitzungsaufzeichnungsservers, bis die aufgelaufenen Nachrichten verarbeitet sind. Zur Minderung der Auswirkungen dieser zusätzlichen IOPS wird Folgendes empfohlen:

• Stellen Sie sicher, dass MSMQ Nachrichten auf einem anderen Datenträger speichert als dem, auf dem die Aufzeichnungsdateien gespeichert werden. Obwohl sich der IOPS-Wert verdreifacht, sinkt die reale Verarbeitungsrate nicht im gleichen Maß.

• Führen Sie geplante Ausfälle nur zu Nebenzeiten durch. Folgen Sie unter Berücksichtigung von Budgetlimits anerkannten Ansätzen zum Erstellen hoch verfügbarer Server. Dazu gehören der Einsatz einer unterbrechungsfreien Stromversorgung (UPS), duale Netzwerkkarten, redundante Switches und per Hot-Swap austauschbare Arbeitsspeicher und Datenträger.

Planung mit Kapazitätsreserve

Die Datenrate der Sitzungsaufzeichnung ist in der Regel uneinheitlich, es sind Bursts und Fehler möglich und die Verarbeitung aufgelaufener Nachrichten erzeugt einen hohen IOPS-Wert. Die Sitzungsaufzeichnungsserver sollten daher über reichlich Kapazitätsreserven verfügen. Das Hinzufügen weiterer Server oder die Aufrüstung vorhandener Server (Erläuterungen hierzu weiter unten) kann die Kapazität erhöhen. Als allgemeine Faustregel sollte ein Sitzungsaufzeichnungsserver bei maximal 50 % Gesamtkapazität ausgeführt werden. Im vorangehenden Beispiel kann ein Server 5,0 MBit/s verarbeiten, setzen Sie als Ziel, das System mit nur 2,5 MBit/s auszuführen. Statt der Aufzeichnung von 5.000 Outlook-Sitzungen, die 3,5 Mbit/s auf einem Sitzungsaufzeichnungsserver generieren, lassen Sie 3.500 Sitzungen aufzeichnen, die nur etwa 2,5 MBit/s generieren.

Datenrückstau und Livewiedergabe

Bei der Livewiedergabe wird eine Sitzungsaufzeichnung noch während der laufenden Sitzung zur Wiedergabe geöffnet. Bei der Livewiedergabe wechselt der für die Sitzung zuständige Sitzungsaufzeichnungsagent in den Streamingmodus. Die Aufzeichnungsdaten werden direkt und ohne interne Pufferung an den Speichermanager gesendet. Da die Aufzeichnungsdatei ständig aktualisiert wird, erhält der Player weiterhin die neuesten Daten aus der Livesitzung. Die Daten werden vom Agent allerdings über MSMQ an den Speichermanager gesendet, weshalb die o. g. Warteschlangenregeln gelten. In diesem Szenario kann ein Problem auftreten. Bei einem Datenrückstau in MSMQ werden die neuen Aufzeichnungsdaten für die Livewiedergabe wie alle anderen Datennachrichten in die Warteschlange gestellt. Die Datei kann zwar weiterhin wiedergegeben werden, doch die Anzeige der neuesten Liveaufzeichnungen verzögert sich. Ist die Livewiedergabe ein wichtiges Feature, müssen Sie dafür sorgen, dass die Wahrscheinlichkeit eines Datenrückstaus gering ist. Sie können Kapazitätsreserven und Fehlertoleranz in Ihre Bereitstellung integrieren.

Skalierbarkeit des Systems

Die Sitzungsaufzeichnung verringert nie die Sitzungsleistung und hält bei einem Datenrückstau nie eine Sitzung an. Der Fokus des Sitzungsaufzeichnungssystems richtet sich auf die Aufrechterhaltung der Benutzererfahrung und der Einzelserver-Skalierbarkeit. Bei einer irreversiblen Überlastung werden aufgezeichnete Sitzungsdaten verworfen. Die Aufzeichnung von ICA-Sitzungen hat nur geringe Auswirkungen auf die Leistung und Skalierbarkeit von VDAs. Der Grad der Auswirkungen hängt von der Plattform, dem verfügbaren Arbeitsspeicher und der Art der aufgezeichneten Sitzungen ab. Bei der nachfolgend aufgeführten Konfiguration ist mit einer Verringerung der Einzelserver-Leistung zwischen 1 % und 5 % rechnen. Anders gesagt: Wenn ein Server ohne Sitzungsaufzeichnung 100 Benutzer hosten kann, kann er bei installierter Sitzungsaufzeichnung 95 bis 99 Benutzer hosten.

• 64-Bit-Server mit 8 GB RAM und einem VDA mit Multisitzungs-OS
• In allen Sitzungen werden Office-Anwendungen wie Outlook oder Excel ausgeführt.
• Die Anwendungen werden aktiv und dauerhaft genutzt.
• Alle Sitzungen werden gemäß den Richtlinien für die Sitzungsaufzeichnung aufgezeichnet.

Werden weniger Sitzungen aufgezeichnet oder ist die Sitzungsaktivität eher sporadisch, sind die Auswirkungen geringer. Oft sind die Skalierbarkeitsauswirkungen vernachlässigbar und die Benutzerdichte pro Server bleibt gleich. Wie bereits erwähnt, basiert die geringe Auswirkung auf den einfachen Verarbeitungsanforderungen der Sitzungsaufzeichnungskomponenten, die auf den VDAs installiert sind. Aufzeichnungsdaten werden aus dem ICA-Sitzungsstack extrahiert und unverändert über MSMQ an den Sitzungsaufzeichnungsserver gesendet. Es ist keine teure Datencodierung erforderlich.

Selbst wenn keine Sitzungen aufgezeichnet werden, besteht ein geringfügiger Mehraufwand für die Sitzungsaufzeichnung. Wenn von einem Server keine Sitzungen aufgezeichnet werden, können Sie die Aufzeichnung dort deaktivieren. Eine Möglichkeit ist, die Sitzungsaufzeichnung zu entfernen. Weniger invasiv ist das Deaktivieren des Kontrollkästchens Sitzungsaufzeichnung für diese VDA-Maschine aktivieren auf der Registerkarte Sitzungsaufzeichnung unter Sitzungsaufzeichnungsagent - Eigenschaften. Wird die Sitzungsaufzeichnung in Zukunft benötigt, aktivieren Sie das Kontrollkästchen.

Durchsatzmessung

Sie können den Durchsatz der Sitzungsaufzeichnungsdaten vom VDA zum Sitzungsaufzeichnungsserver messen. Eine einfache und effektive Methode besteht in der Messung der Größe der Aufzeichnungsdateien sowie der Geschwindigkeit, mit der Speicherplatz auf dem Sitzungsaufzeichnungsserver belegt wird. Die Menge der auf den Datenträger geschriebenen Daten entspricht der Menge des generierten Netzwerkdatenverkehrs. Die Windows-Leistungsüberwachung (perfmon.exe) bietet Standardsystemindikatoren, die Sie zusätzlich den Leistungsindikatoren der Sitzungsaufzeichnung prüfen können. Die Indikatoren gestatten die Durchsatzmessung und die Identifizierung von Engpässen und Systemproblemen. In der folgenden Tabelle werden die nützlichsten Leistungsindikatoren beschrieben.

Hardware des Sitzungsaufzeichnungsservers

Sie können die Kapazität Ihrer Bereitstellung durch sorgfältige Auswahl der Hardware für den Sitzungsaufzeichnungsserver erhöhen. Sie können vertikal skalieren (durch Erhöhung der Kapazität der einzelnen Server) oder horizontal (durch Hinzufügen weiterer Server). In beiden Fällen geht es darum, die Kosten möglichst gering zu halten.

Vertikales Skalieren

Für einzelne Sitzungsaufzeichnungsserver folgen Sie den folgenden bewährten Methoden, um die optimale Leistung zum verfügbaren Budget sicherzustellen. Das System ist auf IOPS angewiesen, da dies einen hohen Durchsatz von Aufzeichnungsdaten aus dem Netzwerk auf den Datenträger gewährleistet. Daher ist es wichtig, in geeignete Netzwerk- und Datenträgerhardware zu investieren. Für einen leistungsstarken Sitzungsaufzeichnungsserver wird ein Dual- oder Dual-Core-Prozessor empfohlen. Eine höhere Spezifikation bringt keinen nennenswerten Vorteil. Es wird ein 64-Bit-Prozessor empfohlen, doch auch ein x86-Prozessor ist geeignet. 4 GB RAM werden empfohlen, mehr bringt auch hier wenig Nutzen.

Horizontales Skalieren

Selbst bei einer optimalen vertikalen Skalierung gibt es Leistungs- und Skalierbarkeitsgrenzen, die ein einzelner Sitzungsaufzeichnungsserver erreichen kann, wenn eine große Anzahl von Sitzungen aufgezeichnet wird. Unter Umständen sind zusätzliche Server zur Bewältigung der Last erforderlich. Sie können weitere Sitzungsaufzeichnungsserver auf anderen Maschinen installieren, damit die Sitzungsaufzeichnungsserver als Lastausgleichspool fungieren. Bei dieser Art der Bereitstellung teilen sich die Sitzungsaufzeichnungsserver den Speicher und die Datenbank. Um die Last aufzuteilen, verweisen Sie die Sitzungsaufzeichnungsagents auf den Load Balancer, der für die Verteilung der Arbeitslast verantwortlich ist.

Netzwerkkapazität

Ein Netzwerk mit 100 MBit/s ist für die Verbindung eines Sitzungsaufzeichnungsservers geeignet. Eine Gigabit-Ethernet-Verbindung kann die Leistung verbessern, führt jedoch nicht zu einer 10 Mal besseren Leistung als eine Verbindung mit 100 MBit/s. In der Praxis ist der Durchsatzgewinn geringer.

Stellen Sie sicher, dass Netzwerkswitches, die von der Sitzungsaufzeichnung verwendet werden, nicht mit Anwendungen von Drittherstellern gemeinsam verwendet werden, die ggf. um die verfügbare Netzwerkbandbreite konkurrieren. Netzwerkswitches sollten nur vom Sitzungsaufzeichnungsserver verwendet werden. Wenn sich das Netzwerk als Engpass erweist, bietet ein Netzwerkupgrade eine relativ kostengünstige Möglichkeit zur Erhöhung der Systemleistung.

Speicher

Investitionen in Datenträger- und Speicherhardware sind der wichtigste Faktor für die Serverskalierbarkeit. Je schneller Daten auf den Datenträger geschrieben werden, desto höher ist die Leistung des Gesamtsystems. Berücksichtigen Sie bei der Auswahl einer Speicherlösung die Schreibleistung stärker als die Leseleistung.

Speichern Sie Daten auf einem RAID oder SAN.

Hinweis:

Das Speichern von Daten in einem NAS mit dateibasiertem Protokoll wie SMB und NFS kann Auswirkungen auf Leistung und Sicherheit haben. Verwenden Sie die neueste Version des Protokolls, um Auswirkungen auf die Sicherheit zu vermeiden, und führen Sie Skalierungstests durch, um eine zufriedenstellende Leistung sicherzustellen.

Bei der Installation auf einem lokalen Datenträger verwenden Sie möglichst einen Datenträgercontroller mit integriertem Cachespeicher. Caching ermöglicht dem Controller die Verwendung des Aufzug-Algorithmus beim Zurückschreiben. Dies minimiert die Bewegung des Datenträgerkopfs und stellt sicher, dass Schreibvorgänge ohne Warten auf den Abschluss des physischen Datenträgervorgangs ausgeführt werden. Dies kann die Schreibleistung bei minimalen Mehrkosten erheblich verbessern. Beim Caching besteht jedoch das Problem eines möglichen Datenverlusts nach Stromausfall. Zur Gewährleistung der Integrität von Daten und Dateisystem sollten Sie eine batteriegetriebene Backuplösung für den Datenträgercontroller mit Cachespeicher in Betracht ziehen.

Erwägen Sie die Verwendung einer geeigneten RAID-Speicherlösung. Je nach Leistungs- und Redundanzanforderungen stehen viele RAID-Level zur Verfügung. In der folgenden Tabelle werden die einzelnen RAID-Level und ihre Eignung für die Sitzungsaufzeichnung angegeben.

RAID 0 und RAID 3 sind die empfohlenen RAID-Level. RAID 1 und RAID 5 sind gängige Standards, werden aber für die Sitzungsaufzeichnung nicht empfohlen. RAID 10 bietet einige Leistungsvorteile, doch die Kosten stehen in keinem Vergleich dazu.

Wählen Sie den Typ und die Spezifikation der Laufwerke. IDE/ATA-Laufwerke und externe USB- oder Firewire-Laufwerke sind nicht für die Verwendung für die Sitzungsaufzeichnung geeignet. Die beiden Hauptalternativen sind SATA und SCSI. SATA-Laufwerke bieten im Vergleich zu SCSI-Laufwerken relativ hohe Übertragungsraten zu geringeren Kosten pro MB. SCSI-Laufwerke bieten jedoch eine bessere Leistung und sind bei Serverbereitstellungen gängiger. Server-RAID-Lösungen unterstützen meist SCSI-Laufwerke, es gibt jetzt aber auch einige SATA-RAID-Produkte. Berücksichtigen Sie bei der Auswahl von Datenträgern die Drehgeschwindigkeit und andere Leistungsmerkmale.

Da die Aufzeichnung von Tausenden von Sitzungen pro Tag erhebliche Mengen an Speicherplatz belegen kann, müssen Sie zwischen Gesamtkapazität und Leistung wählen. Die Aufzeichnung von 5.000 Outlook-Sitzungen des o. g. Beispiels belegt an einem 8-Stunden-Arbeitstag etwa 100 GB Speicherplatz. Zur Speicherung der Aufzeichnungen von 10 Tagen (d. h. 50.000 Sitzungsaufzeichnungsdateien) benötigen Sie 1.000 GB (1 TB). Durch einen kürzeren Aufbewahrungszeitraum vor der Archivierung oder dem Löschen von Aufzeichnungen kann Speicherplatz eingespart werden. Steht 1 TB Speicherplatz zur Verfügung, ist eine siebentägige Aufbewahrungsfrist sinnvoll, die sicherstellt, dass rund 700 GB Speicherplatz belegt werden und 300 GB als Puffer für einen hohen Betrieb zur Verfügung stehen. In der Sitzungsaufzeichnung wird das Archivieren und Löschen von Dateien mit dem ICLDB-Hilfsprogramm unterstützt. Die Mindestaufbewahrungsdauer beträgt zwei Tage. Sie können einen Hintergrundtask planen, der täglich einmal außerhalb der Spitzenzeiten ausgeführt wird. Weitere Informationen zu ICLDB-Befehlen und zur Archivierung finden Sie unter Verwalten der Datensätze in der Datenbank.

Die Alternative zu lokalen Laufwerken und Controllern ist die Verwendung einer SAN-Speicherlösung mit Datenträgerzugriff auf Blockebene. Auf dem Sitzungsaufzeichnungsserver wird das Datenträgerarray als lokales Laufwerk angezeigt. SANs sind teurer, doch da das Datenträgerarray gemeinsam genutzt wird, ist ihre Verwaltung einfacher und zentral. Es gibt zwei SAN-Haupttypen: Fibre Channel und iSCSI. iSCSI – im Wesentlichen SCSI über TCP/IP – gewinnt seit der Einführung von Gigabit-Ethernet an Beliebtheit gegenüber Fibre Channel.

Datenbankskalierbarkeit

Die an die Datenbank für die Sitzungsaufzeichnung gesendete Datenmenge ist gering, da dort nur die Metadaten über die aufgezeichneten Sitzungen gespeichert werden. Die Sitzungsaufzeichnungsdateien werden auf einem separaten Datenträger gespeichert. Normalerweise benötigt jede aufgezeichnete Sitzung nur 1 KB in der Datenbank, es sei denn, Sie fügen durchsuchbare Ereignisse mit der Sitzungsaufzeichnungs-Ereignis-API in die Sitzung ein.

Bei den Express-Editionen von Microsoft SQL Server 2019, Microsoft SQL Server 2017, Microsoft SQL Server 2016, Microsoft SQL Server 2014, Microsoft SQL Server 2012 und Microsoft SQL Server 2008 R2 ist die Größe der Datenbank auf 10 GB beschränkt. Bei 1 KB pro aufgezeichneter Sitzung kann die Datenbank ungefähr 4.000.000 Sitzungen katalogisieren. Andere Editionen von Microsoft SQL Server haben keine Beschränkungen hinsichtlich Datenbankgröße und werden nur durch den verfügbaren Speicherplatz auf dem Datenträger beschränkt. Wenn die Zahl der Sitzungen in der Datenbank ansteigt, wird die Leistung der Datenbank und die Geschwindigkeit der Suchen nur geringfügig beeinträchtigt.

Wenn Sie keine Anpassungen über die Sitzungsaufzeichnungs-Ereignis-API machen, generiert jede aufgezeichnete Sitzung vier Datenbanktransaktionen: zwei beim Start der Aufzeichnung, eine bei der Benutzeranmeldung bei der aufgezeichneten Sitzung und eine am Ende der Aufzeichnung. Beim Anpassen der Sitzungen mit der Sitzungsaufzeichnungs-Ereignis-API erstellt jedes durchsuchbare Ereignis, das aufgezeichnet wurde, eine Transaktion. Da selbst bei der einfachsten Datenbankbereitstellung mehrere Hundert Transaktionen pro Sekunde gehandhabt werden können, wird die Verarbeitungslast für die Datenbank nie überstrapaziert. Die Auswirkung ist so gering, dass die Datenbank für die Sitzungsaufzeichnung normalerweise auf demselben SQL-Server wie andere Datenbanken ausgeführt werden kann, u. a. der Citrix Virtual Apps and Desktops-Datenbank des Datenspeichers.

Wenn Sie in der Bereitstellung der Sitzungsaufzeichnung viele Millionen aufgezeichneter Sitzungen in der Datenbank katalogisieren müssen, halten Sie die Microsoft-Richtlinien zur Skalierbarkeit von SQL Server ein.