El cliente quería VDI. Estaba muy interesado en la combinación de SimpliVity + VDI Citrix Virtual Desktop. Para todos los operadores y empleados de oficinas en las ciudades, etc. Hay cinco mil usuarios solo en la primera ola de migración, y por eso insistieron en pruebas de carga. El VDI puede empezar a desacelerarse, puede funcionar normalmente, y no siempre esto ocurre debido a problemas con el canal. Compramos un paquete de pruebas muy potente específicamente para VDI y cargamos la infraestructura hasta que falló por los discos y el procesador.
Entonces, necesitaremos una botella de plástico, el software LoginVSI para pruebas avanzadas de VDI. Contamos con licencias para 300 usuarios. Luego adquirimos hardware HPE SimpliVity 380 en una configuración adecuada para maximizar la densidad de usuarios en un solo servidor, creamos máquinas virtuales con buena sobreasignación, instalamos software de oficina en Win10 y comenzamos a probar.
¡Vamos!
Sistema
Dos nodos (servidores) HPE SimpliVity 380 Gen10. En cada uno:
- 2 x Intel Xeon Platinum 8170 26c 2.1GHz.
- Memoria RAM: 768GB, 12 x 64GB LRDIMMs DDR4 2666MHz.
- Controlador de disco principal: HPE Smart Array P816i-a SR Gen10.
- Discos duros: 9 x 1.92 TB SATA 6Gb/s SSD (en configuración RAID6 7+2, es decir, este es el modelo Medium en términos de HPE SimpliVity).
- Tarjetas de red: 4 x 1Gb Eth (datos de usuarios), 2 x 10Gb Eth (backend SimpliVity y vMotion).
- Tarjetas FPGA incorporadas especiales en cada nodo para deduplicación/comprensión.
Los nodos están interconectados mediante Ethernet 10Gb directamente sin un switch externo, que se utiliza como backend de SimpliVity y para la transferencia de datos de las máquinas virtuales a través de NFS. Los datos de las máquinas virtuales en el clúster siempre se reflejan entre los dos nodos.
Los nodos se agrupan en un clúster de VMware vSphere administrado por vCenter.
Para realizar las pruebas, se desplegaron un controlador de dominio y un broker de conexiones Citrix. El controlador de dominio, el broker y vCenter se movieron a un clúster separado.
Como infraestructura de prueba, se desplegaron 300 escritorios virtuales en configuración Dedicated – Full Copy, es decir, cada escritorio es una copia completa de la imagen original de la máquina virtual y guarda todos los cambios realizados por los usuarios.
Cada máquina virtual tiene 2 vCPU y 4 GB de RAM:
Se instaló el siguiente software en las máquinas virtuales, necesario para realizar las pruebas:
- Windows 10 (64 bits), versión 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Java 7 Update 13.
- Microsoft Office Professional Plus 2016.
Entre los nodos, hay replicación sincrónica. Cada bloque de datos en el clúster tiene dos copias. Es decir, ahora hay un conjunto completo de datos en cada uno de los nodos. En un clúster de tres o más nodos, las copias de los bloques están en dos ubicaciones diferentes. Al crear una nueva VM, se genera una copia adicional en uno de los nodos del clúster. Si un nodo falla, todas las VMs que se ejecutaron en él se reinician automáticamente en otros nodos donde tienen réplicas. Si un nodo falla por un largo período, comienza la recuperación gradual de la redundancia, y el clúster vuelve a tener una reserva N+1.
El equilibrio y almacenamiento de datos se realizan a nivel del software de almacenamiento de SimpliVity.
Las máquinas virtuales inician un clúster de virtualización, el cual también las organiza en el software de almacenamiento. Los escritorios se tomaron de una plantilla estándar: para la prueba se utilizaron escritorios de financistas y operadores (son dos plantillas diferentes).
Pruebas
Para llevar a cabo las pruebas se utilizó el complejo de software LoginVSI 4.1. El complejo LoginVSI, compuesto por un servidor de administración y 12 máquinas para conexiones de prueba, se desplegó en un host físico separado.
Las pruebas se realizaron en tres modos:
Modo Benchmark: variantes de carga de 300 Knowledge workers y 300 Storage workers.
Modo estándar: variante de carga de 300 Power workers.
Para permitir el funcionamiento de Power workers y aumentar la diversidad de la carga en el complejo LoginVSI, se agregó una biblioteca de archivos adicionales llamada Power Library. Para asegurar la repetibilidad de los resultados, todas las configuraciones del banco de pruebas se dejaron en Default.
Las pruebas de Knowledge y Power workers imitan la carga real de usuarios que trabajan en estaciones de trabajo virtuales.
La prueba Storage workers fue creada específicamente para probar sistemas de almacenamiento de datos, está lejos de las cargas reales y consiste en gran parte en el trabajo del usuario con una gran cantidad de archivos de diferentes tamaños.
Durante el proceso de prueba, los usuarios acceden a las estaciones de trabajo durante 48 minutos, aproximadamente un usuario cada 10 segundos.
Resultados
El resultado principal de la prueba LoginVSI es la métrica VSImax, que se compone del tiempo de ejecución de varias tareas realizadas por el usuario. Por ejemplo: el tiempo de apertura de un archivo en el bloc de notas, el tiempo de compresión de un archivo en 7-Zip, etc.
Una descripción detallada del conteo de métricas está disponible en la documentación oficial de .
En otras palabras, LoginVSI repite un patrón de carga típico, simulando las acciones de un usuario en un paquete de oficina, al leer PDF y más, y mide varios retrasos. Hay un nivel crítico de retraso en el que "todo se ralentiza, es imposible trabajar"; al alcanzar este nivel, se considera que no se ha alcanzado el máximo de usuarios. Si el tiempo de respuesta es más rápido que 1,000 ms que este estado de "todo se ralentiza", se considera que el sistema funciona normalmente y se pueden agregar más usuarios.
Estas son las métricas principales:
Métrica
Acciones realizadas
Detallado descripción
Componentes cargados
NSLD
Tiempo de apertura de un
archivo de texto de 1,500 Kbytes
Se inicia el bloc de notas y
abre un documento aleatorio de 1,500 Kbytes, que fue copiado del grupo
de recursos
CPU y I/O
NFO
Tiempo de apertura del cuadro de diálogo en el bloc de notas
Apertura del archivo VSI-Notepad [Ctrl+O]
CPU, RAM y I/O
ZHC*
Tiempo para crear un archivo Zip con fuerte compresión
Compresión de un archivo aleatorio local en formato .pst de 5MB, que fue copiado de
un grupo de recursos
ZLC*
Tiempo para crear un archivo Zip con débil compresión
CPU y I/O
I/O
Cálculo de un gran
un grupo de recursos
ZLC*
Tiempo para crear un archivo Zip con débil compresión
arreglo de datos aleatorios
CPU
Creación de un gran arreglo
de datos aleatorios que se utilizarán en un temporizador de entrada/salida (temporizador I/O)
Al realizar las pruebas, se mide inicialmente la métrica base VSIbase, que muestra la velocidad de ejecución de tareas sin carga en el sistema. Sobre esta base se determina el umbral VSImax, que es igual a VSIbase + 1,000 ms.
Las conclusiones sobre el rendimiento del sistema se basan en dos métricas: VSIbase, que define la velocidad de funcionamiento del sistema, y el umbral VSImax, que define la cantidad máxima de usuarios que el sistema soporta sin degradación significativa.
CPU
Benchmark de 300 trabajadores del conocimiento
Los trabajadores del conocimiento son usuarios que regularmente sobrecargan la memoria, el procesador y I/O con pequeños picos. El software emula la carga de los usuarios de oficina exigentes, como si estuvieran continuamente haciendo clic en algo (PDF, Java, paquetes de oficina, visualización de fotos, 7-Zip). A medida que se añaden usuarios de cero a 300, el retraso de cada uno aumenta gradualmente.
Datos estadísticos de VSImax:
VSIbase = 986 ms, el umbral VSI no se alcanzó.
Estadísticas de carga en el sistema de almacenamiento desde la supervisión de SimpliVity:
Los resultados sobre rendimiento se basan en dos métricas: VSIbase, que indica la velocidad de funcionamiento del sistema, y el umbral del VSImax, que determina la cantidad máxima de usuarios que el sistema puede soportar sin una degradación significativa.
Datos estadísticos de VSImax:
Con este tipo de carga, el sistema soporta un aumento de la carga prácticamente sin degradación del rendimiento. El tiempo de ejecución de las tareas de los usuarios aumenta suavemente, y el tiempo de respuesta del sistema no cambia durante las pruebas, siendo de hasta 3 ms para escritura y hasta 1 ms para lectura.
Salida: 300 usuarios de conocimiento trabajan sin problemas en el clúster actual y no interfieren entre sí, alcanzando un reasignación de pCPU/vCPU de 1 a 6. Las latencias generales aumentan de manera uniforme con el incremento de la carga, pero no se ha alcanzado el límite preestablecido.
300 trabajadores de almacenamiento benchmark
Estos son usuarios que escriben y leen de manera constante en una proporción de 30 a 70 respectivamente. Esta prueba se realizó más por experimento. Datos de la estadística VSImax:
VSIbase = 1673, el umbral VSI se alcanzó con 240 usuarios.
Datos estadísticos de VSImax:
Este tipo de carga es, en esencia, una prueba de estrés para el sistema de almacenamiento. Durante su ejecución, cada usuario escribe en el disco muchos archivos aleatorios de diferentes tamaños. En este caso, es evidente que al superar un cierto umbral de carga, parte de los usuarios experimentan un aumento en el tiempo de ejecución de las tareas de escritura de archivos. No obstante, la carga en el sistema de almacenamiento, el procesador y la memoria de los hosts no cambia significativamente, por lo que en este momento no se puede determinar con precisión a qué se deben las latencias.
Las conclusiones sobre el rendimiento del sistema a través de esta prueba solo pueden hacerse en comparación con los resultados de pruebas en otros sistemas, ya que tales cargas son sintéticas y no realistas. Sin embargo, en general, la prueba se realizó bastante bien. Hasta 210 sesiones, todo funcionaba correctamente, y luego comenzaron las respuestas inusuales, que no fueron rastreadas en ningún lugar más que en Login VSI.
300 trabajadores de potencia
Estos son usuarios que gustan del procesador, la memoria y un alto IO. Estos "usuarios avanzados" ejecutan regularmente tareas complejas con picos prolongados, como la instalación de nuevo software y la descompresión de grandes archivos. Datos de la estadística VSImax:
VSIbase = 970, el umbral VSI no fue alcanzado.
Datos estadísticos de VSImax:
Durante la prueba, se alcanzó el umbral de carga de los procesadores en uno de los nodos del sistema, pero esto no tuvo un impacto significativo en su funcionamiento:
En este caso, el sistema soporta el aumento de carga sin una degradación significativa del rendimiento. El tiempo de ejecución de las tareas de los usuarios aumenta de manera gradual, mientras que el tiempo de respuesta del sistema no cambia durante la prueba y se mantiene en hasta 3 ms para escritura y hasta 1 ms para lectura.
Las pruebas estándar no fueron suficientes para el cliente, así que fuimos más allá: aumentamos las características de la VM (número de vCPU, para evaluar el aumento de la sobreasignación y el tamaño del disco) y añadimos carga adicional.
Para las pruebas adicionales se utilizó la siguiente configuración del stand:
Se desplegaron 300 escritorios virtuales con la configuración 4vCPU, 4GB RAM, 80GB HDD.
Configuración de una de las máquinas de prueba:
Las máquinas fueron desplegadas en la variante Dedicada – Copia Completa:
300 benchmarks de Knowledge workers con una sobreasignación de 12
Estadísticas de carga en el sistema de almacenamiento desde la supervisión de SimpliVity:
VSIbase = 921 ms, el umbral VSI no fue alcanzado.
Datos estadísticos de VSImax:
Los resultados obtenidos son similares a la prueba de la configuración anterior de la VM.
300 Power workers con una sobreasignación de 12
Estadísticas de carga en el sistema de almacenamiento desde la supervisión de SimpliVity:
VSIbase = 933, el umbral VSI no fue alcanzado.
Datos estadísticos de VSImax:
En esta prueba también se alcanzó el umbral de carga de los procesadores, pero esto no tuvo un impacto significativo en el rendimiento:
Los resultados obtenidos son similares a la prueba de la configuración anterior.
¿Qué pasará si se aplica carga durante 10 horas?
Ahora vemos si habrá un 'efecto acumulativo' y realizamos pruebas durante 10 horas seguidas.
Las pruebas prolongadas y la descripción de la sección deben centrarse en lo que queríamos verificar, si surgirían problemas con la granja bajo una carga prolongada.
Benchmark de 300 Knowledge workers + 10 horas
Además, se realizó una prueba de carga de 300 knowledge workers con trabajo de usuarios durante 10 horas.
Estadísticas de carga en el sistema de almacenamiento desde la supervisión de SimpliVity:
VSIbase = 919 ms, el umbral VSI no fue alcanzado.
Datos de estadísticas VSImax Detallado:
En el gráfico se puede ver que durante toda la prueba no se observa degradación del rendimiento.
Datos estadísticos de VSImax:
El rendimiento del sistema de almacenamiento se mantiene constante durante toda la prueba.
Prueba adicional con carga sintética añadida.
El cliente pidió agregar una carga intensa al disco. Para ello, se asignó a cada una de las máquinas virtuales de los usuarios una tarea que activaba una carga sintética en el disco al iniciar sesión en el sistema. La carga era proporcionada por la herramienta fio, que permite limitar la carga en el disco en función de la cantidad de IOPS. En cada máquina, se ejecutaba una tarea para generar una carga adicional de 22 IOPS 70 % / 30 % Lectura / Escritura Aleatoria.
300 benchmark de trabajadores del conocimiento + 22 IOPS por usuario
Durante las pruebas iniciales, se descubrió que fio generaba una carga adicional significativa en el procesador de las máquinas virtuales. Esto llevó a una rápida sobrecarga de los hosts debido a la CPU y afectó seriamente el rendimiento del sistema en su conjunto.
Carga en CPU de los hosts:
Las latencias del sistema de almacenamiento también aumentaron de manera correspondiente:
La falta de potencia de cálculo se volvió crítica aproximadamente a 240 usuarios:
Como resultado de los hallazgos, se decidió realizar pruebas que ejerzan menos carga sobre la CPU.
230 benchmark de trabajadores de oficina + 22 IOPS por usuario
Para reducir la carga en la CPU, se eligió un tipo de carga de trabajadores de oficina, y se añadieron 22 IOPS de carga sintética por cada sesión.
La prueba se limitó a 230 sesiones para no exceder la carga máxima en la CPU.
La prueba se ejecutó con la actividad de los usuarios durante 10 horas para verificar la estabilidad del sistema durante un trabajo prolongado bajo una carga cercana al máximo.
Estadísticas de carga en el sistema de almacenamiento desde la supervisión de SimpliVity:
VSIbase = 918 ms, no se alcanzó el umbral de VSI.
Datos de estadísticas VSImax Detallado:
En el gráfico se puede ver que durante toda la prueba no se observa degradación del rendimiento.
Datos estadísticos sobre la carga de la CPU:
Durante esta prueba, la carga en la CPU de los hosts estuvo prácticamente en su máxima capacidad.
Datos estadísticos de VSImax:
El rendimiento del sistema de almacenamiento se mantiene constante durante toda la prueba.
La carga en el sistema de almacenamiento durante la prueba fue de aproximadamente 6,500 IOPS en una proporción de 60 / 40 (3,900 IOPS para lectura, 2,600 IOPS para escritura), lo que equivale a aproximadamente 28 IOPS por estación de trabajo.
El tiempo de respuesta promedio fue de 3 ms para escritura y hasta 1 ms para lectura.
Summary
En la simulación de cargas reales en la infraestructura HPE SimpliVity se obtuvieron resultados que confirman la capacidad del sistema para soportar al menos 300 máquinas Full Clone de escritorios virtuales en un par de nodos SimpliVity. Durante toda la prueba, el tiempo de respuesta del sistema de almacenamiento se mantuvo en un nivel óptimo.
Nos impresiona mucho el enfoque de realizar pruebas prolongadas y comparar soluciones antes de la implementación. Podemos probar el rendimiento también con sus cargas de trabajo, si lo desea. Incluyendo en otras soluciones hiperconvergentes. El cliente mencionado actualmente está finalizando pruebas en otra solución en paralelo. Su infraestructura actual es simplemente un conjunto de PCs, un dominio y software en cada estación de trabajo. Migrar a VDI sin pruebas, por supuesto, es bastante complicado. Específicamente, es difícil comprender las capacidades reales de la granja VDI sin haber migrado a usuarios reales. Y estas pruebas permiten evaluar rápidamente las capacidades reales de un sistema sin la necesidad de involucrar a usuarios regulares. De ahí surgió este estudio.
El segundo enfoque importante es que el cliente ya contempló una escalabilidad adecuada. Aquí se puede añadir un servidor y agregar una granja, por ejemplo, para 100 usuarios, todo es predecible en costo por usuario. Por ejemplo, cuando necesiten añadir otros 300 usuarios, sabrán que necesitan dos servidores en una configuración ya definida, en lugar de revisar las capacidades de modernización de su infraestructura en general.
Las posibilidades de federación de HPE SimpliVity son interesantes. El negocio está geográficamente distribuido, por lo que tiene sentido instalar su propio hardware VDI en la oficina lejana. En la federación SimpliVity, cada máquina virtual se replica según un horario, con la posibilidad de hacer esto entre clústeres geográficamente distantes de manera muy rápida y sin carga en el canal; es una copia de seguridad integrada de muy alto nivel. Al replicar máquinas virtuales entre sitios, el canal se utiliza de manera tan mínima como sea posible, lo que permite construir arquitecturas de recuperación desastres muy interesantes con un centro de gestión unificado y múltiples sitios de almacenamiento descentralizados.
Todo esto en conjunto permite evaluar también la parte financiera de manera muy detallada, superponer los costos del VDI a los planes de crecimiento de la empresa y entender cuán rápido se amortizará la solución y cómo funcionará. Porque cualquier VDI es una solución que, al final, ahorra una gran cantidad de recursos, pero que probablemente, no tendrá una opción económicamente viable de cambiarse en un periodo de 5 a 7 años de uso.
En general, si quedan preguntas no para comentarios, escríbeme a mi correo mk@croc.ru.
Fuente: habr.com
