Ü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 über die für XenApp und XenDesktop benötigten hinaus erforderlich. Wenn Sie jedoch viele Sitzungen mit der Sitzungsaufzeichnung aufzeichnen möchten oder die Sitzungen, die Sie aufzeichnen möchten, möglicherweise große Sitzungsdateien erstellen (z. B. Anwendungen mit hohem Grafikanteil), sollten Sie die Leistung des Systems berücksichtigen, wenn Sie die Bereitstellung der Sitzungsaufzeichnung planen.

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 von Sitzungsaufzeichnungsdateien ist der Bedarf an Netzwerkbandbreite, Festplattenspeicher und Datenträger-IOPS in der Regel mindestens zehnmal geringer als bei äquivalenten Videodateien.

    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.

  • 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 somit 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 und 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, da sie hohe Datenmengen erzeugen und ohne Vorteil für die Videowiedergabe sind.

Schätzung der Dateneingabe- und Verarbeitungsraten

Der Sitzungsaufzeichnungsserver ist der zentrale Sammelpunkt für Sitzungsaufzeichnungsdateien. Jede Maschine mit Multisitzungs-OS 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 und 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.

Sie können die Dateneingaberate schätzen, wenn Sie die Anzahl der aufgezeichneten Sitzungen mit der durchschnittlichen Größe jeder Sitzungsaufzeichnung multiplizieren und durch die Länge der Sitzungsaufzeichnungen dividieren. 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 (5000 Sitzungen multipliziert mit 20 MB und dividiert durch 8 Stunden, dividiert durch 3600 Sekunden pro Stunde.) Ein an ein 100-MBit/s-LAN angeschlossener Sitzungsaufzeichnungsserver mit ausreichend Festplattenspeicher für die aufgezeichneten Daten kann basierend auf den physischen Limits durch Datenträger- und Netzwerk-IOPS in der Regel rund 5,0 MBit Daten pro Sekunde verarbeiten. Das ist die Verarbeitungsrate. 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 variieren stark, je nachdem, was aufgezeichnet wird. Auch andere Faktoren wie Bildschirmauflösung, Farbtiefe und Grafikmodus haben Auswirkungen. Eine Sitzung, in der eine CAD-Anwendung mit konstant hoher Grafikaktivität 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 extrem hohe Eingaberate aufweisen und die Verwendung zusätzlicher Sitzungsaufzeichnungsserver erfordern.

Bursts und Fehler

Das obige Beispiel basiert auf einem sehr 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, oder wenn alle Benutzer 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, bis die aufgelaufenen Datennachrichten verarbeitet sind. Datennachrichten werden, wenn das Netzwerk überlastet ist, in der Ausgangswarteschlange auf dem VDA zwischengespeichert oder aber in der Eingangswarteschlange des Sitzungsaufzeichnungsservers, wenn sie bereits das Netzwerk durchlaufen haben und der Speichermanager noch andere Nachrichten verarbeitet.

MSMQ dient auch als Fehlertoleranzmechanismus. Fällt der Sitzungsaufzeichnungsserver aus oder wird die Verbindung unterbrochen, dann werden aufgezeichnete Daten in der Ausgangswarteschlange auf den VDAs gespeichert. Nach Beseitigung des Fehlers werden alle Daten in den Warteschlangen zusammen gesendet. Die Verwendung von MSMQ ermöglicht außerdem das Offlineschalten eines Sitzungsaufzeichnungsservers für Upgrades oder Wartungszwecke, ohne dass die Aufzeichnung bestehender Sitzungen 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 Größe 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 in den Agenteigenschaften) für jeden Sitzungsaufzeichnungsagent auf einen geeigneten Wert festzulegen. Der Standardwert von 7.200 Sekunden (zwei Stunden) 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. Unter normalen Bedingungen 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ß.

  • Sorgen Sie dafür, dass geplante Ausfälle nur zu Nebenzeiten stattfinden. Befolgen Sie, soweit Ihr Budget dies erlaubt, anerkannte Verfahren zum Erstellen hoch verfügbarer Server. Dazu gehören der Einsatz von 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. Kann ein Server 5,0 MBit/s verarbeiten, sollten Sie ihn nur mit 2,5 MBit/s ausfü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 und die Aufzeichnungsdaten werden direkt und ohne interne Pufferung an den Speichermanager gesendet. Da die Aufnahmedatei 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, sorgen Sie durch Kapazitätsreserven und Fehlertoleranz dafür, dass die Wahrscheinlichkeit eines Datenrückstaus gering ist.

Skalierbarkeit von XenApp und XenDesktop

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. Umfangreiche Skalierbarkeitstests von Citrix haben ergeben, dass die Aufzeichnung von ICA-Sitzungen nur geringe Auswirkungen auf die Leistung und Skalierbarkeit von XenApp und XenDesktop-Servern hat. 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. In vielen Fällen sind die Skalierbarkeitsauswirkungen vernachlässigbar und die Benutzerdichte pro Server bleibt gleich. Wie bereits erwähnt, sind die geringen Auswirkung auf die einfachen Verarbeitungsanforderungen der auf den VDAs installierten Sitzungsaufzeichnungskomponenten zurückzuführen. Aufzeichnungsdaten werden einfach 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. Die Auswirkungen sind zwar gering, doch wenn Sie sicher sind, dass von einem Server nie Sitzungen aufgezeichnet werde, können Sie die Aufzeichnung dort deaktivieren. Hierfür können Sie beispielsweise Sitzungsaufzeichnung entfernen. Weniger invasiv ist das Deaktivieren des Kontrollkästchens Sitzungsaufzeichnung für diese VDA-Maschine aktivieren auf der Registerkarte Sitzungsaufzeichnung in den Eigenschaften des Sitzungsaufzeichnungsagents. Wird die Sitzungsaufzeichnung in Zukunft benötigt, aktivieren Sie das Kontrollkästchen.

Durchsatzmessung

Es gibt verschiedene Möglichkeiten, den Durchsatz der Sitzungsaufzeichnungsdaten vom VDA zum Sitzungsaufzeichnungsserver zu messen. Einer der einfachsten und effektivsten Methoden besteht in der Messung der Größe der Sitzungsaufzeichnungsdateien sowie der Geschwindigkeit, mit der Speicherplatz auf dem Sitzungsaufzeichnungsserver belegt wird. Die Menge auf die Festplatte geschriebener Daten spiegelt fast genau die Menge des generierten Netzwerkdatenverkehrs wider. Die Windows-Leistungsüberwachung (perfmon.exe) bietet eine Reihe von Standardsystemindikatoren, die zusätzlich den Leistungsindikatoren der Sitzungsaufzeichnung geprüft werden 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.

Leistungsobjekt Indikatorname Beschreibung
Citrix Sitzungsaufzeichnungsagent Anzahl aktiver Aufzeichnungen Gibt die Anzahl der Sitzungen an, die aktuell auf einem VDA aufgezeichnet werden.
Citrix Sitzungsaufzeichnungsagent Vom Sitzungsaufzeichnungstreiber gelesene Bytes Die Anzahl der von den für das Erfassen von Sitzungsdaten verantwortlichen Kernel-Komponenten gelesenen Bytes. Nützlich zur Ermittlung der Datenmenge, die ein VDA für alle auf dem betreffenden Server aufgezeichneten Sitzungen generiert.
Speichermanager der Citrix Sitzungsaufzeichnung Anzahl aktiver Aufzeichnungen Wie beim Leistungsindikator des Citrix Sitzungsaufzeichnungsagents doch im Hinblick auf den Sitzungsaufzeichnungsserver. Gibt die Gesamtzahl der Sitzungen an, die derzeit für alle Server aufgezeichnet werden.
Speichermanager der Citrix Sitzungsaufzeichnung Message bytes/sec Durchsatz aller aufgezeichneten Sitzungen. Kann verwendet werden, um die Datenverarbeitungsrate des Speichermanagers zu bestimmen. Bei einem MSMQ-Nachrichtenrückstand wird der Speichermanager mit voller Geschwindigkeit ausgeführt. Anhand dieses Werts kann die maximale Verarbeitungsrate des Speichermanagers angegeben werden.
LogicalDisk Disk Write Bytes/sec Kann zur Messung der Datenträger-Schreibleistung verwendet werden. Dies ist wichtig zur Erzielung einer hohen Skalierbarkeit für den Sitzungsaufzeichnungsserver. Auch die Leistung einzelner Laufwerke kann gemessen werden.
MSMQ-Warteschlange Bytes in Queue Anhand dieses Leistungsindikators kann die Menge der in der CitrixSmAudData-Warteschlange aufgelaufenen Daten ermittelt werden. Steigt dieser Wert im Laufe der Zeit an, so ist die Rate der vom Netzwerk empfangenen Aufzeichnungsdaten größer als die Datenverarbeitungsrate des Speichermanagers. Dieser Zähler ist nützlich, um die Auswirkungen von Bursts und Fehlern zu beobachten.
MSMQ-Warteschlange Message in Queue Ähnlich wie “Bytes in Queue”, jedoch wird die Anzahl der Nachrichten wiedergegeben.
Netzwerkschnittstelle Bytes Total/sec Kann an beiden Seiten der Verbindung gemessen werden, um zu ermitteln, wie viele Daten beim Aufzeichnen von Sitzungen generiert werden. Auf dem Sitzungsaufzeichnungsserver gibt dieser Indikator die Rate des Empfangs eingehender Daten an. Dies ist im Unterschied zu dem Leistungsindikator “Message bytes/sec”des Speichermanagers der Citrix Sitzungsaufzeichnung, der die Verarbeitungsrate der Daten wiedergibt. Wenn die Netzwerkrate größer als dieser Wert ist, laufen Nachrichten in der Warteschlange auf.
Prozessor % Processor Time Eine Überwachung dieses Indikators lohnt sich, obwohl die CPU als wahrscheinlicher Engpass eher nicht in Frage kommt.

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 IOPS-abhängig. Dies gewährleistet einen hohen Durchsatz von Aufzeichnungsdaten aus dem Netzwerk auf den Datenträger. 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 deutlich 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 lokalen Festplatten, die entweder von einem lokalen Festplattencontroller als als RAID oder als SAN gesteuert werden.

Hinweis:

Das Speichern von Daten in einem NAS mit dateibasiertem Protokoll wie SMB, CIFS oder NFS hat schwerwiegende Auswirkungen auf Leistung und Sicherheit. Verwenden Sie eine solche Konfiguration nie in einer Produktionsbereitstellung der Sitzungsaufzeichnung.

Bei einer Konfiguration mit lokalen Festplatten sollten Sie einen Festplattencontroller mit integriertem Cache verwenden. Caching ermöglicht dem Controller die Verwendung des Aufzug-Algorithmus beim Zurückschreiben, was die Bewegung des Festplattenkopfs minimiert und sicherstellt, dass Schreibvorgänge ohne Warten auf den Abschluss des physischen Festplattenvorgangs 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 Festplattencontroller mit Cache in Betracht ziehen, die den Cache bei einem Stromausfall aufrecht erhält und dafür sorgt, dass die Daten bei Wiederherstellung der Stromversorgung auf die Festplatte geschrieben werden können.

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-Level Typ Mindestanzahl Datenträger Beschreibung
RAID 0 Mit Striping, ohne Parität 2 Bietet eine hohe Leistung, aber keine Redundanz. Der Verlust eines Datenträgers zerstört das Array. Es ist eine kostengünstige Lösung für die Speicherung von Sitzungsaufzeichnungsdateien, wenn ein Datenverlust nur geringe Auswirkungen hat. Die Leistung kann durch Hinzufügen weiterer Datenträger mühelos erhöht werden.
RAID 1 Gespiegelt, ohne Parität 2 Keine größere Leistung als mit einen Datenträger und daher eine relativ kostspielige Lösung. Verwenden Sie diese Lösung nur, wenn eine hohe Redundanz erforderlich ist.
RAID 3 Mit Striping und dedizierter Parität 3 Bietet hohe Schreibleistung mit ähnlichen Redundanzeigenschaften wie RAID 5. RAID 3 wird für die Videoproduktion und Livestreaming empfohlen. Da es sich bei der Sitzungsaufzeichnung um eine Anwendung dieser Art handelt, wird RAID 3 am ehesten empfohlen, es ist jedoch nicht üblich.
RAID 5 Mit Striping und verteilter Parität 3 Bietet eine hohe Leseleistung mit Redundanz, jedoch auf Kosten einer geringeren Schreibleistung. RAID 5 ist die am häufigsten die allgemeine Verwendung eingesetzte Lösung. Aufgrund der langsamen Schreibleistung wird RAID 5 jedoch nicht für die Sitzungsaufzeichnung empfohlen. Bei RAID 3 sind die Kosten ähnlich, die Schreibleistung ist aber deutlich besser.
RAID 10 Gespiegelt, mit Striping 4 Bietet Leistungsmerkmale wie RAID 0 mit Redundanz wie RAID 1. Eine teure Lösung, die für die Sitzungsaufzeichnung nicht empfohlen wird.

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 Festplatten-Geschwindigkeit 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 Festplattenspeicher eingespart werden. Steht 1 TB Festplattenspeicher zur Verfügung, ist eine siebentägige Aufbewahrungsfrist sinnvoll, die sicherstellt, dass rund 700 GB Festplattenspeicher 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 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 Datenbank für die Sitzungsaufzeichnung erfordert Microsoft SQL Server 2016, Microsoft SQL Server 2014, Microsoft SQL Server 2012 oder Microsoft SQL Server 2008 R2. Die an die Datenbank 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 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 XenApp- oder XenDesktop-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.