Conceptos avanzados

Guía de tamaño de bases de datos para las versiones 7.6 y actual de XenApp y XenDesktop

Descargo de responsabilidad

Este documento contiene enlaces a sitios web controlados por terceros distintos de Citrix. Citrix no es responsable del contenido o el uso de estos sitios web de terceros, ni avala ni acepta ninguna responsabilidad por ellos. Citrix le proporciona estos enlaces únicamente para su comodidad, y la inclusión de cualquier enlace no implica la aprobación por parte de Citrix del sitio web vinculado. Es su responsabilidad tomar precauciones para garantizar que cualquier cosa que seleccione para su uso esté libre de virus u otros elementos de naturaleza destructiva.

Visión general

Una implementación típica de XenDesktop 7 consta de tres bases de datos, de la siguiente manera:

  • Base de datos de configuración del sitio
    Almacena la configuración y el estado actuales de la implementación de XenDesktop
  • Base de datos de monitoreo
    Almacena datos históricos para mostrarlos en Director
  • Base de datos de registro de configuración
    Realiza un seguimiento de los cambios de configuración realizados en la implementación de XenDesktop

De forma predeterminada, las bases de datos de registro y supervisión de la configuración (las bases de datos secundarias) se encuentran en el mismo servidor que la base de datos de configuración del sitio. Inicialmente, las tres bases de datos tienen el mismo nombre. Citrix recomienda cambiar la ubicación de las bases de datos secundarias después de crear un sitio.

Una implementación típica también utiliza la base de datos temporal, TempDB, proporcionada por SQL Server.

Cada base de datos tiene un propósito diferente y crece a un ritmo diferente.

Este documento proporciona información sobre cada base de datos y destaca las principales consideraciones que se deben tener en cuenta al dimensionar las bases de datos para que sean compatibles con XenDesktop 7.

Nota: Todos los números proporcionados son estimaciones. Es de esperar que haya variaciones entre las implementaciones.

En este documento también se indican las diferencias de tamaño entre los escritorios compartidos alojados (HSD) y la infraestructura de escritorios virtuales (VDI). Los entornos mixtos deberán combinar las estimaciones de los dos tipos de escritorio para generar una estimación del tamaño total de la base de datos.

Cambios en los documentos de XenDesktop 7.6

Este documento se ha ampliado para incluir la versión 7.6 de XenDesktop. Esto fue para permitir actualizaciones sobre los cambios de tamaño de las funciones agregadas en la versión 7.6. Las tres nuevas funciones que afectan al tamaño de las bases de datos son:

  • Arrendamiento de conexiones: los archivos de arrendamiento comprimidos se almacenan en la base de datos del sitio
  • Supervisión del uso de las aplicaciones: los detalles de todas las aplicaciones utilizadas en el entorno se almacenan en la base de datos del monitor
  • Supervisión del inventario de revisiones: detalles de las revisiones de Citrix aplicadas a los controladores, los VDA y las imágenes de los VDA del entorno

La información sobre las tallas de la tabla se ha actualizado a continuación. Se observó que el crecimiento de las transacciones por segundo y del registro de transacciones fue similar entre 7,6 y 7,5, por lo que no se actualizaron esas secciones.

Consideraciones de alto nivel

Base de datos del sitio

La base de datos del sitio contiene información de configuración para la ejecución del sistema.

Su uso se caracteriza por:

  • El tamaño máximo se alcanza durante las horas punta, ya que los inicios de sesión de los usuarios generan información de sesión y conexión que se debe rastrear.
  • El tamaño mínimo se alcanza cuando no hay sesiones activas y todos los VDA están cerrados y no registrados.
  • El tamaño máximo se alcanza después de 48 horas, ya que la base de datos almacena muy poca información persistente. Esto se debe a que se mantiene un pequeño registro de conexiones en la base de datos del sitio durante 48 horas.
  • El tamaño base de la base de datos aumenta a medida que aumenta la información de configuración de un sitio. Es decir, más trabajadores y usuarios consumen más espacio en la base de datos.
  • Durante el inicio de sesión se producen altos niveles de transacciones por segundo, ya que cada inicio de sesión de usuario requiere la realización de varias transacciones individuales y se escalan en función de la velocidad de lanzamiento simultáneo.
  • Bajo nivel de ruido de fondo en las transacciones de latidos del VDA. Cada VDA emite un latido cada 5 minutos y esta actualización desencadena una transacción en la base de datos.

Impacto del fracaso

Una interrupción de la base de datos del sitio hace que el sistema no pueda administrarse ni supervisarse. Se mantienen las conexiones existentes. En XenDesktop 7.6, el arrendamiento de conexiones permite realizar nuevas conexiones y reconexiones. En versiones anteriores no se podían realizar nuevas conexiones y reconexiones.

Base de datos de monitoreo

La base de datos de monitoreo contiene información histórica sobre el sitio. Director utiliza esta información para mostrar información histórica.

Su uso se caracteriza por:

  • El tamaño máximo lo controla el período de retención configurado, de la siguiente manera:
    • Para los clientes que no son Platinum, el valor predeterminado es de 7 días, con un período máximo de 7 días.
    • Para los clientes Platinum, el valor predeterminado es de 90 días, sin período máximo.
  • El tamaño máximo puede tardar algún tiempo en alcanzarse, ya que el sistema debe alcanzar el período de retención configurado.
  • Se producen niveles bajos de transacciones por segundo debido a la naturaleza por lotes de las actualizaciones del Servicio de Monitoreo. Es raro ver que las transacciones por segundo superen la marca de las 20 transacciones por segundo.
  • Algunas transacciones en segundo plano son causadas por llamadas de consolidación regulares del Servicio de Monitoreo.
  • El procesamiento nocturno se lleva a cabo para eliminar los datos fuera del período de retención configurado.

Impacto del fracaso

Una interrupción de la base de datos de monitoreo impide que se recopilen datos para el Sitio, lo que significa que los datos no están visibles en Director.

Base de datos de registro de configuración

La base de datos de registro de configuración contiene un registro histórico de todos los cambios de configuración del sitio. Esta información se usa para generar informes o para mostrarla en Studio.

Su uso se caracteriza por:

  • El tamaño máximo es difícil de predecir, ya que depende de la cantidad de actividad de configuración que haya.
  • Todas las acciones de Director, por ejemplo, el restablecimiento de la sesión, se registran en esta base de datos, por lo que es posible que se produzca un crecimiento lento a medida que los administradores usen Director.
  • Transacciones mínimas que se producen en la base de datos cuando no se realizan cambios en la configuración.
  • Una tasa de transacciones baja durante las actualizaciones, ya que las actualizaciones se agrupan en lotes siempre que es posible.
  • La eliminación manual de datos. Los datos de la base de datos de registro de configuración no están sujetos a ninguna política de retención y no se eliminan a menos que un administrador lo haga manualmente.

Impacto del fracaso

El impacto de una interrupción de la base de datos de registro de configuración depende de la configuración del sitio, de la siguiente manera:

  • Si el sitio no permite cambios cuando la base de datos de registro de configuración no está disponible, no es posible volver a configurar la implementación de XenDesktop.
  • Si el sitio permite cambios cuando la base de datos de registro de configuración no está disponible, es posible que se realicen cambios de configuración sin seguimiento en la implementación de XenDesktop.

Base de datos temporal

La base de datos temporal es una base de datos para todo el sistema proporcionada por SQL Server. Se utiliza como almacén de versiones para el aislamiento de instantáneas confirmadas por lectura. XenDesktop 7 usa esta función de SQL Server para reducir la contención de bloqueos en las bases de datos de XenDesktop.

El tamaño del almacén de versiones depende del número de transacciones activas. Sin embargo, en general, no es más que unos pocos MB.

El rendimiento de TempDB sí afecta al rendimiento de la intermediación de XenDesktop, ya que cualquier transacción que genere datos nuevos requiere espacio en TempDB. Sin embargo, XenDesktop tiende a tener transacciones de corta duración, lo que ayuda a mantener reducido el tamaño del almacén de versiones.

La base de datos temporal también se usa cuando las consultas generan grandes conjuntos de resultados intermedios.

Puede encontrar instrucciones sobre el tamaño y la configuración de TempDB en la documentación del producto de Microsoft:

https://docs.microsoft.com/en-us/sql/relational-databases/databases/tempdb-database?view=sql-server-ver15

El área principal de controversia se centra en la cantidad de archivos que se van a utilizar. Las versiones anteriores de SQL Server, como SQL Server 2000, requieren más archivos que las versiones más recientes. Para obtener más información sobre la cantidad de archivos que se deben usar, consulte:

http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-1230-tempdb-should-alwayshave-one-data-file-per-processor-core/

Aislamiento de instantáneas con compromiso de lectura

Citrix recomienda que todas las bases de datos de XenDesktop 7 utilicen el aislamiento de instantáneas con compromiso de lectura. Para obtener más información, consulte Cómo habilitar las instantáneas con compromiso de lectura en XenDesktop.

Dimensionamiento de las bases de datos

El tamaño de las bases de datos depende de varios factores clave, incluida la cantidad de sesiones y conexiones creadas durante una jornada laboral.

Una sesión es cualquier escritorio o aplicación que se ejecuta durante un período de tiempo que puede desconectarse y volver a conectarse.

Una conexión es cualquier momento en que un usuario se conecta a una sesión. La desconexión cierra la conexión, pero no la sesión. Cuando un usuario se vuelve a conectar, se crea una nueva conexión a una sesión existente.

Base de datos del sitio

El tamaño máximo de la base de datos del sitio se basa en la cantidad de VDA y sesiones activas, de la siguiente manera:

Usuarios Solicitudes Tipo Tamaño máximo esperado 7.5 (MB) Tamaño máximo esperado 7.6 (MB)
1000 50 HSD 30 31
10 000 100 HSD 60 198
100 000 200 HSD 330 752
1000 N/A VDI 30 30
10 000 N/A VDI 115 121
40.000 N/A VDI 390 426

Cada aplicación publicada añade 110 KB a la base de datos para almacenar cada icono único.

Nota:

El aumento del tamaño de la versión 7.6 se debe a que las concesiones de conexión se almacenan en la base de datos como parte de la replicación entre los Controllers.

Base de datos de monitoreo

De las tres bases de datos, se espera que la base de datos de monitoreo crezca hasta convertirse en la más grande con el tiempo.

Su tamaño depende de muchos factores, entre los que se incluyen los siguientes:

  • Número de usuarios
  • Número de sesiones
  • Cantidad de conexiones
  • Trabajadores de VDI o HSD
  • Período de retención configurado

A continuación se muestran las estimaciones del tamaño de la base de datos en varios puntos de datos. Estos datos son una estimación basada en los datos observados durante las pruebas de escala de XenDesktop. Se cree que las estimaciones son realistas.

Sin embargo, los clientes que mantienen su base de datos pueden encontrar que su base de datos es más pequeña que las estimaciones.

Los usuarios de HSD se basan en 100 usuarios por servidor de HSD.

Periodos máximos de retención

La cantidad máxima de datos retenidos está controlada por la licencia, de la siguiente manera:

  • Los clientes que no sean Platinum pueden conservar hasta 1 semana (7 días) de datos.
  • Los clientes Platinum pueden conservar datos ilimitados; el valor predeterminado es de 3 meses (90 días).

Los períodos de retención se pueden ajustar mediante el cmdlet Set-MonitorConfiguration .

Cuando los datos superan el período de retención configurado, se eliminan de la base de datos.

XenDesktop 7.5 Supervisión del tamaño de las bases de datos

Estimaciones con 1 conexión y 1 sesión por usuario con una semana laboral de 5 días

Usuarios Tipo 1 semana (MB) 1 mes (MB) 3 meses (MB) 1 año (MB)
1000 HSD 151 70 230 900
10 000 HSD 2,830 600 1.950 7.700
100 000 HSD 1.500 5.900 19.000 76.000
1000 VDI 15 55 170 670
10 000 VDI 120 440 1.400 5.500
40.000 VDI 464 1.700 5.400 21.500

Estimaciones con 2 conexiones y 1 sesión por usuario con una semana laboral de 5 días

Usuarios Tipo 1 semana (MB) 1 mes (MB) 3 meses (MB) 1 año (MB)
1000 HSD 30 100 330 1.300
10 000 HSD 240 925 3,000 12.000
100 000 HSD 2.400 9.200 30 000 119,000
1000 VDI 25 85 280 1.100
10 000 VDI 200 750 2.500 9.800
40.000 VDI 800 3,000 9.700 38,600

Tenga en cuenta que los HSD generan más datos con el tiempo debido al registro de la información de equilibrio de carga, pero inicialmente tienen un tamaño similar al de los escritorios VDI.

XenDesktop 7.6 Supervisión del tamaño de las bases de datos

Los principales cambios con respecto a la versión 7.5 son:

  • Información de hotfix
    Los datos siguientes se basan en 3 revisiones por trabajador (VDI o HSD)
  • Historial de uso de la aplicación
    Esto es principalmente relevante para los sistemas HSD.

Estimaciones con 1 conexión y 1 sesión por usuario con una semana laboral de 5 días

Usuarios Tipo 1 semana (MB) 1 mes (MB) 3 meses (MB) 1 año (MB)
1000 HSD 151 605 1,966 7,865
10 000 HSD 2,830 11,301 36,712 146,834
100 000 HSD 7,194 28,585 92,7758 370,841
1000 VDI 13 49 157 622
10 000 VDI 117 409 1.287 5,090
40.000 VDI 460 1,610 5,058 19,999

Estimaciones con 2 conexiones y 1 sesión por usuario con una semana laboral de 5 días

Usuarios Tipo 1 semana (MB) 1 mes (MB) 3 meses (MB) 1 año (MB)
1000 HSD 159 635 2,063 8251
10 000 HSD 2.904 11,599 37,684 150,718
100 000 HSD 7,940 31,5572 102465 409.672
1000 VDI 21 79 253 1.008
10 000 VDI 191 708 2.258 8,974
40.000 VDI 759 2.805 8,941 35,532

Base de datos de registro de configuración

Proporcionar orientación sobre el tamaño de la base de datos de registro de configuración es mucho más difícil, ya que varía considerablemente en función de la actividad diaria de Director y del tamaño del sitio configurado.

Las actividades que afectan a las sesiones o a los usuarios se registran e incluyen, por ejemplo, el cierre y el restablecimiento de la sesión. Las actividades pasivas, como enumerar las sesiones de un usuario, no lo son.

El mecanismo utilizado para implementar los escritorios también afecta al tamaño de los datos que se registran.

En entornos HSD que no utilizan MCS, el tamaño de la base de datos tiende a estar entre 30 MB y 40 MB.

En los entornos MCS, el tamaño de la base de datos puede superar fácilmente los 200 MB debido al registro de todos los datos de creación de máquinas virtuales.

No se realizaron cambios significativos en la versión 7.6 en la base de datos de registro de configuración.

Actividad de la base de datos durante el inicio de sesión de 100 000 sesiones de HSD

Durante las pruebas de escalabilidad, en las que se simularon 100 000 inicios de sesión en HSD, el crecimiento del registro de transacciones se midió según dos tasas de inicio de sesión, de la siguiente manera:

  • 100 000 usuarios que inician sesión en más de 1 hora
  • 100 000 usuarios que inician sesión en más de 2 horas

Estas tasas se eligieron para proporcionar puntos de datos de ejemplo.

El entorno está compuesto por:

  • 2 controladores de entrega
  • 43 trabajadores de HSD VDA
  • 3 servidores SQL, configurados con las bases de datos, que se encuentran dentro de un grupo de disponibilidad permanente

Los detalles de las configuraciones del servidor se proporcionan al final de este documento.

Crecimiento del registro de transacciones

El crecimiento del registro de transacciones de todas las bases de datos se supervisó mediante el contador de monitoreo de rendimiento SQLServer:Databases — Tamaño utilizado de los archivos de registro (KB).

Base de datos del sitio

Cuando el sistema está inactivo, el registro de transacciones aumenta 3,5 MB por hora. Se trata de una combinación de los latidos del corazón de VDA y Broker Service.

Prueba Crecimiento total de inicios de sesión (MB) Crecimiento total de los cierres de sesión (MB)
100 000 en 1 hora 1.900 1.150
100 000 en 2 horas 1.900 1.150

El crecimiento de los troncos es lineal durante el período de tiempo que se mide. Estos datos sugieren que, por cada inicio de sesión de usuario, el registro de transacciones aumenta en 20 KB. Por cada cierre de sesión del usuario, el registro de transacciones aumenta en 12 KB.

Por lo tanto, el crecimiento diario es de 32 KB por ciclo de inicio y cierre de sesión del usuario.

Base de datos de monitoreo

Cuando el sistema está inactivo, el registro de transacciones aumenta 30,5 MB por hora. Se trata de una combinación de procedimientos almacenados de consolidación y actualizaciones del índice de carga de VDA de HSD.

Prueba Crecimiento total de inicios de sesión (MB) Crecimiento total de los cierres de sesión (MB)
100 000 en 1 hora 670 190
100 000 en 2 horas 650 220

El crecimiento del registro es lineal durante el período de tiempo que se mide. Estos datos sugieren que por cada inicio de sesión de usuario, el registro de transacciones aumenta en 7 KB. Por cada cierre de sesión del usuario, el registro de transacciones aumenta en 2 KB.

Por lo tanto, el crecimiento diario es de 9 KB por ciclo de inicio y cierre de sesión del usuario.

Transacciones por segundo

El crecimiento del registro de transacciones de todas las bases de datos se supervisó mediante los siguientes contadores de monitoreo de rendimiento:

  • SQLServer:bases de datos — Transacciones/segundo
  • SQLServer:databases — Escribe transacciones/segundo

Base de datos del sitio

Cuando el sistema está inactivo, hay 5 transacciones por segundo, de las cuales 1 transacción de escritura por segundo mantiene el ritmo cardíaco de VDA y Broker.

Nota: Estas cifras son estimaciones tomadas de los períodos de tiempo dados. La carga exacta varía en función del número de lanzamientos simultáneos por segundo.

Prueba Transacciones de inicio de sesión por segundo Inicio de sesión: escritura de transacciones por segundo Transacciones de cierre de sesión por segundo Cierre sesión Escriba transacciones por segundo
100 000 en 1 hora 870 310 250 100
100 000 en 2 horas 475 170 140 60

Base de datos de monitoreo

Cuando el sistema está inactivo, los procedimientos almacenados de consolidación se ejecutan una vez por minuto y generan transacciones. Sin embargo, el nivel de transacciones es pequeño. En general, hay de 2 a 3 transacciones y 1 transacción de escritura para cada procedimiento almacenado de consolidación, y se ejecutan 3 procedimientos almacenados de consolidación. Durante los períodos activos, los gastos generales aumentan a medida que se realiza más trabajo.

Nota: Estas cifras son estimaciones tomadas de los períodos de tiempo dados.

Prueba Transacciones de inicio de sesión por segundo Inicio de sesión: escritura de transacciones por segundo Transacciones de cierre de sesión por segundo Cierre sesión Escriba transacciones por segundo
100 000 en 1 hora 4 2 4 2
100 000 en 2 horas 4 2 3.5 2

Uso de la CPU

Todos los servidores SQL utilizados para esta prueba eran servidores de doble núcleo con tecnología Hyper-Threading habilitada. Las especificaciones exactas del hardware se proporcionan al final de este documento.

Se sabía que los servidores eran demasiado grandes para la carga que se estaba ejecutando. Esto nos permitió identificar las limitaciones y los máximos impuestos al hardware. Se espera que la carga de la CPU de SQL pudiera haber sido gestionada por un SQL Server con un solo sistema de cuatro núcleos, en lugar de uno de doble núcleo.

Durante las pruebas, la CPU del sistema se supervisó mediante el contador del monitor de rendimiento. Procesador:% de tiempo de procesador:\ _Total.

Réplica principal

Mientras estaba inactiva, la CPU funcionó entre el 0 y el 2% de la CPU disponible. Los procedimientos almacenados de consolidación provocaron picos cada minuto durante aproximadamente 1 segundo a entre el 8 y el 10% de la CPU del sistema. Se espera que esto escale en función de la cantidad de datos que se procesan.

Durante el inicio de sesión de 100 000 usuarios en 1 hora, la CPU aumentó al 7% y aumentó de forma lineal hasta el 11% a medida que había más sesiones y usuarios en el entorno. Tenga en cuenta que los picos de los procedimientos almacenados de consolidación agregaron un 7% a la CPU total, lo que provocó que los picos alcanzaran el 18% de la CPU.

Durante el cierre de sesión, la CPU funcionó al 3,5%, con un 7% de CPU adicional para los procedimientos almacenados de consolidación. En general, esto sugiere que<se necesitaba un 20% de un núcleo doble para mantener la velocidad de inicio y cierre de sesión.

Nota: El programador de Windows Server 2012 tiende a usar hipersubprocesos solo si es necesario, es decir, hasta que el sistema alcance el 50% de carga, solo ejecuta un subproceso por núcleo siempre que sea posible, por lo que una carga del 20% en 24 hipersubprocesos se ejecuta en 4,8 núcleos.

Dada la carga de trabajo, se cree que se trata de una dura prueba de esfuerzo y que un único servidor SQL de cuatro núcleos sería suficiente para las implementaciones de XenDesktop.

Réplicas secundarias

Se descubrió que las réplicas secundarias configuraban un 2% de CPU durante el inicio de sesión y un 1,5% durante el cierre de sesión. Esto es de esperar, ya que, en su mayor parte, las réplicas almacenan datos del disco principal y solo la réplica sincrónica participa en las transacciones, ya que la réplica principal no confirma una transacción hasta que la secundaria la reconoce.

Según las recomendaciones para que el hardware de alta disponibilidad coincida con la réplica principal, un servidor con especificaciones similares gestionaría esta carga con mucha facilidad.

Uso de bases de datos temporales

La TempDB se usa para muchos propósitos, incluido el almacenamiento de versiones, el espacio para conjuntos de consultas grandes y otros usos de tablas temporales.

Dimensionamiento de TempDB

En esta configuración de SQL, TempDB se configuró para tener 8 archivos de base de datos, cada uno de un tamaño fijo de 5 GB. Esto permite un mejor uso simultáneo de TempDB, pero también proporciona suficiente espacio y no activa ningún evento de crecimiento automático. Según los datos capturados, estaba sobredimensionado para esta implementación. Sin embargo, había suficiente espacio en disco disponible.

También se ajusta a las directrices generales de que el número de archivos de bases de datos TempDB oscila entre un cuarto y la mitad del número de CPU disponibles, pero no supera las 8 sin saber que existe una controversia real.

Tenga en cuenta que solo se utiliza un archivo de registro de TempDB, ya que SQL Server no se beneficia de varios archivos de registro.

Tienda de versiones

TempDB contiene un almacén de versiones para las versiones de fila relacionadas con el aislamiento de instantáneas confirmadas de lectura que utilizan las bases de datos de XenDesktop.

El uso se puede medir con los siguientes contadores de rendimiento:

  • SQLServer:transactions – Tamaño del almacén de versiones (KB)
  • SQLServer:Transactions – Tasa de limpieza de versiones (KB/s)
  • SQLServer:Transactions – Tasa de generación de versiones (KB/s)

Durante un inicio de sesión de 100 000 usuarios durante 1 hora, el tamaño del almacén de versiones se mantuvo en el rango de 10 MB a 30 MB, con un efecto de sierra a medida que las versiones se creaban y, a continuación, se limpiaban. Durante el cierre de sesión, el rango era de 10 MB a 21 MB. Cuando está inactivo, el tamaño del almacén de versiones oscila entre 1 MB y 4 MB.

La velocidad de generación de versiones osciló entre 250 y 500 KB durante el inicio de sesión, entre 150 y 400 KB/s durante el cierre de sesión y entre 0 y 250 KB/s cuando estaba inactivo.

La limpieza de versiones se ejecuta una vez por minuto y alcanza los 2500 KB/s durante el inicio de sesión, los 1750 KB/s durante el cierre de sesión y los 400 KB/s durante los períodos de inactividad.

E/S de disco

Durante las pruebas de inicio de sesión, la E/S del disco se midió con los siguientes contadores de rendimiento:

  • PhysicalDisk: bytes de lectura de disco por segundo
  • PhysicalDisk: bytes de escritura en disco por segundo
  • PhysicalDisk: lecturas de disco por segundo
  • PhysicalDisk: escrituras de disco/segundo

Se descubrió que la E/S de lectura era mínima, ya que el servidor SQL podía almacenar todos los datos en la memoria, lo que provocaba muy poca actividad de lectura en el sistema.

Debido al diseño de las bases de datos y del sistema de almacenamiento, los volúmenes se dividieron: un volumen contenía todos los archivos de datos y un segundo volumen contenía todos los archivos de registro de transacciones.

Los datos muestran un patrón que es difícil de colocar en una tabla. En general, el registro de transacciones tenía un número de bytes de escritura por segundo de 800 KB/s para la prueba de 1 hora y de 400 KB/s para la prueba de 2 horas. Una vez por minuto, cuando se ejecutaban los procedimientos almacenados de consolidación, el registro de transacciones mostraba picos de hasta 30 MB/s.

El análisis de los procedimientos almacenados de consolidación muestra que, a veces, las estadísticas hacen que el plan de consulta no sea óptimo y que una tabla temporal se extiende a TempDB. Esto desencadena escrituras en el registro de transacciones de TempDB.

Esta transferencia de datos se traduce en un estado estable de 300 operaciones de entrada/salida de escritura por segundo (IOPS) para la prueba de 1 hora y 200 IOPS de escritura para la prueba de 2 horas. Los picos de los procedimientos almacenados de consolidación añaden entre 2 y 300 IOPS de escritura adicionales mientras se ejecutan. Tenga en cuenta que en un entorno grande, los procedimientos almacenados de consolidación se ejecutan durante menos de un segundo.

Cuando cada base de datos tiene un punto de control, los datos de las tablas en memoria se sincronizan con los archivos de datos del volumen de datos.

Para obtener más información sobre los puntos de control de SQL, consulte http://technet.microsoft.com/enus/.

Estos puntos de control son períodos de actividad muy cortos, generalmente de menos de 1 segundo.

Durante el inicio de sesión, los puntos de control consumieron entre 6 y 7 MB/s y 500 IOPS de escritura. Durante el cierre de sesión, los puntos de control consumieron 7 MB/s, con un rango de entre 200 y 700 IOPS. Los números varían porque las bases de datos del sitio y de monitoreo tienen diferentes cantidades de datos por punto de control.

Mantenimiento de bases de datos

El mantenimiento de la base de datos en una implementación grande es importante. Si la base de datos no se mantiene correctamente, pueden producirse interrupciones en la base de datos debido a la falta de espacio en la base de datos, por ejemplo, si el registro de transacciones está configurado para crecer automáticamente y llena el disco, o si el registro de transacciones tiene un tamaño fijo y se llena.

Mantenimiento del registro de transacciones

Cuando se utilizan las funciones de alta disponibilidad de SQL Server, por ejemplo, los grupos de disponibilidad Always On o la duplicación de bases de datos, las bases de datos de XenDesktop se ejecutan en el modo de registro completo de transacciones.

Si se ejecuta en el modo de registro completo de transacciones, el registro de transacciones continúa creciendo hasta que se realiza una copia de seguridad de la base de datos o del registro de transacciones.

Esto puede provocar problemas si los archivos de registro de transacciones no se supervisan, ya que, de forma predeterminada, SQL Server configura los archivos de registro para que crezcan automáticamente. Esto provoca dos problemas:

  1. Los archivos de registro de transacciones pueden consumir mucho espacio en disco.
  2. Cada vez que el registro de transacciones crece, se paralizan todas las transacciones hasta que el espacio del registro se reduce a cero.

Citrix recomienda hacer copias de seguridad de los archivos de registro con regularidad. Esto se puede hacer con trabajos programados o planes de mantenimiento.

Como alternativa, utilice el agente de SQL Server para supervisar cuando el tamaño del registro utilizado supere un umbral y ejecutar un trabajo de copia de seguridad.

En las pruebas de escala, se usó un registro de tamaño fijo de 4 GB y se configuró una alerta para hacer una copia de seguridad del registro en otro archivo cuando el archivo de registro alcanzara el 80% de su capacidad. Esto impidió que el registro creciera y consumiera todo el espacio en disco, y también impidió que se pusiera a cero el espacio en disco y se paralizara la base de datos.

Un trabajo de ejemplo ejecutaría un script como:

  BACKUP LOG [CitrixXenDesktop-SiteDB] TO DISK = N'D:\LogBackup\CitrixXenDesktopSiteDB.bak' WITH NOFORMAT, NOINIT, COMPRESSION, NAME = N'Site-Transaction Log Backup', SKIP, NOREWIND, NOUNLOAD

El contador de rendimiento de SQL que se utilizará para la alerta es:

SQL Server: bases de datos: porcentaje de registro utilizado - Citrix XenDesktopSitedB

Repita este procedimiento para cada una de las 3 bases de datos.

Se descubrió que la copia de seguridad del archivo de registro tenía un impacto mínimo en un entorno de XenDesktop en ejecución. Hay un aumento marginal en los tiempos de intermediación, pero no es algo que consideremos significativo.

Para obtener más información sobre la configuración de los trabajos, consulte: https://docs.microsoft.com/en-us/sql/ssms/agent/create-a-job?view=sql-server-ver15

Para obtener más información sobre la configuración de alertas, consulte: https://docs.microsoft.com/en-us/sql/ssms/agent/alerts?view=sql-server-ver15

Mantenimiento de índices

A medida que se ingresan más datos en la base de datos, algunos de los índices comienzan a estar menos llenos, es decir, se almacenan menos registros en cada página SQL. Una página SQL tiene un tamaño de 8 KB. Esto hace que la base de datos aumente sus necesidades de almacenamiento, tanto en memoria como en disco. Al mantener los índices, se puede aumentar el tamaño de la página, lo que reduce los requisitos de memoria de la base de datos.

Citrix recomienda que los planes de mantenimiento de la configuración de los clientes se ejecuten todas las noches y semanalmente para mantener los índices. 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 derivado de la reconstrucción de índices grandes durante las operaciones diarias, especialmente en el caso de una base de datos de monitoreo de gran tamaño.

Microsoft recomienda reconstruir los índices si están fragmentados en más del 30% y reorganizarlos si están menos del 30%. Para obtener más información, consulte la documentación de Microsoft.

Después de reorganizar los índices, las estadísticas también deben actualizarse. Esto es particularmente importante a medida que la base de datos crece; de lo contrario, algunas estadísticas pueden ser deficientes y SQL puede generar planes de consulta de SQL subóptimos.

En términos de espacio ahorrado, el siguiente script de Microsoft se ejecutó en una base de datos de monitoreo de 1,2 GB. Mejoró el llenado de la página y liberó 300 MB de espacio.

Secuencias de comandos de terceros

Microsoft

Microsoft recomienda actualizar los índices de sus bases de datos SQL de WSUS mediante el script disponible en:

https://learn.microsoft.com/en-us/troubleshoot/mem/configmgr/update-management/reindex-the-wsus-database

Al cambiar «USE SUSDB», este script también se puede ejecutar en las bases de datos de XenDesktop. Este script sigue las prácticas recomendadas de Microsoft de reconstruir los índices fragmentados en más del 30% y reorganizar los que están por debajo del 30%. A continuación, actualiza las estadísticas de la base de datos.

Ola Hallengren

También hay scripts más avanzados disponibles en:

http://ola.hallengren.com/

Estos scripts gozan de buena reputación en la comunidad de SQL Server. En concreto, los scripts de índice están disponibles en:

http://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html

Estos scripts se pueden usar para controlar mejor los niveles con el fin de reorganizar o reconstruir los índices.

Configuración del servidor de prueba

Configuración de SQL Server

El grupo de disponibilidad de SQL está compuesto por 3 servidores Dell R720XD con especificaciones idénticas.

Especificación del sistema:

  • 2 CPU Intel Xeon E5-2630 de doble núcleo que funcionan a 2,30 GHz con tecnología Hyper-Threading
  • 64 GB DE RAM ECC
  • PERC H710P Mini con 1 GB de caché respaldada por batería
  • 26 unidades SAS de 300 GB a 10.000 RPM

Los discos se dividieron en los siguientes volúmenes:

  • Volumen del sistema
    • Contiene el sistema operativo y el archivo de página
    • 2 discos como espejo RAID 1
    • Capacidad total 278 GB
  • Volumen de base de datos
    • Contiene la instancia de SQL Server y los archivos de datos de la base de datos
    • 16 discos como banda reflejada de RAID 10
    • Capacidad total 2.231 GB
  • Volumen de registro
    • Contiene los archivos de registro de la base de datos
    • 8 discos como banda reflejada de RAID 10
    • Capacidad total 1.115 GB
  • Software:
    • Edición estándar de Windows Server 2012 R2, con actualizaciones actuales de Windows en el momento de la prueba (agosto de 2014)
    • SQL Server Enterprise 2012 SP2 con actualización acumulativa 1
  • Cambios en la configuración
    • SQL Server se configuró para usar un máximo de 61.440 MB
    • Se habilitó la contención de bases de datos en todas las instancias de SQL
    • El servicio SQL Server Agent se configuró para que se iniciara automáticamente
  • Configuración del grupo de disponibilidad:
    • Todos los servidores se colocaron en un clúster de conmutación por error de Windows
    • Se configuró un grupo de disponibilidad permanente dentro del clúster
    • Las réplicas secundarias se configuraron para ser de confirmación sincrónica, lo que requiere que las transacciones se confirmen en ambas réplicas antes de que se complete la transacción.
    • Se configuró y habilitó el enrutamiento de réplicas de solo lectura para el grupo de disponibilidad

Servidores de prueba de Delivery Controller y HSD

Los servidores de prueba Delivery Controller y HSD se ejecutaban en la misma configuración de hardware y utilizaban blades HP BL460c G1. Se usaron 2 servidores para los Delivery Controllers y 43 servidores proporcionaron la carga de trabajo HSD simulada.

Nota: Si bien estos servidores son relativamente antiguos, la carga de trabajo de los servidores HSD es baja, ya que la simulación de sesión se centra principalmente en colocar la carga en los Delivery Controllers, en lugar de en los servidores HSD.

Especificación del sistema:

  • 2 procesadores Intel Xeon L5320 de cuatro núcleos que funcionan a 1,86 GHz, no son compatibles con Hyper-Thread
  • 16 GB DE RAM ECC
  • Tarjeta RAID HP Smart Array E200I (sin caché respaldada por batería)
  • Un disco duro SAS de 36 GB o 72 GB

Software:

  • Windows Server 2012 R2 Standard edition, con las actualizaciones actuales de Windows en el momento de la prueba (agosto de 2014)
  • Citrix XenDesktop 7.6
Guía de tamaño de bases de datos para las versiones 7.6 y actual de XenApp y XenDesktop