Session Recording

Consideraciones sobre la escalabilidad

Grabación de sesiones es un sistema de alta escalabilidad, capaz de gestionar miles o decenas de miles de sesiones. La instalación y la ejecución de Grabación de sesiones requieren pocos recursos adicionales, además de los necesarios para ejecutar Citrix Virtual Apps and Desktops o Citrix DaaS (antes denominado Citrix Virtual Apps and Desktops Service). Sin embargo, le recomendamos que considere el rendimiento del sistema si tiene pensado grabar muchas sesiones. O bien, si las sesiones que piensa grabar pueden generar archivos de sesión grandes (por ejemplo, aplicaciones con muchos gráficos).

En este artículo, se explica de qué manera Grabación de sesiones alcanza una gran escalabilidad y cómo puede aprovechar al máximo su sistema de grabación con el mínimo coste.

Por qué Grabación de sesiones escala bien

Hay dos razones principales por las que Grabación de sesiones escala bien, en comparación con los productos de la competencia:

  • Tamaño de archivo pequeño

    Un archivo de sesión grabado que se haya creado con Grabación de sesiones es muy compacto. Es muchas veces más pequeño que una grabación de vídeo equivalente hecha con soluciones que hacen raspado de pantalla. El ancho de banda de red, el espacio en disco y las operaciones de E/S por segundo (IOPS) de disco necesarios para transportar y almacenar cada archivo de sesión grabada suele ser, al menos, 10 veces menor que un archivo de vídeo equivalente.

    El tamaño pequeño de los archivos de grabación de sesiones se traduce en una generación más rápida y suave de los fotogramas de vídeo. Las grabaciones son, además, sin pérdida y no presentan pixelación, lo que es habitual en la mayoría de los formatos de vídeo compactos. El texto de las grabaciones es igual de legible durante la reproducción que en las sesiones originales. Para mantener tamaños de archivo pequeños, Grabación de sesiones no graba fotogramas clave dentro de los archivos. Grabación de sesiones puede no contar con paquetes H.264 mientras graba sesiones que contienen vídeos en ejecución y, por lo tanto, puede reducir el tamaño de los archivos de grabación. Para utilizar esta función, establezca HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\SmartAuditor\Agent\DropH264Enabled en 1 en el agente de Grabación de sesiones y establezca el valor de Usar códec de vídeo para compresión en Para áreas en cambio constante.

    Selección de Para áreas en cambio constante

  • Bajo procesamiento requerido para generar archivos

    Un archivo de grabación de sesiones contiene los datos del protocolo ICA de una sesión, que se extraen virtualmente en su formato nativo. Esto significa que el archivo captura la secuencia de datos del protocolo ICA utilizado para comunicarse con la aplicación Citrix Workspace. No es necesario ejecutar costosos componentes de software de transcodificación o codificación para cambiar el formato de los datos en tiempo real. La baja cantidad de procesamiento también es importante a efectos de escalabilidad del VDA. Garantiza una experiencia de usuario final homogénea cuando se graban muchas sesiones desde un mismo VDA.

    Además, solo se graban los canales virtuales ICA que pueden reproducirse, lo que resulta en una mayor optimización. Por ejemplo, los canales de asignación de unidades del cliente y de impresora no se graban. Los canales pueden generar grandes volúmenes de datos sin ningún beneficio en la reproducción de vídeo.

Estimar la tasa de procesamiento y entrada de datos

El servidor de Grabación de sesiones es el punto central de recopilación de los archivos de sesión grabados. Cada máquina que ejecuta un VDA con SO multisesión y Grabación de sesiones habilitada envía los datos de sesión grabados al servidor de Grabación de sesiones. Grabación de sesiones puede gestionar grandes volúmenes de datos y puede tolerar ráfagas y fallos. Sin embargo, hay límites físicos en cuanto a la cantidad de datos que puede gestionar un servidor.

Tenga en cuenta la cantidad de datos que envía a cada servidor de Grabación de sesiones. Calcule la rapidez con la que los servidores pueden procesar y almacenar los datos. La tasa a la cual los sistemas pueden almacenar los datos entrantes debe ser mayor que la tasa de entrada de datos.

Para estimar la velocidad de entrada de datos, haga el siguiente cálculo:

  1. Multiplique el número de sesiones grabadas por el tamaño de sesión promedio.
  2. Divida el producto por el tiempo durante el que graba las sesiones.

Por ejemplo, puede grabar 5000 sesiones de Microsoft Outlook de 20 MB cada una por un día de trabajo de 8 horas. En este caso, la tasa de entrada de datos es de aproximadamente 3,5 Mbps (5000 sesiones multiplicadas por 20 MB, luego dividido por 8 horas y dividido por 3600 segundos por hora). Un servidor de Grabación de sesiones típico conectado a una LAN de 100 Mbps con suficiente espacio en disco para almacenar los datos grabados puede procesar datos a unos 5,0 Mbps. Esta velocidad representa la velocidad de procesamiento en función de los límites físicos impuestos por las IOPS de disco y red. En el ejemplo, la velocidad de procesamiento (5,0 Mbps) es mayor que la velocidad de entrada (3,5 Mbps), por lo que es posible grabar las 5000 sesiones de Outlook.

La cantidad de datos por sesión varía en gran medida en función de lo que esté grabando. Otros factores, como la resolución de la pantalla, la profundidad de color y el modo de gráficos, también afectan. Una sesión en la que se ejecute CAD probablemente genere una grabación mucho mayor que una sesión en la que el usuario envía y recibe correos electrónicos en Outlook. Por lo tanto, registrar el mismo número de sesiones CAD puede generar una elevada tasa de entrada y requerir el uso de más servidores de grabación de sesiones.

Ráfagas y fallos

El ejemplo anterior presupone un procesamiento de datos uniforme, pero no explica cómo afronta el sistema períodos breves de gran actividad, conocidos como ráfagas. Puede producirse una ráfaga cuando todos los usuarios inician sesión a la misma hora de la mañana, lo que se conoce como la hora punta de las 9. También puede ocurrir cuando reciben el mismo correo electrónico en su bandeja de entrada de Outlook a la vez. La velocidad de procesamiento de 5,0 Mbps del servidor de Grabación de sesiones es extremamente inadecuada para hacer frente a esta súbita demanda.

El agente de Grabación de sesiones que se ejecuta en cada VDA utiliza Microsoft Message Queuing (MSMQ) para enviar datos grabados al Administrador de almacenamiento que se ejecuta en el servidor central de grabación de sesiones. Los datos se envían siguiendo una modalidad de almacenamiento y reenvío, similar a la forma en que se entrega un correo electrónico entre el remitente, el servidor de correo y el destinatario. Si el servidor de Grabación de sesiones o la red no pueden manejar la alta tasa de datos durante una ráfaga, los datos grabados se almacenan temporalmente. Es posible que el mensaje de datos se almacene temporalmente en la cola de salida del VDA si la red está congestionada. El otro caso es que los datos han atravesado la red, pero el Administrador de almacenamiento está ocupado procesando otros mensajes. En este caso, el mensaje de datos se almacena en la cola de recepción del servidor de Grabación de sesiones.

MSMQ también sirve de mecanismo de tolerancia a fallos. Si el servidor de Grabación de sesiones deja de estar disponible o se interrumpe la conexión, los datos grabados permanecen en la cola de salida de cada VDA. Cuando se corrige el fallo, todos los datos en cola se envían juntos. MSMQ también le permite desconectar un servidor para tareas de actualización o mantenimiento sin interrumpir la grabación de la sesión y perder datos.

La principal limitación de MSMQ es que el espacio en disco para almacenamiento temporal de mensajes de datos es finito. Esto limita el tiempo que puede durar un evento de ráfaga, fallo o mantenimiento antes de que se pierdan datos. El sistema en general podrá continuar tras la pérdida de datos, pero, en esta situación, faltarán fragmentos de datos en las grabaciones individuales. Un archivo en el que falten datos todavía se puede reproducir, pero solo hasta el punto en que se empezaron a perder los datos. Tenga en cuenta lo siguiente:

  • Agregar más espacio en disco a cada servidor, especialmente al servidor de Grabación de sesiones, y hacerlo disponible para MSMQ puede aumentar la tolerancia a ráfagas y fallos.

  • Es importante configurar el parámetro Vida del mensaje de cada agente de Grabación de sesiones en un nivel adecuado (en la ficha Conexiones de Propiedades del agente de Grabación de sesiones). El valor predeterminado es 7200 segundos (dos horas). Esto significa que cada mensaje de datos grabado tiene dos horas para llegar al Administrador de almacenamiento antes de que este lo deseche y dañe el archivo de grabación. Con más espacio en disco disponible (o menos sesiones para grabar), puede optar por aumentar este valor. El valor máximo es 365 días.

La otra limitación con MSMQ es que, cuando los datos se atrasan, hay IOPS de disco adicionales en la cola para leer y escribir mensajes de datos. Normalmente, Administrador de almacenamiento recibe y procesa los datos en la red directamente, sin que el mensaje de datos se escriba en disco. Almacenar los datos implica una sola operación de escritura en disco, que anexa el archivo de sesión grabado. Cuando los datos llevan retraso, las IOPS del disco se triplican: cada mensaje debe escribirse en disco, leerse desde disco y escribirse en archivo. Puesto que Administrador de almacenamiento está muy ocupado con las IOPS, la tasa de procesamiento del servidor de Grabación de sesiones desciende hasta que se despeja el atasco de mensajes. Para mitigar los efectos de estas IOPS adicionales, adopte las siguientes recomendaciones:

  • Asegúrese de que el disco en el que MSMQ almacena los mensajes es diferente de las carpetas de almacenamiento de archivos de grabación. Aunque el tráfico de bus de IOPS se triplica, el descenso de la tasa de procesamiento real nunca es tan grave.

  • Planifique cortes de suministro solo en horas normales. En función de sus restricciones presupuestarias, siga los enfoques reconocidos para crear servidores de alta disponibilidad. Aquí se incluyen el uso de sistemas de alimentación ininterrumpida (SAI), tarjetas de interfaz de red (NIC) dobles, conmutadores redundantes y memoria y discos intercambiables en caliente.

Diseño con capacidad de reserva

Es poco probable que la tasa de datos de sesión grabados sea uniforme. Pueden producirse ráfagas y fallos, y despejar mensajes acumulados es costoso en términos de IOPS. Por este motivo, diseñe cada servidor de Grabación de sesiones con suficiente capacidad de reserva. Al agregar más servidores o mejorar la especificación de los servidores existentes, como se describe en secciones posteriores, siempre se obtiene capacidad adicional. La regla general es hacer funcionar cada servidor de Grabación de sesiones a un máximo del 50% de su capacidad total. En el ejemplo anterior, si el servidor puede procesar 5,0 Mbps, procure que el sistema funcione a solo 2,5 Mbps. En lugar de grabar 5000 sesiones de Outlook, que generan 3,5 Mbps en un servidor de Grabación de sesiones, reduzca este valor a 3500, lo que genera solo 2,5 Mbps.

Retrasos y reproducción en directo

Por reproducción en directo, se entiende cuando un revisor abre una grabación de una sesión para reproducirla mientras la sesión sigue activa. Durante la reproducción en directo, el agente de Grabación de sesiones responsable cambia a un modo de streaming para esa sesión. Los datos de grabación se envían inmediatamente al Administrador de almacenamiento, sin almacenamiento en búfer interno. Puesto que el archivo de grabación se actualiza constantemente, el reproductor puede seguir alimentándose con los datos más recientes de la sesión en vivo. Sin embargo, los datos se envían desde el agente al Administrador de almacenamiento a través de MSMQ, por lo que se aplican las reglas de cola descritas anteriormente. Puede ocurrir un problema en este caso. Cuando MSMQ lleva retraso acumulado, los nuevos datos grabados disponibles para la reproducción en vivo se ponen en la cola con todos los demás mensajes de datos. Así, el revisor puede seguir reproduciendo el archivo, pero se retrasará el visionado en directo de los últimos datos grabados. Si la reproducción en directo es una función importante para los revisores, puede garantizar una baja probabilidad de retraso acumulado. Diseñe capacidad de reserva y tolerancia a fallos en su implementación.

Escalabilidad del sistema

Grabación de sesiones nunca reduce el rendimiento de la sesión ni detiene las sesiones en respuesta a los atrasos registrados en los datos. Mantener una buena experiencia de usuario final y la escalabilidad en un solo servidor es fundamental en el diseño del sistema de Grabación de sesiones. Si el sistema de grabación se sobrecarga irreversiblemente, se descartan los datos de sesión grabados. La grabación de sesiones ICA tiene un impacto bajo en el rendimiento y la escalabilidad de los VDA. El tamaño del impacto depende de la plataforma, la memoria disponible y los gráficos de las sesiones que se están grabando. Con la siguiente configuración, puede esperar un impacto en la escalabilidad de un solo servidor de entre el 1% y el 5%. En otras palabras, si un servidor puede alojar 100 usuarios sin Grabación de sesiones instalada, puede alojar entre 95 y 99 usuarios después de la instalación:

  • Servidor de 64 bits con 8 GB de RAM que ejecuta un VDA con SO multisesión
  • Todas las sesiones ejecutan aplicaciones de productividad de oficina, como Outlook y Excel
  • El uso de aplicaciones es activo y sostenido
  • Todas las sesiones se graban según lo configurado en las directivas de Grabación de sesiones

Si se graban menos sesiones o la actividad de las sesiones es menos sostenida y más esporádica, el impacto es menor. A menudo, el impacto en la escalabilidad es insignificante y la densidad de usuarios por servidor sigue siendo la misma. Como se mencionó anteriormente, el bajo impacto se debe a los bajos requisitos de procesamiento de los componentes de Grabación de sesiones presentes en cada VDA. Los datos grabados se extraen de la pila de sesiones ICA y se envían tal cual al servidor de Grabación de sesiones a través de MSMQ. No hay una costosa codificación de datos.

Sí hay una sobrecarga menor por el uso de Grabación de sesiones, incluso cuando no se graba ninguna sesión. Si no va a grabar ninguna sesión desde un servidor en particular, puede inhabilitar la grabación en ese servidor. Una forma de hacer esto es quitar Grabación de sesiones. Un enfoque menos invasivo consiste en desmarcar la casilla de verificación Habilitar la grabación de sesiones para esta máquina VDA de la ficha Grabación de sesiones, en Propiedades del agente de Grabación de sesiones. Si necesita grabar sesiones en un futuro, puede volver a marcar esta casilla de verificación.

Medición del rendimiento

Puede medir la capacidad de procesamiento de datos de sesiones grabadas entre el VDA emisor y el servidor de Grabación de sesiones receptor. Un enfoque sencillo y eficaz consiste en observar el tamaño de los archivos de grabación y la velocidad a la que se consume el espacio en disco en el servidor de Grabación de sesiones. El volumen de datos escritos en disco refleja estrechamente el volumen de tráfico de red que se está generando. La herramienta Monitor de rendimiento de Windows (perfmon.exe) tiene contadores de sistema estándar que puede observar, además de los contadores que se proporcionan con Grabación de sesiones. Los contadores sirven para medir el rendimiento e identificar cuellos de botella y problemas del sistema. En la siguiente tabla, se describen algunos de los contadores de rendimiento más útiles.

Objeto de rendimiento Nombre de contador Descripción
Agente de Grabación de sesiones de Citrix Active Recording Count El número de sesiones que se están grabando actualmente en un VDA determinado.
Agente de Grabación de sesiones de Citrix Bytes read from the Session Recording Driver La cantidad de bytes leídos de los componentes del núcleo responsables de la obtención de datos de sesión. Útil para determinar la cantidad de datos que genera un solo VDA para todas las sesiones grabadas en ese servidor.
Administrador de almacenamiento de grabación de sesiones de Citrix Active Recording Count Parecido al contador del agente de Grabación de sesiones de Citrix, excepto que se refiere al servidor de Grabación de sesiones. Indica el número total de sesiones que se están grabando actualmente en todos los servidores.
Administrador de almacenamiento de grabación de sesiones de Citrix Message bytes/sec El rendimiento de todas las sesiones grabadas. Sirve para determinar la velocidad a la que el Administrador de almacenamiento está procesando los datos. Si MSMQ lleva retraso acumulado con mensajes, el Administrador de almacenamiento funciona a plena velocidad. Se puede usar este valor para indicar la velocidad máxima de procesamiento del Administrador de almacenamiento.
LogicalDisk Disk Write Bytes/sec Se puede utilizar para medir el rendimiento de escritura en disco, que es importante para lograr una alta escalabilidad para el servidor de Grabación de sesiones. También se puede observar el rendimiento de unidades individuales.
Cola de MSMQ Bytes in Queue Sirve para determinar la cantidad de datos atrasados en la cola de mensajes CitrixSmAudData. Si este valor aumenta con el tiempo, la tasa de datos grabados recibidos de la red es mayor que la velocidad a la que Storage Manager puede procesarlos. Este contador es útil para observar el efecto de ráfagas y fallos.
Cola de MSMQ Message in Queue Similar al contador Bytes en cola, pero mide el número de mensajes.
Interfaz de red Bytes Total/sec Sirve para medir en ambos lados del enlace y observar la cantidad de datos que se generan al grabar las sesiones. Cuando se mide en el servidor de Grabación de sesiones, este contador indica la tasa a la que se reciben los datos entrantes. Contrasta con el contador Message bytes/sec de Administrador de almacenamiento de grabación de sesiones de Citrix, que mide la tasa de procesamiento de los datos. Si la velocidad de red es mayor que este valor, se acumulan mensajes en la cola de mensajes.
Procesador % Processor Time Vale la pena monitorizarlo, a pesar de que es poco probable que la CPU constituya un cuello de botella.

Hardware del servidor de Grabación de sesiones

Puede aumentar la capacidad de la implementación seleccionando cuidadosamente el hardware del servidor de Grabación de sesiones. Tiene dos opciones: escalar verticalmente (aumentando la capacidad de cada servidor) o escalar horizontalmente (agregando más servidores). Al elegir cualquiera de las opciones, su objetivo es aumentar la escalabilidad a un coste más bajo.

Escalado vertical

Al examinar un único servidor de Grabación de sesiones, tenga en cuenta las siguientes prácticas recomendadas a fin de garantizar un rendimiento óptimo para el presupuesto disponible. El sistema depende de un valor de IOPS que pueda garantizar una alta capacidad de procesamiento de los datos grabados desde la red en el disco. Por lo tanto, es importante invertir en hardware de red y disco apropiado. Para un servidor de Grabación de sesiones de alto rendimiento, se recomienda una CPU doble o una CPU de doble núcleo, y se obtiene poco de cualquier especificación más alta. Se recomienda una arquitectura de procesador de 64 bits, pero también es adecuado un procesador x86. Se recomiendan 4 GB de RAM y, de nuevo, no hay un gran beneficio al agregar más.

Escalado horizontal

Incluso con las mejores prácticas de escalado vertical, existen límites de rendimiento y escalabilidad que se pueden alcanzar con un único servidor de Grabación de sesiones al grabar muchas sesiones. Podría ser necesario agregar otros servidores adicionales para adaptarse a la carga. Se pueden instalar varios servidores de grabación de sesiones adicionales en máquinas diferentes para tenerlos funcionando como un grupo con carga equilibrada. En este tipo de implementación, los servidores de grabación de sesiones comparten los recursos de almacenamiento y la base de datos. Para distribuir la carga, dirija los agentes de grabación de sesiones al equilibrador de carga responsable de la distribución de la carga de trabajo.

Capacidad de la red

Un enlace de red de 100 Mbps es adecuado para conectar con un servidor de Grabación de sesiones. Una conexión Ethernet de Gb puede mejorar el rendimiento, pero no mejorará el rendimiento 10 veces más que un enlace de 100 Mbps. En la práctica, la ganancia en rendimiento es menor.

Compruebe que los conmutadores de red utilizados que utilice Grabación de sesiones no se comparten con aplicaciones de terceros que puedan competir por el ancho de banda disponible de la red. Preferiblemente, los conmutadores de red están dedicados para usarse con el servidor de Grabación de sesiones. Si la congestión de la red resulta ser el cuello de botella, la actualización de la red es una forma relativamente económica de aumentar la escalabilidad del sistema.

Almacenamiento

La inversión en hardware de disco y almacenamiento es el factor más importante en la escalabilidad del servidor. Cuanto más rápido se pueda escribir en el disco, mayor será el rendimiento del sistema. Al seleccionar una solución de almacenamiento, piense más en el rendimiento de escritura que en el de lectura.

Almacene los datos en un sistema RAID o SAN.

Nota:

Es posible que el almacenamiento de datos en NAS, basado en protocolos de archivo, como SMB y NFS, afecta al rendimiento y a la seguridad. Use la versión más reciente del protocolo vigente para evitar problemas de seguridad y haga pruebas de escalado para garantizar un rendimiento adecuado.

Para una configuración de unidad local, considere un controlador de disco con memoria caché incorporada. El almacenamiento en caché permite al controlador utilizar el algoritmo del ascensor durante las operaciones de reescritura. De este modo, se minimiza el movimiento del cabezal del disco y se garantiza que las operaciones de escritura se completen sin esperar a que se complete la operación en el disco físico. Esto puede mejorar significativamente el rendimiento de escritura con un coste adicional mínimo. Sin embargo, el almacenamiento en caché plantea el problema de la pérdida de datos tras un corte de energía. Para garantizar la integridad de los datos y el sistema de archivos, considere el uso de una batería de respaldo para el controlador de disco con memoria caché.

Considere la posibilidad de utilizar una solución de almacenamiento RAID adecuada. Existen muchos niveles de RAID disponibles, en función de los requisitos de rendimiento y redundancia. En la siguiente tabla, se especifica cada uno de los niveles de RAID y la aplicabilidad de cada estándar a Grabación de sesiones.

Nivel de RAID Tipo Cantidad mínima de discos Descripción
RAID 0 Conjunto dividido sin paridad 2 Proporciona un alto rendimiento, pero sin redundancia. La pérdida de cualquier disco destruye la matriz. RAID 0 es una solución de bajo coste para almacenar archivos de sesión grabados donde el impacto de la pérdida de datos es bajo. Es fácil escalar el rendimiento al agregar más discos.
RAID 1 Conjunto duplicado sin paridad 2 No hay ganancia de rendimiento en comparación con un disco, lo que lo convierte en una solución relativamente costosa. Utilice esta solución solo si se requiere un alto nivel de redundancia.
RAID 3 Conjunto dividido con paridad dedicada 3 Proporciona un alto rendimiento de escritura con características de redundancia similares a las de RAID 5. RAID 3 se recomienda para aplicaciones de producción de vídeo y streaming en directo. Dado que Grabación de sesiones es una aplicación de este tipo, RAID 3 es muy recomendable, aunque no es común.
RAID 5 Conjunto dividido con paridad distribuida 3 Proporciona un alto rendimiento de lectura con redundancia, pero a costa de un rendimiento de escritura más lento. RAID 5 es el más común para uso general. Debido a su bajo rendimiento de escritura, no se recomienda RAID 5 para Grabación de sesiones. Se puede implementar RAID 3 a un coste similar, pero con un rendimiento de escritura mayor.
RAID 10 Conjunto de espejo y conjunto dividido 4 Proporciona características de rendimiento de RAID 0, con las ventajas de redundancia de RAID 1. Una solución costosa que no se recomienda para Grabación de sesiones.

RAID 0 y RAID 3 son los niveles RAID más recomendados. RAID 1 y RAID 5 son estándares populares, pero no se recomiendan para Grabación de sesiones. RAID 10 proporciona algunas ventajas en términos de rendimiento, pero es demasiado caro para la ganancia adicional.

Decida sobre el tipo y la especificación de las unidades de disco. Las unidades IDE/ATA y las unidades USB o Firewire externas no son adecuadas para uso con Grabación de sesiones. La alternativa principal está entre SATA y SCSI. Las unidades SATA proporcionan velocidades de transferencia razonablemente altas a un coste reducido por MB, en comparación con las unidades SCSI. Sin embargo, las unidades SCSI ofrecen un mayor rendimiento y son más comunes en las implementaciones de servidores. Las soluciones RAID en servidores son compatibles principalmente con unidades SCSI, pero ya hay disponibles algunos productos RAID SATA. Al evaluar las especificaciones de las unidades de disco, tenga en cuenta la velocidad de rotación del disco y otras características de rendimiento.

Dado que la grabación de miles de sesiones al día puede consumir cantidades significativas de espacio en disco, debe elegir entre la capacidad general y el rendimiento. En el ejemplo anterior, la grabación de 5000 sesiones de Outlook durante un día laborable de 8 horas consume aproximadamente 100 GB de espacio de almacenamiento. Para almacenar las grabaciones de 10 días (es decir, 50 000 archivos de grabación de sesiones), necesita 1000 GB (1 TB). Esta presión sobre el espacio en disco puede aliviarse acortando el período de retención antes de archivar o eliminar las grabaciones antiguas. Si hay 1 TB de espacio en disco disponible, es razonable un período de retención de siete días, lo que garantiza que el uso de espacio en disco se mantenga en alrededor de 700 GB, con 300 GB de reserva para los días más ajetreados. En Grabación de sesiones, el archivado y la eliminación de archivos son compatibles con la utilidad ICLDB. Tiene un período mínimo de retención de dos días. Puede programar una tarea para que se ejecute en segundo plano una vez al día en algún momento de baja actividad. Para obtener más información acerca de los comandos y el archivado de ICLDB, consulte Administrar los registros de la base de datos.

La alternativa al uso de unidades y controladores locales es usar una solución de almacenamiento SAN basada en acceso al disco a nivel de bloque. En el servidor de Grabación de sesiones, la matriz de discos aparece como una unidad local. Las soluciones SAN son más costosas de configurar, pero a medida que la matriz de discos se comparte, tienen la ventaja de una administración más simple y centralizada. Existen dos tipos principales de SAN: de canal de fibra (FC) e iSCSI. iSCSI es esencialmente SCSI a través de TCP/IP y está ganando popularidad, con respecto a FC, desde la introducción de Gb Ethernet.

Escalabilidad de la base de datos

El volumen de datos que se envía a la base de datos de Grabación de sesiones es pequeño, ya que la base de datos almacena solamente metadatos de las sesiones grabadas. Los archivos de las sesiones grabadas en sí se escriben a un disco aparte. Por regla general, cada sesión grabada necesita solamente 1 KB de espacio en la base de datos, a menos que se utilice la API de eventos de Grabación de sesiones para agregar eventos a la sesión.

Las ediciones Express Edition de Microsoft SQL Server 2019, Microsoft SQL Server 2017, Microsoft SQL Server 2016, Microsoft SQL Server 2014, Microsoft SQL Server 2012 y Microsoft SQL Server 2008 R2 imponen una limitación de tamaño de 10 GB a la base de datos. A 1 KB por sesión grabada, la base de datos puede catalogar aproximadamente 4 millones de sesiones. Otras ediciones de Microsoft SQL Server no tienen restricciones de tamaño de la base de datos y están limitadas solamente por el espacio de disco disponible. Cuando aumenta el número de sesiones en la base de datos, el rendimiento de ésta y la velocidad de las búsquedas disminuye de forma insignificante.

Si no realiza personalizaciones mediante la API de eventos de Grabación de sesiones, cada sesión grabada genera cuatro transacciones de base de datos: dos cuando se inicia la grabación, una cuando el usuario se conecta a la sesión que se está grabando y otra cuando la grabación finaliza. Si utiliza la API de eventos de grabación de sesiones para personalizar sesiones, cada evento grabado, susceptible de búsquedas, genera una transacción. Ya que incluso la instalación de base de datos más básica puede manipular cientos de transacciones por segundo, la carga de proceso en la base de datos no se ve afectada. El impacto es tan poco que la base de datos de Grabación de sesiones puede ejecutarse en el mismo servidor SQL Server donde hay otras bases de datos, incluido el almacén de datos de Citrix Virtual Apps and Desktops.

Si la implementación de Grabación de sesiones requiere la catalogación de millones de sesiones grabadas en la base de datos; siga las instrucciones de Microsoft relativas a la escalabilidad de SQL Server.