Conceptos avanzados

Tamaño y escalado de la caché de host local

La caché de host local se introdujo en XenApp y XenDesktop 7.12 para reemplazar la función de concesión de conexiones suministrada en XenDesktop 7.6. La caché de host local abarca más casos que el arrendamiento de conexiones, pero requiere diferentes consideraciones de diseño.

Los detalles sobre las consideraciones de diseño de la función de leasing de conexiones se pueden encontrar en https://www.citrix.com/blogs/2014/11/11/xendesktop-7-6-connection-leasing-design-considerations/.

  • La caché de host local admite más casos de uso que el arrendamiento de conexiones.
  • Cuando está operativo, la caché de host local requiere más recursos (CPU y memoria) que la concesión de conexiones.
  • Durante el modo de interrupción, solo un agente por zona manejará registros de VDA y sesiones de broker.
  • Un proceso electoral decide qué intermediario estará activo durante la interrupción, pero no tiene en cuenta los recursos del intermediario.
  • Si un solo broker en una zona no sería capaz de manejar todos los inicios de sesión durante el funcionamiento normal, no funcionará bien en modo de interrupción.
  • No hay administración de sitios disponibles durante el modo de interrupción.
  • Un SQL Server de alta disponibilidad sigue siendo el diseño recomendado.
  • Para casos de conectividad de base de datos intermitentes, es mejor aislar SQL Server y dejar el sitio en modo de interrupción hasta que se solucionen todos los problemas subyacentes.
  • Hay un límite de 5000 VDA por zona (no se aplica).
  • No hay límite de 14 días.
  • Los escritorios agrupados no se admiten en modo de interrupción, en la configuración predeterminada.

Arquitectura

La concesión de conexiones se introdujo en XenDesktop 7.6 para permitir el acceso continuo a los recursos durante los períodos de interrupción de la base de datos del sitio. No admite escritorios agrupados de VDI y, de forma predeterminada, los usuarios deben haberse conectado a un recurso en los 14 días anteriores. Otra restricción era que intentaría conectar a los usuarios al último host de escritorio o aplicación al que se habían conectado durante el funcionamiento normal. Si esto no estuviera disponible, entonces la conexión no se negociaría.

La arquitectura de las dos tecnologías (leasing de conexiones y caché de host local) es muy diferente, y requieren diferentes recursos para operar. La concesión de conexiones crea archivos de concesión XML individuales, que pueden requerir varios GB de espacio en disco, dependiendo del número de recursos de un sitio. La caché de host local utiliza una base de datos local de SQL Server y es más eficiente en el uso de espacio en disco, pero requiere mucho más memoria y CPU que el arrendamiento de conexiones. Ambos tienen fases de sincronización donde los detalles de la base de datos del sitio principal se sincronizan con los brokers (Controllers). La sincronización inicial de leasing de conexiones puede causar IOPS considerables debido a la gran cantidad de archivos individuales que se crean en el sistema de archivos. Aunque la caché de host local utiliza una base de datos SQL que aún requiere IOPS, tiene la ventaja de optimizar SQL estas escrituras.

En una configuración de arrendamiento de conexiones con varios intermediarios, cada intermediario tiene una copia de los arrendamientos XML y es capaz de intermediar conexiones durante una interrupción, lo que ayuda a equilibrar la carga. Sin embargo, con la Caché de Host Local, se elige un solo broker para que se encargue de todas las conexiones y se encargue de los registros de VDA. Todos los agentes VDA del sitio se volverán a registrar con este único broker y, como tal, ese agente experimentará una mayor demanda de recursos en comparación con un sitio de varios agentes en funcionamiento normal, especialmente en sitios con un gran número de agentes VDA.

Caché de host local utiliza Microsoft LocalDB, que aparece en el Administrador de tareas como el proceso sqlserver.exe. Se ha configurado para usar hasta 1 GB de memoria para el almacenamiento en caché del grupo de búferes de base de datos. Sin embargo, el proceso crecerá más allá de esto ya que el motor SQL necesita memoria para sí mismo y otras cachés más pequeñas. En general, cuanto más tiempo sea la interrupción y más recursos se acceda durante el modo de interrupción, más uso de memoria LocalDB aumentará. Sin embargo, cuando se restaura la conectividad de la base de datos del sitio, sqlserver.exe se mantendrá en esta memoria y no la devolverá inmediatamente al grupo principal.

Efecto de los zócalos y núcleos de CPU durante el modo de interrupción

En versiones anteriores de XenApp y XenDesktop, los administradores no se preocupaban necesariamente por la configuración de CPU del equipo broker (Controller): El diseño del número de sockets y núcleos, ya sea en una máquina física o virtual.

Caché de host local utiliza una versión en tiempo de ejecución de SQL Server llamada LocalDB que tiene licencias específicas que lo limita al menor de cuatro núcleos o un solo socket. Esto puede tener un efecto significativo en el rendimiento cuando la máquina física o virtual se ha configurado con varios sockets con solo un núcleo único o doble. Una máquina de broker con 4 sockets y un núcleo por socket limitará LocalDB a usar un solo núcleo, mientras que la misma máquina virtual configurada como una máquina de 4 núcleos de 1 socket significa que LocalDB puede acceder a los 4 núcleos (aunque los comparta con otros procesos). Durante el modo de interrupción, LocalDB ejecutará el mismo broker y código SQL que durante el funcionamiento normal. Muchas de las consultas SQL pueden tener un uso intensivo de CPU y tener un impacto directo en el rendimiento de la intermediación durante el modo de interrupción.

Otros factores incluyen la configuración del sitio en sí:

  • Número de solicitudes publicadas
  • El número de usuarios que se negocian
  • La velocidad a la que los usuarios intentan iniciar sesiones
  • Rendimiento de Active Directory

A medida que la utilización total de la CPU del broker se acerca al 100%, el tiempo de respuesta de la intermediación aumentará, los inicios de sesión tardarán más tiempo en procesarse y algunos intentos de inicio de sesión pueden fallar.

Sitios con varios intermediarios

Durante el modo de interrupción del sitio, solo un agente procesa las solicitudes de registro y de inicio de sesión. En un sitio multi-broker se lleva a cabo un proceso electoral para designar al intermediario que estará activo durante la interrupción. Sin embargo, este proceso electoral no tiene en cuenta los recursos físicos disponibles para los intermediarios. Esto significa que en un sitio donde los intermediarios tienen diferentes cantidades de recursos, el broker elegido no será necesariamente el más poderoso en términos de CPU o RAM, lo que podría conducir potencialmente a un rendimiento deficiente durante el modo de interrupción. Es importante que cada broker cumpla los requisitos adicionales de Caché de Host Local, en caso de que se elija.

Sincronización con la base de datos del sitio

El servicio CitrixConfigSync maneja la importación de datos de la base de datos del sitio en una copia local en los brokers. Supervisa la base de datos del sitio en busca de cambios en la configuración del sitio y activa una nueva importación cuando se producen cambios. Se realiza una copia de la base de datos local actual antes de que comience la importación. Cuanto mayor sea el número de recursos (como los VDA) de un sitio, más tardará la importación, pero debería ser inferior a diez minutos para un sitio con 5000 VDA.

Ubicación de la base de datos

La base de datos local se almacena en:

C:\Windows\ServiceProfiles\NetworkService\HaDatabaseName.mdf

Para garantizar la fiabilidad, el servicio CitrixConfigSync realiza una copia de seguridad de la importación de base de datos sincronizada anteriormente correctamente, antes de iniciar una nueva sincronización de base de datos del sitio. Si por algún motivo la sincronización no se realiza correctamente, la copia de seguridad se utilizará hasta que se complete una sincronización correcta. No debe copiar la base de datos manualmente.

Comparación de la caché de host local con el arrendamiento de conexiones

  Concesión de conexiones Caché de host local
Espacio del disco Se recomienda 2 GB Depende de la configuración del sitio. Para 50 hosts RDS con 125 K usuarios, se utilizan 300 MB.
RAM 100 MB 3 GB, ~1 GB para SQL Server, 2 GB para High Availability Service y CitrixConfigSync Service.
Hora de sincronización de la configuración Dependiente de IOPS; 40 000 VDA: ~ 26 minutos 5000 VDA: ~ 7 minutos
Tiempo de activación durante la interrupción Tiempo de espera SQL predeterminado de 150 segundos, 30 segundos+período de espera de 120 segundos (configurable) Depende del número de VDA y de la última sincronización de registro con el broker. Solo un agente estará disponible para el registro de VDA durante el modo de interrupción, por lo que para un gran número de VDA puede pasar varios minutos antes de que se registren todos los VDA.
Tiempo para restaurar las operaciones normales 120 segundos para que el arrendamiento se desactive, los VDA deben volver a registrarse con los intermediarios Como se indica anteriormente, los VDA deberán anular el registro del broker secundario y volver a registrarse en el broker principal.
Número de agentes VDA admitidos 50 000 5000 Un sitio puede tener más que esto, pero el tiempo necesario para sincronizar la base de datos del sitio aumentará con el número de agentes VDA. El rendimiento de un solo broker con una gran cantidad de agentes VDA podría provocar que no se intermedien algunas conexiones durante la interrupción.
Administración del sitio durante la interrupción No No

Configuración de límites de memoria LocalDB

El proceso LocalDB se ha limitado a 1 GB de RAM para el almacenamiento en caché, que normalmente no debería ser modificado. Este valor se puede cambiar si es necesario; para que los cambios surtan efecto, el sitio debe estar en funcionamiento normal (no en modo de interrupción) y debe forzarse una sincronización de base de datos del sitio.

Para reducir la memoria a 768 MB:

Paso 1: Modifique el archivo C:\Program Files\Citrix\Broker\Service\HighAvailabilityService.exe.config.

Busque la sección <appSettings> y agregue una entrada:

<add key="MaxServerMemoryInMB" value="768" />

Paso 2: Para forzar la sincronización de la base de datos, detenga el servicio de alta disponibilidad. Si sqlserver.exe se está ejecutando, deténgalo mediante el Administrador de tareas o PowerShell.

Paso 3: Ahora haga un cambio trivial en el sitio, por ejemplo, cambie la descripción de un grupo de entrega agregando un “.” y, a continuación, quítelo de nuevo. A continuación, inicie el servicio de alta disponibilidad; que debería iniciar sqlserver.exe y debería producirse una sincronización.

Reducir demasiado la memoria afectará el rendimiento y no se recomienda. Sin embargo, aumentarlo a 2 GB no mejora significativamente el rendimiento, y el recurso de CPU es más un cuello de botella que la RAM.

Habilitación o desactivación de la caché de host local

Tanto el arrendamiento de conexiones como la caché de host local se pueden inhabilitar, pero solo uno de ellos puede estar activo a la vez.

Set-BrokerSite –ConnectionLeasingEnabled $False

Set-BrokerSite –LocalHostCacheEnabled $True

Limitaciones

Los escritorios deben haberse asignado antes de que puedan utilizarse en modo de interrupción. Los escritorios sin asignar no estarán disponibles para la intermediación. Esto puede dar lugar a que los escritorios no estén disponibles e informen “en modo de mantenimiento” si se produce una interrupción antes de que se hayan sincronizado todas las asignaciones, a pesar de que un usuario tenga realmente asignado un escritorio.

Los escritorios agrupados no se admiten en modo de interrupción, en la configuración predeterminada. Hay una solución alternativa, pero tiene posibles implicaciones en materia de seguridad y rendimiento. Si configura un grupo de entrega que contenga escritorios agrupados para que no se reinicie al cerrar la sesión, los escritorios agrupados encendidos de ese grupo estarán disponibles en modo de interrupción. Sin embargo, después de que un usuario cierre la sesión, el escritorio no estará en un estado limpio porque el escritorio no se reinicia. Esto podría ser un problema de seguridad en cualquier caso. Si el siguiente usuario de ese escritorio es un administrador local de ese escritorio, es posible que se pueda acceder a los datos de un usuario anterior. Y aunque ese riesgo es menos preocupante para los usuarios estándar (no administradores), tenga en cuenta que las aplicaciones podrían comportarse incorrectamente y causar problemas de rendimiento a lo largo del tiempo. Importante: Los administradores deben considerar cuidadosamente las posibles implicaciones de usar esta solución alternativa para usar escritorios agrupados no reiniciados en modo de interrupción.

Al igual que con el arrendamiento de conexiones, no se pueden realizar cambios en el sitio durante la interrupción; la base de datos es efectivamente una instantánea de la base de datos del sitio principal y se descarta cada vez que se produce una nueva sincronización.

Comparación del rendimiento del broker de vCPU 6 y 8 en condiciones de estrés

Se configuró un sitio con 50 trabajadores RDS y 5075 VDI VDA. Cada trabajador RDS es capaz de admitir 2500 usuarios simulados. Se estableció una tasa de lanzamiento de 20 usuarios por segundo. Se han agregado números distintos de aplicaciones publicadas al sitio.

Para los trabajadores de RDS, se lanzaron 100 000 usuarios, para VDI 5075.

Las pruebas se realizaron en modo normal y local de caché de host operativo (interrupción).

En el sistema de 6 vCPU, hay muy poco espacio para la CPU, y se produce una pequeña cantidad de excepciones (<10) cuando el recuento de aplicaciones publicadas es superior a 0.

Las actualizaciones de Windows fueron inhabilitadas por la directiva de grupo ya que durante varias ejecuciones, se encontró que el proceso tiworker.exe (Módulo de Windows Installer) utilizaba casi un núcleo completo durante largos períodos de tiempo. Esto dio lugar a un gran número de fallos de lanzamiento, por lo que las pruebas se ejecutaron de nuevo. El procesador de broker es bastante viejo, pero el proceso de tiworker consumirá un solo núcleo de uno más nuevo, afectando la prueba.

Configuración del hipervisor

  • XenServer 7.0
  • AMD Opteron 8431 2,4 GHz: 4 x 6 núcleos
  • 128 GB de RAM
  • Almacenamiento en caché de lectura habilitado
  • Windows Storage Server 2012R2 con almacenamiento basado en SSD

Configuración del broker

  • 2 zócalos con 3 núcleos y 2 zócalos con 4 núcleos
  • 10 GB de RAM
  • Windows Server 2016
  • Grupo de entrega único para cada tipo de VDA
  • Todas las aplicaciones visibles para el usuario
  • XenDesktop 7.12

Configurar StoreFront

  • 6 servidores StoreFront
  • Windows Server 2016
  • 4 CPU virtuales
  • 10 GB de RAM

Configuración de NetScaler

  • VPX 8000 versión 11.063.16

Configuración de SQL Server

  • Intel E5-2630 2,3 GHz 2x12 núcleos
  • SQL Server 2012
  • 64 GB de RAM

Nota: Solo se desconectó la base de datos del sitio; las bases de datos de configuración y supervisión seguían estando accesibles durante la prueba. Esto significa que el Servicio de Monitor estaba consumiendo algo de CPU durante las pruebas.

gráfico que muestra los tiempos de respuesta de inicio de sesión

Generalmente, a medida que aumenta el número de aplicaciones, el tiempo de respuesta de inicio de sesión aumenta y los tiempos de respuesta de interrupción son peores que el funcionamiento normal. Aumentar el número de vCPU mejora los tiempos de respuesta. Tenga en cuenta que la CPU utilizada en las pruebas es bastante antigua y las CPU más modernas generalmente darán un mejor rendimiento.

gráfico que muestra el tiempo para iniciar sesión

La fila ‘min teórico’ es el tiempo mínimo absoluto que tardarían 100 000 usuarios para iniciar sesión si el entorno era capaz de procesar 20 lanzamientos por segundo, dando 1 hora 23 minutos 20 segundos. En estas pruebas, la fila de aplicaciones 0 administró 1:30:57 en el caso de 6 vCPU, y 1:30:48 en el caso de 8 vCPU. El rendimiento del dominio de Active Directory tendrá cierto impacto en la rapidez con la que se autentican los usuarios.

gráfico que muestra el uso de memoria de la memoria de la base de datos local de

En condiciones normales, el uso de la memoria LocalDB aumentará durante el funcionamiento y se mantendrá en esa memoria a menos que haya presión sobre el sistema; cuantos más usuarios se procesen, mayor será la memoria utilizada, hasta el límite de 1 GB. En la primera prueba de VDI, LocalDB no había liberado memoria de la ejecución anterior de RDS. Para las pruebas VDI posteriores, el broker se reinició antes de la prueba y se utilizó menos memoria.

gráfico que muestra el uso de memoria de servicio de alta disponibilidad de caché de host local

gráfico que muestra el uso de la CPU de la caché de host local

Nota: Los valores se han normalizado a la CPU total del sistema, por lo que el 33.33% son dos de cada seis núcleos, el 30% es 2-1/2 núcleos en la configuración de 8 vCPU.

El término “off” se refiere al funcionamiento normal del sitio; “on” significa que la caché de host local está activa.

La tasa de lanzamiento de solicitudes de 20 usuarios por segundo es bastante exigente para el broker, incluso en funcionamiento normal. En funcionamiento normal, el sistema de 6 vCPU no tiene espacio de ampliación; la CPU del broker aumenta a medida que aumenta el número de aplicaciones publicadas, lo que resulta en tiempos de respuesta más lentos. Cuando la caché de host local está activa, el servicio de broker secundario (HA) tiene que competir con LocalDB (SQL) para el recurso de CPU, lo que da tiempos de respuesta peores que la operación normal.

En el sistema de 8 vCPU, hay algo de margen de ampliación y LocalDB se ampliará, pero en este entorno, alcanzó un máximo de 2-1/2 núcleos, a pesar de que todavía hay una pequeña cantidad de CPU disponible.

Durante el funcionamiento normal, LocalDB no consumirá CPU a menos que se produzca una sincronización.

Durante la interrupción, el broker principal no utilizará prácticamente ninguna CPU.

Tamaño de la base de datos

Para la configuración VDI 5075, LocalDB era de alrededor de 40 MB, para los 100 000 RDS esta variaba entre 100-300 MB, dependiendo del número de aplicaciones e inicios de sesión. A medida que se toma una copia de la base de datos antes de iniciar una nueva importación, permita 1 GB de espacio para LocalDB.

Resumen

Durante la interrupción de la base de datos del sitio, la caché de host local admite una gama más amplia de recursos y condiciones que el arrendamiento de conexiones, pero requiere más CPU y memoria al operar.

En varios sitios de broker, cualquier broker puede ser elegido para ser el intermediario de interrupción y, por lo tanto, todos deben tener suficientes recursos para hacer frente al modo de interrupción. No se realiza ninguna evaluación de los recursos de los intermediarios, por lo que en un sitio con intermediarios menores y más poderosos, es posible que el intermediario menos poderoso sea elegido durante la interrupción.

El diseño de los núcleos y zócalos debe considerarse como parte del diseño de los intermediarios.

El número de aplicaciones publicadas tendrá un efecto en los tiempos de respuesta de inicio de sesión y en el rendimiento máximo de inicio de sesión.

Los agentes con recursos de CPU insuficientes pueden provocar errores en los inicios.

Dos núcleos adicionales y 2 GB de RAM son un buen punto de partida para probar el rendimiento en el modo de interrupción de la caché de host local en comparación con el arrendamiento de conexiones.

1 GB de espacio en disco será suficiente para la base de datos LocalDB.

Un broker sobrecargado dará como resultado conexiones fallidas.

Este artículo fue escrito por Joe Deller.