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 la Grabación de sesiones requieren pocos recursos adicionales, además de los necesarios para ejecutar Citrix Virtual Apps and Desktops. Sin embargo, si va a utilizar la Grabación de sesiones para grabar muchas sesiones o si las sesiones que quiere grabar van a producir archivos de grabación muy grandes (por ejemplo, aplicaciones con muchos gráficos), tenga en cuenta los efectos en el rendimiento del sistema al planificar la implementación de la Grabación de sesiones.

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

  

• 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, y 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 de cliente e impresora no se graban, ya que 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 tolerar ráfagas y fallos, pero existe una serie de límites físicos en torno a la cantidad de datos que un servidor puede gestionar.

Tenga en cuenta cuántos datos se enviarán a cada Servidor de grabación de sesiones y con qué rapidez pueden los servidores procesar y almacenar estos 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 tasa de entrada de datos, multiplique la cantidad de sesiones grabadas por el tamaño medio de cada grabación y divida por el tiempo que se grabarán 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 en función de los límites físicos impuestos por las IOPS de disco y red. Esta es la tasa o velocidad de procesamiento. 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.

Tenga en cuenta que la cantidad de datos por sesión varía mucho, según lo que se esté grabando; además de otros factores que también influyen, como la resolución de pantalla, la profundidad de color y el modo gráfico. Una sesión que ejecute un paquete CAD con actividad gráfica constantemente alta probablemente genere 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, 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. Se puede producir una ráfaga cuando todos los usuarios inician sesión a la misma hora por la mañana, lo que se conoce como la hora punta de las 9, o cuando reciben un 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 de sesión grabados se almacenan temporalmente hasta que se despeje el atasco de mensajes de datos. El mensaje de datos puede almacenarse temporalmente en la cola de salida del VDA si la red está congestionada, o bien 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 sigue ocupado procesando otros mensajes.

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 se mantienen en la cola de salida de cada VDA. Cuando se corrige el fallo, todos los datos en cola se envían juntos. El uso de MSMQ le permite, además, desconectar un Servidor de grabación de sesiones para tareas de actualización o mantenimiento sin interrumpir la grabación de sesiones existente 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 de 7200 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 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. En condiciones normales, 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 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 de la sesión cambia a un modo de streaming, y 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 mediante el diseño de una implementación con capacidad de reserva y tolerancia a fallos.

Escalabilidad de Citrix Virtual Apps and Desktops

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. Las extensas 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 Citrix Virtual Apps and Desktops es bajo. 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. 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 bajos 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 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. Aunque el impacto es bajo, si tiene la seguridad de que nunca se grabará ninguna sesión desde un servidor concreto, 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

Existen varias formas de medir la capacidad de procesamiento de datos de sesiones grabadas entre el VDA emisor y el servidor de Grabación de sesiones receptor. Uno de los enfoques más simples y efectivos es observar el tamaño de los archivos que se graban y la velocidad a la que se consume 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 una serie de contadores de sistema estándar que se pueden 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.

Hardware del Servidor de grabación de sesiones

Puede aumentar la capacidad de la implementación seleccionando cuidadosamente el hardware utilizado para el 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 IOPS. Esto garantiza un alto rendimiento 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 considerablemente 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 conjunto de discos locales controlados como matriz RAID con un controlador de discos local o como red 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, lo que minimiza el movimiento del cabezal del disco y 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 reserva para el controlador del disco de almacenamiento en caché, de manera que, si se apaga la corriente, la caché se mantenga y los datos se escriban en el disco cuando finalmente se restablezca la corriente.

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.

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 es compatible con la utilidad ICLDB y 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

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 que se envía a la base de datos 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.