SQL Server y las bases de datos de Citrix

Microsoft SQL Server es un componente importante de cualquier implementación de Citrix Virtual Apps and Desktops. Planificar y comprender las interacciones de Citrix SQL es muy beneficioso para usted y su organización a la hora de mantener un entorno Citrix saludable y con buen rendimiento. La falta de alta disponibilidad de SQL Server y de amplios recursos informáticos tiene un efecto negativo en la experiencia del usuario y el tiempo de actividad de la infraestructura de Citrix.

Resumen base de datos

Hay 3 bases de datos que se requieren o se crean durante la implementación de Citrix Virtual Apps and Desktops:

Sitio (también conocido como Configuración del sitio): Almacena la configuración del sitio en ejecución, además de datos dinámicos relacionados con la intermediación, como el estado actual de la sesión, la conexión, la carga y la información de estado de VDA.

Registro de configuración (también conocido como Registro): Almacena información sobre los cambios de configuración del sitio y las actividades administrativas. Esta base de datos se usa cuando la función Registro de configuración está habilitada (opción predeterminada).

Supervisión: Esta base de datos almacena los datos que utiliza Director, como la información de conexión y de sesión.

En versiones anteriores de Citrix Virtual Apps and Desktops, como XenApp y XenDesktop 7.6, la base de datos necesaria para Citrix Virtual Apps and Desktops se creó como una base de datos durante la configuración inicial del sitio (a través de Studio o mediante la ejecución de scripts en SQL Server). Después de la instalación, el administrador podría dividirla en diferentes bases de datos para mejorar el rendimiento o cumplir con las pautas de backup y seguridad.

Con las versiones más recientes de Citrix Virtual Apps and Desktops, puede crear las bases de datos durante la configuración inicial del sitio, así como a través de Studio o ejecutando scripts en SQL Server. La base de datos se divide automáticamente en tres bases de datos independientes.

Para entornos con bases de datos de monitoreo de gran tamaño, una configuración ideal sería alojar la base de datos de supervisión en un servidor diferente al de las bases de datos de registro de configuración y configuración del sitio. Registra más datos, los cambios se producen con mayor frecuencia y los datos no se consideran tan críticos como las demás bases de datos. Para obtener más información, consulte la Guía de tamaño de la base de datos o la página 97 del manual de VDI.

Cada actualización acumulativa (CU) de la versión de servicio a largo plazo (LTSR) contiene correcciones en el esquema de la base de datos SQL. Por ejemplo, consulte CTX230536. Para proteger mejor su entorno contra problemas inesperados, asegúrese de contar con un proceso para actualizar periódicamente su entorno a la CU más reciente. Además, asegúrese de contar con la supervisión adecuada de SQL Server y bases de datos para detectar eventos de fallas y problemas con una alta utilización de recursos y espacio libre.

Interacción de Citrix con SQL

Los agentes de Citrix Virtual Apps and Desktops utilizan la base de datos como un bus de mensajes para las comunicaciones con los agentes y almacenan datos de configuración, supervisión y auditoría. Las bases de datos se utilizan constantemente y pueden consumir importantes recursos informáticos en el servidor SQL.

Por ejemplo, la enumeración de recursos (recursos identificados y presentados al usuario), el inicio de recursos y las etapas de inicio de la sesión requieren que Citrix Delivery Controller interactúe con el servidor SQL.

Enumeración: después de una autenticación correcta a través de Citrix ADC y StoreFront, el Delivery Controller se pone en contacto con la base de datos del sitio de Citrix para comprobar qué aplicaciones están disponibles para el usuario, según las credenciales de AD. Cuando se identifican los recursos, se extrae de la base de datos información adicional, como nombres de aplicaciones, escritorios e iconos.

Iniciar: cuando el usuario selecciona la aplicación o el escritorio que se va a iniciar, StoreFront inicia una solicitud de inicio al Delivery Controller. A continuación, el Delivery Controller contacta con la base de datos del sitio en el servidor SQL para seleccionar el VDA adecuado al que enviar al usuario.

Inicialización de la sesión: después de iniciar la sesión, el VDA se pone en contacto con Delivery Controller para escribir la información de la sesión en la base de datos del sitio

Recomendaciones para las bases

Para asegurarse de que una interrupción del servidor SQL tenga un impacto mínimo en la infraestructura de Citrix Virtual Apps and Desktops, los clientes pueden elegir entre las siguientes opciones de alta disponibilidad compatibles con Citrix:

• Grupos de disponibilidad AlwaysOn
• Clústeres de conmutación por error Alway
• Grupos de disponibilidad básica
• Hipervisor HA*

Nota:

Aunque Citrix admite Hypervisor HA, no se recomienda utilizarlo en entornos que alojen aplicaciones EHR, donde el tiempo de actividad es de suma importancia.

Citrix y Epic recomiendan usar el mismo enfoque de alta disponibilidad para las tres bases de datos, aunque el registro de configuración y la supervisión de la disponibilidad de la base de datos no son necesarios para establecer las sesiones de los usuarios finales. Por ejemplo, si planea usar el grupo de disponibilidad siempre activa de SQL como estrategia de alta disponibilidad, úselo para los tres objetos de base de datos.

También le recomendamos que realice una copia de seguridad diaria completa de las propias bases de datos de Citrix, especialmente de la base de datos del sitio. Los períodos de retención varían según los requisitos de la organización, pero es típico mantener siete días de respaldos completos y al menos un mes de respaldos semanales. Los programas de respaldo del registro de transacciones deben basarse en una combinación de los estándares de su organización y la tasa de crecimiento del registro de transacciones en relación con la cantidad de almacenamiento disponible que tiene que asignar. Asegúrese de supervisar el almacenamiento disponible en el servidor SQL.

Alinee su modelo de recuperación para las bases de datos de Citrix con los requisitos del enfoque de alta disponibilidad que está adoptando.

Según la recomendación de Microsoft, los clientes deben configurar planes de mantenimiento para que se ejecuten cada noche y cada semana para mantener los índices de la base de datos. Los planes de mantenimiento pueden consistir simplemente en reorganizar los índices durante la noche durante la semana y reconstruir los índices los fines de semana.

Esta recomendación evita cualquier impacto en el rendimiento de la reconstrucción de índices grandes durante las operaciones diarias, especialmente para una base de datos de supervisión grande.

Microsoft recomienda que los índices se reconstruyan si están fragmentados en más del 30% y que se reorganicen si están menos del 30%. Consulte la sección Mantenimiento de bases de datos.

Caché de host local

Para tener en cuenta los casos en los que la base de datos deja de estar disponible, Citrix agregó la función Caché de host local (LHC) a la plataforma Citrix Virtual Apps and Desktops Desktop 7.x (7.12 y versiones posteriores, incluidos XenApp y XenDesktop 7.15 LTSR). La activación de esta opción permite a los usuarios de Aplicaciones publicadas conectarse si se interrumpe la comunicación entre los Delivery Controllers y la base de datos de configuración de sitios de Citrix. Si SQL está configurado en una arquitectura de alta disponibilidad, como Always On, Mirroring o Clustering, esta función ofrece tolerancia a errores adicional cuando se produce una interrupción completa de SQL o se interrumpe la conectividad de red.

Esto no debe considerarse una alternativa a la alta disponibilidad de SQL, ya que la funcionalidad de administración de sitios no está disponible durante una interrupción de SQL y el proceso de conmutación por error no es instantáneo. En caso de una interrupción de SQL, la funcionalidad de intermediación se pierde hasta que se haya transferido al LHC y los VDA se han vuelto a registrar. Este caso también se encuentra al volver a la transición al modo normal de operación cuando se restaura la conectividad/disponibilidad de SQL.

La caché de host local conserva una copia de los datos del sitio estático en una base de datos local de SQL Express LocalDB en cada Delivery Controller y se basa en estos datos durante una interrupción de la base de datos para dar soporte continuo a los registros de VDA y a las solicitudes de intermediación de sesiones.

Consideraciones de diseño de caché de host

Debido a la variación en el tamaño de las implementaciones de los miembros de la comunidad de Epic, se recomienda que trabaje en estrecha colaboración con Citrix para determinar los recursos adicionales necesarios para utilizar LHC.

• Consideraciones sobre la escalabilidad
  • Los límites máximos documentados para el LHC en XenApp y Xendesktop 7.15 son 10 000 VDA en una zona única y 40 000 VDA en una implementación multizona. En un entorno de Citrix Virtual Apps, la escalabilidad de LHC y zona depende de la tasa de inicio de sesión y el recuento de usuarios. Por lo tanto, la escalabilidad real que se observa en su entorno puede ser inferior a los máximos publicados. Para esta arquitectura, recomendamos considerar zonas adicionales si el recuento de sesiones esperado supera los 10 000 y/o la tasa de inicio de sesión es superior a 10 usuarios por segundo.
• Tamaño de Delivery Controller: Cuando LHC está activo, el Delivery Controller (DC) principal elegido por zona gestiona todos los registros, enumeraciones, inicios y actualizaciones de VDA.
  • RAM: Los servicios de caché del host local pueden consumir 2 GB más de RAM dependiendo de la duración de la interrupción y del número de usuarios que se inician durante la interrupción.
  • CPU: Debido a la carga de CPU adicional en el DC elegido, se deben considerar núcleos adicionales para compensar.

  La configuración de la CPU de un Controller, en particular el número de núcleos disponibles para SQL Server Express LocalDB, afecta directamente al rendimiento de la caché de host local, incluso más que la asignación de memoria. Este consumo de recursos de CPU solo se ha observado durante el periodo de interrupción cuando la base de datos no está disponible y el servicio High Availability Service está activo.

  A pesar de que LocalDB pueda usar varios núcleos (hasta 4), está limitada a solamente un socket. Agregar más sockets, por ejemplo, tener 4 sockets con 1 núcleo cada uno, no mejora el rendimiento. En vez de ello, Citrix recomienda usar varios sockets con varios núcleos. En las pruebas llevadas a cabo por Citrix, una configuración de 2x3 (2 sockets, 3 núcleos) proporciona un mejor rendimiento que las configuraciones 4x1 y 6x1.

• Almacenamiento: Durante el modo de caché de host local, el uso de almacenamiento aumenta aproximadamente 1 MB cada 2-3 minutos, suponiendo un promedio de 10 inicios de sesión por segundo. El consumo de almacenamiento aumenta en relación con la velocidad de inicio de sesión Para obtener más información, consulte el artículo Caché de host local.

Efectos de una interrupción de la base de datos

En caso de una interrupción total de la base de datos, casi todas las funciones críticas de Delivery Controller se ven afectadas, lo que resalta la importancia de diseñar e implementar una de las estrategias de HA de SQL recomendadas. En la siguiente tabla se indican estos efectos:

Componente	Impacto de la interrupción de la base de datos
Base de datos de configuración del sitio	Los usuarios no pueden conectarse ni volver a conectarse a un escritorio virtual. Nota: La caché de host local (LHC) permite a los usuarios con escritorios compartidos alojados, aplicaciones de explorador y Windows alojadas y escritorios personales volver a conectarse a sus aplicaciones y escritorios incluso cuando la base de datos del sitio no esté disponible. En el modo LHC, no se recopilan datos de supervisión y no se pueden realizar cambios de configuración en el sitio.
Base de datos de supervisión	Director no muestra ningún dato histórico y no se puede iniciar Studio. La intermediación de las solicitudes de los usuarios entrantes y las sesiones de usuario existentes no se ve afectada.
Base de datos de registros de configuración	Si Permitir cambios cuando se desconecta la base de datos se ha habilitado en las preferencias de registro de Citrix Virtual Apps and Desktops, una interrupción de la base de datos de registro de configuración no tiene ningún impacto (excepto los cambios de configuración que no se están registrando). De lo contrario, los administradores no pueden realizar ningún cambio en Citrix Virtual Apps and Desktops.

Recomendación de tamaño de SQL

El servidor SQL debe tener el tamaño correcto para garantizar el rendimiento y la estabilidad de un entorno. Dado que cada producto Citrix usa SQL Server de una manera diferente y cada cliente tiene patrones de uso diferentes, no se pueden proporcionar recomendaciones genéricas de tamaño que abarquen todo. En cambio, a continuación se proporcionan recomendaciones de dimensionamiento de SQL Server por producto, y el rendimiento debe supervisarse cuidadosamente durante la implementación para validar las suposiciones de dimensionamiento.

Para un entorno SQL que aloja solo bases de datos relacionadas con Citrix, los servidores SQL deben aprovisionarse con un mínimo de 4 vCPU y 8 GB de RAM para un máximo de 10 000 usuarios. Para implementaciones más grandes o implementaciones con altas tasas de inicio de sesión, recomendamos un mínimo de 8 vCPU y 16 GB de RAM. Para obtener más información sobre los conceptos de dimensionamiento de bases de datos SQL para implementaciones de Citrix Virtual Apps and Desktops 7.x, consulte Dimensionamiento de bases de datos de Citrix XenDesktop 7.x Este artículo también incluye información sobre las funciones de la carga de trabajo, como la tasa estimada de crecimiento del registro de transacciones.

Tenga en cuenta que la base de datos de supervisión varía en tamaño según la configuración de retención de datos. XenApp y XenDesktop 7.15 LTSR tienen más opciones que 7.6 LTSR, después de que se haya agregado al producto la capacidad de capturar datos granulares de rendimiento de VDA. Para obtener más información sobre cómo configurar estos parámetros, consulte Supervisar la configuración de directivas y tenerlo en cuenta en los cálculos de tamaño de la base

Actualizaciones y correcciones de CU

Varias veces al año, Citrix lanza CU para los LTSR de Citrix Virtual Apps and Desktops. Estas CUs solo contienen actualizaciones de seguridad y correcciones de errores, sin nuevas funciones introducidas. Citrix recomienda ejecutar las CU más recientes, porque solucionan los problemas que se han identificado en el producto. Algunas de estas correcciones están relacionadas con SQL. Abordan los problemas, como los bloqueos, los interbloqueos y los procedimientos del almacén, que han identificado Citrix o nuestros clientes. Por ejemplo, hay varias correcciones relacionadas con SQL en las CU de XenApp 7.6 hasta CU5. La recomendación sería revisar la sección Problemas resueltos para cada CU y buscar SQL dentro de la página.

Nota:

LC8477 se lanzó en 7.6 CU5 y 7.17

Referencias adicionales

• XenApp y XenDesktop 7.15 LTSR
• Manual de VDI
• Tamaño Citrix bases de datos
• Caché de host local de Citrix

Escrito por Henry Vernov, Ingeniero principal de sistemas.