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 lo necesario 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 planea grabar muchas sesiones. O bien, las sesiones que planea grabar podrían generar 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 renderizació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 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, al igual que 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 Usar códec de vídeo para la compresión en Para regiones que cambian activamente.

  

• Poco procesamiento necesario para generar archivos

  Un archivo de sesión grabado contiene los datos del protocolo ICA® para una sesión que se extraen 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 puede manejar un solo servidor.

Considere cuántos datos 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 la 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 3,5 Mbps. (5.000 sesiones por 20 MB divididas por 8 horas, divididas por 3.600 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 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 superior a la tasa de entrada (3,5 Mbps), por lo que la grabación de las 5.000 sesiones de Outlook es factible.

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. Una sesión en la que se ejecuta 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, grabar el mismo número de sesiones CAD puede generar una alta tasa de entrada y requerir el uso de más servidores de grabación de sesiones.

Picos y fallos

El ejemplo anterior asume un rendimiento uniforme y simple de los datos, pero no explica cómo el sistema gestiona los períodos cortos de mayor actividad, conocidos como picos. Un pico 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 grabación de sesiones es muy inadecuada para hacer frente a esta demanda repentina.

El agente de grabación de sesiones 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 grabación de sesiones. Los datos se envían de forma de almacenar y reenviar, de forma similar a cómo se entrega un correo electrónico entre el remitente, el servidor de correo y el receptor. Si el servidor de grabación de sesiones 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 grabación de sesiones.

MSMQ también sirve como mecanismo de tolerancia a fallos. Si el servidor de grabación de sesiones 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 realizar tareas de mantenimiento sin interrumpir la grabación de sesiones ni 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 un pico, 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 se perdieron los datos por primera vez. Tenga en cuenta lo siguiente:

• Agregar más espacio en disco a cada servidor, especialmente al servidor de grabación de sesiones, y ponerlo a disposición de MSMQ puede aumentar la tolerancia a los picos y fallos.

• Es importante configurar el ajuste de vida útil del mensaje (Message Life) para cada agente de grabación de sesiones a un nivel adecuado (en la ficha Conexiones de las propiedades del agente de grabación de sesiones). 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 que 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 en el disco. El almacenamiento de los datos implica una única operación de escritura en el disco que anexa 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. Dado que el Storage Manager está muy limitado por las IOPS, la tasa de procesamiento del servidor de grabación de sesiones 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 de la tasa de procesamiento real nunca es tan grave.

• Planifique las interrupciones solo en horas de menor actividad. Dependiendo de las limitaciones presupuestarias, siga los enfoques reconocidos para construir servidores de alta disponibilidad. Los enfoques incluyen el uso de fuentes de alimentación ininterrumpida (UPS), NIC dobles, conmutadores redundantes y memoria y discos de intercambio 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 mensajes es costosa en IOPS. Por esta razón, diseñe cada servidor de Grabación de sesiones 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 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, el objetivo es que el sistema funcione solo a 2,5 Mbps. En lugar de grabar 5.000 sesiones de Outlook que generan 3,5 Mbps en un servidor de Grabación de sesiones, reduzca a 3.500 sesiones que generen solo unos 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 Grabación de sesiones responsable cambia a un modo de transmisión para esa sesión. Los datos de grabación se envían inmediatamente al Administrador de almacenamiento 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 Administrador de almacenamiento se realizan a través de MSMQ, por lo que se aplican las reglas de cola descritas anteriormente. En este escenario puede producirse 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 haya una baja probabilidad de retraso. Puede diseñar 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 y nunca detiene las sesiones en respuesta a los retrasos de datos grabados. Mantener la experiencia del usuario final y la escalabilidad de un solo servidor es primordial en el diseño del sistema de Grabación de sesiones. Si el sistema de grabación se sobrecarga irreversiblemente, 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 Grabación de sesiones instalada, 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 Grabación de sesiones

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 Grabación de sesiones 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 codificación de datos costosa.

Existe una pequeña sobrecarga al usar Grabación de sesiones 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 Grabación de sesiones es una forma. Un enfoque menos invasivo es desmarcar la casilla Habilitar grabación de sesiones para esta máquina VDA en la ficha Grabación de sesiones de Propiedades del agente de grabación de sesiones. Si se requiere la grabación de sesiones 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 Grabación de sesiones receptor. 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 Grabación de sesiones. 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 Grabación de sesiones. 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 Session Recording

Puede aumentar la capacidad de su implementación seleccionando cuidadosamente el hardware del servidor de Session Recording. 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 Session Recording, considere las siguientes prácticas recomendadas para garantizar un rendimiento óptimo con los presupuestos disponibles. El sistema depende de las IOPS que puedan garantizar una alta tasa de transferencia de datos grabados desde la red al disco. Por lo tanto, es importante invertir en hardware de red y de disco adecuados. Para un servidor de Session Recording 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 Session Recording al grabar muchas sesiones. Puede ser necesario añadir servidores adicionales para satisfacer la carga. Puede instalar más servidores de Session Recording en diferentes máquinas para que los servidores de Session Recording funcionen como un grupo de equilibrio de carga. En este tipo de implementación, los servidores de Session Recording comparten el almacenamiento y la base de datos. Para distribuir la carga, dirija los agentes de Session Recording 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 Session Recording. 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 la tasa de transferencia es menor.

Asegúrese de que los conmutadores de red utilizados por Session Recording 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 Session Recording. 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 en 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 escalabilidad 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 el algoritmo de ascensor durante la escritura en caché. 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 un sistema de respaldo de batería 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 cómo se aplica 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 algunos beneficios de rendimiento, pero es demasiado costoso 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 tasas de transferencia razonablemente altas a un costo reducido por MB en comparación con las unidades SCSI. Sin embargo, las unidades SCSI ofrecen un mejor rendimiento y son más comunes en implementaciones de servidores. Las soluciones RAID de servidor admiten principalmente 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 5.000 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 1.000 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 archivo y la eliminación de archivos se admiten 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 almacena solo metadatos sobre las sesiones grabadas. Los archivos de las sesiones grabadas se escriben en un disco separado. 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 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 están limitadas solo 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 en 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 de 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.