O cliente quería VDI. Realmente mirei a combinación SimpliVity + VDI Citrix Virtual Desktop. Para todos os operadores, empregados da oficina municipal, etc. Só na primeira onda de migración hai cinco mil usuarios e, por iso, insistiron na proba de carga. O VDI pode comezar a ralentizarse, pode deitarse tranquilamente, e isto non sempre ocorre debido a problemas coa canle. Compramos un paquete de probas moi potente específicamente para VDI e cargamos a infraestrutura ata que pesaba demasiado nos discos e no procesador.
Polo tanto, necesitaremos unha botella de plástico e o software LoginVSI para probas VDI sofisticadas. Témolo con licenzas para 300 usuarios. Despois levamos o hardware HPE SimpliVity 380 nun paquete axeitado para a tarefa de máxima densidade de usuarios por servidor, cortamos máquinas virtuais cunha boa subscrición, instalamos software ofimático en Win10 e comezamos as probas.
Imos alí!
Sistema
Dous nodos (servidores) HPE SimpliVity 380 Gen10. En cada un:
- 2 x Intel Xeon Platinum 8170 26c 2.1Ghz.
- RAM: 768 GB, 12 x 64 GB LRDIMM DDR4 2666 MHz.
- Controlador de disco principal: HPE Smart Array P816i-a SR Gen10.
- Discos duros: 9 x 1.92 TB SSD SATA 6 Gb/s (en configuración RAID6 7+2, é dicir, este é un modelo Medio en termos de HPE SimpliVity).
- Tarxetas de rede: 4 x 1 Gb Eth (datos de usuario), 2 x 10 Gb Eth (backend de SimpliVity e vMotion).
- Tarxetas FPGA especiais incorporadas en cada nodo para deduplicación/compresión.
Os nodos conéctanse entre si mediante unha interconexión Ethernet de 10 Gb directamente sen un interruptor externo, que se usa como backend SimpliVity e para transferir datos da máquina virtual a través de NFS. Os datos de máquinas virtuais nun clúster son sempre reflectidos entre dous nodos.
Os nodos combínanse nun clúster de Vmware vSphere xestionado por vCenter.
Para probar, implantáronse un controlador de dominio e un corredor de conexión Citrix. O controlador de dominio, o corredor e vCenter colócanse nun clúster separado.
Como infraestrutura de proba, despregáronse 300 escritorios virtuais na configuración Dedicada - Copia completa, é dicir, cada escritorio é unha copia completa da imaxe orixinal da máquina virtual e garda todos os cambios realizados polos usuarios.
Cada máquina virtual ten 2 vCPU e 4 GB de RAM:
Instalouse o seguinte software necesario para a proba nas máquinas virtuais:
- Windows 10 (64 bits), versión 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Actualización 7 de Java 13.
- Microsoft Office Professional Plus 2016.
Entre nodos - replicación síncrona. Cada bloque de datos do clúster ten dúas copias. É dicir, agora hai un conxunto completo de datos en cada un dos nodos. Cun grupo de tres ou máis nodos, as copias dos bloques están en dous lugares diferentes. Ao crear unha nova máquina virtual, créase unha copia adicional nun dos nodos do clúster. Cando falla un nodo, todas as máquinas virtuales que se executaban anteriormente nel reinician automaticamente noutros nodos nos que teñan réplicas. Se un nodo falla durante moito tempo, comeza a restauración gradual da redundancia e o clúster volve á redundancia N+1.
O equilibrio e o almacenamento dos datos prodúcense no nivel de almacenamento do software da propia SimpliVity.
As máquinas virtuais executan un clúster de virtualización, que tamén as coloca no almacenamento de software. As mesas en si foron tomadas segundo un modelo estándar: as mesas dos financeiros e os oficiais de operacións viñeron para a proba (son dous modelos diferentes).
Probas
Para probar, utilizouse a suite de probas de software LoginVSI 4.1. O complexo LoginVSI, composto por un servidor de control e 12 máquinas para conexións de proba, implantouse nun host físico separado.
A proba realizouse en tres modalidades:
Modo de referencia: casos de carga 300 traballadores de coñecemento e 300 traballadores de almacenamento.
Modo estándar - caso de carga 300 Traballadores de potencia.
Para que os traballadores de Power poidan traballar e aumentar a diversidade de cargas, engadiuse unha biblioteca de ficheiros de Power Library adicionais ao complexo LoginVSI. Para garantir a repetibilidade dos resultados, todos os axustes do banco de probas quedaron como predeterminados.
As probas de Knowledge and Power Workers simulan a carga de traballo real dos usuarios que traballan en estacións de traballo virtuais.
A proba de traballadores de almacenamento creouse especificamente para probar sistemas de almacenamento de datos; está lonxe de ser cargas de traballo reais e implica principalmente que o usuario traballe con un gran número de ficheiros de diferentes tamaños.
Durante a proba, os usuarios inician sesión nas estacións de traballo durante 48 minutos a un ritmo de aproximadamente un usuario cada 10 segundos.
Descubrimentos
O principal resultado das probas de LoginVSI é a métrica VSImax, que se compila a partir do tempo de execución de varias tarefas lanzadas polo usuario. Por exemplo: tempo para abrir un ficheiro no Bloc de notas, tempo para comprimir un ficheiro en 7-Zip, etc.
Unha descrición detallada do cálculo de métricas está dispoñible na documentación oficial para .
Noutras palabras, LoginVSI repite un patrón de carga típico, simulando accións do usuario nunha suite ofimática, lendo un PDF, etc., e mide varias latencias. Hai un nivel crítico de atrasos "todo se ralentiza, é imposible funcionar"), ante o que se considera que non se alcanzou o número máximo de usuarios. Se o tempo de resposta é 1 ms máis rápido que este estado "todo é lento", entón considérase que o sistema funciona normalmente e pódense engadir máis usuarios.
Aquí están as principais métricas:
Métricas
Accións realizadas
Detallado описание
Compoñentes cargados
N.S.L.D.
Texto horario de apertura
arquivo cun peso de 1 KB
Ábrese o bloc de notas e
abre un documento aleatorio de 1 KB que se copia do grupo
recursos
CPU e E/S
NFO
Horario de apertura do diálogo
windows no bloc de notas
Abrir un ficheiro VSI-Notepad [Ctrl+O]
CPU, RAM e E/S
ZHC*
É hora de crear un ficheiro Zip altamente comprimido
Compresión local
Copiouse un ficheiro .pst de 5 MB aleatorio
pool de recursos
CPU e E/S
ZLC*
É hora de crear un ficheiro Zip débilmente comprimido
Compresión local
Copiouse un ficheiro .pst de 5 MB aleatorio
pool de recursos
E /
CPU
Calculando grande
matriz de datos aleatorios
Creación dunha gran matriz
datos aleatorios que se usarán no temporizador de entrada/saída (temporizador de E/S)
CPU
Cando se realizan as probas, calcúlase inicialmente a métrica básica de VSIbase, que mostra a velocidade á que se executan os traballos sen carga no sistema. En función del, determínase o Limiar VSImax, que é igual a VSIbase + 1 ms.
As conclusións sobre o rendemento do sistema realízanse en función de dúas métricas: VSIbase, que determina a velocidade do sistema, e VSImax umbral, que determina o número máximo de usuarios que o sistema pode manexar sen unha degradación significativa.
Referencia de 300 traballadores do coñecemento
Os traballadores do coñecemento son usuarios que cargan regularmente memoria, procesador e E/S con varios pequenos picos. O software emula a carga de traballo dos usuarios de oficina esixentes, coma se estivesen constantemente a buscar algo (PDF, Java, suite ofimática, visualización de fotos, 7-Zip). A medida que engades usuarios de cero a 300, o atraso de cada un aumenta gradualmente.
Datos estatísticos VSImax:
VSIbase = 986 ms, non se alcanzou o limiar VSI.
Estatísticas de carga do sistema de almacenamento do seguimento de SimpliVity:
Con este tipo de carga, o sistema pode soportar unha carga aumentada sen degradar practicamente o rendemento. O tempo que tarda en completar as tarefas do usuario aumenta sen problemas, o tempo de resposta do sistema non cambia durante a proba e é de ata 3 ms para escribir e ata 1 ms para ler.
Conclusión: 300 usuarios de coñecemento traballan no clúster actual sen ningún problema e non interfiren entre si, chegando a sobresubscrición de pCPU/vCPU de 1 a 6. Os atrasos xerais crecen uniformemente a medida que aumenta a carga, pero non se alcanzou o límite estipulado.
Referencia de 300 traballadores de almacenamento
Estes son usuarios que escriben e len constantemente nunha proporción de 30 a 70, respectivamente. Esta proba levouse a cabo máis por experimentación. Datos estatísticos VSImax:
VSIbase = 1673, alcanzouse o limiar VSI en 240 usuarios.
Estatísticas de carga do sistema de almacenamento do seguimento de SimpliVity:
Este tipo de carga é esencialmente unha proba de esforzo do sistema de almacenamento. Cando se executa, cada usuario escribe moitos ficheiros aleatorios de diferentes tamaños no disco. Neste caso, pódese ver que cando se supera un determinado limiar de carga para algúns usuarios, aumenta o tempo que tarda en completar as tarefas de escritura de ficheiros. Ao mesmo tempo, a carga do sistema de almacenamento, procesador e memoria dos anfitrións non cambia significativamente, polo que actualmente é imposible determinar exactamente o que está a causar os atrasos.
As conclusións sobre o rendemento do sistema usando esta proba só se poden facer en comparación cos resultados das probas noutros sistemas, xa que tales cargas son sintéticas e pouco realistas. Con todo, en xeral a proba foi ben. Todo foi ben ata as 210 sesións, e entón comezaron as respostas estrañas, que non foron rastrexadas en ningún lado, excepto Login VSI.
300 traballadores do poder
Estes son usuarios que adoran a CPU, a memoria e o alto IO. Estes "usuarios avanzados" executan regularmente tarefas complexas con ráfagas longas, como instalar software novo e desempaquetar arquivos grandes. Datos estatísticos VSImax:
VSIbase = 970, non se alcanzou o limiar VSI.
Estatísticas de carga do sistema de almacenamento do seguimento de SimpliVity:
Durante a proba, alcanzouse o limiar de carga do procesador nun dos nodos do sistema, pero isto non tivo un impacto significativo no seu funcionamento:
Neste caso, o sistema pode soportar unha maior carga sen unha degradación significativa do rendemento. O tempo que tarda en completar as tarefas do usuario aumenta sen problemas, o tempo de resposta do sistema non cambia durante a proba e é de ata 3 ms para escribir e ata 1 ms para ler.
As probas regulares non foron suficientes para o cliente, e fomos máis aló: aumentamos as características da VM (número de vCPU para avaliar o aumento da sobresubscrición e o tamaño do disco) e engadimos carga adicional.
Ao realizar probas adicionais, utilizouse a seguinte configuración de stand:
Desplegáronse 300 escritorios virtuais nunha configuración de 4vCPU, 4 GB de RAM e 80 GB de disco duro.
Configuración dunha das máquinas de proba:
As máquinas están implantadas na opción Dedicada - Copiar completa:
Punto de referencia de 300 traballadores do coñecemento con sobresubscrición 12
Datos estatísticos VSImax:
VSIbase = 921 ms, non se alcanzou o limiar VSI.
Estatísticas de carga do sistema de almacenamento do seguimento de SimpliVity:
Os resultados obtidos son similares aos de probar a configuración anterior da VM.
300 traballadores do poder con 12 sobresubscricións
Datos estatísticos VSImax:
VSIbase = 933, non se alcanzou o limiar VSI.
Estatísticas de carga do sistema de almacenamento do seguimento de SimpliVity:
Durante esta proba, tamén se alcanzou o limiar de carga do procesador, pero isto non tivo un impacto significativo no rendemento:
Os resultados obtidos son similares aos de probar a configuración anterior.
Que pasa se executas a carga durante 10 horas?
Agora imos ver se haberá un "efecto de acumulación" e realizar probas durante 10 horas seguidas.
As probas a longo prazo e a descrición da sección deberían estar dirixidas ao feito de que queriamos comprobar se xurdirían problemas coa cercha baixo unha carga prolongada.
300 traballadores do coñecemento de referencia + 10 horas
Ademais, probouse un caso de carga de 300 traballadores do coñecemento, seguido do traballo do usuario durante 10 horas.
Datos estatísticos VSImax:
VSIbase = 919 ms, non se alcanzou o limiar VSI.
VSImax Datos estatísticos detallados:
O gráfico mostra que non se observa ningunha degradación do rendemento durante toda a proba.
Estatísticas de carga do sistema de almacenamento do seguimento de SimpliVity:
O rendemento do sistema de almacenamento segue sendo o mesmo durante toda a proba.
Probas adicionais coa adición de carga sintética
O cliente pediu engadir unha carga salvaxe ao disco. Para iso, engadiuse unha tarefa ao sistema de almacenamento en cada unha das máquinas virtuais do usuario para executar unha carga sintética no disco cando o usuario inicia sesión no sistema. A carga foi proporcionada pola utilidade fio, que permite limitar a carga no disco polo número de IOPS. En cada máquina, lanzouse unha tarefa para lanzar unha carga adicional por valor de 22 IOPS 70%/30% de lectura/escritura aleatoria.
Benchmark de 300 traballadores de coñecemento + 22 IOPS por usuario
Nas probas iniciais, descubriuse que fio impoñía unha sobrecarga significativa da CPU nas máquinas virtuais. Isto levou a unha rápida sobrecarga da CPU dos hosts e afectou moito o funcionamento do sistema no seu conxunto.
Carga da CPU do host:
Ao mesmo tempo, os atrasos do sistema de almacenamento tamén aumentaron naturalmente:
A falta de potencia informática fíxose crítica ao redor de 240 usuarios:
Debido aos resultados obtidos, decidiuse realizar probas que fosen menos intensivas en CPU.
230 oficinistas de referencia + 22 IOPS por usuario
Para reducir a carga na CPU, seleccionouse o tipo de carga dos traballadores de Office e tamén se engadiron 22 IOPS de carga sintética a cada sesión.
A proba limitouse a 230 sesións para non superar a carga máxima da CPU.
A proba realizouse cos usuarios durante 10 horas para comprobar a estabilidade do sistema durante o funcionamento a longo prazo con carga próxima á máxima.
Datos estatísticos VSImax:
VSIbase = 918 ms, non se alcanzou o limiar VSI.
VSImax Datos estatísticos detallados:
O gráfico mostra que non se observa ningunha degradación do rendemento durante toda a proba.
Estatísticas de carga da CPU:
Ao realizar esta proba, a carga na CPU dos hosts era case máxima.
Estatísticas de carga do sistema de almacenamento do seguimento de SimpliVity:
O rendemento do sistema de almacenamento segue sendo o mesmo durante toda a proba.
A carga no sistema de almacenamento durante a proba foi de aproximadamente 6 IOPS nunha relación 500/60 (40 IOPS de lectura, 3 IOPS de escritura), o que supón aproximadamente 900 IOPS por estación de traballo.
O tempo de resposta foi de media de 3 ms para escribir e ata 1 ms para ler.
Total
Ao simular cargas reais na infraestrutura HPE SimpliVity, obtivéronse resultados que confirman a capacidade do sistema para admitir escritorios virtuais de polo menos 300 máquinas Full Clone nun par de nodos SimpliVity. Ao mesmo tempo, o tempo de resposta do sistema de almacenamento mantívose nun nivel óptimo durante toda a proba.
Estamos moi impresionados polo enfoque de probas longas e comparación de solucións antes da implementación. Tamén podemos probar o rendemento das túas cargas de traballo se o desexas. Incluíndo outras solucións hiperconverxentes. O citado cliente está agora rematando as probas doutra solución en paralelo. A súa infraestrutura actual é simplemente unha flota de PCs, un dominio e software en cada lugar de traballo. Pasar a VDI sen probas é, por suposto, bastante difícil. En concreto, é difícil comprender as capacidades reais dunha granxa VDI sen migrar usuarios reais a ela. E estas probas permítenche avaliar rapidamente as capacidades reais dun sistema en particular sen a necesidade de involucrar aos usuarios comúns. De aí veu este estudo.
O segundo enfoque importante é que o cliente se comprometa inmediatamente a unha escala adecuada. Aquí podes mercar un servidor adicional e engadir unha granxa, por exemplo, para 100 usuarios, todo é previsible ao prezo do usuario. Por exemplo, cando necesiten engadir 300 usuarios máis, saberán que necesitan dous servidores nunha configuración xa definida, en lugar de reconsiderar a actualización da súa infraestrutura completa.
As posibilidades da federación HPE SimpliVity son interesantes. A empresa está separada xeograficamente, polo que ten sentido instalar o seu propio hardware VDI separado nunha oficina distante. Na federación SimpliVity, cada máquina virtual replícase segundo unha programación coa capacidade de replicarse entre clústeres xeograficamente remotos moi rapidamente e sen carga na canle: esta é unha copia de seguridade integrada de moi bo nivel. Ao replicar máquinas virtuales entre sitios, a canle úsase o máis mínimo posible, e isto fai posible construír arquitecturas DR moi interesantes en presenza dun único centro de control e unha morea de sitios de almacenamento descentralizados.
Todo isto en conxunto permite avaliar o lado financeiro con gran detalle, e superpoñer os custos de VDI aos plans de crecemento da empresa, e comprender a rapidez con que vai pagar a solución e como funcionará. Porque calquera VDI é unha solución que, en definitiva, aforra moitos recursos, pero ao mesmo tempo, moi probablemente, sen a oportunidade rendible de cambialo dentro de 5-7 anos de uso.
En xeral, se tes algunha dúbida que non sexa para comentar, escríbeme por correo electrónico [protexido por correo electrónico].
Fonte: www.habr.com