Überlegungen zur Skalierbarkeit

Session Recording ist ein hoch skalierbares System, das Tausende oder Zehntausende von Sitzungen verarbeitet. Die Installation und Ausführung von Session Recording erfordert nur wenige zusätzliche Ressourcen über das hinaus, was für den Betrieb von Citrix Virtual Apps and Desktops™ oder Citrix DaaS (ehemals Citrix Virtual Apps and Desktops service) erforderlich ist. Wir empfehlen Ihnen jedoch, die Leistung Ihres Systems zu berücksichtigen, wenn Sie viele Sitzungen aufzeichnen möchten. Oder die Sitzungen, die Sie aufzeichnen möchten, könnten zu großen Sitzungsdateien führen (z. B. grafisch intensive Anwendungen).

Dieser Artikel erklärt, 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 sehr kompakt. Sie ist um viele Größenordnungen kleiner als eine gleichwertige Videoaufzeichnung, die mit Lösungen erstellt wurde, die den Bildschirm auslesenn. Die für den Transport/die Speicherung einer aufgezeichneten Sitzungsdatei 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 ein schnelleres und flüssigeres Rendern von Videobildern. Aufzeichnungen sind außerdem verlustfrei und weisen keine Verpixelung auf, die bei den meisten kompakten Videoformaten üblich ist. Text in Aufzeichnungen ist während der Wiedergabe leicht lesbar, genau wie in den ursprünglichen Sitzungen. Um kleine Dateigrößen beizubehalten, zeichnet Session Recording keine Keyframes innerhalb der Dateien auf. Session Recording kann H.264-Pakete während der Aufzeichnung von Sitzungen mit laufenden Videos verwerfen und so die Aufzeichnungsdateigrößen reduzieren. Um diese Funktionalität zu nutzen, stellen Sie HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\SmartAuditor\Agent\DropH264Enabled auf 1 auf dem Session Recording-Agenten ein und setzen Sie den Wert von Videocodec für Komprimierung verwenden auf Für sich aktiv ändernde Bereiche.

  

• Geringer Verarbeitungsaufwand zur Dateierstellung

  Eine aufgezeichnete Sitzungsdatei enthält die ICA®-Protokolldaten für eine Sitzung, die praktisch in ihrem nativen Format extrahiert werden. Die Datei erfasst den ICA-Protokolldatenstrom, der für die Kommunikation mit der Citrix Workspace™-App verwendet wird. Es ist nicht erforderlich, teure Transkodierungs- oder Kodierungssoftwarekomponenten auszuführen, um das Datenformat in Echtzeit zu ändern. Der geringe Verarbeitungsaufwand ist auch für die VDA-Skalierbarkeit wichtig. Er 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. Diese Kanäle können große Datenmengen erzeugen, ohne einen Vorteil bei der Videowiedergabe zu bieten.

Schätzung der Dateneingabe- und Verarbeitungsraten

Der Session Recording-Server ist der zentrale Sammelpunkt für aufgezeichnete Sitzungsdateien. Jede Maschine, die einen Multi-Session-OS-VDA mit aktiviertem Session Recording ausführt, sendet aufgezeichnete Sitzungsdaten an den Session Recording-Server. Session Recording kann große Datenmengen verarbeiten und ist tolerant gegenüber Spitzenlasten und Fehlern. Es gibt jedoch physikalische Grenzen, wie viele Daten ein Server verarbeiten kann.

Berücksichtigen Sie, wie viele Daten Sie an jeden Session Recording-Server senden. Schätzen Sie, wie schnell die Server die 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 Dateneingangsrate zu schätzen, führen Sie die folgende Berechnung durch:

1. Multiplizieren Sie die Anzahl der aufgezeichneten Sitzungen mit der durchschnittlichen Sitzungsgröße.
2. Teilen Sie das Produkt 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-stündigen Arbeitstag aufzeichnen. In diesem Fall beträgt die Dateneingangsrate 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 zur Speicherung der aufgezeichneten Daten verfügt, kann Daten mit etwa 5,0 Mbit/s verarbeiten. Diese Rate ist die Verarbeitungsrate, die auf den physikalischen Grenzen basiert, die durch Disk- und Netzwerk-IOPS auferlegt werden. Im Beispiel ist die Verarbeitungsrate (5,0 Mbit/s) höher als die Eingangsrate (3,5 Mbit/s), sodass die Aufzeichnung der 5.000 Outlook-Sitzungen machbar ist.

Die Datenmenge pro Sitzung variiert stark, je nachdem, was aufgezeichnet wird. Andere Faktoren wie Bildschirmauflösung, Farbtiefe und Grafikmodus haben ebenfalls Auswirkungen. Eine Sitzung, in der CAD ausgeführt wird, erzeugt wahrscheinlich eine viel größere Aufzeichnung als eine Sitzung, in der der Benutzer E-Mails in Outlook sendet und empfängt. Daher kann die Aufzeichnung der gleichen Anzahl von CAD-Sitzungen eine hohe Eingangsrate erzeugen und den Einsatz von mehr Session Recording-Servern erfordern.

Spitzen und Fehler

Das vorherige Beispiel geht von einem einfachen, gleichmäßigen Datendurchsatz aus, erklärt aber nicht, wie das System mit kurzen Perioden höherer Aktivität, sogenannten Spitzen, umgeht. Eine Spitze kann auftreten, wenn sich alle Benutzer morgens gleichzeitig anmelden, bekannt als der 9-Uhr-Ansturm. Sie kann auch auftreten, wenn sie alle gleichzeitig dieselbe E-Mail in ihrem Outlook-Posteingang erhalten. Die Verarbeitungsrate von 5,0 Mbit/s des Session Recording-Servers ist für die Bewältigung dieser plötzlichen Nachfrage völlig unzureichend.

Der Session Recording-Agent, der auf jedem VDA ausgeführt wird, 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 eine hohe Datenrate in Spitzen nicht verarbeiten kann, werden die aufgezeichneten Daten vorübergehend gespeichert. Die Datennachricht kann vorübergehend in der Ausgangswarteschlange auf dem VDA gespeichert werden, wenn das Netzwerk überlastet ist. Der andere Fall ist, dass die Daten das Netzwerk durchlaufen haben, der Storage Manager aber mit der Verarbeitung anderer Nachrichten beschäftigt ist. In diesem Fall wird die Datennachricht in der Empfangswarteschlange des Session Recording-Servers gespeichert.

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

Die Haupteinschränkung von MSMQ besteht darin, dass der Speicherplatz für die temporäre Speicherung von Datennachrichten begrenzt ist. Diese Einschränkung begrenzt, wie lange eine Spitze, ein Fehler oder ein Wartungsereignis dauern kann, bevor Daten schließlich 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 Spitzen und Fehlern erhöhen.

• Es ist wichtig, die Einstellung für die Nachrichtenlebensdauer (Message Life) für jeden Session Recording-Agenten auf einen geeigneten Wert zu konfigurieren (auf der Registerkarte Verbindungen in den Eigenschaften des Session Recording-Agenten). Der Standardwert beträgt 7.200 Sekunden (zwei Stunden). Das bedeutet, dass jede aufgezeichnete Datennachricht zwei Stunden Zeit hat, den Storage Manager zu erreichen, bevor der Storage Manager sie verwirft und die Aufzeichnungsdatei beschädigt. 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 ist, dass bei Datenrückständen zusätzliche Disk-IOPS in der Warteschlange zum Lesen und Schreiben von Datennachrichten anfallen. Normalerweise empfängt und verarbeitet der Storage Manager Daten direkt aus dem Netzwerk, ohne dass Datennachrichten jemals auf die Festplatte geschrieben werden. 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, befolgen 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. Zu diesen Ansätzen gehören der Einsatz von unterbrechungsfreien Stromversorgungen (USV), Dual-NICs, redundanten Switches sowie Hot-Swap-fähigem Speicher und Festplatten.

Planen Sie für Reservekapazität

The data rate of recorded session data is unlikely to be uniform, bursts and faults might occur, and the clearing of message backlogs is expensive in IOPS. For this reason, design each Session Recording server with plenty of spare capacity. Adding more servers or improving the specification of existing servers, as described in later sections, always gains you extra capacity. The general rule of thumb is to run each Session Recording server at a maximum of 50% of its total capacity. In the earlier example, if the server can process 5.0 Mbps, target the system to run only at 2.5 Mbps. Instead of recording 5,000 Outlook sessions that generate 3.5 Mbps on one Session Recording server, reduce to 3,500 sessions that generate only about 2.5 Mbps.

Rückstände und Livewiedergabe

Live playback is when a reviewer opens a session recording for playback while the session is still active. During live playback, the responsible Session Recording agent switches to a streaming mode for that session. Recording data is sent immediately to the Storage Manager without internal buffering. Because the recording file is constantly updated, the player can continue to be fed with the latest data from the live session. However, data sent from the agent to the Storage Manager is through MSMQ, so the queuing rules described earlier apply. A problem can occur in this scenario. When MSMQ is backlogged, the new recorded data available for live playback is queued like all other data messages. The reviewer can still play the file, but viewing the latest live recorded data is delayed. If live playback is an important feature for reviewers, ensure a low probability of backlog. You can design spare capacity and fault tolerance into your deployment.

Systemskalierbarkeit

Session Recording reduziert niemals die Sitzungsleistung und beendet niemals Sitzungen aufgrund von Rückständen bei aufgezeichneten Daten. Die Aufrechterhaltung der Endbenutzererfahrung und der Single-Server-Skalierbarkeit ist von größter Bedeutung beim Design des Session Recording-Systems. Wenn das Aufzeichnungssystem irreversibel überlastet wird, werden aufgezeichnete Sitzungsdaten verworfen. Das Aufzeichnen von ICA-Sitzungen hat geringe Auswirkungen auf die Leistung und Skalierbarkeit von VDAs. Das Ausmaß der Auswirkungen hängt von der Plattform, dem verfügbaren Arbeitsspeicher und der grafischen Beschaffenheit der aufgezeichneten Sitzungen ab. Mit der folgenden Konfiguration können Sie eine Auswirkung auf die Single-Server-Skalierbarkeit zwischen 1 % und 5 % erwarten. Mit anderen Worten, wenn ein Server 100 Benutzer ohne installierte Session Recording hosten kann, kann er nach der Installation 95–99 Benutzer hosten:

• 64-Bit-Server mit 8 GB RAM, der einen Multi-Session-OS-VDA ausführt
• Alle Sitzungen, die Office-Produktivitätsanwendungen wie Outlook und Excel ausführen
• Die Nutzung von Anwendungen ist aktiv und dauerhaft
• Alle Sitzungen werden gemäß den Session Recording-Richtlinien aufgezeichnet.

Bei weniger aufgezeichneten Sitzungen oder weniger dauerhafter und sporadischerer Sitzungsaktivität sind die Auswirkungen geringer. Oftmals ist die Auswirkung auf die Skalierbarkeit vernachlässigbar und die Benutzerdichte pro Server bleibt gleich. Wie bereits erwähnt, resultieren die geringen Auswirkungen aus den einfachen Verarbeitungsanforderungen der Sitzungsaufzeichnungskomponenten auf jedem VDA. Aufgezeichnete Daten werden aus dem ICA-Sitzungsstapel 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. Wenn Sie keine Sitzungen von einem bestimmten Server aufzeichnen möchten, können Sie die Aufzeichnung auf diesem Server deaktivieren. Das Entfernen der Sitzungsaufzeichnung ist eine Möglichkeit. Ein weniger invasiver Ansatz ist, das Kontrollkästchen Sitzungsaufzeichnung für diesen VDA-Computer aktivieren auf der Registerkarte Sitzungsaufzeichnung in den Eigenschaften des Sitzungsaufzeichnungs-Agenten zu deaktivieren. Wenn die Sitzungsaufzeichnung zukünftig erforderlich ist, aktivieren Sie dieses Kontrollkästchen erneut.

Durchsatzmessung

You can measure the throughput of recorded session data from the sending VDA to the receiving Session Recording server. A simple and effective approach is to observe the size of recording files and the rate at which disk space on the Session Recording server is being consumed. The volume of data written to disk closely reflects the volume of network traffic being generated. The Windows Performance Monitor tool (perfmon.exe) has standard system counters that you can observe in addition to some counters provided by Session Recording. Counters can be used to measure throughput, and identify bottlenecks and system problems. The following table outlines some of the most useful performance counters.

Hardware für Session Recording-Server

Sie können die Kapazität Ihrer Bereitstellung erhöhen, indem Sie die Hardware des Session Recording-Servers 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 Session Recording-Servers sollten Sie die folgenden Best Practices berücksichtigen, um eine optimale Leistung bei verfügbaren Budgets zu gewährleisten. Das System hängt von IOPS ab, die einen hohen Durchsatz der aufgezeichneten Daten vom Netzwerk auf die Festplatte gewährleisten können. Daher ist es wichtig, in geeignete Netzwerk- und Festplattenhardware zu investieren. Für einen hochleistungsfähigen Session Recording-Server 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 das Hinzufügen von mehr RAM kaum Vorteile.

Skalierung nach außen

Selbst mit den besten Skalierungspraktiken gibt es Grenzen für Leistung und Skalierbarkeit, die mit einem einzelnen Session Recording-Server beim Aufzeichnen vieler Sitzungen erreicht werden können. 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 arbeiten. 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 könnte 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 geringer.

Stellen Sie sicher, dass die von Session Recording verwendeten Netzwerk-Switches nicht mit Anwendungen von Drittanbietern 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 Netzwerküberlastungen sich als Engpass erweisen, ist ein Netzwerk-Upgrade eine relativ kostengünstige Möglichkeit, die Skalierbarkeit des Systems zu erhöhen.

Speicher

Die Investition in Festplatten- und Speicherhardware ist der wichtigste Faktor für die Skalierbarkeit des Servers. Je schneller Daten auf die Festplatte geschrieben werden können, desto höher ist die Leistung des Gesamtsystems. Bei der Auswahl einer Speicherlösung sollten Sie der Schreibleistung mehr Beachtung schenken als der Leseleistung.

Speichern Sie Daten auf einem RAID oder einem SAN.

Hinweis:

Das Speichern von Daten auf einem NAS, basierend auf dateibasierten Protokollen wie SMB und NFS, kann Leistungs- und Sicherheitsauswirkungen haben. Verwenden Sie die neueste Version des Protokolls, um Sicherheitsrisiken zu vermeiden, und führen Sie Skalierungstests durch, um eine ordnungsgemäße Leistung sicherzustellen.

Für eine lokale Laufwerkskonfiguration streben Sie einen Festplattencontroller mit integriertem Cache-Speicher an. Caching ermöglicht es dem Controller, beim Write-Back eine Elevator-Sortierung zu verwenden. Dies minimiert die Bewegung des Schreib-/Lesekopfs und stellt sicher, 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 Integrität der Daten und des Dateisystems zu gewährleisten, sollten Sie eine Batteriepufferung für den Caching-Festplattencontroller 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. Die folgende Tabelle gibt die einzelnen RAID-Level und deren Anwendbarkeit auf die Sitzungsaufzeichnung 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 die Sitzungsaufzeichnung nicht empfohlen. RAID 10 bietet zwar 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 und externe USB- oder Firewire-Laufwerke sind für die Verwendung in der Sitzungsaufzeichnung nicht geeignet. Die Hauptwahl besteht zwischen SATA und SCSI. SATA-Laufwerke bieten im Vergleich zu SCSI-Laufwerken eine recht hohe Übertragungsrate zu geringeren Kosten pro MB. 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 inzwischen verfügbar. Berücksichtigen Sie bei der Bewertung der Spezifikationen von Festplattenprodukten die Rotationsgeschwindigkeit der Festplatte und andere Leistungsmerkmale.

Da die Aufzeichnung Tausender 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 beansprucht. 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 Löschung alter Aufzeichnungen gemildert werden. Wenn 1 TB Speicherplatz verfügbar ist, ist eine Aufbewahrungsfrist von sieben Tagen angemessen, wodurch der Speicherplatzverbrauch bei etwa 700 GB bleibt und 300 GB als Puffer für arbeitsreiche Tage zur Verfügung stehen. In der Sitzungsaufzeichnung wird das Archivieren und Löschen von Dateien mit dem ICLDB-Dienstprogramm unterstützt. Es hat eine Mindestaufbewahrungsfrist von zwei Tagen. Sie können eine Hintergrundaufgabe so planen, dass sie 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 die Verwendung einer SAN-Speicherlösung, die auf blockbasiertem Festplattenzugriff basiert. Für den Sitzungsaufzeichnungsserver erscheint das Festplatten-Array als lokales Laufwerk. SANs sind teurer einzurichten, aber da das Festplatten-Array gemeinsam genutzt wird, haben SANs den Vorteil einer vereinfachten und zentralisierten Verwaltung. Es gibt zwei Haupttypen von SANs: Fibre Channel und iSCSI. iSCSI ist im Wesentlichen SCSI über TCP/IP und gewinnt seit der Einführung von Gb Ethernet gegenüber Fibre Channel an Popularität.

Datenbank-Skalierbarkeit

Das Datenvolumen, das an die Sitzungsaufzeichnungsdatenbank gesendet wird, 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 2019, 2017, 2016, 2014, 2012 und 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 Suchen 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 einfachste Datenbankbereitstellung Hunderte von Transaktionen pro Sekunde verarbeiten kann, ist die Verarbeitungslast auf die Datenbank wahrscheinlich nicht übermäßig hoch. Die Auswirkungen sind so gering, dass die Session Recording-Datenbank auf demselben SQL Server wie andere Datenbanken, einschließlich der Citrix Virtual Apps and Desktops-Datenspeicherdatenbank, ausgeführt werden kann.

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