Escalabilidad de un solo servidor de Citrix Virtual Apps and Desktops

Información general

En este artículo se proporcionan recomendaciones y orientación para estimar cuántos usuarios o máquinas virtuales (VM) pueden ser compatibles en un único host físico. Esto se conoce comúnmente como “escalabilidad de un solo servidor” (SSS) de Citrix Virtual Apps and Desktops. En el contexto de Citrix Virtual Apps (CVA) o virtualización de sesiones, también se denomina comúnmente “densidad de usuario”. La idea es determinar cuántos usuarios o máquinas virtuales se pueden ejecutar en una sola pieza de hardware que ejecute un hipervisor importante, como Citrix Hypervisor.

En este artículo, cubrimos varias de las variables o factores que influyen en el SSS de Citrix Virtual Apps and Desktops (CVAD). Proporcionamos recomendaciones y directrices sencillas para estimar rápidamente SSS para un entorno determinado. Concluimos proporcionando algunos ejemplos de tamaño mediante escenarios del mundo real.

¡Advertencia! Este artículo contiene instrucciones para estimar el SSS. Cabe señalar que la orientación es de alto nivel y no necesariamente será específica para su situación o entorno único. La única manera de entender realmente CVAD SSS es utilizar una herramienta de prueba de escalabilidad o carga como Login VSI. Citrix recomienda utilizar esta guía y estas sencillas reglas para estimar rápidamente el SSS. Sin embargo, Citrix recomienda utilizar Login VSI o la herramienta de prueba de carga de su elección para validar los resultados, especialmente antes de comprar hardware o tomar decisiones financieras.

Factores de escalabilidad

Hay muchos factores, parámetros o variables que afectan a SSS. No se trata en absoluto de una lista exhaustiva, pero los siguientes son varios de los principales factores que influyen en el SSS. Aunque hay muchos más factores que influyen en el rendimiento y la escalabilidad, como antivirus y agentes de supervisión, codificación gráfica, vulnerabilidades de seguridad recientes como Spectre y L1 Terminal Fault, los factores que se detallan a continuación suelen tener el mayor impacto en CVAD SSS. Ahora veamos cómo calcular rápidamente CVAD SSS mediante una fórmula simple.

Carga de trabajo

Uno de los principales factores que afectan el rendimiento y la escalabilidad es la carga de trabajo en sí. Algunas cargas de trabajo pueden implicar a los trabajadores de tareas que realizan tareas sencillas de entrada de datos en un servidor CVA. Otras cargas de trabajo pueden implicar desarrolladores que compilen código o ingenieros manipulen modelos 3D a través de Citrix Virtual Desktops (CVD). Estas cargas se denominan comúnmente cargas de trabajo “ligeras” y “pesadas”, respectivamente. Y como verá más adelante en este artículo, este tipo de varianza de carga de trabajo puede tener un impacto dramático en SSS.

Hardware

El hardware físico en el que se ejecutan las cargas de trabajo tiene un impacto directo en SSS. Probablemente no hace falta decirlo, pero un servidor más nuevo equipado con 28 núcleos y 1 TB de RAM será capaz de soportar más usuarios que una pieza de hardware más antigua con solo 12 núcleos y 256 GB de RAM ejecutando una carga de trabajo similar. Y la CPU desempeña un papel especialmente importante en el CVAD SSS como se verá más adelante.

Relación de actividad

Uno de los aspectos a menudo pasados por alto de SSS es la relación de actividad o la frecuencia con la que los usuarios trabajan frente a inactivos. Muchas herramientas de pruebas de escalabilidad adoptan un enfoque conservador y pueden utilizar una proporción de actividad bastante alta como el 80% (lo que significa efectivamente que los usuarios están activos o trabajando el 80% del tiempo y el 20% del tiempo inactivo). Sin embargo, a menudo vemos en el mundo real que las relaciones de actividad están más cerca del 40-60%. Y este tiempo de inactividad adicional puede afectar drásticamente el SSS y la cantidad de hardware que se necesita comprar para soportar un entorno CVAD.

Relación de sobresuscripción de CPU

La mayoría de las cargas de trabajo de CVAD están vinculadas a la CPU, lo que significa que el punto final del agotamiento de los recursos está directamente relacionado con el número de núcleos físicos disponibles en el sistema. Y dado que los usuarios pueden no estar activos el 100% del tiempo y tenemos herramientas como Intel Hyper Threading disponibles (por no hablar de los programadores de CPU del hipervisor son cada vez más eficientes), a menudo podemos “sobrecomprometer” o sobresuscribir recursos como CPU. Y la relación que uno sobresuscribe la CPU también puede afectar a SSS (de una manera positiva o negativa si no se hace con cuidado). Citrix ha descubierto que una relación de sobresuscripción de CPU de 2:1 es a menudo óptima en SSS de CVA. Por ejemplo, si un servidor físico está equipado con chips de doble socket de 20 núcleos (es decir, “2 x 20”), hay 40 núcleos físicos disponibles en total. Y con Hyper Threading habilitado, habría 80 núcleos virtuales o lógicos disponibles. Al aplicar una proporción de 2:1 al número de núcleos físicos (40), recomendamos utilizar 80 núcleos al dimensionar o estimar SSS. Al final de este artículo se proporcionan más ejemplos para ilustrar este concepto con más detalle.

Arquitectura y funciones del microprocesador

La arquitectura de chip y memoria subyacente también puede desempeñar un papel importante en SSS. Además, Intel ha realizado recientemente mejoras significativas en el diseño de la arquitectura del microprocesador subyacente. En los chips más antiguos, como Broadwell y Haswell, Intel conectó procesadores mediante una arquitectura basada en anillos. Pero a medida que aumentaba el número de núcleos, la latencia de acceso aumentaba y el ancho de banda por núcleo disminuía de modo que Intel mitigaría esto dividiendo el chip en dos mitades y agregando un segundo anillo para reducir las distancias. Y esta división invisible era algo que debía tenerse en cuenta en CVAD SSS para proporcionar resultados óptimos. Esto se ha referido en el pasado como “NUMA” o Acceso a la memoria no uniforme. Y la guía principal era asegurarse de que el tamaño de las VM CVA es lo más grande posible, pero no cruzar nodos NUMA, clústeres sub-NUMA o anillos al mismo tiempo. Si ha dimensionado sus VM CVA demasiado grandes y efectivamente se extendieron nodos o anillos NUMA, puede llevar a NUMA “agitando” al acceder a recursos no locales y esto produciría un SSS reducido. Avance rápido hasta hoy e Intel ha pasado de una arquitectura basada en anillos a una arquitectura basada en mallas. Y esta nueva arquitectura de malla introducida en Skylake no tiene las mismas limitaciones que antes donde tenemos que dividir chips, dividir núcleos o agregar anillos. Y esto cambia la forma en que dimensionamos los servidores CVA en particular. Por lo tanto, es importante comprender el chip específico que se está utilizando en el hardware que compra y cómo se diseña y construye la arquitectura del microprocesador subyacente

Los multiplicadores mágicos

Si quiere medir o estimar rápidamente el SSS de CVAD, esta guía es efectiva. Es tan fácil como esto: Tome el número de núcleos físicos en un servidor, multiplique por 5 o 10, y el resultado será su SSS. Si está buscando el número de máquinas virtuales CVD que puede admitir, entonces usaría el “multiplicador mágico” de 5. Si intenta comprender cuántos usuarios de CVA pueden ejecutar en una sola pieza de hardware, usaría 10. Veamos algunos ejemplos del mundo real para ver cómo se aplica esto en la práctica.

Ejemplo 1: Citrix Virtual Desktops

Supongamos que está ejecutando Windows 10 con aplicaciones estándar de Office y algunas aplicaciones personalizadas. Ha identificado que una especificación de máquina virtual de 2 vCPU / 4 GB de RAM funcionaría mejor teniendo en cuenta la carga de trabajo/imagen. Está considerando comprar blades Cisco con 36 núcleos físicos (2x18) y 768 GB de RAM. Y le gustaría entender qué tipo de densidad puede esperar. Vamos a utilizar la Regla de 5 para CVD:

5 x 36 = 180 VM por host

Nota Las cargas de trabajo basadas en VDI y RDSH especializadas de Citrix están limitadas a la CPU el 99,9% del tiempo. La CPU se ha convertido en el cuello de botella de escalabilidad en lugar de la memoria, el almacenamiento en disco o el almacenamiento en red. Estos multiplicadores omiten otras áreas aparte de la CPU porque la CPU se ha convertido en el factor principal. Aunque los hipersubprocesos, las velocidades de reloj y los núcleos virtuales son todos importantes, nada es más importante que el número de núcleos físicos en un servidor. Al utilizar la regla de 5 y 10, es mejor ignorar todos los demás números al principio para hacer el tamaño inicial para evitar confusiones.

Ejemplo 2: Citrix Virtual Apps (hardware antiguo)

Supongamos que está ejecutando una aplicación como SAP en Windows Server 2012 R2 a través de CVA. Está replanteando algunos blades HP antiguos con 24 núcleos físicos (2x12) y 256 GB de RAM. Ha investigado en el sitio web de Intel que el chip subyacente emplea una arquitectura de búfer de anillo y cada socket se divide efectivamente en 2 nodos NUMA con 6 núcleos cada uno. Por lo tanto, la especificación de una máquina virtual con 6 vCPU / 24 GB de RAM parece óptima para maximizar la escalabilidad lineal y minimizar las sacudidas NUMA. Mediante una relación de sobresuscripción de CPU de 2:1, utiliza los 48 núcleos lógicos e implementa 8 servidores XenApp en cada host (48/6 = 8). Uso de la regla de 10 para CVA:

10 x 24 = 240 usuarios por host

Ejemplo 3: Citrix Virtual Apps (hardware más reciente)

Supongamos que está ejecutando una aplicación de atención médica popular en Windows Server 2016 a través de CVA. Está considerando adquirir blades Dell con 32 núcleos físicos (2x16) y 256 GB de RAM. Ha investigado en el sitio web de Intel que el chip subyacente emplea una arquitectura de malla y que existe una directiva empresarial para reducir su huella de VM tanto como sea posible. Usted decide sobre la especificación de una máquina virtual con 16 vCPU / 48 GB de RAM. Mediante una relación de sobresuscripción de CPU de 2:1, utiliza los 64 núcleos lógicos e implementa 4 servidores XenApp en cada host (64/16 = 4). Uso de la regla de 10 para CVA:

10 x 32 = 320 usuarios por host

Como se mencionó anteriormente, nos damos cuenta de que hay muchas más variables o parámetros que influyen en la escalabilidad en comparación con solo el número de núcleos físicos en un servidor. Y puede haber ciertas situaciones en las que la carga de trabajo de CVAD no está vinculada a la CPU, por lo que se requiere cuidado adicional al dimensionar. Además, otros factores que no hemos discutido, como la velocidad del reloj de la CPU y las tormentas de inicio de sesión también importan y complican aún más los ejercicios de dimensionamiento. Sin embargo, a través de años de experiencia en el campo y cientos de implementaciones hemos descubierto que nada importa tanto como el número de núcleos físicos. Si quiere comprender su SSS exacto para su carga de trabajo particular y su entorno único, Citrix recomienda encarecidamente utilizar una herramienta como Login VSI para probar y/o validar correctamente los resultados.

Referencias

Descripción técnica de la familia escalable de procesadores Intel Xeon

Prácticas recomendadas de antivirus

Prueba de carga de VSI de inicio de sesión