Citrix Virtual Apps and Desktops: Zonas, latencia y rendimiento de la intermediación

Zonas

Las implementaciones que abarcan ubicaciones muy dispersas conectadas por una WAN pueden enfrentarse a problemas de latencia y confiabilidad de la red.
En lugar de crear varios sitios, cada uno de los cuales requiere su propia base de datos de sitios de SQL Server que debe administrar por separado, puede configurar zonas dentro de un solo sitio.

Impacto de latencia en la intermediación de rendimiento

Los usuarios finales lanzan recursos todos los días. Con la adición de zonas, los usuarios ahora pueden estar en enlaces de mayor latencia siempre que haya un intermediario local.
La latencia adicional afecta a la experiencia del usuario final. En la mayoría de los trabajos que realizan los usuarios, ven la lentitud esperada que está vinculada a los viajes de ida y vuelta entre los corredores de satélites y la base de datos SQL.

La intermediación de sesiones tiene un punto débil: se debe a la necesidad de elegir el VDA con la carga más baja para lanzar una aplicación.
Se produce dentro de una transacción de base de datos y necesita una instantánea de todas las cargas actuales de los VDA del grupo de entrega.
Se bloquea a todos los trabajadores de un grupo de entrega, lo que impide que otros usuarios (lo que provoca la serialización) acepten los mismos bloqueos. También espera y bloquea los cambios de estado de los trabajadores (como los eventos de sesión).

Con una latencia baja, la demora entre la toma de las cerraduras y su liberación es pequeña. Sin embargo, a medida que aumenta la latencia, aumenta el tiempo que se mantienen los bloqueos y, por lo tanto, aumenta el tiempo dedicado a las sesiones de intermediación.

Hemos analizado diferentes tipos de latencias y tasas de lanzamiento.
Las latencias son los tiempos de ida y vuelta (RTT) y se basaron en las estadísticas de latencia IP de Verizon . La mayoría de los RTT son inferiores a los valores máximos listados, pero queríamos asegurarnos de que estábamos realizando pruebas con algunos RTT útiles.

Los tiempos de ida y vuelta de 10 milisegundos (ms) cubren la mayoría de los retrasos entre países, 45 ms cubren Norteamérica, Europa y Japón, 90 ms cubren el transatlántico, 160 ms cubren el Transpacífico, América Latina y Asia Pacífico y 250 ms cubren la región EMEA a Asia Pacífico.

Probamos con diferentes tipos de solicitudes simultáneas, cubriendo valores de 12 a 60 en incrementos de 12.

Nota: Las sesiones de VDA se simulan, ya que las pruebas se centran en el impacto de la latencia en el broker. Para esta prueba, hay 57 VDA dentro de un grupo de entrega. Cada prueba intentó iniciar 10 000 usuarios.

Resultados de RTT de 10 ms          
Solicitudes simultáneas 12 24 36 48 60
Tiempo medio de respuesta (segundos) 0.9 1.4 1.6 2.1 2.6
Solicitudes de intermediación con broker por segundo 14 17.8 22.9 23.2 22.9
Errores (%) 0 0 0 0 0
Tiempo para iniciar 10 000 usuarios 11m 57s 9m 24s 7m 16s 7m 11s 7m 17s

Como era de esperar, 10 ms es lo suficientemente rápido como para manejar las cargas colocadas en el sistema y no hubo errores. Esta es la forma más rápida de lanzar usuarios. A la velocidad máxima de lanzamiento de 60 usuarios simultáneos, los tiempos de respuesta promedio fueron de 2,6 segundos, tomando 7 minutos y 17 segundos para iniciar los 10 000 usuarios.

Resultados de RTT de 45 ms          
Solicitudes simultáneas 12 24 36 48 60
Tiempo medio de respuesta (segundos) 1.7 3.1 4.3 6.4 7.3
Solicitudes de intermediación con broker por segundo 7.1 7.8 8.4 7.5 8.2
Errores (%) 0 0 0 0.01 0.01
Tiempo para iniciar 10 000 usuarios 23m 28s 21m 19s 19m 51s 22m 15s 20m 19s

Con 45 ms, los resultados seguían siendo buenos. A las tasas de lanzamiento muy altas, uno o dos usuarios vieron un error.

Nota: El impacto de la serialización se puede observar en los tiempos de respuesta, con un aumento de 1,7 segundos a 7,3 segundos para negociar una sesión. El tiempo total para negociar a 10 000 usuarios fue de 20 a 23 minutos.

Resultados de RTT de 90 ms          
Solicitudes simultáneas 12 24 36 48 60
Tiempo medio de respuesta (segundos) 2.9 6.4 9.5 12.9 16.2
Solicitudes de intermediación con broker por segundo 4.1 3.7 3.8 3.7 3.7
Errores (%) 0 0 0 0.01 0.01
Tiempo para iniciar 10 000 usuarios 40m 30s 44m 29s 44m 11s 44m 55s 45m 04s

Los resultados de 90 ms mostraron pocos errores.
El impacto de las transacciones por encima de la latencia se hace más evidente, ya que los usuarios ven un tiempo promedio aceptable de 2,9 segundos para intermediar una sesión con 12 solicitudes simultáneas, que aumenta a 16,2 segundos, lo que es inaceptable para negociar una sesión con 60 solicitudes simultáneas.
En este caso, es más ventajoso para los usuarios de corredores a un precio más bajo. Se necesitaron entre 40 y 45 minutos para lanzar a los 10 000 usuarios.

Resultados de RTT de 160 ms          
Solicitudes simultáneas 12 24 36 48 60
Tiempo medio de respuesta (segundos) 5.7 11.4 17.3 23.2 28.0
Solicitudes de intermediación con broker por segundo 2.1 2.1 2.1 2.1 2.1
Errores (%) 0 0 0.12 4.0 17.7
Tiempo para iniciar 10 000 usuarios 1 h 19 min 0 s 1 h 19 min 27 s 1 h 19 min 55 s 1 h 20 min 26 s N/D

Con los 160 ms, comenzamos a ver errores significativos con tasas de lanzamiento más altas, con un 4% de errores en 48 solicitudes y un 17,7 por ciento de errores en 60 solicitudes, junto con tiempos de respuesta que se acercan a los 30 segundos.
Sin embargo, hasta 36 solicitudes, la tasa de error es del 0,1 por ciento con un tiempo promedio de intermediación de 17 segundos.

Nota: Es difícil juzgar el tiempo de lanzamiento de 60 solicitudes, ya que es difícil tener en cuenta el fracaso del 17 por ciento.

Con esta latencia, recomendamos no pasar 24 solicitudes simultáneas. Además, el tamaño del Sitio puede ser un factor: el lanzamiento de 1000 usuarios en llevaría unos 8 minutos. Esto ampliaría hasta 1 hora y 20 minutos para 10 000 usuarios. Por lo tanto, no recomendaríamos un sitio grande con este nivel de latencia para la base de datos.

Resultados de RTT de 250 ms          
Solicitudes simultáneas 12 24 36 48 60
Tiempo medio de respuesta (segundos) 9.3 15.4 26.7 - -
Solicitudes de intermediación con broker por segundo 1.3 1.6 1.3 - -
Errores (%) 0 0 4.6 42.8 99.0
Tiempo para iniciar 10 000 usuarios 2 h 8 min 33 s 1 h 46 min 52 s 2 h 3 min 46 s N/D N/D

Con una latencia tan alta, se produjeron muchos tiempos de espera con tasas de lanzamiento simultáneas más altas. Con 48 solicitudes, el 42.8 por ciento de las solicitudes fallaron. En 60 solicitudes, los tiempos de espera eran tan comunes que el sitio no sería utilizable, ya que el 99 por ciento de las solicitudes fallaban. Las únicas tasas de lanzamiento aceptables fueron 12 y 24 solicitudes. Sería difícil recomendar la implementación de un sitio grande con este nivel de latencia: el lanzamiento de 1000 usuarios tomó 13 minutos con 12 solicitudes simultáneas y 11 minutos con 24 solicitudes simultáneas. Tomaría hasta 2 horas y 8 minutos para 10 000 usuarios.

Limitar solicitudes

Si necesita trabajar con una latencia alta y descubre que se agotan demasiados tiempos de espera, se agregó una clave de registro a XenApp y XenDesktop 7.7 para que puedan gestionar solo un número fijo de solicitudes de intermediación simultáneas. StoreFront volverá a intentar las solicitudes por encima del límite transcurridos unos segundos. Esto ayuda a retrasar las solicitudes y, por lo tanto, reduce las colas de bloqueo. Sin embargo, algunos usuarios pueden terminar viendo tiempos de lanzamiento prolongados, ya que siempre tienen mala suerte y su solicitud siempre se rechaza.

La clave es un DWORD y debe almacenarse en: HKEY_LOCAL_MACHINE\Software\Citrix\DesktopServer\ThrottledRequestAddressMaxConcurrentTransactions

Si la clave no existe, no se establece ningún límite en las solicitudes de intermediación.

Nota: La clave es por Delivery Controller, por lo que el total de solicitudes en SQL Server debe dividirse entre los Controllers remotos.

Resumen

La intermediación funciona sobre la latencia, pero debe tenerse en cuenta la latencia para dimensionar una zona remota. Si una zona es grande, aún puede ser conveniente mantener una base de datos local en esa zona. Si la zona es pequeña, el uso de una zona remota puede funcionar bien y también reducir los costos de administración sin afectar a la experiencia del usuario final.

Le recomendamos que sus zonas tengan un RTT inferior a 250 ms; más allá de eso, debería considerar la posibilidad de configurar diferentes sitios.

Este artículo ha sido modificado de una publicación de blog escrita por Chris Gilbert. Para leer el blog original y ver los comentarios, vaya a https://www.citrix.com/blogs/2016/02/09/zones-latency-and-brokering-performance-2/.

Citrix Virtual Apps and Desktops: Zonas, latencia y rendimiento de la intermediación