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. Sin embargo, si planea usar Session Recording para grabar muchas sesiones o si las sesiones que planea grabar pueden generar archivos de sesión grandes (por ejemplo, aplicaciones con gráficos intensivos), considere el rendimiento de su sistema al planificar su implementación de Session Recording.

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 con el 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 y almacenar cada archivo de Session Recording 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 Use video codec for compression en For actively changing regions.

  

• Poco procesamiento necesario 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 y 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 porque 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 un solo servidor puede manejar.

Considere cuántos datos envía a cada Servidor de Session Recording y con qué rapidez los servidores pueden procesar y almacenar estos datos. La velocidad a la que su sistema puede almacenar los datos entrantes debe ser superior a la velocidad de entrada de datos.

Para estimar la tasa de entrada de datos, multiplique el número de sesiones grabadas por el tamaño promedio de cada sesión grabada y divida 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 dividido por 8 horas, dividido 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 alrededor de 5,0 Mbps, basándose en los límites físicos impuestos por las IOPS de disco y red. Esta tasa es la tasa de procesamiento. 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, mientras que otros factores como la resolución de pantalla, la profundidad de color y el modo gráfico también tienen un impacto. Una sesión que ejecuta un paquete CAD donde la actividad gráfica es constantemente alta probablemente genera una grabación mucho mayor que una sesión en la que el usuario final envía y recibe correos electrónicos en Microsoft 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.

Ráfagas y fallos

El ejemplo anterior asume un rendimiento de datos uniforme y simple, pero no explica cómo el sistema maneja períodos cortos de mayor actividad, conocidos como ráfagas. Una ráfaga podría 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, o 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 Administrador de almacenamiento que se ejecuta en el servidor de grabación de sesiones central. Los datos se envían en un modo de almacenar y reenviar, 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 la alta tasa de datos en una ráfaga, los datos de sesión grabados se almacenan temporalmente hasta que se borra la acumulación de mensajes de datos. El mensaje de datos podría almacenarse temporalmente en la cola de salida del VDA si la red está congestionada, o almacenarse en la cola de recepción del servidor de grabación de sesiones si los datos han atravesado la red pero el Administrador de almacenamiento todavía está ocupado procesando otros mensajes.

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 se retienen en la cola de salida de cada VDA. Cuando se rectifica el fallo, todos los datos en cola se envían juntos. El uso de MSMQ también permite desconectar un servidor de grabación de sesiones para una actualización o mantenimiento sin interrumpir la grabación de las sesiones existentes 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 cuánto tiempo puede durar 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 faltantes. Un archivo con datos faltantes 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 ráfagas y fallos.

• Es importante configurar el ajuste de Vida del mensaje para cada agente de grabación de sesiones a un nivel adecuado (en la pestaña Conexiones de las Propiedades del agente de grabación de sesiones). El valor predeterminado de 7.200 segundos (dos horas) significa que cada mensaje de datos grabado tiene dos horas para llegar al Administrador de almacenamiento antes de que se descarte y los archivos de grabación se dañen. 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. En condiciones normales, el Administrador de almacenamiento recibe y procesa los datos de la red directamente sin que el mensaje de datos se escriba 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 un archivo. Como el Administrador de almacenamiento está fuertemente 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 en la tasa de procesamiento real nunca es tan grave.

• Realice las interrupciones planificadas solo en horas de menor actividad. Dependiendo de las restricciones presupuestarias, siga los enfoques reconocidos para construir servidores de alta disponibilidad. Los enfoques incluyen el uso de UPS, NIC dobles, conmutadores redundantes y memoria y discos de intercambio en caliente.

Diseño para capacidad de reserva

Es poco probable que la tasa de datos de las sesiones grabadas sea uniforme, pueden ocurrir ráfagas y fallos, y la eliminación de las acumulaciones de mensajes es costosa en IOPS. Por esta razón, diseñe cada servidor de grabación de sesiones con mucha capacidad de reserva. Agregar 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.

Acumulaciones y reproducción en vivo

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 sigue activa. Durante la reproducción en directo, el Agente de grabación de sesiones responsable de la sesión cambia a un modo de transmisión para esa sesión, y los datos de grabación se envían inmediatamente al Administrador de almacenamiento sin almacenamiento en búfer interno. Debido a 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 surgir un problema. Cuando MSMQ tiene una cola de mensajes acumulada, 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 acumulación de mensajes diseñando una capacidad de reserva y tolerancia a fallos en su implementación.

Escalabilidad de Citrix Virtual Apps™ and Desktops

La Grabación de sesiones nunca reduce el rendimiento de la sesión ni detiene las sesiones en respuesta a la acumulación 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 sesión grabados se descartan. Las exhaustivas pruebas de escalabilidad realizadas por Citrix revelan que el impacto de la grabación de sesiones ICA en el rendimiento y la escalabilidad de los servidores de Citrix Virtual Apps and Desktops es bajo. 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 la 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 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 la configuración de las directivas de Grabación de sesiones

Si se graban menos sesiones o la actividad de la sesión es menos sostenida y más esporádica, el impacto es menor. En muchos casos, 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 instalados 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 costosa de datos.

Existe una sobrecarga menor al usar la Grabación de sesiones incluso cuando no se graban sesiones. Aunque el impacto es bajo, si está seguro de que no se graban sesiones desde un servidor en particular, puede deshabilitar la grabación en ese servidor. Quitar la Grabación de sesiones 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 Grabación de sesiones de las Propiedades del Agente de grabación de sesiones. Si la grabación de sesiones es necesaria en el futuro, vuelva a seleccionar esta casilla.

Medición del rendimiento

Existen varias formas de medir el rendimiento de los datos de sesión grabados desde el VDA de envío hasta el Servidor de grabación de sesiones receptor. Uno de los enfoques más sencillos y eficaces es observar el tamaño de los archivos que se graban 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 una serie de contadores de sistema estándar que se pueden 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 grabación de sesiones

Puede aumentar la capacidad de su implementación seleccionando cuidadosamente el hardware utilizado para el Servidor de grabación de sesiones. Tiene dos opciones: escalado vertical (aumentando la capacidad de cada servidor) o escalado horizontal (agregando más servidores). Al tomar cualquiera de las 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. Esto garantiza 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 dual 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 de 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 significativamente 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 están dedicados para su 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 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 conjunto de discos locales controlados como RAID por un controlador de disco local o como 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é incorporada. El almacenamiento en caché permite al controlador usar la clasificación por elevador durante la escritura diferida, lo que 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. Esto puede mejorar significativamente el rendimiento de escritura con un costo 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é, lo que garantiza que, si se pierde la alimentación, la caché se mantenga y los datos se escriban en el disco cuando se restablezca la alimentación.

Considere la posibilidad de utilizar una solución de almacenamiento RAID adecuada. Hay muchos niveles de RAID disponibles según los requisitos de rendimiento y redundancia. La siguiente tabla especifica cada uno de los niveles de RAID y cómo se aplica cada estándar a la grabación de sesiones.

RAID 0 y RAID 3 son los niveles de 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 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, 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 una cantidad considerable de espacio en disco, debe elegir entre la capacidad total 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 sesión grabados), 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 se admiten con la utilidad ICLDB y tienen 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 un momento de menor actividad. Para obtener más información sobre los comandos de 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

La base de datos de Grabación de sesiones requiere Microsoft SQL Server 2019, Microsoft SQL Server 2017, Microsoft SQL Server 2016, Microsoft SQL Server 2014, Microsoft SQL Server 2012 o Microsoft SQL Server 2008 R2. El volumen de datos enviados a la base de datos 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 2019, 2017, 2016, 2014, 2012 y 2008 R2 imponen una limitación de tamaño de base de datos de 10 GB. Con 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.