Überlegungen zur Skalierbarkeit

Session Recording ist ein hoch skalierbares System, das Tausende oder Zehntausende von Sitzungen verarbeiten kann. Die Installation und Ausführung von Session Recording erfordert nur wenige zusätzliche Ressourcen über das hinaus, was für den Betrieb von XenApp und XenDesktop erforderlich ist. Wenn Sie jedoch Session Recording verwenden möchten, um eine große Anzahl von Sitzungen aufzuzeichnen, oder wenn die aufzuzeichnenden Sitzungen zu großen Sitzungsdateien führen können (z. B. grafisch intensive Anwendungen), berücksichtigen Sie die Leistung Ihres Systems bei der Planung Ihrer Session Recording-Bereitstellung.

Dieser Artikel erläutert, wie Session Recording eine hohe Skalierbarkeit erreicht und wie Sie das Beste aus Ihrem Aufzeichnungssystem zu geringsten Kosten herausholen können.

Warum Session Recording gut skaliert

Es gibt zwei Hauptgründe, warum Session Recording im Vergleich zu Konkurrenzprodukten gut skaliert:

• Geringe Dateigröße

  Eine mit Session Recording erstellte aufgezeichnete Sitzungsdatei ist hochkompakt. Sie ist um viele Größenordnungen kleiner als eine gleichwertige Videoaufzeichnung, die mit Screen-Scraping-Lösungen erstellt wurde. Die für den Transport und die Speicherung jeder Session Recording-Datei erforderliche Netzwerkbandbreite, der Speicherplatz und die Festplatten-IOPS sind typischerweise mindestens 10-mal geringer als bei einer gleichwertigen Videodatei.

  Die geringe Größe der aufgezeichneten Sitzungsdateien bedeutet eine schnellere und flüssigere Wiedergabe von Videobildern. Aufzeichnungen sind auch völlig verlustfrei und weisen keine Verpixelung auf, die bei den meisten kompakten Videoformaten üblich ist. Text in Aufzeichnungen ist während der Wiedergabe genauso gut lesbar wie in den ursprünglichen Sitzungen. Um kleine Dateigrößen beizubehalten, zeichnet Session Recording keine Keyframes innerhalb der Dateien auf.

• Geringer Verarbeitungsaufwand zum Generieren von Dateien

  Eine aufgezeichnete Sitzungsdatei enthält die ICA®-Protokolldaten für eine Sitzung, die praktisch in ihrem nativen Format extrahiert werden. Dies bedeutet, dass die Datei den ICA-Protokolldatenstrom erfasst, der für die Kommunikation mit der Citrix Workspace™ App verwendet wird. Es ist nicht erforderlich, aufwendige Transkodierungs- oder Kodierungssoftwarekomponenten auszuführen, um das Datenformat in Echtzeit zu ändern. Der geringe Verarbeitungsaufwand ist auch für die VDA-Skalierbarkeit wichtig und stellt sicher, dass die Endbenutzererfahrung erhalten bleibt, wenn viele Sitzungen vom selben VDA aufgezeichnet werden.

  Darüber hinaus werden nur die ICA-virtuellen Kanäle aufgezeichnet, die wiedergegeben werden können, was zu einer weiteren Optimierung führt. Beispielsweise werden die Kanäle für Drucker und Clientlaufwerkzuordnung nicht aufgezeichnet, da sie große Datenmengen ohne Nutzen für die Videowiedergabe generieren können.

Schätzung der Dateneingabe- und Verarbeitungsraten

Der Session Recording Server ist der zentrale Sammelpunkt für aufgezeichnete Sitzungsdateien. Jede Maschine, auf der ein Multi-Session-OS-VDA mit aktiviertem Session Recording ausgeführt wird, sendet aufgezeichnete Sitzungsdaten an den Session Recording Server. Session Recording kann große Datenmengen verarbeiten und Spitzen und Fehler tolerieren, aber es gibt physikalische Grenzen dafür, wie viele Daten ein Server verarbeiten kann.

Berücksichtigen Sie, wie viele Daten Sie an jeden Session Recording Server senden werden und wie schnell die Server diese Daten verarbeiten und speichern können. Die Rate, mit der Ihr System eingehende Daten speichern kann, muss höher sein als die Dateneingaberate.

Um Ihre Dateneingaberate zu schätzen, multiplizieren Sie die Anzahl der aufgezeichneten Sitzungen mit der durchschnittlichen Größe jeder aufgezeichneten Sitzung und dividieren Sie das Ergebnis durch die Zeit, für die Sie Sitzungen aufzeichnen. Sie könnten beispielsweise 5.000 Microsoft Outlook-Sitzungen von jeweils 20 MB über einen 8-Stunden-Arbeitstag aufzeichnen. In diesem Fall beträgt die Dateneingaberate ungefähr 3,5 Mbit/s. (5.000 Sitzungen mal 20 MB geteilt durch 8 Stunden, geteilt durch 3.600 Sekunden pro Stunde.) Ein typischer Session Recording Server, der an ein 100-Mbit/s-LAN angeschlossen ist und über ausreichend Speicherplatz für die aufgezeichneten Daten verfügt, kann Daten mit etwa 5,0 Mbit/s verarbeiten, basierend auf den physikalischen Grenzen, die durch Festplatten- und Netzwerk-IOPS auferlegt werden. Dies ist die Verarbeitungsrate. Im Beispiel ist die Verarbeitungsrate (5,0 Mbit/s) höher als die Eingaberate (3,5 Mbit/s), sodass die Aufzeichnung der 5.000 Outlook-Sitzungen machbar ist.

Beachten Sie, dass die Datenmenge pro Sitzung stark davon abhängt, was aufgezeichnet wird, während andere Faktoren wie Bildschirmauflösung, Farbtiefe und Grafikmodus ebenfalls Auswirkungen haben. Eine Sitzung, die ein CAD-Paket ausführt, bei dem die Grafikaktivität ständig hoch ist, erzeugt wahrscheinlich eine viel größere Aufzeichnung als eine Sitzung, in der der Endbenutzer E-Mails in Microsoft Outlook sendet und empfängt. Daher kann die Aufzeichnung der gleichen Anzahl von CAD-Sitzungen eine extrem hohe Eingangsrate erzeugen und den Einsatz von mehr Session Recording Servern erfordern.

Bursts und Fehler

Das vorherige Beispiel geht von einem sehr einfachen, gleichmäßigen Datendurchsatz aus, erklärt aber nicht, wie das System mit kurzen Perioden höherer Aktivität, sogenannten Bursts, umgeht. Ein Burst kann auftreten, wenn sich alle Benutzer morgens gleichzeitig anmelden, bekannt als der 9-Uhr-Ansturm, oder wenn sie dieselbe E-Mail gleichzeitig in ihrem Outlook-Posteingang erhalten. Die Verarbeitungsrate von 5,0 Mbit/s des Session Recording Servers ist völlig unzureichend, um diese plötzliche Nachfrage zu bewältigen.

Der auf jedem VDA ausgeführte Session Recording Agent verwendet Microsoft Message Queuing (MSMQ), um aufgezeichnete Daten an den Storage Manager zu senden, der auf dem zentralen Session Recording Server ausgeführt wird. Die Daten werden nach dem Store-and-Forward-Prinzip gesendet, ähnlich wie eine E-Mail zwischen Absender, Mailserver und Empfänger zugestellt wird. Wenn der Session Recording Server oder das Netzwerk die hohe Datenrate in einem Burst nicht verarbeiten kann, werden die aufgezeichneten Sitzungsdaten vorübergehend gespeichert, bis der Rückstand an Datennachrichten abgearbeitet ist. Die Datennachricht kann vorübergehend in der Ausgangswarteschlange auf dem VDA gespeichert werden, wenn das Netzwerk überlastet ist, oder in der Empfangswarteschlange des Session Recording Servers, wenn die Daten das Netzwerk durchlaufen haben, der Storage Manager aber noch mit der Verarbeitung anderer Nachrichten beschäftigt ist.

MSMQ dient auch als Fehlertoleranzmechanismus. Wenn der Session Recording Server ausfällt oder die Verbindung unterbrochen wird, werden die aufgezeichneten Daten in der Ausgangswarteschlange jedes VDA gespeichert. Wenn der Fehler behoben ist, werden alle in der Warteschlange befindlichen Daten zusammen gesendet. Die Verwendung von MSMQ ermöglicht es Ihnen auch, einen Session Recording Server für Upgrades oder Wartungsarbeiten offline zu nehmen, ohne die Aufzeichnung bestehender Sitzungen zu unterbrechen und Daten zu verlieren.

Die Hauptbeschränkung von MSMQ besteht darin, dass der Speicherplatz für die temporäre Speicherung von Datennachrichten begrenzt ist. Dies begrenzt, wie lange ein Burst, ein Fehler oder ein Wartungsereignis dauern kann, bevor Daten letztendlich verloren gehen. Das Gesamtsystem kann nach Datenverlust weiterarbeiten, aber in dieser Situation fehlen einzelnen Aufzeichnungen Datenblöcke. Eine Datei mit fehlenden Daten ist weiterhin abspielbar, jedoch nur bis zu dem Punkt, an dem die Daten zuerst verloren gingen. Beachten Sie Folgendes:

• Das Hinzufügen von mehr Speicherplatz zu jedem Server, insbesondere zum Session Recording Server, und dessen Bereitstellung für MSMQ kann die Toleranz gegenüber Bursts und Fehlern erhöhen.

• Es ist wichtig, die Einstellung für die Nachrichtenlebensdauer (Message Life) für jeden Session Recording Agent auf ein angemessenes Niveau zu konfigurieren (auf der Registerkarte Verbindungen in den Session Recording Agent-Eigenschaften). Der Standardwert von 7.200 Sekunden (zwei Stunden) bedeutet, dass jede aufgezeichnete Datennachricht zwei Stunden Zeit hat, den Storage Manager zu erreichen, bevor sie verworfen wird und Aufzeichnungsdateien beschädigt werden. Mit mehr verfügbarem Speicherplatz (oder weniger aufzuzeichnenden Sitzungen) können Sie diesen Wert erhöhen. Der Maximalwert beträgt 365 Tage.

Die andere Einschränkung bei MSMQ besteht darin, dass bei Datenrückständen zusätzliche Disk-IOPS in der Warteschlange zum Lesen und Schreiben von Datennachrichten anfallen. Unter normalen Bedingungen empfängt und verarbeitet der Storage Manager Daten direkt aus dem Netzwerk, ohne dass die Datennachricht jemals auf die Festplatte geschrieben wird. Das Speichern der Daten beinhaltet einen einzigen Schreibvorgang auf die Festplatte, der die aufgezeichnete Sitzungsdatei anhängt. Wenn Daten im Rückstand sind, verdreifachen sich die Disk-IOPS: Jede Nachricht muss auf die Festplatte geschrieben, von der Festplatte gelesen und in die Datei geschrieben werden. Da der Storage Manager stark IOPS-gebunden ist, sinkt die Verarbeitungsrate des Session Recording Servers, bis der Nachrichtenrückstand beseitigt ist. Um die Auswirkungen dieser zusätzlichen IOPS zu mindern, beachten Sie die folgenden Empfehlungen:

• Stellen Sie sicher, dass sich die Festplatte, auf der MSMQ Nachrichten speichert, von den Speicherordnern für Aufzeichnungsdateien unterscheidet. Auch wenn der IOPS-Busverkehr verdreifacht wird, ist der Rückgang der tatsächlichen Verarbeitungsrate niemals so gravierend.

• Planen Sie Ausfälle nur außerhalb der Spitzenzeiten. Befolgen Sie je nach Budgetbeschränkungen anerkannte Ansätze zum Aufbau hochverfügbarer Server. Diese Ansätze umfassen die Verwendung von USV, Dual-NICs, redundanten Switches sowie Hot-Swap-fähigem Speicher und Festplatten.

Auslegung für Reservekapazität

Die Datenrate aufgezeichneter Sitzungsdaten ist unwahrscheinlich gleichmäßig, Bursts und Fehler können auftreten, und das Beseitigen von Nachrichtenrückständen ist IOPS-intensiv. Aus diesem Grund sollte jeder Session Recording Server mit reichlich Reservekapazität ausgelegt werden. Das Hinzufügen weiterer Server oder die Verbesserung der Spezifikationen bestehender Server, wie in späteren Abschnitten beschrieben, verschafft Ihnen immer zusätzliche Kapazität. Die Faustregel besagt, dass jeder Session Recording Server mit maximal 50 % seiner Gesamtkapazität betrieben werden sollte. Im vorherigen Beispiel, wenn der Server 5,0 Mbit/s verarbeiten kann, sollte das System nur mit 2,5 Mbit/s betrieben werden. Anstatt 5.000 Outlook-Sitzungen auf einem Session Recording Server aufzuzeichnen, die 3,5 Mbit/s erzeugen, reduzieren Sie dies auf 3.500 Sitzungen, die nur etwa 2,5 Mbit/s erzeugen.

Rückstände und Live-Wiedergabe

Live-Wiedergabe ist, wenn ein Prüfer eine Sitzungsaufzeichnung zur Wiedergabe öffnet, während die Sitzung noch aktiv ist. Während der Live-Wiedergabe wechselt der für die Sitzung zuständige Session Recording Agent in einen Streaming-Modus für diese Sitzung, und die Aufzeichnungsdaten werden sofort ohne interne Pufferung an den Storage Manager gesendet. Da die Aufzeichnungsdatei ständig aktualisiert wird, kann der Player weiterhin mit den neuesten Daten aus der Live-Sitzung versorgt werden. Daten, die vom Agent an den Storage Manager gesendet werden, erfolgen jedoch über MSMQ, daher gelten die zuvor beschriebenen Warteschlangenregeln. In diesem Szenario kann ein Problem auftreten. Wenn MSMQ im Rückstand ist, werden die neuen aufgezeichneten Daten, die für die Live-Wiedergabe verfügbar sind, wie alle anderen Datennachrichten in die Warteschlange gestellt. Der Prüfer kann die Datei weiterhin abspielen, aber die Anzeige der neuesten live aufgezeichneten Daten ist verzögert. Wenn die Live-Wiedergabe eine wichtige Funktion für Prüfer ist, stellen Sie eine geringe Wahrscheinlichkeit von Rückständen sicher, indem Sie Reservekapazität und Fehlertoleranz in Ihre Bereitstellung integrieren.

Skalierbarkeit von XenApp® und XenDesktop

Die Sitzungsaufzeichnung reduziert niemals die Sitzungsleistung und beendet niemals Sitzungen aufgrund von Rückständen bei aufgezeichneten Daten. Die Aufrechterhaltung der Endbenutzererfahrung und der Skalierbarkeit auf einem einzelnen Server ist bei der Entwicklung des Sitzungsaufzeichnungssystems von größter Bedeutung. Wenn das Aufzeichnungssystem irreversibel überlastet wird, werden aufgezeichnete Sitzungsdaten verworfen. Umfangreiche Skalierbarkeitstests von Citrix® zeigen, dass die Aufzeichnung von ICA-Sitzungen die Leistung und Skalierbarkeit von XenApp- und XenDesktop-Servern nur geringfügig beeinträchtigt. Das Ausmaß der Beeinträchtigung hängt von der Plattform, dem verfügbaren Arbeitsspeicher und der grafischen Natur der aufgezeichneten Sitzungen ab. Mit der folgenden Konfiguration können Sie eine Skalierbarkeitsbeeinträchtigung eines einzelnen Servers zwischen 1 % und 5 % erwarten. Mit anderen Worten: Wenn ein Server ohne installierte Sitzungsaufzeichnung 100 Benutzer hosten kann, kann er nach der Installation 95–99 Benutzer hosten:

• 64-Bit-Server mit 8 GB RAM, auf dem ein Multi-Session-OS-VDA ausgeführt wird
• Alle Sitzungen führen Office-Produktivitätsanwendungen wie Outlook und Excel aus
• Die Nutzung der Anwendungen ist aktiv und dauerhaft
• Alle Sitzungen werden gemäß den Richtlinien für die Sitzungsaufzeichnung aufgezeichnet

Wenn weniger Sitzungen aufgezeichnet werden oder die Sitzungsaktivität weniger dauerhaft und sporadischer ist, ist die Auswirkung geringer. In vielen Fällen ist die Skalierbarkeitsauswirkung vernachlässigbar, und die Benutzerdichte pro Server bleibt gleich. Wie bereits erwähnt, ist die geringe Auswirkung auf die einfachen Verarbeitungsanforderungen der auf jedem VDA installierten Komponenten für die Sitzungsaufzeichnung zurückzuführen. Aufgezeichnete Daten werden einfach aus dem ICA-Sitzungsstack extrahiert und unverändert über MSMQ an den Sitzungsaufzeichnungsserver gesendet. Es gibt keine aufwendige Datenkodierung.

Es gibt einen geringen Overhead bei der Verwendung der Sitzungsaufzeichnung, selbst wenn keine Sitzungen aufgezeichnet werden. Obwohl die Auswirkung gering ist, können Sie die Aufzeichnung auf einem bestimmten Server deaktivieren, wenn Sie sicher sind, dass dort niemals Sitzungen aufgezeichnet werden. Das Entfernen der Sitzungsaufzeichnung ist eine Möglichkeit, dies zu tun. Ein weniger invasiver Ansatz ist das Deaktivieren des Kontrollkästchens Sitzungsaufzeichnung für diese VDA-Maschine aktivieren auf der Registerkarte Sitzungsaufzeichnung in den Eigenschaften des Sitzungsaufzeichnungs-Agenten. Wenn die Sitzungsaufzeichnung in Zukunft erforderlich ist, aktivieren Sie dieses Kontrollkästchen erneut.

Durchsatzmessung

Es gibt verschiedene Möglichkeiten, den Durchsatz aufgezeichneter Sitzungsdaten vom sendenden VDA zum empfangenden Sitzungsaufzeichnungsserver zu messen. Einer der einfachsten und effektivsten Ansätze ist die Beobachtung der Größe der aufgezeichneten Dateien und der Rate, mit der Speicherplatz auf dem Sitzungsaufzeichnungsserver belegt wird. Das Volumen der auf die Festplatte geschriebenen Daten spiegelt das Volumen des generierten Netzwerkverkehrs wider. Das Windows-Leistungsüberwachungstool (perfmon.exe) verfügt über eine Reihe von Standard-Systemindikatoren, die zusätzlich zu einigen von der Sitzungsaufzeichnung bereitgestellten Indikatoren beobachtet werden können. Indikatoren können verwendet werden, um den Durchsatz zu messen und Engpässe sowie Systemprobleme zu identifizieren. Die folgende Tabelle zeigt einige der nützlichsten Leistungsindikatoren.

Hardware des Sitzungsaufzeichnungsservers

Sie können die Kapazität Ihrer Bereitstellung erhöhen, indem Sie die für den Sitzungsaufzeichnungsserver verwendete Hardware sorgfältig auswählen. Sie haben zwei Möglichkeiten: Skalierung nach oben (durch Erhöhung der Kapazität jedes Servers) oder Skalierung nach außen (durch Hinzufügen weiterer Server). Bei beiden Entscheidungen ist es Ihr Ziel, die Skalierbarkeit zu geringstmöglichen Kosten zu erhöhen.

Skalierung nach oben

Bei der Betrachtung eines einzelnen Sitzungsaufzeichnungsservers sollten Sie die folgenden Best Practices berücksichtigen, um eine optimale Leistung innerhalb des verfügbaren Budgets zu gewährleisten. Das System ist von IOPS abhängig. Dies gewährleistet einen hohen Durchsatz aufgezeichneter Daten vom Netzwerk auf die Festplatte. Daher ist es wichtig, in geeignete Netzwerk- und Festplattenhardware zu investieren. Für einen Hochleistungs-Sitzungsaufzeichnungsserver wird eine Dual-CPU oder eine Dual-Core-CPU empfohlen, aber eine höhere Spezifikation bringt kaum Vorteile. Eine 64-Bit-Prozessorarchitektur wird empfohlen, aber ein x86-Prozessortyp ist ebenfalls geeignet. 4 GB RAM werden empfohlen, aber auch hier bringt mehr Arbeitsspeicher kaum Vorteile.

Horizontale Skalierung

Selbst mit den besten Praktiken zur vertikalen Skalierung gibt es Leistungsgrenzen und Skalierbarkeitsgrenzen, die mit einem einzelnen Session Recording-Server erreicht werden können, wenn eine große Anzahl von Sitzungen aufgezeichnet wird. Es kann notwendig sein, zusätzliche Server hinzuzufügen, um die Last zu bewältigen. Sie können weitere Session Recording-Server auf verschiedenen Maschinen installieren, damit die Session Recording-Server als Lastenausgleichspool fungieren. Bei dieser Art der Bereitstellung teilen sich die Session Recording-Server den Speicher und die Datenbank. Um die Last zu verteilen, leiten Sie die Session Recording-Agenten an den Lastenausgleich weiter, der für die Workload-Verteilung zuständig ist.

Netzwerkkapazität

Eine 100-Mbit/s-Netzwerkverbindung ist für den Anschluss eines Session Recording-Servers geeignet. Eine Gigabit-Ethernet-Verbindung kann die Leistung verbessern, führt aber nicht zu einer zehnmal höheren Leistung als eine 100-Mbit/s-Verbindung. In der Praxis ist der Durchsatzgewinn deutlich geringer.

Stellen Sie sicher, dass die von Session Recording verwendeten Netzwerk-Switches nicht mit Drittanbieteranwendungen geteilt werden, die um die verfügbare Netzwerkbandbreite konkurrieren könnten. Idealerweise sind Netzwerk-Switches ausschließlich für die Verwendung mit dem Session Recording-Server vorgesehen. Wenn sich Netzwerküberlastung als Engpass erweist, ist ein Netzwerk-Upgrade eine relativ kostengünstige Möglichkeit, die Skalierbarkeit des Systems zu erhöhen.

Speicher

Investitionen in Festplatten- und Speicherhardware sind der wichtigste Faktor für die Serverskalierbarkeit. Je schneller Daten auf die Festplatte geschrieben werden können, desto höher ist die Leistung des Gesamtsystems. Achten Sie bei der Auswahl einer Speicherlösung mehr auf die Schreibleistung als auf die Leseleistung.

Speichern Sie Daten auf einem Satz lokaler Festplatten, die entweder als RAID von einem lokalen Festplatten-Controller oder als SAN gesteuert werden.

Hinweis:

Das Speichern von Daten auf einem NAS, das auf dateibasierten Protokollen wie SMB, CIFS oder NFS basiert, hat schwerwiegende Auswirkungen auf Leistung und Sicherheit. Verwenden Sie diese Konfiguration niemals in einer Produktionsumgebung von Session Recording.

Für eine lokale Laufwerkskonfiguration sollten Sie einen Festplatten-Controller mit integriertem Cache-Speicher anstreben. Caching ermöglicht es dem Controller, beim Write-Back eine Elevator-Sortierung zu verwenden, was die Festplattenkopfbewegung minimiert und sicherstellt, dass Schreibvorgänge abgeschlossen werden, ohne auf den Abschluss des physischen Festplattenvorgangs warten zu müssen. Dies kann die Schreibleistung bei minimalen zusätzlichen Kosten erheblich verbessern. Caching birgt jedoch das Problem des Datenverlusts nach einem Stromausfall. Um die Datenintegrität und das Dateisystem zu gewährleisten, sollten Sie eine Batterie-Backup-Einrichtung für den Caching-Festplatten-Controller in Betracht ziehen, die sicherstellt, dass bei Stromausfall der Cache erhalten bleibt und Daten auf die Festplatte geschrieben werden, wenn die Stromversorgung schließlich wiederhergestellt ist.

Erwägen Sie die Verwendung einer geeigneten RAID-Speicherlösung. Je nach Leistungs- und Redundanzanforderungen stehen viele RAID-Level zur Verfügung. Die folgende Tabelle gibt die einzelnen RAID-Level und deren Anwendbarkeit für Session Recording an.

RAID 0 und RAID 3 sind die am meisten empfohlenen RAID-Level. RAID 1 und RAID 5 sind beliebte Standards, werden aber für Session Recording nicht empfohlen. RAID 10 bietet einige Leistungsvorteile, ist aber für den zusätzlichen Gewinn zu teuer.

Entscheiden Sie sich für den Typ und die Spezifikation der Festplattenlaufwerke. IDE/ATA-Laufwerke sowie externe USB- oder Firewire-Laufwerke sind für die Verwendung in Session Recording nicht geeignet. Die Hauptwahl besteht zwischen SATA und SCSI. SATA-Laufwerke bieten recht hohe Übertragungsraten zu geringeren Kosten pro MB im Vergleich zu SCSI-Laufwerken. SCSI-Laufwerke bieten jedoch eine bessere Leistung und sind in Serverbereitstellungen häufiger anzutreffen. Server-RAID-Lösungen unterstützen meist SCSI-Laufwerke, aber einige SATA-RAID-Produkte sind jetzt verfügbar. Berücksichtigen Sie bei der Bewertung der Spezifikationen von Festplattenprodukten die Rotationsgeschwindigkeit der Festplatte und andere Leistungsmerkmale.

Da die Aufzeichnung von Tausenden von Sitzungen pro Tag erhebliche Mengen an Speicherplatz beanspruchen kann, müssen Sie zwischen Gesamtkapazität und Leistung wählen. Aus dem früheren Beispiel geht hervor, dass die Aufzeichnung von 5.000 Outlook-Sitzungen über einen 8-Stunden-Arbeitstag etwa 100 GB Speicherplatz verbraucht. Um Aufzeichnungen von 10 Tagen (d. h. 50.000 aufgezeichnete Sitzungsdateien) zu speichern, benötigen Sie 1.000 GB (1 TB). Dieser Druck auf den Speicherplatz kann durch Verkürzung der Aufbewahrungsfrist vor der Archivierung oder dem Löschen alter Aufzeichnungen gemildert werden. Wenn 1 TB Speicherplatz verfügbar ist, ist eine Aufbewahrungsfrist von sieben Tagen angemessen, wodurch die Speichernutzung bei etwa 700 GB bleibt, wobei 300 GB als Puffer für arbeitsreiche Tage verbleiben. In der Sitzungsaufzeichnung wird das Archivieren und Löschen von Dateien mit dem Dienstprogramm ICLDB unterstützt und hat eine Mindestaufbewahrungsfrist von zwei Tagen. Sie können eine Hintergrundaufgabe planen, die einmal täglich zu einer Nebenzeit ausgeführt wird. Weitere Informationen zu den ICLDB-Befehlen und zur Archivierung finden Sie unter Verwalten Ihrer Datenbankdatensätze.

Die Alternative zur Verwendung lokaler Laufwerke und Controller ist eine SAN-Speicherlösung, die auf blockbasiertem Festplattenzugriff basiert. Für den Session Recording Server erscheint das Festplatten-Array als lokales Laufwerk. SANs sind in der Einrichtung teurer, aber da das Festplatten-Array gemeinsam genutzt wird, bieten SANs den Vorteil einer vereinfachten und zentralisierten Verwaltung. Es gibt zwei Haupttypen von SAN: Fibre Channel und iSCSI. iSCSI ist im Wesentlichen SCSI über TCP/IP und gewinnt seit der Einführung von Gb Ethernet an Popularität gegenüber Fibre Channel.

Datenbankskalierbarkeit

Die Session Recording-Datenbank erfordert Microsoft SQL Server 2016, Microsoft SQL Server 2014, Microsoft SQL Server 2012 oder Microsoft SQL Server 2008 R2. Das an die Datenbank gesendete Datenvolumen ist gering, da die Datenbank nur Metadaten zu den aufgezeichneten Sitzungen speichert. Die Dateien der aufgezeichneten Sitzungen selbst werden auf eine separate Festplatte geschrieben. Typischerweise benötigt jede aufgezeichnete Sitzung nur etwa 1 KB Speicherplatz in der Datenbank, es sei denn, die Session Recording Event API wird verwendet, um durchsuchbare Ereignisse in die Sitzung einzufügen.

Die Express-Editionen von Microsoft SQL Server 2016, Microsoft SQL Server 2014, Microsoft SQL Server 2012 und Microsoft SQL Server 2008 R2 unterliegen einer Datenbankgrößenbeschränkung von 10 GB. Bei 1 KB pro Aufzeichnungssitzung kann die Datenbank etwa 4.000.000 Sitzungen katalogisieren. Andere Editionen von Microsoft SQL Server haben keine Datenbankgrößenbeschränkungen und sind nur durch den verfügbaren Speicherplatz begrenzt. Mit zunehmender Anzahl von Sitzungen in der Datenbank nimmt die Leistung der Datenbank und die Geschwindigkeit der Suchvorgänge nur vernachlässigbar ab.

Wenn Sie keine Anpassungen über die Session Recording Event API vornehmen, generiert jede aufgezeichnete Sitzung vier Datenbanktransaktionen: zwei beim Start der Aufzeichnung, eine, wenn der Benutzer sich bei der aufgezeichneten Sitzung anmeldet, und eine, wenn die Aufzeichnung endet. Wenn Sie die Session Recording Event API verwenden, um Sitzungen anzupassen, generiert jedes aufgezeichnete durchsuchbare Ereignis eine Transaktion. Da selbst die grundlegendste Datenbankbereitstellung Hunderte von Transaktionen pro Sekunde verarbeiten kann, ist es unwahrscheinlich, dass die Verarbeitungslast auf der Datenbank überlastet wird. Die Auswirkungen sind gering genug, dass die Session Recording-Datenbank auf demselben SQL Server wie andere Datenbanken ausgeführt werden kann, einschließlich der XenApp- oder XenDesktop-Datenspeicherdatenbank.

Wenn Ihre Session Recording-Bereitstellung viele Millionen aufgezeichneter Sitzungen in der Datenbank katalogisieren muss, befolgen Sie die Microsoft-Richtlinien für die SQL Server-Skalierbarkeit.