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 garantizar que todo 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 mostrarlos en Director
• La base de datos de registros de configuración
  rastrea los cambios de configuración realizados XenDesktop la implementación

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 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. Se esperan variaciones entre las 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 total de la base de datos.

Cambios en los documentos de XenDesktop 7.6

Este documento se ha ampliado para abarcar la versión 7.6 de 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 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 era similar 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, ya que los inicios de sesión de los usuarios generan información de sesión y conexión para realizar un seguimiento
• El tamaño mínimo se alcanza cuando no hay sesiones activas y todos los VDA se cierran y se anulan el registro.
• 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 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 de 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 la escala se basa en la tasa de lanzamiento simultáneo.
• Bajo nivel de ruido de fondo de las transacciones de latidos del VDA. Cada VDA proporciona 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 era posible realizar nuevas conexiones ni 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 alcanzarse, ya que el sistema debe alcanzar el período de retención configurado.
• Los niveles bajos de transacciones por segundo se producen debido a la naturaleza por lotes de las actualizaciones del Servicio de supervisión. Es raro ver que las transacciones por segundo superan la marca de 20 transacciones por segundo.
• Algunas transacciones en segundo plano causadas por llamadas regulares de consolidación del Servicio de supervisión.
• 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 supervisión impide que se recopilen datos para el sitio, lo que significa que los datos no están visibles en Director.

Base de datos de registros de configuración

La base de datos de registros 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 cuánta actividad de configuración haya.
• Cualquier acción, por ejemplo, el 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 utilizan Director.
• Se producen transacciones mínimas 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 cuando es posible.
• La eliminación manual de los datos. Los datos de la base de datos de registros 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 fracaso

El impacto de una interrupción de la base de datos de registros 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 registros 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 registros 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 de 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 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 sí que 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 el tamaño pequeñ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/en-us/sql/relational-databases/databases/tempdb-database?view=sql-server-ver15

El área principal de contención 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 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 por lectura

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

Dimensionar las bases

El tamaño de las bases de datos depende de una serie de 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 se puede desconectar y volver a conectar.

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:

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

Nota:

El aumento del 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 crezca a la mayor con el tiempo.

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

• Cantidad de usuarios
• Número de sesiones
• Número de conexiones
• Trabajadores de VDI o HSD
• Periodo 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 al realizar pruebas de escalado 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 de retención máximos

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 mantener 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 son más antiguos que el período de retención configurado, se eliminan de la base de datos.

Dimensionamiento de bases 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 la información de equilibrio de carga, pero inicialmente tienen un tamaño similar al de los escritorios VDI.

Dimensionamiento de bases de datos de supervisión de XenDesktop 7.6

Los principales cambios con respecto a 7.5 son:

• Información de revisiones
  Los datos siguientes se basan en 3 revisiones por trabajador (VDI o HSD)
• Historial de uso de la aplicación
  Esto es relevante principalmente 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 registros de configuración

Proporcionar orientación para dimensionar la base de datos de registros 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. Las actividades pasivas, como enumerar las sesiones de un usuario, no lo son.

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

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

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

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

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

Durante las pruebas de escalabilidad, que simulan 100 000 inicios de sesión de HSD, el crecimiento del registro de transacciones se midió con 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 se compone de:

• 2 Delivery Controllers
• 43 trabajadores de HSD VDA
• 3 servidores SQL, configurados con las bases de datos, mantenidos dentro de 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 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 aumenta 3,5 MB por hora. Se trata de una combinación de latidos de VDA y Broker Service.

El crecimiento de los troncos es lineal durante el período de tiempo que se mide. Estos datos sugieren que, por inicio de sesión de usuario, el registro de transacciones crece 20 KB. Por cada usuario que cierra sesión, el registro de transacciones aumenta 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 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.

El crecimiento del registro es lineal durante el período de tiempo que se mide. Estos datos sugieren que por inicio de sesión de usuario, el registro de transacciones crece 7 KB. Por cada usuario que cierra sesión, el registro de transacciones aumenta 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 de supervisión 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 transacción de escritura/segundo mantiene los latidos del VDA y del Broker.

Nota: Estas cifras 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.

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 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.

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 del 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 impuestos al hardware. Se espera que la carga de la CPU de SQL pueda haber sido manejada por un SQL Server con un solo sistema de cuatro núcleos, en lugar de un sistema de doble núcleo hexagonal.

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 la CPU inactiva funcionaba al 0-2% de la CPU disponible. Los procedimientos almacenados de consolidación causaban picos cada minuto durante ~1 a 8-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 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ó al 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 dura prueba de esfuerzo 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 para que el hardware de alta disponibilidad coincida con la réplica principal, esta carga se gestionaría muy fácilmente mediante un servidor con especificaciones similares.

Uso temporal de la base

El TempDB se utiliza para muchos fines, incluido el almacenamiento de versiones, el espacio para grandes conjuntos de consultas y otros usos temporales de tablas.

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 mucho espacio y no activa ningún evento de autocrecimiento. Según los datos capturados, estaba sobredimensionada para esta implementación. Sin embargo, había suficiente 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 estaba inactivo, el tamaño del almacén de versiones oscilaba entre 1 MB y 4 MB.

La tasa de generación de versiones estaba 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 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:

• Disco físico: Bytes de lectura de disco/segundo
• Disco físico: bytes de escritura en disco/segundo
• Disco físico: 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 el 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 colocar en una tabla. En general, el registro de transacciones tenía una escritura de 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 de 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 que una tabla temporal se extiende a TempDB. Esto desencadena la escritura en el registro de transacciones de TempDB.

Esta transferencia de datos se traduce en un estado estable de 300 operaciones de entrada/salida (IOPS) de escritura por segundo (IOPS) para la prueba de 1 hora y 200 IOPS de escritura para la prueba de 2 horas. Los picos para los procedimientos almacenados de consolidación agregan otras 2 a 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 se comprueba cada base de datos, 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 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 s.

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, oscilando entre 200 y 700 IOPS. Las cifras varían porque las bases de datos del sitio y de supervisión tienen diferentes cantidades de datos para el punto de control.

Mantenimiento 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 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 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, de forma predeterminada, SQL Server configura los archivos de registro para que 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 pone a cero.

Citrix recomienda que se realicen 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 cuándo el tamaño utilizado del registro 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 hacer una copia de seguridad del registro en otro archivo cuando el archivo de registro alcanzara el 80% de su capacidad. Esto detuvo el crecimiento del registro y el consumo de todo el espacio en disco, y también detuvo la puesta a cero del espacio en disco y el bloqueo de 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:

SqlServer:Databases: Porcentaje de registro utilizado: CitrixXenDesktopSiteDB

Repita esta operación para cada una de las 3 bases de datos.

Se descubrió que la copia de seguridad del archivo de registro tiene 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 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 introducen más datos en la base de datos, algunos de los índices comienzan a llenarse menos, 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 clientes configuren planes de mantenimiento para que se ejecuten cada noche y cada semana 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 de la reconstrucción de índices grandes durante las operaciones diarias, especialmente para una base de datos de supervisión grande.

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

Después de reorganizar los índices, también deben actualizarse 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 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 llenado de páginas y liberó 300 MB de espacio.

Guiones 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

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

http://ola.hallengren.com/

Estos scripts están bien considerados en la comunidad de SQL Server. En concreto, los scripts de Index están disponibles en:

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

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

Configuración del servidor de pruebas

Configuración de SQL Server

El grupo de disponibilidad de SQL estaba compuesto por 3 servidores Dell R720XD con la misma especificación.

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
• Unidades SAS de 26 300 GB a 10 000 RPM

Los discos se dividieron en los siguientes volúmenes:

• Volumen del sistema
  • Contiene el SO y el archivo de paginación
  • 2 discos como espejo RAID 1
  • Capacidad total: 278 GB
• Volumen base de datos
  • Contiene la instancia de SQL Server y los archivos de datos de la base
  • 16 discos como banda duplicada RAID 10
  • Capacidad total: 2.231 GB
• Volumen de registro
  • Contiene los archivos de registro de la base
  • 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)
  • 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 la base de datos en todas
  • El servicio SQL Server Agent se configuró para que se inicie 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 Always On Availability dentro del clúster
  • Las réplicas secundarias se configuraron para ser confirmadas sincrónicas, lo que requiere que las transacciones se confirmen en ambas réplicas antes de que se complete la transacción
  • Se configuró y habilitó la redirección 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: 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 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 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