Dimensionar las instancias de VDA en Google Cloud Compute Engine

Introducción

Este documento proporciona orientación económica y escalabilidad de instancia única para las empresas que implementan cargas de trabajo de Citrix (VDA) en Google Cloud Compute Engine. La atención se centra en las cargas de trabajo compartidas alojadas (VDA de Windows Server con la función RDSH instalada) que se ejecutan en instancias de VM de Google Compute Engine. Las pruebas de escala se realizaron utilizando una carga de trabajo sintética pesada y reproducible, con el objetivo de proporcionar una orientación conservadora pero procesable. Terminamos con una guía de dimensionamiento para Google Cloud VMware Engine.

Resumen ejecutivo

Los hallazgos de este estudio sugieren lo siguiente:

  • Para un gran porcentaje de casos de uso (cargas de trabajo), el rendimiento de un VDA de Citrix tiende a estar limitado por la CPU, el disco o la red.
  • Los procesadores más recientes disponibles en Google Cloud en el momento de la publicación proporcionaron la mejor experiencia del usuario final (según la medición, dada nuestra gran carga de trabajo de referencia). Están disponibles en las familias de instancias N2, N2D y C2, y aprovechan los procesadores Cascade Lake de Intel y Milán de AMD.
  • La familia de máquinas virtuales Tau de Google no estaba disponible para esta prueba, pero probablemente valga la pena considerarlas para las cargas de trabajo de Citrix VDA.
  • Los tamaños de instancia de 4 vCPU y 8 vCPU tendían a ofrecer la mayor densidad y los costes más bajos por usuario.
  • Para nuestra pesada carga de trabajo de pruebas, el tipo de instancia N2D-Standard-8 (con el procesador AMD Milan) era el más rentable, ya que ofrecía costes tan bajos como 0,028 USD por hora de usuario según los precios publicados.
  • Con los procesadores más recientes, el tipo de almacenamiento que se usa para el disco persistente no tiene un impacto importante en la escalabilidad de la instancia.
  • Si bien no se han probado explícitamente como parte de este estudio, las cargas de trabajo que requieren una GPU deben ejecutarse en los tipos de instancia N1. Cuando la aceleración de la GPU es un requisito, aprovechar los procesadores Skylake y el almacenamiento en disco persistente SSD Premium probablemente producirá el mejor rendimiento y la mayor escalabilidad.

Consideraciones de capacidad

En esta sección, analizamos algunos de los factores clave que afectan la escalabilidad de un solo servidor, como la carga de trabajo, el sobrecompromiso de la CPU, la arquitectura del procesador y la selección de almacenamiento.

La selección de carga de trabajo utilizada para las pruebas debe aproximarse a los usuarios de su entorno. Por ejemplo, si el 50% de los usuarios generan una carga de usuarios ligera y el 30% de los usuarios generan una carga moderada y el 20% restante genera una carga de trabajo pesada, entonces usar una carga de trabajo moderada le daría una idea aproximada de lo que puede esperar. Sin embargo, si tuviera un entorno en el que el 20% de los usuarios generan una carga de usuario ligera y el 80% genera una carga de trabajo pesada, el uso de una carga de trabajo pesada le proporcionaría la mejor aproximación.

La situación ideal es realizar pruebas de escalabilidad con su propia carga de trabajo, en lugar de confiar en los números de escalabilidad derivados de nuestras pruebas. Una característica útil de Login Enterprise es que puede crear fácilmente sus propias cargas de trabajo personalizadas o crear una carga de trabajo a partir de los flujos de trabajo de aplicaciones proporcionados de forma inmediata. Para esta prueba, queríamos seleccionar una carga de trabajo que fuera representativa de la mayoría de los usuarios y proporcionara datos relevantes para la comparación, a la vez que proporcionáramos estimaciones conservadoras para aquellas empresas que no realizan pruebas de escalabilidad en sus propias cargas de trabajo.

Otra consideración es la proporción de usuarios con respecto a las vCPU en una instancia. Esta relación se expresa en función del número de usuarios esperado respecto al número de vCPU presentes en la máquina virtual. Por ejemplo, si esperamos 2 usuarios por cada vCPU, la proporción se expresaría como 2:1. Dado que las cargas de trabajo de CVAD hacen un uso intensivo de la CPU, la tasa de sobreasignación se usa comúnmente para realizar estimaciones y la proporcionamos para los tipos de instancias recomendados. La cantidad de usuarios por CPU virtual puede variar según la carga de trabajo, la arquitectura del procesador de la CPU o incluso la cantidad de memoria disponible en un host.

La arquitectura del procesador también tiene un impacto en los resultados de escalabilidad, como cabría esperar con las cargas de trabajo con uso intensivo de CPU. Uno de los objetivos de este estudio fue determinar qué familias y formas de instancias de procesamiento son las más rentables en Google Cloud. En igualdad de condiciones, los procesadores más rápidos suelen proporcionar más usuarios por instancia que los procesadores más lentos, pero normalmente tienen un coste adicional.

El tipo y el tamaño del almacenamiento utilizado para el disco persistente en la máquina virtual pueden afectar la escalabilidad de un solo servidor porque el disco local se usa para intercambiar memoria y almacenar perfiles de usuario. Los discos más rápidos reducen la latencia del disco, lo que lleva a operaciones de lectura/escritura más rápidas. Si un disco se queda sin espacio para almacenar perfiles de usuario o tiene una latencia prolongada en los tiempos de recuperación de intercambio de memoria, el rendimiento general del host se degradará. El uso del almacenamiento SSD Premium para discos persistentes en Google Cloud debería minimizar los cuellos de botella de almacenamiento y garantizar que estamos probando el procesamiento del tipo de instancia y no el almacenamiento. Para evaluar el almacenamiento, mantenemos el tipo de instancia estático y variamos el tipo de disco.

Otro factor es la velocidad de lanzamiento de las sesiones. Si las sesiones se inician rápidamente (por ejemplo, 1 sesión cada 10 segundos) y moderadamente (1 sesión por minuto), encontrará resultados diferentes. Las tormentas de inicio de sesión provocarán estrés en el entorno y siempre debe tener la capacidad suficiente para soportar los períodos de inicio de sesión pico. Sin embargo, las pruebas de escalabilidad generalmente se realizan a una velocidad de inicio de sesión moderada de una sesión cada 30 segundos o 60 segundos, según la intensidad de la carga de trabajo. Los intervalos más largos proporcionan una visión más precisa del número de sesiones activas que se pueden admitir en un estado estable.

Entorno de pruebas

Para las pruebas de escalabilidad, las máquinas virtuales de infraestructura se configuraron de la siguiente manera:

  • Dispositivo virtual One Login Enterprise que ejecuta la versión 4.5.11
  • Cuatro lanzadores de Login Enterprise que se ejecutan en instancias e2-standard-2 con un intervalo de inicio de sesión de 1 minuto
  • Un Citrix Cloud Connector
  • Un controlador de dominio de Active Directory que actúa también como servidor de perfiles y servidor DNS

Las cargas de trabajo de Citrix se ejecutaron en una sola instancia de Windows Server 2019 Datacenter con el siguiente software configurado:

  • Función RDSH de Microsoft instalada, incluida la experiencia de escritorio
  • VDA de SO multisesión de Citrix Server 2103.0.0.29045
  • Microsoft Office 2019
  • Microsoft Defender con configuración predeterminada
  • Actualizaciones más recientes de Windows disponibles en el momento de la prueba (septiembre de 2021)
  • Se usaron configuraciones listas para usar a menos que se especifique lo contrario

Tipos de instancias

Para este estudio, primero seleccionamos familias de máquinas en las que esperábamos tener el uso más eficiente de los recursos, incluidas las siguientes:

  • N1 (Intel Skylake de uso general compatible con GPU)
  • N2 (lago en cascada Intel de uso general)
  • N2D (AMD de uso general)
  • C2 (carga de trabajo optimizada para computación Intel Cascade Lake)
  • E2 (Intel Skylake con costes optimizados)

Nota:

Las instancias T2D de la serie Tau de Google no estaban disponibles en el momento de la prueba, pero según los resultados que se detallan aquí, tenemos grandes expectativas para ellas.

Comenzamos evaluando las versiones de 8 vCPU de las familias de máquinas seleccionadas y evaluamos los resultados para determinar los mejores resultados. Luego, fuimos un paso más allá y evaluamos las versiones de 4 vCPU y 16 vCPU en esas familias de máquinas. Se realizaron ejecuciones de prueba en los siguientes tipos de instancias de máquinas virtuales:

  • n1-estándar-8 (Skylake)
  • n1-alta cpu-8 (Skylake)
  • n1-highmem-8 (Skylake)
  • n2-standard-8 (Lago Cascade)
  • c2-standard-4 (Lago Cascade)
  • c2-standard-8 (Lago Cascade)
  • c2-standard-16 (Lago Cascade)
  • e2-estándar-8 (Skylake)
  • n2d-standard-4 (Roma)
  • n2d-standard-8 (Roma)
  • n2d-standard-16 (Roma)
  • n2d-standard-4 (Milán)
  • n2d-standard-8 (Milán)
  • n2d-standard-16 (Milán)

Aprendimos desde el principio que las versiones de 2 vCPU de las familias de máquinas no son adecuadas para nuestra pesada carga de trabajo de referencia. Por este motivo, nuestras pruebas se centraron en las formas de instancia de 4 vCPU, 8 vCPU y 16 vCPU.

Las sesiones de usuario se simularon con Login Enterprise en cada tipo de instancia en diferentes ejecuciones de prueba para analizar la escalabilidad de los diferentes tipos y formas de instancias de máquinas virtuales.

Arquitectura de laboratorio

Toda la infraestructura para la intermediación y administración de sesiones la proporcionó el servicio Citrix Cloud Virtual Apps and Desktops. Se instalaron un controlador de dominio de Active Directory y Cloud Connector en una VPC, lo que creó una ubicación de recursos en Google Cloud. La siguiente figura muestra la arquitectura de prueba.

Arquitectura de laboratorio

Nota:

Las instancias N2 y N2D no estaban disponibles en la región US-West2, por lo que se crearon en la región US-West1.

Carga de trabajo de trabajador del conocimiento empresarial con puntuación de experiencia de usuario final (EUX)

Esta versión de Login Enterprise proporciona una forma de construir el flujo de trabajo de un usuario virtual en una carga de trabajo común de trabajadores del conocimiento de Office 365. En estrecha colaboración con Login VSI, esta prueba también utilizó un sistema de puntuación experimental llamado puntuación EUX. La puntuación EUX es una forma de cuantificar la capacidad de respuesta de la experiencia o sensación de un usuario en una sesión de escritorio o aplicación. El flujo de trabajo de este usuario incluye las siguientes aplicaciones:

  • Iniciar sesión Aplicación VSI EUX Score
  • Microsoft Outlook
  • Microsoft Word
  • Microsoft Excel
  • Microsoft PowerPoint
  • Microsoft Edge
  • YouTube

Login Enterprise Knowledge Worker es una carga de trabajo pesada e intensiva de CPU cuando se usa al 100% de simultaneidad, y permite una media de 2 usuarios por CPU virtual en las instancias de nube probadas.

Varias veces durante la sesión, la aplicación de puntuación EUX ejecuta un conjunto de instrucciones y registra el tiempo que lleva ejecutar cada paso. Los resultados se pueden utilizar para generar la puntuación EUX de una sesión. Quienes estén familiarizados con la aplicación Login VSI heredada encontrarán estas operaciones familiares.

La puntuación máxima teórica de EUX es de 10, sin embargo, la puntuación es más útil en comparación con sí misma en diferentes cargas de trabajo. Por ejemplo, si observamos la misma carga de usuarios en un c2-standard-8 con un promedio de puntuación EUX de 7,59, vemos este gráfico en el que la línea continua representa la instancia n2d-standard-8 y la línea discontinua representa la instancia c2-standard-8. El gráfico muestra claramente la instancia n2d-standard-8, con una puntuación EUX promedio de 8,07, superando a la instancia c2-standard-8 durante toda la prueba. También puede ver cómo la puntuación baja ligeramente a medida que el sistema se vuelve ocupado.

Línea de tendencia EUX Score

La puntuación media de EUX, aunque no es una representación perfecta de toda la ejecución de la prueba, sí que proporciona un indicador de cómo es probable que se desempeñe una configuración en particular en las condiciones de carga de trabajo. La siguiente tabla muestra las puntuaciones de EUX para diferentes configuraciones de tipos de máquinas para un solo usuario que ejecuta la carga de trabajo de EUX.

vCPU Memoria (GiB) Puntaje EUX (usuario único)
  N2D-Standard-4-Milán AMD 4 16 8.61
  N2D-Standard-8-Milán AMD 8 32 8.54
  C2-Standard-8-Cascade Lake 8 32 8.5
  C2-Standard-16-Cascade Lake 16 64 8,4
  N2D-Standard-16-Milán AMD 16 64 8.35
  C2-Standard-4-Cascade Lake 4 16 8.13
  n1-highmem-8-Skylake 8 42 7.75
  n1-standard-8-Skylake 8 30 7.7
  AMD N2D-Standard-8-Roma 8 32 7.7
  N2D-Standard-16-Roma AM 16 64 7.7
  n1-highcpu-8-Skylake 8 7.2 7.56
  Lago Cascade N2-Standard-8-Cascade 8 32 7.56
  e2-standard-8-Broadwell 8 32 7.45
  AMD N2D-Standard-4-Roma 4 16 7.29

Cuando se usa sola para un solo usuario, la puntuación EUX proporciona un indicador relativamente bueno del potencial de rendimiento máximo de la máquina virtual para la carga de trabajo de prueba. Desafortunadamente, la puntuación EUX no proporciona datos suficientes para determinar el número de usuarios que admite un tipo de instancia en particular. Para ello, necesitamos medir y evaluar criterios adicionales, como la utilización de la CPU y los nuevos contadores de rendimiento de demora de entrada de usuario de Windows.

Método de puntuación

Analizar los resultados de las pruebas en cualquier sistema es siempre un desafío y requiere un análisis de múltiples componentes dentro del sistema. Dado que utilizamos la misma prueba en cada host, los resultados de las pruebas son lo suficientemente consistentes como para poder realizar una comparación entre las configuraciones de la instancia. Para obtener una cantidad estimada de usuarios que admitiría un tipo de instancia en particular, también medimos dos contadores de rendimiento clave: utilización de la CPU y demora de entrada del usuario.

Utilización de la CPU: este contador (Procesador (_Total)% de tiempo de procesador) mide el porcentaje de tiempo transcurrido en el que todas las vCPU del procesador están ocupadas ejecutando tareas de subprocesos no inactivos. La utilización de la CPU ha sido históricamente uno de los mejores indicadores de la experiencia del usuario porque a medida que la utilización de la CPU se acerca a la carga completa, la experiencia del usuario se degrada rápidamente.

Para este análisis, se calculó una media móvil de un minuto en función del tiempo total del procesador. Observamos el número de usuarios en el sistema cuando la media móvil alcanzó el 85% y nuevamente el 90%.

Demora de entrada del usuario: Este contador (Demora de entrada del usuario por sesión (máx.)\ Demora máxima de entrada) mide el tiempo que tarda el usuario en salir de la cola y procesarla. Este contador es un buen indicador de la experiencia del usuario porque el retraso es algo que el usuario notará cuando alcance más de un segundo.

Para este análisis, se calculó una media móvil de un minuto en función de la demora máxima de usuario experimentada por cualquier usuario en el host de la sesión. Por ejemplo, si 3 usuarios estuvieran en el sistema y los tres experimentaran retrasos de usuario, el usuario con el retraso de entrada más alto sería el seleccionado para la media móvil. Observamos el número de usuarios en el sistema cuando la media móvil de la peor experiencia alcanzó un retraso de 1 segundo (1000 ms) y nuevamente cuando alcanzó un retraso de 2 segundos (2000 ms). Recuerde que no todos los usuarios experimentarían este tipo de retraso, pero cualquier usuario es suficiente para garantizar una llamada al servicio de asistencia cuando un retraso de 2 segundos es común para todos los movimientos del ratón y el teclado.

Estos dos rangos nos proporcionaron puntos de datos sobre el número de usuarios que un tipo de instancia podía admitir.

Número mínimo de usuarios: se calcula comparando el número de usuarios con un uso de CPU del 85% y el retardo de entrada de usuario de 1 segundo y seleccionando el número más bajo. Número máximo de usuarios: se calcula comparando el número de usuarios con un uso de CPU del 90% y el retardo de entrada de usuario de 2 segundos y seleccionando el número más bajo.

Usuarios esperados

Antes de determinar los costes esperados, primero teníamos que determinar cuántos usuarios se ejecutan correctamente en un tipo de instancia. Esto resultó ser un poco más difícil de lo esperado originalmente porque el sistema de puntuación EUX no nos indicaba el número total de usuarios que podían caber en el sistema antes de que el rendimiento se degradara a un nivel inaceptable, sino la experiencia en general de todos los usuarios del sistema.

Mediante la combinación de los contadores de utilización de la CPU y retardo de entrada del usuario, tal como se describió anteriormente, pudimos identificar el rango de usuarios esperados en un tipo de instancia en particular. Es cierto que la elección de los límites métricos (85-90% de CPU y retardos de entrada de 1-2 segundos) parece un poco arbitraria, pero para nuestros propósitos proporciona un punto de referencia para usar en combinación con la puntuación EUX. Al final, decidimos usar el número más conservador para los usuarios esperados mediante el siguiente cálculo:

Usuarios esperados: se calcula tomando el valor mínimo de cada uno de los siguientes para una ejecución de prueba que superó con un 99% o más:

  1. Usuarios que inician sesión durante la ejecución de la prueba
  2. Los usuarios iniciaron sesión cuando la media móvil de 1 minuto de UID máximo estaba por encima de 1 segundo
  3. Los usuarios iniciaron sesión cuando la media móvil de 1 minuto de UID máximo estaba por encima de 2 segundos
  4. Los usuarios iniciaron sesión cuando la media móvil de 1 minuto de la CPU superaba el 85%
  5. Los usuarios iniciaron sesión cuando la media móvil de 1 minuto de la CPU superaba el 90%

Costos esperados

Los siguientes gráficos muestran el coste por usuario por hora de cada una de las instancias de 8 vCPU probadas en este estudio. Todos los hosts tienen un precio con un disco de rendimiento de 100 GB y los costes de licencia de Windows correspondientes se incluyen en el total.

Comparación de la familia de 8 vCPU

Como puede ver en los datos, las configuraciones de familias de máquinas más rentables para esta carga de trabajo son el estándar c2 (Cascade Lake), el estándar n2d (Roma) y el estándar n2d (Milán). Pudimos lograr un coste total de procesamiento y almacenamiento de 0,028 USD por hora por usuario con la configuración n2d-standard-8 (Milán) utilizando los costes de máquina para la región US-Central1 a partir del 1 de noviembre de 2021.

Recomendaciones informáticas

Como se mencionó anteriormente, cuando hablamos de las proporciones de usuarios a vCPU, estos son los resultados de nuestros principales competidores de nuestras pruebas:

Usuarios esperados por vCPU

Como puede ver en el gráfico, las instancias de 4 vCPU y 8 vCPU pueden alcanzar y superar el objetivo de 2 usuarios por vCPU, con la n2d-standard-8 Milan a la cabeza. Una conclusión clave interesante aquí es que las instancias de 16 vCPU tienen menos usuarios por vCPU de lo esperado. Esto nos sorprendió tanto como a usted ahora, ya que normalmente esas instancias más grandes tienen mejores números de escala que este. Sin embargo, para esta carga de trabajo en estos tipos de instancias, vamos a seguir recomendando las instancias de 4 u 8 vCPU que obtienen más de 2 usuarios por tipo de instancia.

En términos generales, los procesadores de última generación deberían proporcionar la mejor escalabilidad en una carga de trabajo con uso intensivo de la CPU, como el Knowledge Worker que utilizamos para este estudio. Los tipos que cuentan con el mayor número de usuarios por CPU virtual incluyen dos generaciones de chips AMD EPYC (Roma y Milán) y solo el último procesador Intel (Cascade Lake), esto se debe a que solo elegimos incluir los 3 tipos de mejor rendimiento.

Resulta que pudimos proporcionar algunos números comparativos entre las generaciones de procesadores cuando los tipos de instancia ofrecían la posibilidad de elegir entre los dos tipos de procesadores. Desafortunadamente, esto significó que no pudimos comparar los procesadores Cascade Lake que se ejecutan en instancias N2 o C2 directamente con las generaciones anteriores que se ejecutan en instancias N1. Sin embargo, pudimos comparar los procesadores Broadwell y Skylake de Intel, así como los procesadores EPYC de Roma y Milán de AMD. La siguiente tabla muestra la comparación de procesadores.

Comparación de procesadores

Como muestra el gráfico, la tendencia general es que las últimas generaciones proporcionen el mejor rendimiento. Una ventaja de Google Cloud es que puede elegir la generación de procesadores para los tipos de máquinas N1 y N2D y los costes siguen siendo los mismos independientemente de la selección del procesador, por lo que, a menos que necesites o quieras ese procesador de la generación anterior, asegúrate de configurar la generación de procesadores vCPU a la última.

Si bien los procesadores Cascade Lake son la última generación de Intel y es probable que tengan el mejor rendimiento, ya que la prueba hace un uso intensivo de la CPU, es posible que no siempre quiera optar por la última generación. Aunque no se muestra en este gráfico, un hallazgo extraño es que el procesador Broadwell superó ocasionalmente a los procesadores Skylake más nuevos en el n1-standard-8. Creemos que esto es posible para aplicaciones que tienen gráficos intensivos porque los procesadores Broadwell admiten memoria de cuatro canales, mientras que los procesadores Skylake solo admiten memoria de doble canal.

También hay factores no relacionados con el desempeño que se deben considerar. Además del rendimiento de un procesador en la carga de trabajo, se debe tener en cuenta lo siguiente al elegir las familias de máquinas y la configuración:

GPU virtual: si tiene una carga de trabajo que requiere una GPU, la única familia de máquinas que probamos que admite una GPU es la familia N1.

Disponibilidad: no todas las generaciones de procesadores ni siquiera las familias de máquinas están disponibles en cada región. Observe las regiones en las que desea implementar y determine qué opciones de procesamiento tiene antes de decidirse por una configuración de máquina virtual en particular.

Costo: los costes varían según la región. Para este documento, utilizamos la región US-Central1 para toda la información de costes porque normalmente tiene los costes más bajos y tendrá todos los tipos de máquinas disponibles. En algunos casos, es posible que los descuentos por compromiso de uso no estén disponibles en ciertas regiones.

Consideraciones de almacenamiento

Google Cloud ofrece diferentes tipos de almacenamiento en bloque para usar en discos persistentes en instancias informáticas, cada uno con un conjunto de criterios de rendimiento para las necesidades de las aplicaciones. Durante este estudio, probamos los tres tipos más ampliamente disponibles: Estándar, Equilibrado y SSD.

|Menor coste|<——>|Mayor rendimiento| |—|—|—| |Estándar|balanceado|SSD| Big computación/big data, análisis de registros, discos fríos|La mayoría de las aplicaciones empresariales, bases de datos simples, aplicaciones LOB de estado estable, discos de arranque|La mayoría de las bases caché persistente, análisis de escalamiento horizontal| |1200 IOPS, rendimiento de 2000 MiB/s |80 000 IOPS, rendimiento de 1200 MiB/s | 100 000 IOPS, rendimiento de 1200 MiB/s | |0,04 USD por GIB|0,10 USD por GIB|0,17 USD por GIB|

Realizamos una serie de pruebas en diferentes familias de máquinas de 8 vCPU, C2, N2D y N1, en las que variamos los tipos de discos, pero mantuvimos constante la potencia de procesamiento. Esas pruebas nos permitieron hacer una comparación rápida entre discos estándar, balanceados y SSD. Los resultados se muestran en la tabla siguiente.

Comparación de tipos de discos

Una de las cosas más interesantes que se destaca de este gráfico es que cuanto más rápida sea la vCPU, es menos probable que el tipo de disco tenga un impacto en el número esperado de usuarios. Por ejemplo, las familias de máquinas C2 y N2D tuvieron muy poco impacto al cambiar el tipo de disco, pero la familia N1 observó una diferencia significativa (casi un 33% de aumento) en la escalabilidad. Sin embargo, tenga en cuenta que el disco estándar cuesta menos de la mitad del coste del disco balanceado y menos de una cuarta parte del coste de un disco SSD, por lo que si el rendimiento es el mismo, los costes de almacenamiento más bajos pueden valer la pena a largo plazo.

Los datos de nuestras pruebas de carga de trabajo específicas muestran que si el coste es la principal preocupación al migrar a GCP, el uso de discos menos costosos no afectará significativamente el rendimiento de las últimas generaciones de procesadores. Sin embargo, los resultados con la carga de trabajo pueden variar, por lo que le recomendamos encarecidamente que pruebe su carga de trabajo antes de comprometerse con una arquitectura en particular.

Uso de la puntuación EUX

Aunque este documento no utilizó completamente el algoritmo de puntuación EUX, descubrimos que tenía una alta correlación con los contadores de rendimiento que analizamos. Terminamos utilizando los tres puntos de datos (puntuación EUX, utilización de CPU y demora de entrada del usuario) para calcular nuestros usuarios esperados. El siguiente gráfico proporciona una visión de cómo varían las puntuaciones de EUX entre un solo usuario del sistema y la puntuación de EUX según nuestra carga de usuarios esperada.

Comparación de puntuación EUX

Como puede ver, con la única excepción de que el Broadwell E2-Standard-8 obtuvo 6,93, todos los puntajes de EUX están por encima de 7,0. Realizamos más de 300 pruebas durante este análisis y en todas las carreras en las que la puntuación EUX estaba por debajo de 7.0, pudimos identificar inmediatamente la causa de la puntuación EUX más baja. La mayoría de las veces, la utilización de la CPU fue superior al 90% o el retraso máximo de entrada del usuario superó los 2 segundos.

Nos gustaría ir más allá al decir que, si bien una puntuación EUX de 7,0 es la puntuación aceptable más baja absoluta, es posible que los usuarios tampoco estén satisfechos con ese nivel. Una buena regla general deducida de nuestras pruebas es la siguiente:

La puntuación EUX obtenida de un sistema cargado con el número esperado de usuarios debe ser superior a 7,0 y la puntuación EUX de un solo usuario menos medio punto.

Guía de escalabilidad para Google Cloud VMware Engine

A la fecha de publicación, Citrix Engineering acababa de completar las pruebas necesarias para que Google Cloud VMware Engine (GCVE) se considerara una plataforma con soporte oficial para la virtualización de Citrix. Citrix no había completado ninguna prueba de escalabilidad formal para GCVE. Dicho esto, GCVE es un servicio administrado de Google que proporciona centros de datos definidos por software (SDDC) con tecnología de VMware basados en la arquitectura Cloud Foundation (VCF) de VMware. Dado que VMware, sus clientes y sus socios han estado implementando Citrix en sistemas basados en VCF durante muchos años, ya hay una gran cantidad de conocimientos disponibles con una correlación directa con GCVE.

Por ejemplo: GCVE está disponible actualmente en un tipo de nodo denominado ve1-standard-72. Este tipo de nodo tiene 36 núcleos físicos (72 núcleos hipersubprocesos) y 768 GB de RAM. Al calcular una carga de trabajo de escritorio compartido alojado en Windows Server 2019 con el VDA de SO de servidor y una configuración de SDDC de 3 nodos, tendrá un total de 108 núcleos físicos disponibles o 216 vCPU con hiperproceso. Como referencia, normalmente vemos la escalabilidad más eficiente con un VDA de SO de servidor Citrix con una configuración de 4 vCPU (2 núcleos físicos) y suficiente memoria para admitir la carga de trabajo del usuario. Después de reservar algunos recursos de computación y memoria para el host de VMware, esperamos que cada nodo de GCVE pueda alojar cómodamente alrededor de 17 instancias de Citrix VDA, cada una con 4 vCPU y 36 GB de RAM.

Si está familiarizado con la “Regla de 5 y 10” deNick Rintalan, que proporciona una guía de escalabilidad de un solo servidor para los centros de datos locales, recordará sus recomendaciones de unos 10 usuarios de sesión CVAD por núcleo físico. Como los servidores GCVE tienen hiperprocesos, una máquina virtual de 4 vCPU utiliza 2 núcleos físicos por cada host de sesión de Citrix. La aplicación de la regla de 10 para los hosts de sesión CVAD significa que podemos esperar unos 20 usuarios por VM con una carga de trabajo ligera. Para una carga de trabajo pesada, ese número es aproximadamente la mitad o unos 10 usuarios por VM.

Estos cálculos se utilizan para identificar el número aproximado de usuarios que se esperan dentro del clúster de GCVE y cambiarán en función de una carga de trabajo en particular. Le recomendamos encarecidamente que pruebe su propia carga de trabajo y tome una decisión sobre qué configuración funciona mejor con su carga de trabajo.

Conclusión

Los hallazgos de este estudio sugieren lo siguiente:

Como era de esperar, el rendimiento de un Citrix VDA tiende a estar limitado por la CPU en lugar del rendimiento del disco o el ancho de banda de la red.

Los procesadores más recientes disponibles en Google Cloud en el momento de la publicación proporcionaron la mejor experiencia de usuario final (medida según la carga de trabajo de referencia de nuestros trabajadores del conocimiento). Están disponibles en las familias de instancias N2, N2D y C2, y aprovechan los procesadores Cascade Lake de Intel y Milán y Rome de AMD.

Para el perfil de trabajador con conocimiento, los tres tipos de instancias más rentables son:

  • El tipo de instancia N2D-Standard-8 (con el procesador AMD Milan), que logró 2.875 usuarios por CPU virtual, fue el más rentable, con costes tan bajos como 0,0280 USD por hora de usuario con precios de pago por uso publicados.
  • El tipo de instancia N2D-Standard-8 (con el procesador AMD Rome), seguido de 2,25 usuarios por vCPU y un coste tan bajo como 0,036 USD por hora.
  • El tipo de instancia C2-Standard-8 (con el procesador Intel Cascade Lake) también logró 2,25 usuarios por CPU con un coste ligeramente superior a 0,040 USD por hora de usuario.

Los procesadores más rápidos son la mejor plataforma para las cargas de trabajo de los trabajadores del conocimiento Los resultados muestran que el punto óptimo son los tamaños de instancia de 8 vCPU y 4 vCPU, mientras que el cambio a tamaños de instancia de 16 vCPU reduce significativamente la cantidad de usuarios que puede esperar por vCPU.

Con los procesadores más recientes, el tipo de almacenamiento que se usa para el disco persistente no tiene un impacto importante en la escalabilidad de la instancia. Si bien no encontramos correlación entre el tipo de rendimiento del disco y la cantidad de usuarios esperados en una máquina virtual cuando se usaron los tipos de instancia N2D y C2, sí que observamos una diferencia de rendimiento significativa para las instancias N1.

Si bien no se han probado explícitamente como parte de este estudio, las cargas de trabajo que requieren una GPU deben ejecutarse en los tipos de instancia N1. Cuando la aceleración de la GPU es un requisito, aprovechar los procesadores Skylake y el almacenamiento en disco persistente SSD Premium probablemente producirá el mejor rendimiento y la mayor escalabilidad.

Como siempre, tenga en cuenta que se trata de una carga de trabajo de ejemplo que se utiliza para pruebas y validación y que puede representar o no su carga de trabajo. Le recomendamos probar sus cargas de trabajo en Google Cloud antes de comprometerse con una arquitectura específica. Puede aprovechar la herramienta Login Enterprise de Login VSI para crear una carga de trabajo personalizada que se aproxime a las actividades diarias de sus usuarios y proporcione una puntuación EUX que le ayudará a evaluar su experiencia. Registre la puntuación EUX con un solo usuario en el sistema y, a continuación, agregue los usuarios de uno en uno hasta que la puntuación baje 0,5 para determinar los usuarios recomendados en un sistema.

Un agradecimiento especial al equipo de Login VSI que trabajó estrechamente con nosotros mientras usábamos sus algoritmos de puntuación EUX para evaluar Google Cloud.

Dimensionar las instancias de VDA en Google Cloud Compute Engine