Conceptos avanzados

Guía sobre el tamaño de las bases de datos desde la versión 7.6 de XenApp y XenDesktop hasta la versión Current Release

Renuncia de responsabilidades

Este documento contiene enlaces a sitios web controlados por terceros distintos de Citrix. Citrix no es responsable ni respalda ni acepta ninguna responsabilidad por el contenido o el uso de estos sitios web de terceros. Citrix le proporciona estos enlaces solo como una conveniencia, y la inclusión de ningún enlace no implica la aprobación por parte de Citrix del sitio web vinculado. Es su responsabilidad tomar precauciones para asegurarse de que lo que seleccione para su uso esté libre de virus u otros elementos de naturaleza destructiva.

Información general

Una implementación típica de XenDesktop 7 consta de tres bases de datos, como se indica a continuación:

  • Base de datos de configuración del sitio
    Almacena la configuración y el estado actuales de la implementación de XenDesktop
  • Supervisión de la base de datos
    Almacena datos históricos para su visualización 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 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 deben tenerse en cuenta al dimensionar las bases de datos para que sean compatibles con XenDesktop 7.

Nota: Todas las cifras proporcionadas son estimaciones. Es de esperar variaciones entre implementaciones.

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

Cambios de documentos para XenDesktop 7.6

Este documento se ha ampliado para abarcar 7.6 XenDesktop. Esto era para permitir actualizaciones sobre los cambios de tamaño de las funciones agregadas en 7.6. Las tres nuevas funciones que afectan al tamaño de la base de datos son:

  • Leasing de conexiones: Los archivos de concesión comprimidos se almacenan en la base de datos del sitio
  • Supervisión del uso de aplicaciones: Los detalles de todas las aplicaciones utilizadas en el entorno se almacenan en la base de datos de monitores
  • Supervisión del inventario de revisiones: Detalles de las revisiones de Citrix aplicadas a las imágenes de Controllers, VDA y VDA en el entorno

La información sobre el tamaño de la tabla se ha actualizado a continuación. Se observó que las transacciones por segundo y el crecimiento del registro de transacciones eran similares en 7.6 a 7.5, por lo que no se realizaron actualizaciones en 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 pico a medida que los inicios de sesión del usuario generan información de sesión y conexión para ser rastreada.
  • Se alcanza el tamaño mínimo cuando no hay sesiones activas y los VDA se cierran y no se registran.
  • 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 dentro de la base de datos del sitio durante 48 horas.
  • El tamaño previsto de la base de datos crece a medida que crece la información de configuración de un sitio.Es decir, más trabajadores y usuarios consumen más espacio de base de datos.
  • Se producen altos niveles de transacciones por segundo durante el inicio de sesión, ya que cada inicio de sesión de usuario requiere que se realicen varias transacciones individuales y escalen en función de la velocidad de inicio simultáneo.
  • Ruido de fondo de bajo nivel de las transacciones de latidos del VDA. Cada VDA proporciona un latido una vez cada 5 minutos y esta actualización desencadena una transacción en la base de datos.

Impacto del fallo

Una interrupción de la base de datos del sitio hace que el sistema no se pueda administrar ni supervisar. Las conexiones existentes se mantienen. En XenDesktop 7.6 Connection Leasing permite realizar nuevas conexiones y reconexiones. En versiones anteriores no son posibles nuevas conexiones y reconexiones.

Base de datos de supervisión

La base de datos de supervisión 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 se controla mediante 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 llegar, ya que el sistema tiene que alcanzar el período de retención configurado.
  • Se producen niveles bajos de transacciones por segundo debido al carácter por lotes de las actualizaciones realizadas por el Servicio de Supervisión. Es raro ver que las transacciones por segundo pasan las 20 transacciones por segundo marca.
  • Algunas transacciones en segundo plano causadas por llamadas periódicas de consolidación del Servicio de Supervisión.
  • El procesamiento nocturno se lleva a cabo para eliminar datos fuera del período de retención configurado.

Impacto del fallo

Una interrupción de la base de datos de supervisión impide que se recopilen datos para el sitio, lo que significa que los datos no son visibles en Director.

Base de datos de registros de configuración

La base de datos de registro de configuración contiene un registro histórico de todos los cambios de configuración en el sitio. Esta información se utiliza para generar informes o para mostrarse 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.
  • Cualquier acción, por ejemplo, restablecimiento de sesión, de Director se registra en esta base de datos, por lo que puede haber un crecimiento lento a medida que los administradores usan Director.
  • Transacciones mínimas que se producen en la base de datos cuando no se realizan cambios en la configuración.
  • Una tasa de transacción baja durante las actualizaciones, ya que las actualizaciones se realizan por lotes siempre que sea 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 directiva de retención y no se eliminan a menos que un administrador lo haga manualmente.

Impacto del fallo

El impacto de una interrupción de la base de datos de registro de configuración depende de la configuración del sitio, como se indica a continuación:

  • 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, se pueden realizar 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 de todo el sistema proporcionada por SQL Server. Se utiliza como almacén de versiones para el aislamiento de instantáneas confirmadas de lectura. XenDesktop 7 utiliza 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. En general, sin embargo, no es más que unos pocos MB.

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

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

Encontrará instrucciones sobre el tamaño y la configuración de TempDB en MSDN:

http://technet.microsoft.com/en-us/library/ms175527(v=sql.105).aspx

El área principal de contención se centra en el número de archivos a usar. 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 el número de archivos que se van a utilizar, 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 confirmadas de lectura

Citrix recomienda que todas las bases de datos de XenDesktop 7 utilicen Aislamiento de instantáneas confirmadas por lectura. Para obtener más información, consulte How to Enable Read-Committed Snapshot in XenDesktop.

Ajustar el tamaño de las bases de datos

Los tamaños de la base de datos dependen de una serie de factores clave, incluido el número de sesiones y conexiones creadas durante un día laborable.

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

Una conexión es cada vez 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 el número de agentes VDA y sesiones activas, como se indica a continuación:

Usuarios Aplicaciones Tipo Tamaño máximo esperado 7,5 (MB) Tamaño máximo esperado 7,6 (MB)
1.000 50 HSD 30 31
10 000 100 HSD 60 198
100 000 200 HSD 330 752
1.000 N/D VDI 30 30
10 000 N/D VDI 115 121
40 000 N/D VDI 390 426

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

Nota:

El mayor tamaño de 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 Controllers.

Base de datos de supervisión

De las tres bases de datos, se espera que la base de datos de supervisión aumente hasta llegar a ser la más grande a lo largo del tiempo.

Su tamaño depende de muchos factores, incluidos los siguientes:

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

A continuación se presentan estimaciones del tamaño de la base de datos en varios puntos de datos. Estos datos son una estimación basada en los datos que se ven al realizar 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 menor que las estimaciones.

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

Períodos máximos de retención

La cantidad máxima de datos retenidos se controla mediante licencia, de la siguiente manera:

  • Los clientes que no son 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.

Una vez que los datos son anteriores al período de retención configurado, se elimina de la base de datos.

Tamaño de la base de datos de supervisión de XenDesktop 7.5

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)
1.000 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
1.000 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)
1.000 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
1.000 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 SSD generan más datos con el tiempo debido al registro de información de equilibrio de carga, pero inicialmente tienen un tamaño similar al de los escritorios VDI.

Tamaño de la base de datos de supervisión de XenDesktop 7.6

Los principales cambios de 7.5 son:

  • Información de revisiones
    Los datos siguientes se basan en 3 revisiones por trabajador (VDI o HSD)
  • Historial de uso de aplicaciones
    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)
1.000 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.758 370.841
1.000 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)
1.000 HSD 159 635 2.063 8.251
10 000 HSD 2.904 11.599 37.684 150.718
100 000 HSD 7.940 31.572 102.465 409.672
1.000 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 registros de configuración

Proporcionar orientación para dimensionar la base de datos de registro de configuración es mucho más difícil, ya que varía drásticamente según la actividad diaria de Director y el tamaño del sitio configurado.

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

El mecanismo utilizado para implementar escritorios también afecta el 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.

Para 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 compilación de VM.

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

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

Durante las pruebas de escalabilidad, simulando 100k inicios de sesión HSD, el crecimiento del registro de transacciones se midió bajo dos velocidades de inicio de sesión, como se indica a continuación:

  • 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 se compone de:

  • 2 Delivery Controllers
  • 43 trabajadores de HSD VDA
  • 3 SQL Servers, configurados con las bases de datos, mantenidos dentro de un grupo de disponibilidad Always On

Al final de este documento se proporcionan detalles sobre las configuraciones del servidor.

Crecimiento del registro de transacciones

El crecimiento del registro de transacciones para todas las bases de datos se supervisó mediante el contador de monitor de rendimiento SqlServer:Databases: Tamaño de los archivos de registro utilizados (KB).

Base de datos del sitio

Cuando el sistema está inactivo, el registro de transacciones crece 3,5 MB por hora. Esta es una combinación de latidos de VDA y Broker Service.

Prueba Crecimiento total de inicio de sesión (MB) Crecimiento total del cierre de sesión (MB)
100 000 en 1 hora 1.900 1.150
100 000 durante 2 horas 1.900 1.150

El crecimiento de los registros es lineal durante el período de tiempo que se está midiendo. Estos datos sugieren que, por inicio de sesión de usuario, el registro de transacciones crece en 20 KB. Por usuario cierre de sesión, el registro de transacciones crece en 12 KB.

Por lo tanto, el crecimiento por día es de 32 KB por ciclo de inicio de sesión o cierre de sesión de usuario.

Base de datos de supervisión

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

Prueba Crecimiento total de inicio de sesión (MB) Crecimiento total del cierre de sesión (MB)
100 000 en 1 hora 670 190
100 000 durante 2 horas 650 220

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

Por lo tanto, el crecimiento por día es de 9 KB por ciclo de inicio de sesión o cierre de sesión de usuario.

Transacciones por segundo

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

  • SqlServer:Databases: Transacciones/segundo
  • SqlServer:Databases: Escritura de transacciones/segundo

Base de datos del sitio

Cuando el sistema está inactivo, hay 5 transacciones/segundo de las cuales 1 escritura/segundo mantiene latidos de VDA y Broker.

Nota: Estos números son estimaciones tomadas de los períodos de tiempo dados. La carga exacta varía según el número de lanzamientos simultáneos por segundo.

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

Base de datos de supervisión

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 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, la sobrecarga aumenta a medida que se lleva a cabo más trabajo.

Nota: Estos números son estimaciones tomadas de los períodos de tiempo dados.

Prueba Transacciones de inicio de sesión por segundo Transacciones de escritura de inicio de sesión por segundo Transacciones de cierre de sesión por segundo Transacciones de escritura de cierre de sesión por segundo
100 000 en 1 hora 4 2 4 2
100 000 durante 2 horas 4 2 3,5 2

Uso de CPU

Todos los servidores SQL utilizados para esta prueba eran servidores hex-core duales con tecnología Hyper-Threading habilitada. Las especificaciones exactas de hardware se proporcionan al final de este documento.

Se sabía que los servidores tenían un tamaño excesivo para la carga que se estaba ejecutando. Esto nos permitió identificar las limitaciones y los máximos colocados en el hardware. Se espera que la carga de la CPU SQL podría haber sido manejada por un SQL Server con un solo núcleo cuádruple, en lugar de un sistema doble hex-core.

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

Réplica principal

Mientras que la CPU inactiva se ejecutó en 0 -2% de la CPU disponible. Los procedimientos almacenados de consolidación causaron picos cada minuto durante ~1s a 8 -10% de la CPU del sistema. Se espera que esta escala se escale en función de la cantidad de datos que se procesen.

Durante el inicio de sesión de 100 000 usuarios en 1 hora, la CPU subió al 7% y aumentó linealmente al 11% a medida que más sesiones y usuarios estaban presentes en el entorno. Tenga en cuenta que los picos de procedimientos almacenados de consolidación agregaron un 7% al total de la CPU, haciendo que los picos alcancen el 18% de la CPU.

Durante el cierre de sesión, la CPU se ejecutó en un 3,5%, con un 7% de CPU adicional para los procedimientos almacenados de consolidación. En general, esto sugiere que <20% de un doble núcleo hexagonal era necesario para mantener la tasa de inicio de sesión y cierre de sesión.

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

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

Réplicas secundarias

Se encontró 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 primario en sus discos, y solo la réplica síncrona está involucrada con las transacciones, ya que la réplica principal no confirma una transacción hasta que la secundaria la reconoce.

Según las recomendaciones de hardware de alta disponibilidad para que coincida con la réplica principal, esta carga sería manejada muy fácilmente por un servidor especificado de manera similar.

Uso de la base de datos temporal

El TempDB se utiliza para muchos propósitos, incluido el almacén de versiones, espacio para grandes conjuntos de consultas y otro uso de tablas temporales.

Tamaño de TempDB

En esta configuración 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 mucho espacio y no activa ningún evento de autocrecimiento. En función de los datos capturados, fue sobredimensionado para esta implementación. Sin embargo, había mucho espacio en disco disponible.

También se mantiene dentro de la guía general de que el número de archivos de base de datos TempDB está entre un cuarto y medio del número de CPU disponible, pero no excede 8 sin saber que hay contención 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.

Almacén 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 mediante los siguientes contadores de rendimiento:

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

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

La velocidad de generación de versiones se encontraba en el intervalo de 250 a 500 KB durante el inicio de sesión; de 150 a 400 KB/s durante el cierre de sesión y de 0 a 250 KB/s cuando está inactivo.

La limpieza de versiones se ejecuta una vez por minuto y alcanza los 2.500 KB/s durante el inicio de sesión, 1.750 KB/s durante el cierre de sesión y 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 discos/segundo
  • PhysicalDisk: Bytes de escritura de disco/segundo
  • PhysicalDisk: Lecturas de disco/segundo
  • PhysicalDisk: Escrituras en disco/segundo

Se encontró que la E/S de lectura era mínima, ya que el servidor SQL pudo contener todos los datos en la memoria, lo que causa 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, con un volumen que contiene todos los archivos de datos y un segundo volumen que contiene 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 una escritura bytes/segundo de 800 kb/s para la prueba de 1 hora, y 400 kb/s para la prueba de 2 horas. Una vez por minuto, cuando se ejecutan los procedimientos almacenados de consolidación, el registro de transacciones mostró picos a 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 sea subóptimo, y una tabla temporal se derrama en TempDB. Esto desencadena escrituras en el registro de transacciones para TempDB.

Esta transferencia de datos se traduce en un estado constante 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 agregan otras 2—300 IOPS de escritura mientras se ejecuta. 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 está marcada, los datos se sincronizan desde las tablas en memoria con los archivos de datos del volumen de datos.

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

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

Durante el inicio de sesión, los puntos de comprobación 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, oscilando entre 200 y 700 IOPS. Los números varían porque las bases de datos de sitio y supervisión tienen diferentes cantidades de datos para el 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 de la base de datos debido a la falta de espacio de 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, Grupos de disponibilidad siempre activados o reflejo de base de datos, las bases de datos de XenDesktop se ejecutan en modo Registro de transacciones completo.

Al ejecutar en modo de registro de transacciones completo, el registro de transacciones continúa creciendo hasta que se realiza una copia de seguridad de base de datos o registro de transacciones.

Esto puede causar 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 se crezcan automáticamente. Esto provoca 2 problemas:

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

Citrix recomienda realizar 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 SQL Server para supervisar cuándo el tamaño del registro utilizado supera un umbral y ejecutar un trabajo de copia de seguridad.

En las pruebas de escala se utilizó un registro de tamaño fijo de 4 GB y se configuró una alerta para realizar una copia de seguridad del registro en otro archivo cuando el archivo de registro alcanzó el 80% lleno. Esto detuvo el registro creciendo y consumiendo todo el espacio en disco, y también lo detuvo poniendo a cero el espacio en disco y paralizando 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 SQL que se utilizará para la alerta es:

SqlServer:Databases: Porcentaje de registro utilizado: CitrixXenDesktopSiteDB

Repita esto 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 algo que creemos que sea significativo.

Para obtener más información sobre la configuración de trabajos, consulte: http://msdn.microsoft.com/en-us/library/ms187880.aspx

Para obtener más información sobre la configuración de alertas, consulte: http://msdn.microsoft.com/en-us/library/ms191508.aspx

Mantenimiento del índice

A medida que se introducen más datos en la base de datos, algunos de los índices comienzan a estar menos llenos, es decir, menos registros se almacenan en cada página SQL. Una página SQL es 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 la plenitud de la página, lo que reduce los requisitos de memoria de la base de datos.

Citrix recomienda que el mantenimiento de la configuración de los clientes planifique la ejecución nocturna y semanal para mantener los índices. Los planes de mantenimiento pueden ser simplemente reorganizar los índices durante la noche durante la semana y reconstruir los índices durante 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 son mayores del 30% fragmentados y que se reorganicen si son inferiores al 30%. Para obtener más información, consulte Reorganizar y reconstruir índices en la biblioteca de Microsoft TechNet.

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

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

Scripts de terceros

Microsoft

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

http://gallery.technet.microsoft.com/scriptcenter/6f8cde49-5c52-4abd-9820-f1d270ddea61

Al cambiar la opción “USE SUSDB”, este script también se puede ejecutar en bases de datos de XenDesktop. Este script sigue la práctica recomendada de Microsoft de reconstruir índices más del 30% fragmentados y reorganizar los inferiores al 30%. A continuación, actualiza las estadísticas de la base de datos.

Ola Hallengren

Los scripts más avanzados también están disponibles en:

http://ola.hallengren.com/

Estos scripts son bien considerados en la comunidad de SQL Server. Específicamente, los scripts de índice disponibles en:

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

Estos scripts se pueden utilizar para un control más preciso sobre los niveles para reorganizar o reconstruir los índices.

Configuración del servidor de prueba

Configuración de SQL Server

El grupo de disponibilidad SQL consta de 3 servidores Dell R720XD especificados de forma idéntica.

Especificaciones del sistema:

  • Procesador Intel Xeon E5-2630 de 2 núcleos hex-core que funciona a 2,30 GHz con tecnología Hyper-Threading habilitada
  • 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 un espejo RAID 1
    • Capacidad total: 278 GB
  • Volumen de base de datos
    • Contiene la instancia de SQL Server y los archivos de datos de base de datos
    • 16 discos como banda duplicada RAID 10
    • Capacidad total: 2.231 GB
  • Volumen de registro
    • Contiene los archivos de registro de la base de datos
    • 8 discos como banda duplicada RAID 10
    • Capacidad total: 1.115 GB
  • Software:
    • Windows Server 2012 R2 Standard Edition, con actualizaciones actuales de Windows en el momento de la prueba (agosto de 2014)
    • Service Pack 2 de SQL Server Enterprise 2012 con actualización acumulativa 1
  • Cambios de configuración
    • SQL Server se configuró para usar un máximo de 61.440 MB
    • Se habilitó la contención de la base de datos en todas las instancias SQL
    • El servicio Agente SQL Server se configuró para iniciar automáticamente
  • Configuración del grupo de disponibilidad:
    • Todos los servidores se colocaron dentro de un clúster de conmutación por error de Windows
    • Se configuró un grupo Always On Availability dentro del clúster
    • Las réplicas secundarias se configuraron para ser confirmaciones sincrónicas, requiriendo 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éplica de solo lectura para el grupo de disponibilidad

Delivery Controller y servidores de prueba HSD

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

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

Especificaciones del sistema:

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

Software:

  • Windows Server 2012 R2 Standard Edition, con actualizaciones actuales de Windows en el momento de la prueba (agosto de 2014)
  • Citrix XenDesktop 7.6
Guía sobre el tamaño de las bases de datos desde la versión 7.6 de XenApp y XenDesktop hasta la versión Current Release