Consideraciones de escalabilidad

Session Recording es un sistema altamente escalable que gestiona miles o decenas de miles de sesiones. La instalación y ejecución de Session Recording requiere pocos recursos adicionales más allá de los necesarios para ejecutar Citrix Virtual Apps and Desktops™ o Citrix DaaS (anteriormente, servicio Citrix Virtual Apps and Desktops). Sin embargo, le recomendamos que considere el rendimiento de su sistema si tiene previsto grabar muchas sesiones. O bien, las sesiones que tiene previsto grabar podrían dar lugar a archivos de sesión grandes (por ejemplo, aplicaciones con gráficos intensivos).

Este artículo explica cómo Session Recording logra una alta escalabilidad y cómo puede sacar el máximo partido a su sistema de grabación al menor coste.

Por qué Session Recording escala bien

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

• Tamaño de archivo pequeño

  Un archivo de sesión grabado con Session Recording es muy compacto. Es muchos órdenes de magnitud más pequeño que una grabación de vídeo equivalente realizada con soluciones que capturan la pantalla. El ancho de banda de red, el espacio en disco y las IOPS de disco necesarios para transportar/almacenar un archivo de sesión grabado suelen ser al menos 10 veces menores que los de un archivo de vídeo equivalente.

  El pequeño tamaño de los archivos de sesión grabados significa una representación más rápida y fluida de los fotogramas de vídeo. Las grabaciones también son sin pérdidas y no presentan la pixelación que es común en la mayoría de los formatos de vídeo compactos. El texto de las grabaciones es fácil de leer durante la reproducción, como ocurre en las sesiones originales. Para mantener los archivos pequeños, Session Recording no graba fotogramas clave dentro de los archivos. Session Recording puede descartar paquetes H.264 mientras graba sesiones que tienen vídeos en ejecución y, por lo tanto, reducir el tamaño de los archivos de grabación. Para usar esta funcionalidad, establezca HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\SmartAuditor\Agent\DropH264Enabled en 1 en el agente de Session Recording y establezca el valor de Use video codec for compression en For actively changing regions.

  

• Bajo procesamiento requerido para generar archivos

  Un archivo de sesión grabado contiene los datos del protocolo ICA® para una sesión que se extrae virtualmente en su formato nativo. El archivo captura el flujo de datos del protocolo ICA que se utiliza 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 para la escalabilidad de VDA. Garantiza que la experiencia del usuario final se mantenga cuando se graban muchas sesiones desde el mismo VDA.

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

Estimar las tasas de entrada y procesamiento de datos

El servidor de Session Recording es el punto de recopilación central para los archivos de sesión grabados. Cada máquina que ejecuta un VDA de SO multisesión con Session Recording habilitado envía datos de sesión grabados al servidor de Session Recording. Session Recording puede manejar grandes volúmenes de datos y puede tolerar ráfagas y fallos. Pero existen límites físicos en la cantidad de datos que cualquier servidor puede manejar.

Considere la cantidad de datos que envía a cada servidor de Session Recording. Estime la rapidez con la que los servidores pueden procesar y almacenar los datos. La velocidad a la que su sistema puede almacenar los datos entrantes debe ser superior a la tasa de entrada de datos.

Para estimar su tasa de entrada de datos, realice el siguiente cálculo:

1. Multiplique el número de sesiones grabadas por el tamaño medio de la sesión.
2. Divida el producto por el tiempo durante el cual está grabando las sesiones.

Por ejemplo, podría grabar 5.000 sesiones de Microsoft Outlook de 20 MB cada una durante una jornada laboral de 8 horas. En este caso, la tasa de entrada de datos es de aproximadamente 28 Mbps (5.000 sesiones multiplicadas por 20 MB, divididas por 8 horas, divididas por 3.600 segundos por hora y multiplicadas por 8 para la conversión a Mbps). Un servidor de Session Recording 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 tasa es la tasa de procesamiento basada en los límites físicos impuestos por las IOPS de disco y red. En el ejemplo, la tasa de procesamiento (5,0 Mbps) es inferior a la tasa de entrada (28 Mbps), por lo que grabar las 5.000 sesiones de Outlook es imposible.

La cantidad de datos por sesión varía mucho según lo que se esté grabando. Otros factores como la resolución de pantalla, la profundidad de color y el modo gráfico también influyen. Es probable que una sesión en la que se ejecuta CAD 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, grabar el mismo número de sesiones CAD puede generar una alta tasa de entrada y requerir el uso de más servidores de Session Recording.

Ráfagas y fallos

El ejemplo anterior asume un rendimiento de datos uniforme y simple, pero no explica cómo el sistema gestiona los períodos cortos de mayor actividad, conocidos como ráfagas. Una ráfaga puede ocurrir cuando todos los usuarios inician sesión al mismo tiempo por 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 tasa de procesamiento de 5,0 Mbps del servidor de Session Recording es muy inadecuada para hacer frente a esta demanda repentina.

El agente de Session Recording que se ejecuta en cada VDA utiliza Microsoft Message Queuing (MSMQ) para enviar los datos grabados al Storage Manager que se ejecuta en el servidor central de Session Recording. Los datos se envían de forma de almacenamiento y reenvío, de manera similar a cómo se entrega un correo electrónico entre el remitente, el servidor de correo y el receptor. Si el servidor de Session Recording o la red no pueden manejar una alta tasa de datos en ráfagas, los datos grabados se almacenan temporalmente. El mensaje de datos podría almacenarse 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 Storage Manager está ocupado procesando otros mensajes. En este caso, el mensaje de datos se almacena en la cola de recepción del servidor de Session Recording.

MSMQ también sirve como mecanismo de tolerancia a fallos. Si el servidor de Session Recording se cae o el enlace se rompe, los datos grabados permanecen en la cola de salida de cada VDA. Cuando se rectifica el fallo, todos los datos en cola se envían juntos. MSMQ también permite desconectar un servidor para actualizarlo o realizarle mantenimiento sin interrumpir la grabación de sesiones y sin perder datos.

La principal limitación de MSMQ es que el espacio en disco para el almacenamiento temporal de mensajes de datos es finito. Esta limitación restringe la duración de una ráfaga, un fallo o un evento de mantenimiento antes de que los datos se pierdan finalmente. El sistema general puede continuar después de la pérdida de datos, pero en esta situación, las grabaciones individuales tienen fragmentos de datos perdidos. Un archivo con datos perdidos sigue siendo reproducible, pero solo hasta el punto en que los datos se perdieron por primera vez. Tenga en cuenta lo siguiente:

• Añadir más espacio en disco a cada servidor, especialmente al servidor de Session Recording, y ponerlo a disposición de MSMQ puede aumentar la tolerancia a ráfagas y fallos.

• Es importante configurar el ajuste de duración del mensaje (Message Life) para cada agente de Session Recording a un nivel adecuado (en la ficha Conexiones de las propiedades del agente de Session Recording). El valor predeterminado es de 7.200 segundos (dos horas). Esto significa que cada mensaje de datos grabado tiene dos horas para llegar al Storage Manager antes de que este lo descarte 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 de 365 días.

La otra limitación de MSMQ es que cuando los datos se acumulan, hay IOPS de disco adicionales en la cola para leer y escribir mensajes de datos. Normalmente, el Storage Manager recibe y procesa los datos directamente de la red, sin que los mensajes de datos se escriban nunca en el disco. El almacenamiento de los datos implica una única operación de escritura en disco que añade el archivo de sesión grabado. Cuando los datos se acumulan, las IOPS de disco se triplican: cada mensaje debe escribirse en el disco, leerse del disco y escribirse en el archivo. Como el Storage Manager está muy limitado por las IOPS, la tasa de procesamiento del servidor de Session Recording disminuye hasta que se borra la acumulación 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 sea diferente de las carpetas de almacenamiento de archivos de grabación. Aunque el tráfico del bus de IOPS se triplique, la caída en la tasa de procesamiento real nunca es tan grave.

• Planifique las interrupciones solo en horas de menor actividad. Según las limitaciones presupuestarias, siga los enfoques reconocidos para construir servidores de alta disponibilidad. Estos enfoques incluyen el uso de fuentes de alimentación ininterrumpida (UPS), NIC duales, conmutadores redundantes y memoria y discos intercambiables en caliente.

Diseño para capacidad de reserva

Es poco probable que la velocidad de datos de las sesiones grabadas sea uniforme, pueden producirse ráfagas y fallos, y la eliminación de los retrasos de los mensajes es costosa en IOPS. Por esta razón, diseñe cada servidor de Session Recording con mucha capacidad de reserva. Añadir más servidores o mejorar las especificaciones de los servidores existentes, como se describe en secciones posteriores, siempre le proporciona capacidad adicional. La regla general es ejecutar cada servidor de Session Recording a un máximo del 50% de su capacidad total. En el ejemplo anterior, si el servidor puede procesar 5,0 Mbps, el objetivo es que el sistema funcione solo a 2,5 Mbps.

Retrasos y reproducción en directo

La reproducción en directo se produce cuando un revisor abre una grabación de sesión para su reproducción mientras la sesión aún está activa. Durante la reproducción en directo, el agente de Session Recording responsable cambia a un modo de transmisión para esa sesión. Los datos de grabación se envían inmediatamente al Storage Manager sin almacenamiento en búfer interno. Dado que el archivo de grabación se actualiza constantemente, el reproductor puede seguir recibiendo los datos más recientes de la sesión en directo. Sin embargo, los datos enviados del agente al Storage Manager se realizan a través de MSMQ, por lo que se aplican las reglas de cola descritas anteriormente. En este escenario puede surgir un problema. Cuando MSMQ tiene un retraso, los nuevos datos grabados disponibles para la reproducción en directo se ponen en cola como todos los demás mensajes de datos. El revisor aún puede reproducir el archivo, pero la visualización de los datos grabados en directo más recientes se retrasa. Si la reproducción en directo es una característica importante para los revisores, asegúrese de que la probabilidad de retraso sea baja. Puede diseñar capacidad de reserva y tolerancia a fallos en su implementación.

Escalabilidad del sistema

Session Recording nunca reduce el rendimiento de la sesión ni detiene las sesiones en respuesta a los retrasos de los datos grabados. Mantener la experiencia del usuario final y la escalabilidad de un solo servidor es primordial en el diseño del sistema de Session Recording. Si el sistema de grabación se sobrecarga de forma irreversible, los datos de la sesión grabada se descartan. La grabación de sesiones ICA tiene un bajo impacto en el rendimiento y la escalabilidad de los VDA. El tamaño del impacto depende de la plataforma, la memoria disponible y la naturaleza gráfica de las sesiones que se graban. 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 a 100 usuarios sin Session Recording instalado, puede alojar a 95-99 usuarios después de la instalación:

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

Con menos sesiones grabadas o una actividad de sesión 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 sencillos requisitos de procesamiento de los componentes de Session Recording en cada VDA. Los datos grabados se extraen de la pila de sesiones ICA y se envían tal cual al servidor de Session Recording a través de MSMQ. No hay una codificación de datos costosa.

Existe una sobrecarga menor al usar Session Recording incluso cuando no se graban sesiones. Si no va a grabar ninguna sesión desde un servidor en particular, puede deshabilitar la grabación en ese servidor. Eliminar Session Recording es una forma. Un enfoque menos invasivo es desmarcar la casilla Habilitar la grabación de sesiones para esta máquina VDA en la ficha Session Recording de las Propiedades del agente de Session Recording. Si la grabación de sesiones es necesaria en el futuro, vuelva a seleccionar esta casilla.

Medición del rendimiento

Puede medir el rendimiento de los datos de sesión grabados desde el VDA de envío al servidor de Session Recording de recepción. Un enfoque simple y eficaz es 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 Session Recording. El volumen de datos escritos en el disco refleja fielmente el volumen de tráfico de red que se genera. La herramienta Monitor de rendimiento de Windows (perfmon.exe) tiene contadores de sistema estándar que puede observar, además de algunos contadores proporcionados por Session Recording. Los contadores se pueden usar para medir el rendimiento e identificar cuellos de botella y problemas del sistema. La siguiente tabla describe algunos de los contadores de rendimiento más útiles.

Hardware del servidor de grabación de sesiones

Puede aumentar la capacidad de su 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 (añadiendo más servidores). Al tomar cualquiera de las dos decisiones, su objetivo es aumentar la escalabilidad al menor coste.

Escalado vertical

Al examinar un único servidor de grabación de sesiones, tenga en cuenta las siguientes prácticas recomendadas para garantizar un rendimiento óptimo con los presupuestos disponibles. El sistema depende de las IOPS que puedan garantizar un alto rendimiento de los datos grabados desde la red al disco. Por lo tanto, es importante invertir en hardware de red y de disco adecuado. Para un servidor de grabación de sesiones de alto rendimiento, se recomienda una CPU doble o una CPU de doble núcleo, pero apenas se obtiene beneficio de una especificación superior. Se recomienda una arquitectura de procesador de 64 bits, pero un tipo de procesador x86 también es adecuado. Se recomiendan 4 GB de RAM, pero, de nuevo, hay poco beneficio en añadir 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. Puede ser necesario añadir servidores adicionales para satisfacer la carga. Puede instalar más servidores de grabación de sesiones en diferentes máquinas para que los servidores de grabación de sesiones funcionen como un grupo de equilibrio de carga. En este tipo de implementación, los servidores de grabación de sesiones comparten el almacenamiento y la base de datos. Para distribuir la carga, dirija los agentes de grabación de sesiones al equilibrador de carga que es responsable de la distribución de la carga de trabajo.

Capacidad de red

Un enlace de red de 100 Mbps es adecuado para conectar un servidor de grabación de sesiones. Una conexión Ethernet Gb podría mejorar el rendimiento, pero no resulta en un rendimiento 10 veces mayor que un enlace de 100 Mbps. En la práctica, la ganancia en el rendimiento es menor.

Asegúrese de que los conmutadores de red utilizados por la grabación de sesiones no se compartan con aplicaciones de terceros que puedan competir por el ancho de banda de red disponible. Idealmente, los conmutadores de red se dedican al uso con el servidor de grabación de sesiones. Si la congestión de la red resulta ser el cuello de botella, una 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 puedan escribir los datos en el disco, mayor será el rendimiento del sistema general. Al seleccionar una solución de almacenamiento, preste más atención al rendimiento de escritura que al rendimiento de lectura.

Almacene los datos en un RAID o una SAN.

Nota:

El almacenamiento de datos en un NAS, basado en protocolos basados en archivos como SMB y NFS, podría tener implicaciones de rendimiento y seguridad. Utilice la última versión del protocolo para evitar implicaciones de seguridad y realice pruebas de escalado para garantizar un rendimiento adecuado.

Para una configuración de unidad local, busque un controlador de disco con memoria caché integrada. El almacenamiento en caché permite al controlador utilizar la clasificación por elevación durante la escritura diferida. Minimiza el movimiento del cabezal del disco y garantiza que las operaciones de escritura se completen sin esperar a que finalice la operación física del disco. 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 después de un fallo de alimentación. Para garantizar la integridad de los datos y del sistema de archivos, considere una batería de respaldo para el controlador de disco con caché.

Considere usar una solución de almacenamiento RAID adecuada. Hay muchos niveles RAID disponibles según los requisitos de rendimiento y redundancia. La siguiente tabla especifica cada uno de los niveles RAID y la aplicabilidad de cada estándar a la 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 la Grabación de sesiones. RAID 10 ofrece algunas ventajas de rendimiento, pero es demasiado caro para la ganancia adicional.

Decida el tipo y las especificaciones de las unidades de disco. Las unidades IDE/ATA y las unidades USB o Firewire externas no son adecuadas para su uso en la Grabación de sesiones. La elección principal es entre SATA y SCSI. Las unidades SATA ofrecen velocidades de transferencia razonablemente altas a un coste por MB reducido en comparación con las unidades SCSI. Sin embargo, las unidades SCSI ofrecen un mejor rendimiento y son más comunes en las implementaciones de servidores. Las soluciones RAID de servidor suelen admitir unidades SCSI, pero ahora hay disponibles algunos productos RAID SATA. Al evaluar las especificaciones de los productos de unidades de disco, considere 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. Según el ejemplo anterior, la grabación de 5000 sesiones de Outlook durante una jornada laboral de 8 horas consume aproximadamente 100 GB de espacio de almacenamiento. Para almacenar grabaciones de 10 días (es decir, 50 000 archivos de sesiones grabadas), necesita 1000 GB (1 TB). Esta presión sobre el espacio en disco se puede aliviar acortando el período de retención antes de archivar o eliminar grabaciones antiguas. Si hay 1 TB de espacio en disco disponible, un período de retención de siete días es razonable, lo que garantiza que el uso del espacio en disco se mantenga en torno a los 700 GB, con 300 GB restantes como búfer para los días de mayor actividad. En la Grabación de sesiones, el archivado y la eliminación de archivos son compatibles con la utilidad ICLDB. Tiene un período de retención mínimo de dos días. Puede programar una tarea en segundo plano para que se ejecute una vez al día en algún momento de menor actividad. Para obtener más información sobre los comandos ICLDB y el archivado, consulte Administrar los registros de la base de datos.

La alternativa al uso de unidades y controladores locales es utilizar una solución de almacenamiento SAN basada en el acceso a disco a nivel de bloque. Para el servidor de Grabación de sesiones, la matriz de discos aparece como una unidad local. Las SAN son más caras de configurar, pero como la matriz de discos se comparte, las SAN tienen la ventaja de una administración simplificada y centralizada. Hay dos tipos principales de SAN: Fibre Channel e iSCSI. iSCSI es esencialmente SCSI sobre TCP/IP y está ganando popularidad sobre Fibre Channel desde la introducción de Gb Ethernet.

Escalabilidad de la base de datos

El volumen de datos enviados a la base de datos de Grabación de sesiones es pequeño porque la base de datos solo almacena metadatos sobre las sesiones grabadas. Los archivos de las sesiones grabadas se escriben en un disco independiente. Normalmente, cada sesión grabada requiere solo aproximadamente 1 KB de espacio en la base de datos, a menos que se utilice la API de eventos de Grabación de sesiones para insertar eventos buscables en la sesión.

Las ediciones Express de Microsoft SQL Server de 2019, 2017, 2016, 2014, 2012 y 2008 R2 imponen una limitación de tamaño de base de datos de 10 GB. A 1 KB por sesión de grabación, la base de datos puede catalogar aproximadamente 4.000.000 de sesiones. Otras ediciones de Microsoft SQL Server no tienen restricciones de tamaño de base de datos y solo están limitadas por el espacio en disco disponible. A medida que aumenta el número de sesiones en la base de datos, el rendimiento de la base de datos y la velocidad de las búsquedas disminuyen solo de forma insignificante.

Si no realiza personalizaciones a través de la API de eventos de Grabación de sesiones, cada sesión grabada genera cuatro transacciones de base de datos: dos cuando comienza la grabación, una cuando el usuario inicia sesión en la sesión que se está grabando y una cuando finaliza la grabación. Si utiliza la API de eventos de Grabación de sesiones para personalizar sesiones, cada evento buscable grabado genera una transacción. Dado que incluso la implementación de base de datos más básica puede manejar cientos de transacciones por segundo, es poco probable que la carga de procesamiento de la base de datos se vea afectada. El impacto es lo suficientemente ligero como para que la base de datos de Grabación de sesiones pueda ejecutarse en el mismo SQL Server que otras bases de datos, incluida la base de datos del almacén de datos de Citrix Virtual Apps and Desktops.

Si su implementación de Grabación de sesiones requiere que se cataloguen muchos millones de sesiones grabadas en la base de datos, siga las directrices de Microsoft para la escalabilidad de SQL Server.