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 XenApp y XenDesktop. Sin embargo, si planea usar Session Recording para grabar un gran número de sesiones o si las sesiones que planea grabar pueden dar como resultado 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 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 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 de fotogramas de vídeo más rápida y fluida. Las grabaciones también son completamente sin pérdidas y no tienen 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, al igual que en las sesiones originales. Para mantener los archivos pequeños, Session Recording no graba fotogramas clave dentro de los archivos.

• 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. Esto significa que 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 componentes de software de transcodificación o codificación costosos 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 son capaces de reproducirse, 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 enviará 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 su 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 sesiones. Por ejemplo, podría grabar 5000 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. (5000 sesiones por 20 MB divididas por 8 horas, divididas por 3600 segundos por hora). Un servidor de Session Recording típico conectado a una LAN de 100 Mbps con suficiente espacio en disco para almacenar los datos grabados es capaz de 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 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 5000 sesiones de Outlook es factible.

Tenga en cuenta que 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. Es probable que una sesión que ejecuta un paquete CAD donde la actividad gráfica es constantemente alta 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, grabar el mismo número de sesiones CAD puede generar una tasa de entrada extremadamente alta 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 muy simple, pero no explica cómo el sistema maneja 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, 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 datos grabados al Administrador de almacenamiento que se ejecuta en el servidor central de grabación de sesiones. Los datos se envían de forma de almacenar y reenviar, 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 grabación de sesiones o la red no pueden manejar la alta tasa de datos en una ráfaga, los datos de la sesión grabada se almacenan temporalmente hasta que se elimine el retraso de los mensajes de datos. El mensaje de datos puede 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 le 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. Esto limita el tiempo que 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 perdidos. Un archivo con datos perdidos aún se puede reproducir, pero solo hasta el punto en que se perdieron los datos por primera vez. Tenga en cuenta lo siguiente:

• Adding more disk space to each server, especially the Session Recording Server, and making it available to MSMQ can increase the tolerance to bursts and faults.

• It is important to configure the Message Life setting for each Session Recording Agent to an appropriate level (on the Connections tab in Session Recording Agent Properties). The default value of 7,200 seconds (two hours) means that each recorded data message has two hours to reach the Storage Manager before it is discarded and recording files are damaged. With more disk space available (or fewer sessions to record), you can choose to increase this value. The maximum value is 365 days.

The other limitation with MSMQ is that when data backlogs, there is extra disk IOPS in the queue to read and write data messages. Under normal conditions, the Storage Manager receives and processes data from the network directly without the data message ever being written to disk. Storing the data involves a single write operation to disk that appends the recorded session file. When data is backlogged, the disk IOPS is tripled: each message must be written to disk, read from disk, and written to file. As the Storage Manager is heavily IOPS bound, the processing rate of the Session Recording Server drops until the backlog of messages is cleared. To mitigate the effects of this extra IOPS, adopt the following recommendations:

• 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 limitaciones 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 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. 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 es capaz de procesar 5,0 Mbps, intente 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 esto a 3.500 sesiones que generan solo alrededor de 2,5 Mbps.

Retrasos y reproducción en directo

Live playback is when a reviewer opens a session recording for playback while the session is still active. During live playback, the Session Recording Agent responsible for the session switches to a streaming mode for that session, and recording data is sent immediately to the Storage Manager without internal buffering. Because the recording file is constantly updated, the Player can continue to be fed with the latest data from the live session. However, data sent from the Agent to the Storage Manager is through MSMQ, so the queuing rules described earlier apply. A problem can occur in this scenario. When MSMQ is backlogged, the new recorded data available for live playback is queued like all other data messages. The reviewer can still play the file, but viewing latest live recorded data is delayed. If live playback is an important feature for reviewers, ensure a low probability of backlog by designing spare capacity and fault tolerance into your deployment.

Escalabilidad de XenApp® y XenDesktop

La Grabación de sesiones nunca reduce el rendimiento de las sesiones ni las detiene en respuesta a los retrasos en los datos grabados. Mantener la experiencia del usuario final y la escalabilidad de un solo servidor es fundamental en el diseño del sistema de Grabación de sesiones. Si el sistema de grabación se sobrecarga de forma irreversible, los datos de sesión grabados se descartan. Las exhaustivas pruebas de escalabilidad realizadas por Citrix® revelan que el impacto de grabar sesiones ICA en el rendimiento y la escalabilidad de los servidores XenApp y XenDesktop 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 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

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 simplemente 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 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 nunca se grabarán sesiones desde un servidor en particular, puede deshabilitar la grabación en ese servidor. Eliminar la Grabación de sesiones es una forma de hacerlo. 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 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 al 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 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 la 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: escalar verticalmente (aumentando la capacidad de cada servidor) o escalar horizontalmente (agregando más servidores). Al tomar cualquiera de las decisiones, su objetivo es aumentar la escalabilidad al menor costo.

Escalado vertical

Al examinar un único servidor de grabación de sesiones, considere 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 se gana poco con 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, se obtiene poco beneficio al 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 solo servidor de grabación de sesiones al grabar un gran número de 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 se encarga 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 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 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 de archivos como SMB, CIFS o NFS tiene graves implicaciones de rendimiento y seguridad. Nunca utilice esta configuración en una implementación de producción de Grabación de sesiones.

Para una configuración de unidad local, busque un controlador de disco con memoria caché incorporada. El almacenamiento en caché permite al controlador utilizar la ordenación de ascensor 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 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é, 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 su aplicabilidad 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 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 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 una cantidad considerable 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 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 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 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 2016, Microsoft SQL Server 2014, Microsoft SQL Server 2012 y Microsoft SQL Server 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 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 XenApp o XenDesktop.

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.