Guía de dimensionamiento de bases de datos para XenApp y XenDesktop versiones 7.6 hasta la versión actual

Aviso legal

Este documento contiene enlaces a sitios web controlados por terceros ajenos a Citrix. Citrix no es responsable y no respalda ni acepta ninguna responsabilidad por el contenido o el uso de estos sitios web de terceros. Citrix le proporciona estos enlaces solo para su comodidad, y la inclusión de cualquier enlace no implica el respaldo por parte de Citrix del sitio web enlazado. 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 actual y el estado de la implementación de XenDesktop
• Base de datos de supervisión 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 de configuración y de supervisió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 distinto.

Este documento proporciona información sobre cada base de datos y destaca las principales consideraciones a tener en cuenta al dimensionar las bases de datos para admitir XenDesktop 7.

Nota: Todos los números proporcionados son estimaciones. Se esperan variaciones entre las implementaciones.

En este documento también se señalan las diferencias de dimensionamiento entre los escritorios compartidos alojados (HSD) y la infraestructura de escritorio virtual (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 del documento para XenDesktop 7.6

Este documento se ha ampliado para cubrir XenDesktop 7.6. Esto fue para permitir actualizaciones sobre los cambios de tamaño para las características añadidas en la versión 7.6. Las tres nuevas características que afectan al tamaño de la base 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 aplicaciones: los detalles de todas las aplicaciones utilizadas en el entorno se almacenan en la base de datos de supervisión.
• Supervisión del inventario de revisiones: detalles de las revisiones de Citrix aplicadas a los controladores, VDA e imágenes de 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 la versión 7.6 a la 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 el funcionamiento del sistema.

Su uso se caracteriza por:

• El tamaño máximo se alcanza durante las horas pico, ya que los inicios de sesión de los usuarios generan información de sesión y conexión que debe rastrearse.
• El tamaño mínimo se alcanza cuando no hay sesiones activas y todos los VDA están apagados 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 de referencia 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 en la 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 múltiples transacciones individuales y se escala en función de la tasa de lanzamiento concurrente.
• Ruido de fondo de bajo nivel de las transacciones de latido de VDA. Cada VDA proporciona un latido una vez cada 5 minutos y esta actualización activa 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 pueda ser administrado ni supervisado. Las conexiones existentes se mantienen. En XenDesktop 7.6, el arrendamiento de conexiones permite establecer nuevas conexiones y reconexiones. En versiones anteriores, las nuevas conexiones y reconexiones no son posibles.

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 datos históricos.

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 clientes que no son Platinum, el valor predeterminado es de 7 días, con un período máximo de 7 días.
  • Para clientes Platinum, el valor predeterminado es de 90 días, sin período máximo.
• El tamaño máximo puede tardar un tiempo en alcanzarse, ya que el sistema tiene que llegar al período de retención configurado.
• Se producen bajos niveles de transacciones por segundo debido a la naturaleza por lotes de las actualizaciones del Servicio de supervisión. Es raro ver que las transacciones por segundo superen la marca de 20 transacciones por segundo.
• Algunas transacciones en segundo plano causadas por llamadas de consolidación regulares del Servicio de supervisión.
• Se realiza un procesamiento nocturno para eliminar los datos que están 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 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 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, el restablecimiento de sesión, desde 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 de configuración.
• Una baja tasa de transacciones durante las actualizaciones, ya que las actualizaciones se procesan por lotes cuando es posible.
• La eliminación manual de datos. Los datos dentro 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 de un fallo

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 reconfigurar 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 no rastreados 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 de lectura confirmada (Read-Committed Snapshot Isolation). XenDesktop 7 utiliza esta característica 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 supera unos pocos MB.

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

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

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

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

El principal punto de contención se centra en el número de archivos 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 el número de archivos 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 de lectura confirmada

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

Dimensionamiento de las bases de datos

El tamaño de las bases de datos depende de varios 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 y que puede desconectarse y volverse 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, esto 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 VDA y sesiones activas, de la siguiente manera:

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

Nota:

El aumento de tamaño para la versión 7.6 se debe a que los arrendamientos de conexión se almacenan en la base de datos como parte de la replicación entre los Controladores.

Base de datos de supervisión

De las tres bases de datos, se espera que la Base de datos de supervisión sea la que más crezca con el tiempo.

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

• Número de usuarios
• Número de sesiones
• Número de conexiones
• Trabajadores 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 observados durante las pruebas de escalabilidad de XenDesktop. Se considera que las estimaciones son realistas.

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

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 está controlada por la 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 utilizando el cmdlet Set-MonitorConfiguration.

Una vez que los datos superan el período de retención configurado, se eliminan 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

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

Tenga en cuenta que los HSD 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.

Dimensionamiento de la base de datos de supervisión de XenDesktop 7.6

Los principales cambios con respecto a la versión 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

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

Base de datos de registro 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, el cierre de sesión y el restablecimiento de la sesión. Las actividades pasivas, como la enumeración de las sesiones de un usuario, no se registran.

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 suele 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 la VM.

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

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

Durante las pruebas de escalabilidad, simulando 100 000 inicios de sesión HSD, el crecimiento del registro de transacciones se midió bajo dos tasas de inicio de sesión, de la siguiente manera:

• 100 mil usuarios iniciando sesión en 1 hora
• 100 mil usuarios iniciando sesión en 2 horas

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

El entorno estaba compuesto por:

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

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 para todas las bases de datos se monitorizó utilizando el contador del monitor de rendimiento SqlServer:Databases – Log File(s) Used Size (KB).

Base de datos del sitio

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

El crecimiento del registro es lineal durante el período de tiempo medido. Estos datos sugieren que, por inicio de sesión de usuario, el registro de transacciones crece 20 KB. Por cierre de sesión de usuario, el registro de transacciones crece 12 KB.

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

Supervisión de la base de datos

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

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

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

Transacciones por segundo

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

• SqlServer:Databases – Transacciones/segundo
• SqlServer:Databases – Transacciones de escritura/segundo

Base de datos del sitio

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

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

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-3 transacciones y 1 transacción de escritura por 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 realiza más trabajo.

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

Uso de CPU

Todos los servidores SQL utilizados para esta prueba eran servidores de doble núcleo hexagonal con hyper-threading habilitado. Las especificaciones exactas del hardware se proporcionan al final de este documento.

Se sabía que los servidores estaban sobredimensionados para la carga que se ejecutaba. Esto nos permitió identificar las limitaciones y los máximos impuestos al hardware. Se espera que la carga de CPU de SQL podría haber sido manejada por un servidor SQL con un solo procesador de cuatro núcleos, en lugar de un sistema de doble procesador de seis núcleos.

Durante las pruebas, la CPU del sistema se monitorizó utilizando el contador del monitor de rendimiento Procesador – % Tiempo de procesador – _Total.

Réplica principal

Mientras estaba inactiva, la CPU funcionaba al 0-2% de la CPU disponible. Los procedimientos almacenados de consolidación causaron picos cada minuto durante ~1s, alcanzando el 8-10% de la CPU del sistema. Se espera que esto 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 saltó 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 los procedimientos almacenados de consolidación añadieron un 7% a la CPU total, haciendo 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 <20% de un procesador de doble núcleo hexagonal fue necesario para mantener la tasa de inicio y cierre de sesión.

Nota: El programador de Windows Server 2012 tiende a usar los hyper-threads solo si es necesario, es decir, hasta que el sistema alcanza el 50% de carga, ejecuta solo un hilo por núcleo cuando es posible, por lo que una carga del 20% en 24 hyper-threads se ejecuta en 4,8 núcleos.

Dada la carga de trabajo, se cree que esta es una prueba de estrés 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 de la principal en sus discos, y solo la réplica síncrona está involucrada 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 (HA) coincida con la réplica principal, esta carga sería manejada muy fácilmente por un servidor con especificaciones similares.

Uso de la base de datos temporal

TempDB se utiliza para muchos propósitos, incluyendo el almacén de versiones, espacio para grandes conjuntos de consultas y otros usos de tablas temporales.

Tamaño de TempDB

En esta configuración de SQL, TempDB se configuró para tener 8 archivos de base de datos, cada uno con un tamaño fijo de 5 GB. Esto permite un mejor uso concurrente de TempDB, a la vez que proporciona mucho 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 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 de TempDB esté entre un cuarto y la mitad del número de CPU disponibles, pero sin exceder 8 sin saber que hay una contención real.

Tenga en cuenta que solo se utiliza un archivo de registro de TempDB, ya que SQL Server no se beneficia de múltiples 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ánea de lectura confirmada utilizado por 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 – Tasa de limpieza de versiones (KB/s)
• SQLServer:Transactions – Tasa de generación de versiones (KB/s)

Durante 100.000 inicios de sesión en 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 diente de sierra a medida que se creaban y luego se limpiaban las versiones. Durante el cierre de sesión, el rango fue de 10 MB a 21 MB. Cuando estaba inactivo, el tamaño del almacén de versiones oscilaba entre 1 MB y 4 MB.

La tasa de generación de versiones estuvo en el rango de 250-500 KB durante el inicio de sesión; 150-400 KB/s durante el cierre de sesión, y 0-250 KB/s cuando estaba inactivo.

La limpieza de versiones se ejecuta una vez por minuto y alcanzó 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 de disco se midió con los siguientes contadores de rendimiento:

• PhysicalDisk – Bytes de lectura de disco/segundo
• PhysicalDisk – Bytes de escritura de disco/segundo
• PhysicalDisk – Lecturas de disco/segundo
• PhysicalDisk – Escrituras de disco/segundo

Se encontró que la E/S de lectura era mínima, ya que el servidor SQL pudo mantener todos los datos en memoria, lo que provocó 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 contenía todos los archivos de datos y un segundo volumen que contenía todos los archivos de registro de transacciones.

Los datos muestran un patrón difícil de tabular. En general, el registro de transacciones tuvo una tasa de bytes de escritura/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 ejecutan los procedimientos almacenados de consolidación, el registro de transacciones mostró 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 sea subóptimo y una tabla temporal se desborda en 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 por segundo (IOPS) de escritura 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 otras 2-300 IOPS de escritura 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 se somete a un punto de control, los datos se sincronizan desde las tablas en memoria con los archivos de datos en el 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 6-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 la base 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 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 funciones de alta disponibilidad de SQL Server, por ejemplo, Always On Availability Groups o Database Mirroring, las bases de datos de XenDesktop se ejecutan en modo de registro de transacciones completo.

Al ejecutarse en modo de registro de transacciones completo, el registro de transacciones sigue creciendo hasta que se realiza una copia de seguridad de la base de datos o del registro de transacciones.

Esto puede causar problemas si los archivos de registro de transacciones no se supervisan, ya que, por defecto, SQL Server configura los archivos de registro para que crezcan automáticamente. Esto causa 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 del registro se ha puesto a cero.

Citrix recomienda que los archivos de registro se respalden regularmente. Esto se puede hacer con trabajos programados o planes de mantenimiento.

Alternativamente, utilice el Agente SQL Server para supervisar cuándo el tamaño utilizado del registro supera un umbral y ejecutar un trabajo de copia de seguridad.

En las pruebas de escalabilidad, se utilizó 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 alcanzaba el 80% de su capacidad. Esto impidió que el registro creciera y consumiera todo el espacio en disco, y también evitó que pusiera a cero el espacio en disco y detuviera 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 a utilizar para la alerta es:

SQLServer:Databases - Percent Log Used - 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 XenDesktop en ejecución; hay un aumento marginal en los tiempos de intermediación, pero no algo que consideremos significativo.

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

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

Mantenimiento de índices

A medida que se introducen más datos en la base de datos, algunos de los índices empiezan a estar menos llenos, es decir, se almacenan menos registros 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 ocupación de las páginas, lo que reduce los requisitos de memoria de la base de datos.

Citrix recomienda que los clientes configuren planes de mantenimiento para ejecutarse cada noche y semanalmente para mantener los índices. Los planes de mantenimiento pueden consistir simplemente en reorganizar los índices durante la noche entre semana y reconstruirlos 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 se reorganicen si lo están en menos del 30%. Para obtener más información, consulte la documentación de Microsoft.

Después de reorganizar los índices, también se deben actualizar las estadísticas. 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 SQL subóptimos.

En cuanto al espacio ahorrado, el script de Microsoft que se muestra a continuación se ejecutó en una base de datos de supervisión de 1,2 GB. Mejoró el llenado de páginas y liberó 300 MB de espacio.

Scripts de terceros

Microsoft

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

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

Al cambiar el “USE SUSDB”, este script también se puede ejecutar en bases de datos de XenDesktop. Este script sigue las mejores prácticas de Microsoft de reconstruir índices fragmentados en más del 30% y reorganizar los que están por debajo del 30%. Luego 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 son muy valorados 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 índices.

Configuración del servidor de prueba

Configuración de SQL Server

El grupo de disponibilidad de SQL estaba compuesto por 3 servidores Dell R720XD idénticamente especificados.

Especificación del sistema:

• 2 CPU Intel Xeon E5-2630 de seis núcleos a 2,30 GHz con hyper-threading habilitado
• 64 GB de RAM ECC
• PERC H710P Mini con caché de 1 GB con batería de respaldo
• 26 unidades SAS de 300 GB y 10k RPM

Los discos se dividieron en los siguientes volúmenes:

• Volumen del sistema
  • Conteniendo el SO y el archivo de paginación
  • 2 discos como un espejo RAID 1
  • Capacidad total 278 GB
• Volumen de la base de datos
  • Conteniendo la instancia de SQL Server y los archivos de datos de la base de datos
  • 16 discos como una franja espejada RAID 10
  • Capacidad total 2.231 GB
• Volumen de registro
  • Conteniendo los archivos de registro de la base de datos
  • 8 discos como una franja espejada RAID 10
  • Capacidad total 1.115 GB
• Software:
  • Windows Server 2012 R2 Standard Edition, con las actualizaciones de Windows actuales en el momento de la prueba (agosto de 2014)
  • SQL Server Enterprise 2012 SP2 con Actualización acumulativa 1
• Cambios de configuración
  • SQL Server se configuró para usar un máximo de 61.440 MB
  • La contención de la base de datos se habilitó en todas las instancias de SQL
  • El servicio SQL Server Agent se configuró para iniciarse 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 de disponibilidad Always On 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 la transacción se complete
  • El enrutamiento de réplicas de solo lectura se configuró y habilitó para el grupo de disponibilidad

Servidores de prueba de Delivery Controller™ y HSD

Los servidores de prueba de Delivery Controller y HSD se ejecutaban con la misma configuración de hardware, utilizando 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 sesión se centra principalmente en cargar los Delivery Controllers, en lugar de los servidores HSD.

Especificaciones del sistema:

• 2 Intel Xeon L5320 de cuatro núcleos a 1,86 GHz, sin capacidad de hyper-threading
• 16 GB de RAM ECC
• Tarjeta RAID HP Smart Array E200I (sin caché con batería de respaldo)
• Un disco duro SAS de 36 GB o 72 GB

Software:

• Windows Server 2012 R2 Standard edition, con las actualizaciones de Windows actuales en el momento de la prueba (agosto de 2014)
• Citrix XenDesktop 7.6