O cliente desejava VDI. Ele estava muito interessado na combinação SimpliVity + VDI Citrix Virtual Desktop. Para todos os operadores, funcionários de escritórios nas cidades e assim por diante. Há cinco mil usuários apenas na primeira onda de migração, e por isso eles insistiram em testes de carga. O VDI pode começar a ter lentidão, pode tranquilamente parar — e isso nem sempre ocorre por problemas na rede. Compramos um pacote de testes muito poderoso especificamente para VDI e carregamos a infraestrutura até que ela falhasse em disco e processador.
Então, precisaremos de uma garrafa plástica, do software LoginVSI para testes avançados de VDI. Temos com licenças para 300 usuários. Depois, pegamos o hardware HPE SimpliVity 380 na configuração adequada para maximizar a densidade de usuários em um único servidor, criamos máquinas virtuais com boa reatribuição e instalamos nelas o software de escritório no Win10 e começamos os testes.
Vamos lá!
Sistema
Dois nós (servidores) HPE SimpliVity 380 Gen10. Em cada um:
- 2 x Intel Xeon Platinum 8170 26c 2,1GHz.
- Memória RAM: 768GB, 12 x 64GB LRDIMMs DDR4 2666MHz.
- Controlador de disco principal: HPE Smart Array P816i-a SR Gen10.
- Discos rígidos: 9 x 1,92 TB SATA 6Gb/s SSD (na configuração RAID6 7+2, ou seja, este é o modelo Medium em termos de HPE SimpliVity).
- Placas de rede: 4 x 1Gb Eth (dados dos usuários), 2 x 10Gb Eth (back-end SimpliVity e vMotion).
- FPGA especial embutido em cada nó para deduplicação/compressão.
Os nós estão interconectados entre si via 10Gb Ethernet diretamente, sem um switch externo, que é usado como back-end do SimpliVity e para transferir dados das máquinas virtuais via NFS. Os dados das máquinas virtuais no cluster são sempre espelhados entre os dois nós.
Os nós estão agrupados em um cluster VMware vSphere gerenciado pelo vCenter.
Para a realização dos testes, foram desplegados um controlador de domínio e um broker de conexões Citrix. O controlador de domínio, o broker e o vCenter estão em um cluster separado.
Como infraestrutura de teste, foram desplegados 300 desktops virtuais na configuração Dedicada – Cópia Completa, ou seja, cada desktop é uma cópia completa da imagem original da máquina virtual e mantém todas as alterações feitas pelos usuários.
Cada máquina virtual possui 2vCPU e 4GB de RAM:
Nas máquinas virtuais, foi instalado o seguinte software necessário para a realização dos testes:
- Windows 10 (64 bits), versão 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Java 7 Update 13.
- Microsoft Office Professional Plus 2016.
Entre os nós — replicação síncrona. Cada bloco de dados no cluster tem duas cópias. Isso significa que agora há um conjunto completo de dados em cada um dos nós. Com um cluster de três ou mais nós, as cópias dos blocos estão em dois locais diferentes. Ao criar uma nova VM, uma cópia adicional é criada em um dos nós do cluster. Se um nó falhar, todas as VMs que estavam em execução nele são automaticamente reiniciadas em outros nós onde têm réplicas. Se o nó falhar por um longo período, começa a recuperação gradual da redundância, e o cluster retorna à reserva N+1.
O balanceamento e o armazenamento de dados ocorrem no nível do armazenamento programático do próprio SimpliVity.
As máquinas virtuais iniciam um cluster de virtualização, que também as aloca no armazenamento programático. As estações de trabalho utilizaram um modelo padrão: participaram do teste mesas de analistas financeiros e operadores (são dois modelos diferentes).
Testes
Para realizar os testes, foi utilizado o complexo de software LoginVSI 4.1. O complexo LoginVSI, composto por um servidor de gerenciamento e 12 máquinas para conexões de teste, foi implantado em um host físico separado.
Os testes foram realizados em três modos:
Modo Benchmark — opções de carga de 300 Knowledge workers e 300 Storage workers.
Modo Padrão — opção de carga de 300 Power workers.
Para possibilitar o trabalho de Power workers e aumentar a diversidade de carga, foi adicionada uma biblioteca de arquivos adicionais, Power Library, ao complexo LoginVSI. Para garantir a repetibilidade dos resultados, todas as configurações do ambiente de teste foram mantidas como Default.
Os testes de Knowledge e Power workers simulam a carga real de usuários trabalhando em estações de trabalho virtuais.
O teste Storage workers foi criado especificamente para testar sistemas de armazenamento de dados, distantes das cargas reais e, em grande parte, consiste no trabalho do usuário com um grande número de arquivos de tamanhos diversos.
Durante os testes, os usuários acessam as estações de trabalho durante 48 minutos, aproximadamente um usuário a cada 10 segundos.
Resultados
O principal resultado do teste LoginVSI é a métrica VSImax, que é composta pelo tempo de execução de várias tarefas realizadas pelo usuário. Por exemplo: o tempo de abertura de um arquivo no bloco de notas, o tempo de compactação de um arquivo no 7-Zip, etc.
Uma descrição detalhada da contagem de métricas está disponível na documentação oficial sobre .
Em outras palavras, o LoginVSI replica um padrão de carga típico, simulando as ações do usuário em um pacote de escritório, ao ler PDFs e assim por diante, e mede vários atrasos. Existe um nível crítico de atrasos, ‘tudo está travando, impossível trabalhar’, até o qual considera-se que o número máximo de usuários não foi atingido. Se o tempo de resposta for de 1.000 ms mais rápido do que este estado de ‘tudo está travando’, considera-se que o sistema está funcionando normalmente e é possível adicionar mais usuários.
Aqui estão as principais métricas:
Métrica
Ações executadas
Detalhado descrição
Componentes carregados
NSLD
Tempo de abertura de texto
arquivo de 1.500 Kbytes
O bloco de notas é iniciado e
abre um documento aleatório de 1.500 Kbytes, copiado do pool
de recursos
CPU e I/O
NFO
Tempo de abertura da caixa de diálogo
no bloco de notas
Abertura de arquivo VSI-Notepad [Ctrl+O]
CPU, RAM e I/O
ZHC*
Tempo de criação de um arquivo Zip com compressão forte
Compressão de um arquivo aleatório local no formato .pst com 5MB, copiado do
pool de recursos
ZLC*
CPU e I/O
Tempo de criação de um arquivo Zip com compressão fraca
I/O
Compressão de um arquivo aleatório local no formato .pst com 5MB, copiado do
pool de recursos
ZLC*
Cálculo de um grande
CPU
array de dados aleatórios
Criação de um grande array
de dados aleatórios que serão usados no temporizador de entrada/saída (I/O-timer)
Durante os testes, a métrica base VSIbase é inicialmente calculada, que mostra a velocidade de execução das tarefas sem carga no sistema. Com base nela, determina-se o VSImax Threshold, que é igual a VSIbase + 1.000 ms.
CPU
As conclusões sobre o desempenho do sistema são feitas com base em duas métricas: VSIbase, que determina a velocidade de operação do sistema, e VSImax threshold, que determina o número máximo de usuários que o sistema suportará sem degradação significativa.
Benchmark de 300 trabalhadores do conhecimento
Trabalhadores do conhecimento são usuários que regularmente sobrecarregam a memória, o processador e I/O com picos pequenos e frequentes. O software emula a carga de usuários de escritório exigentes, como se estivessem constantemente clicando em algo (PDF, Java, pacote de escritório, visualização de fotos, 7-Zip). À medida que os usuários são adicionados de 0 a 300, a latência de cada um aumenta suavemente.
Dados estatísticos do VSImax:
VSIbase = 986 ms, o Threshold VSI não foi atingido.
Estatísticas de carga do sistema de armazenamento a partir do monitoramento SimpliVity:
Estatísticas de carga do sistema de armazenamento do monitoramento SimpliVity:
Com este tipo de carga, o sistema suporta o aumento da carga praticamente sem degradação de desempenho. O tempo de execução das tarefas dos usuários aumenta suavemente, enquanto o tempo de resposta do sistema não muda durante os testes, permanecendo em até 3 ms para gravação e até 1 ms para leitura.
Conclusão: 300 usuários de knowledge trabalham sem problemas no cluster atual e não interferem uns nos outros, alcançando uma sobrecarga de pCPU/vCPU de 1 para 6. As latências gerais aumentam uniformemente com o aumento da carga, mas o limite estabelecido não foi alcançado.
300 trabalhadores de Storage benchmark
São usuários que escrevem e leem constantemente na proporção de 30 para 70, respectivamente. Este teste foi realizado mais por experimentação. Dados da estatística VSImax:
VSIbase = 1673, o limiar do VSI foi alcançado em 240 usuários.
Estatísticas de carga do sistema de armazenamento do monitoramento SimpliVity:
Esse tipo de carga, na verdade, é um teste de estresse do sistema de armazenamento. Durante sua execução, cada usuário grava no disco uma série de arquivos aleatórios de diferentes tamanhos. Neste caso, é visível que, ao exceder um certo limite de carga, parte dos usuários apresenta aumento no tempo de execução das tarefas de gravação de arquivos. No entanto, a carga no sistema de armazenamento, CPU e memória dos hosts permanece praticamente a mesma, o que torna impossível determinar exatamente quais são as causas das latências no momento.
As conclusões sobre o desempenho do sistema com esse teste podem ser feitas apenas em comparação com os resultados de testes em outros sistemas, pois essas cargas são sintéticas e irreais. No entanto, de maneira geral, o teste foi bem. Até 210 sessões tudo funcionou bem, e então começaram as respostas estranhas, que não foram monitoradas em nenhum outro lugar, exceto no Login VSI.
300 trabalhadores Power
São usuários que apreciam CPU, memória e altos I/O. Esses 'usuários avançados' regularmente executam tarefas complexas com picos prolongados, como instalação de novos softwares e descompactação de grandes arquivos. Dados da estatística VSImax:
VSIbase = 970, o limiar do VSI não foi alcançado.
Estatísticas de carga do sistema de armazenamento do monitoramento SimpliVity:
Durante os testes, o limite de carga dos processadores em um dos nós do sistema foi alcançado, mas isso não teve um impacto significativo em seu funcionamento:
Nesse caso, o sistema suporta o aumento da carga sem degradação significativa do desempenho. O tempo de execução das tarefas dos usuários aumenta suavemente, e o tempo de resposta do sistema permanece constante durante os testes, sendo de até 3 ms para gravação e até 1 ms para leitura.
Os testes tradicionais não foram suficientes para o cliente, então fomos além: aumentamos as características da VM (número de vCPUs para avaliar o aumento da sobrecarga e o tamanho do disco) e adicionamos carga adicional.
Durante os testes adicionais, a seguinte configuração de bancada foi utilizada:
Foram implantados 300 desktops virtuais na configuração 4vCPU, 4GB RAM, 80GB HDD.
Configuração de uma das máquinas de teste:
As máquinas foram implantadas na variante Dedicated – Full Copy:
300 Knowledge workers benchmark com sobrecarga de 12
VSIbase = 986 ms, o Threshold VSI não foi atingido.
VSIbase = 921 ms, o VSI Threshold não foi alcançado.
Estatísticas de carga do sistema de armazenamento do monitoramento SimpliVity:
Os resultados obtidos são semelhantes aos do teste da configuração anterior da VM.
300 Power workers com sobrecarga de 12
VSIbase = 986 ms, o Threshold VSI não foi atingido.
VSIbase = 933, o VSI Threshold não foi alcançado.
Estatísticas de carga do sistema de armazenamento do monitoramento SimpliVity:
Neste teste, também foi alcançado o limite de carga dos processadores, mas isso não teve um impacto significativo no desempenho:
Os resultados obtidos são semelhantes aos do teste da configuração anterior.
O que acontece se a carga for mantida por 10 horas?
Agora vamos ver se haverá um 'efeito de acúmulo' e conduzimos os testes por 10 horas seguidas.
Os testes prolongados e a descrição da seção devem focar em nossa intenção de verificar se ocorrerão problemas com a fazenda sob carga prolongada.
300 Knowledge workers benchmark + 10 horas
Além disso, foi realizada uma testagem da carga de 300 knowledge workers com a subsequente operação dos usuários por 10 horas.
VSIbase = 986 ms, o Threshold VSI não foi atingido.
VSIbase = 919 ms, o VSI Threshold não foi alcançado.
Dados estatísticos VSImax Detalhados:
O gráfico mostra que durante todo o teste não houve degradação do desempenho.
Estatísticas de carga do sistema de armazenamento do monitoramento SimpliVity:
O desempenho do sistema de armazenamento permanece consistente ao longo de todo o teste.
Testes adicionais foram realizados com a adição de carga sintética.
O cliente solicitou a adição de carga intensa no disco. Para isso, foi adicionado um trabalho de execução de carga sintética no disco em cada uma das máquinas virtuais dos usuários ao entrar no sistema. A carga foi garantida pela ferramenta fio, que permite limitar a carga no disco em termos de IOPS. Em cada máquina, uma tarefa foi iniciada para gerar uma carga adicional de 22 IOPS, com uma distribuição de 70%/30% de Leitura/Escrita Aleatória.
300 Benchmark de trabalhadores do conhecimento + 22 IOPS por usuário
Durante os testes iniciais, foi descoberto que o fio cria uma carga adicional significativa na CPU das máquinas virtuais. Isso levou a um rápido sobrecarregamento dos hosts em termos de CPU e impactou fortemente o funcionamento do sistema como um todo.
Carga na CPU dos hosts:
As latências do sistema de armazenamento também aumentaram de forma previsível:
A falta de capacidade computacional tornou-se crítica com cerca de 240 usuários:
Em decorrência dos resultados obtidos, decidiu-se realizar um teste que carregasse menos a CPU.
230 Benchmark de trabalhadores de escritório + 22 IOPS por usuário
Para reduzir a carga na CPU, foi escolhido um tipo de carga de trabalhadores de escritório, sendo adicionados 22 IOPS de carga sintética a cada sessão.
O teste foi limitado a 230 sessões para não exceder a carga máxima na CPU.
O teste foi iniciado com a operação contínua dos usuários por 10 horas para verificar a estabilidade do sistema sob uma carga que se aproximasse do máximo.
VSIbase = 986 ms, o Threshold VSI não foi atingido.
VSIbase = 918 ms, o limiar VSI não foi alcançado.
Dados estatísticos VSImax Detalhados:
O gráfico mostra que durante todo o teste não houve degradação do desempenho.
Estatísticas da carga na CPU:
Durante a realização deste teste, a carga na CPU dos hosts foi praticamente máxima.
Estatísticas de carga do sistema de armazenamento do monitoramento SimpliVity:
O desempenho do sistema de armazenamento permanece consistente ao longo de todo o teste.
A carga no sistema de armazenamento durante o teste foi de aproximadamente 6.500 IOPS, numa proporção de 60/40 (3.900 IOPS para leitura, 2.600 IOPS para gravação), o que equivale a cerca de 28 IOPS por estação de trabalho.
O tempo de resposta médio foi de 3 ms para gravação e até 1 ms para leitura.
Resultado
Ao simular cargas reais na infraestrutura HPE SimpliVity, foram obtidos resultados que confirmam a capacidade do sistema de suportar o funcionamento de pelo menos 300 máquinas Full Clone em um par de nós SimpliVity. Nesse processo, o tempo de resposta do sistema de armazenamento permaneceu em níveis ótimos durante todo o teste.
Gostamos muito da abordagem de realizar testes longos e comparar soluções antes da implementação. Podemos testar o desempenho para suas cargas de trabalho, se desejar. Incluindo outras soluções hiperconvergentes. O cliente mencionado está agora finalizando testes em outra solução paralelamente. Sua infraestrutura atual é, basicamente, um parque de PCs, com domínio e software em cada estação de trabalho. Transitar para VDI sem testes é, naturalmente, bem complicado. Especificamente, é difícil entender as reais capacidades da farm VDI sem ter migrado usuários reais para ela. E esses testes permitem avaliar rapidamente as capacidades reais de um sistema ou outro sem a necessidade de envolver usuários comuns. Daí surgiu tal pesquisa.
A segunda abordagem importante é que o cliente já planejou a escalabilidade correta. É possível adquirir um servidor adicional e adicionar uma farm, por exemplo, para 100 usuários, com preços previsíveis por usuário. Por exemplo, quando eles precisarem adicionar mais 300 usuários, saberão que precisarão de dois servidores em uma configuração já definida, em vez de revisar as possibilidades de modernização de sua infraestrutura como um todo.
As possibilidades de federação do HPE SimpliVity são interessantes. O negócio é geograficamente dividido, portanto, faz sentido ter seu próprio hardware VDI em um escritório remoto. Na federação SimpliVity, cada máquina virtual é replicada de acordo com um cronograma, permitindo a transferência entre clusters geograficamente distantes de forma muito rápida e sem sobrecarregar a conexão — isso é um backup embutido de muito bom nível. Durante a replicação de VMs entre locais, a banda utilizada é mínima, tanto quanto possível, permitindo a construção de arquiteturas DR muito interessantes, com um centro de controle unificado e várias localidades descentralizadas de armazenamento.
Tudo isso, em conjunto, permite avaliar a parte financeira em muito detalhe, sobrepondo os custos do VDI aos planos de crescimento da empresa, e entender quão rapidamente a solução se pagará e como ela funcionará. Porque qualquer VDI é uma solução que, ao final, economiza uma quantidade enorme de recursos, mas que, provavelmente, não terá uma possibilidade economicamente viável de ser trocada ao longo de 5 a 7 anos de uso.
Em geral, se você tiver mais dúvidas que não sejam para comentários, escreva-me por e-mail para mk@croc.ru.
Fonte: habr.com
