O cliente queria VDI. Eu realmente observei a combinação SimpliVity + VDI Citrix Virtual Desktop. Para todos os operadores, funcionários de prefeituras e assim por diante. São cinco mil usuários só na primeira onda de migração e por isso insistiram no teste de carga. O VDI pode começar a desacelerar, pode deitar com calma - e isso nem sempre acontece devido a problemas com o canal. Compramos um pacote de testes muito poderoso especificamente para VDI e carregamos a infraestrutura até que ela ficasse muito pesada nos discos e no processador.
Portanto, precisaremos de uma garrafa plástica e do software LoginVSI para testes VDI sofisticados. Temos licenças para 300 usuários. Em seguida, pegamos o hardware HPE SimpliVity 380 em um pacote adequado para a tarefa de densidade máxima de usuários por servidor, cortamos máquinas virtuais com bom excesso de assinaturas, instalamos software de escritório no Win10 nelas e começamos os testes.
Vamos lá!
Sistema
Dois nós (servidores) HPE SimpliVity 380 Gen10. Em cada:
- 2 x Intel Xeon Platinum 8170 26c 2.1 GHz.
- RAM: 768 GB, 12 LRDIMMs DDR64 de 4 GB de 2666 MHz.
- Controlador de disco primário: HPE Smart Array P816i-a SR Gen10.
- Discos rígidos: 9 SSD SATA 1.92 Gb/s de 6 TB (na configuração RAID6 7+2, ou seja, este é um modelo médio em termos do HPE SimpliVity).
- Placas de rede: 4 x 1Gb Eth (dados do usuário), 2 x 10Gb Eth (backend SimpliVity e vMotion).
- Placas FPGA integradas dedicadas em cada nó para desduplicação/compactação.
Os nós são conectados entre si por meio de uma interconexão Ethernet de 10 Gb diretamente sem um switch externo, que é usado como back-end do SimpliVity e para transferência de dados de máquinas virtuais via NFS. Os dados da máquina virtual em um cluster são sempre espelhados entre dois nós.
Os nós são combinados em um cluster VMware vSphere gerenciado pelo vCenter.
Para testes, um controlador de domínio e um agente de conexão Citrix foram implantados. O controlador de domínio, o corretor e o vCenter são colocados em um cluster separado.
Como infraestrutura de teste, foram implantados 300 desktops virtuais na configuração Dedicado – Full Copy, ou seja, cada desktop é uma cópia completa da imagem original da máquina virtual e salva todas as alterações feitas pelos usuários.
Cada máquina virtual possui 2vCPU e 4 GB de RAM:
O seguinte software necessário para teste foi instalado nas máquinas virtuais:
- Windows 10 (64 bits), versão 1809.
- Adobe Reader XI.
- Agente de entrega virtual Citrix 1811.1.
- Doro PDF 1.82.
- Java 7 Atualização 13.
- Microsoft Office Professional Plus 2016.
Entre nós - replicação síncrona. Cada bloco de dados no cluster possui duas cópias. Ou seja, agora existe 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. Quando um nó falha, todas as VMs anteriormente executadas nele são reiniciadas automaticamente em outros nós onde possuem réplicas. Se um nó falhar por um longo período, a restauração gradual da redundância começará e o cluster retornará à redundância N+1.
O balanceamento e o armazenamento de dados ocorrem no nível de armazenamento de software do próprio SimpliVity.
As máquinas virtuais executam um cluster de virtualização, que também as coloca no armazenamento de software. As próprias mesas foram tiradas de acordo com um modelo padrão: as mesas dos financeiros e dos oficiais de operações vieram para o teste (são dois modelos diferentes).
Teste
Para testes, foi utilizado o conjunto de testes do software LoginVSI 4.1. O complexo LoginVSI, composto por um servidor de controle e 12 máquinas para conexões de teste, foi implantado em um host físico separado.
O teste foi realizado em três modos:
Modo Benchmark - casos de carga 300 trabalhadores do conhecimento e 300 trabalhadores do armazenamento.
Modo padrão - caso de carga 300 Power Workers.
Para permitir que os trabalhadores do Power trabalhem e aumentem a diversidade de carga, uma biblioteca de arquivos adicionais da Power Library foi adicionada ao complexo LoginVSI. Para garantir a repetibilidade dos resultados, todas as configurações da bancada de testes foram deixadas como padrão.
Os testes Knowledge e Power Workers simulam a carga de trabalho real dos usuários que trabalham em estações de trabalho virtuais.
O teste Storage Workers foi criado especificamente para testar sistemas de armazenamento de dados; está longe de cargas de trabalho reais e envolve principalmente o usuário trabalhando com um grande número de arquivos de diferentes tamanhos.
Durante o teste, os usuários fazem login nas estações de trabalho por 48 minutos, a uma taxa de aproximadamente um usuário a cada 10 segundos.
Descobertas
O principal resultado do teste LoginVSI é a métrica VSImax, que é compilada a partir do tempo de execução de diversas tarefas iniciadas pelo usuário. Por exemplo: hora de abrir um arquivo no Bloco de Notas, hora de compactar um arquivo no 7-Zip, etc.
Uma descrição detalhada do cálculo das métricas está disponível na documentação oficial do .
Em outras palavras, o LoginVSI repete um padrão de carregamento típico, simulando ações do usuário em um pacote de escritório, lendo um PDF e assim por diante, e mede diversas latências. Existe um nível crítico de atrasos “tudo fica lento, não dá para trabalhar”), antes do qual se considera que o número máximo de utilizadores não foi atingido. Se o tempo de resposta for 1 ms mais rápido que esse estado “tudo está lento”, então o sistema será considerado funcionando normalmente e mais usuários poderão ser adicionados.
Aqui estão as principais métricas:
Métricas
Ações tomadas
Detalhado описание
Componentes carregados
N.S.L.D.
Horário de abertura do texto
arquivo pesando 1 KB
O bloco de notas abre e
abre um documento aleatório de 1 KB que é copiado do pool
ресурсов
CPU e E/S
NFO
Horário de abertura do diálogo
janelas no bloco de notas
Abrindo um arquivo VSI-Notepad [Ctrl+O]
CPU, RAM e E/S
ZHC*
É hora de criar um arquivo Zip altamente compactado
Compressão local
arquivo .pst aleatório de 5 MB copiado de
conjunto de recursos
CPU e E/S
ZLC*
É hora de criar um arquivo Zip fracamente compactado
Compressão local
arquivo .pst aleatório de 5 MB copiado de
conjunto de recursos
I / O
CPU
Calculando grande
matriz de dados aleatórios
Criando uma grande matriz
dados aleatórios que serão usados no temporizador de entrada/saída (temporizador de E/S)
CPU
Quando o teste é realizado, inicialmente é calculada a métrica básica do VSIbase, que mostra a velocidade com que os jobs são executados sem carga no sistema. Com base nele, é determinado o VSImax Threshold, que é igual a VSIbase + 1ms.
As conclusões sobre o desempenho do sistema são feitas com base em duas métricas: VSIbase, que determina a velocidade do sistema, e limite VSImax, que determina o número máximo de usuários que o sistema pode suportar sem degradação significativa.
Referência de 300 trabalhadores do conhecimento
Os trabalhadores do conhecimento são usuários que carregam regularmente memória, processador e IO com vários pequenos picos. O software emula a carga de trabalho de usuários exigentes de escritório, como se estivessem constantemente cutucando alguma coisa (PDF, Java, suíte de escritório, visualização de fotos, 7-Zip). À medida que você adiciona usuários de zero a 300, o atraso de cada um aumenta gradualmente.
Dados estatísticos VSImax:
VSIbase = 986ms, o limite VSI não foi atingido.
Estatísticas de carga do sistema de armazenamento do monitoramento SimpliVity:
Com esse tipo de carga, o sistema pode suportar cargas maiores praticamente sem degradação no desempenho. O tempo necessário para concluir as tarefas do usuário aumenta suavemente, o tempo de resposta do sistema não muda durante o teste e é de até 3 ms para gravação e até 1 ms para leitura.
Conclusão: 300 usuários de conhecimento trabalham no cluster atual sem problemas e não interferem entre si, atingindo um excesso de assinaturas de pCPU/vCPU de 1 a 6. Os atrasos gerais crescem uniformemente à medida que a carga aumenta, mas o limite estipulado não foi atingido.
Referência de 300 trabalhadores de armazenamento
São usuários que escrevem e leem constantemente na proporção de 30 a 70, respectivamente. Este teste foi realizado mais por uma questão de experimentação. Dados estatísticos VSImax:
VSIbase = 1673, limite de VSI alcançado em 240 usuários.
Estatísticas de carga do sistema de armazenamento do monitoramento SimpliVity:
Esse tipo de carga é essencialmente um teste de estresse do sistema de armazenamento. Quando é executado, cada usuário grava muitos arquivos aleatórios de tamanhos diferentes no disco. Nesse caso, percebe-se que quando um determinado limite de carga é ultrapassado para alguns usuários, o tempo necessário para concluir as tarefas de gravação de arquivos aumenta. Ao mesmo tempo, a carga no sistema de armazenamento, processador e memória dos hosts não muda significativamente, por isso é atualmente impossível determinar exatamente o que está causando os atrasos.
Conclusões sobre o desempenho do sistema utilizando este teste só podem ser feitas em comparação com resultados de testes em outros sistemas, uma vez que tais cargas são sintéticas e irrealistas. No entanto, no geral o teste correu bem. Tudo correu bem até 210 sessões, e então começaram as respostas estranhas, que não foram rastreadas em nenhum lugar, exceto no Login VSI.
300 trabalhadores de energia
Esses são usuários que adoram CPU, memória e alto IO. Esses “usuários avançados” executam regularmente tarefas complexas com longos intervalos, como instalar novo software e descompactar arquivos grandes. Dados estatísticos VSImax:
VSIbase = 970, o limite VSI não foi atingido.
Estatísticas de carga do sistema de armazenamento do monitoramento SimpliVity:
Durante o teste, o limite de carga do processador foi atingido em um dos nós do sistema, mas isso não teve um impacto significativo em sua operação:
Neste caso, o sistema pode suportar o aumento da carga sem degradação significativa do desempenho. O tempo necessário para concluir as tarefas do usuário aumenta suavemente, o tempo de resposta do sistema não muda durante o teste e é de até 3 ms para gravação e até 1 ms para leitura.
Os testes regulares não foram suficientes para o cliente e fomos além: aumentamos as características da VM (número de vCPUs para avaliar o aumento do excesso de assinaturas e do tamanho do disco) e adicionamos carga adicional.
Ao realizar testes adicionais, foi utilizada a seguinte configuração de suporte:
300 desktops virtuais foram implantados em uma configuração de 4 vCPU, 4 GB de RAM e 80 GB de HDD.
Configuração de uma das máquinas de teste:
As máquinas são implantadas na opção Dedicada – Cópia Completa:
Referência de 300 trabalhadores do conhecimento com excesso de inscrições 12
Dados estatísticos VSImax:
VSIbase = 921 ms, o limite VSI não foi atingido.
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 trabalhadores de energia com 12 assinaturas excessivas
Dados estatísticos VSImax:
VSIbase = 933, o limite VSI não foi atingido.
Estatísticas de carga do sistema de armazenamento do monitoramento SimpliVity:
Durante estes testes, o limite de carga do processador também foi atingido, 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 você executar a carga por 10 horas?
Agora vamos ver se haverá um “efeito de acumulação” e fazer testes por 10 horas seguidas.
Os testes de longo prazo e a descrição da seção deveriam ter como objetivo verificar se surgiriam problemas com a treliça sob carga prolongada sobre ela.
Referência de 300 trabalhadores do conhecimento + 10 horas
Além disso, foi testado um caso de carga de 300 trabalhadores do conhecimento, seguido de trabalho do usuário por 10 horas.
Dados estatísticos VSImax:
VSIbase = 919 ms, o limite VSI não foi atingido.
Dados estatísticos detalhados do VSImax:
O gráfico mostra que não há degradação de desempenho observada durante todo o teste.
Estatísticas de carga do sistema de armazenamento do monitoramento SimpliVity:
O desempenho do sistema de armazenamento permanece o mesmo durante todo o teste.
Testes adicionais com adição de carga sintética
O cliente pediu para adicionar uma carga selvagem ao disco. Para isso, foi adicionada uma tarefa ao sistema de armazenamento em cada uma das máquinas virtuais do usuário para executar uma carga sintética no disco quando o usuário fizer login no sistema. A carga foi fornecida pelo utilitário fio, que permite limitar a carga no disco pelo número de IOPS. Em cada máquina foi lançada uma tarefa para lançar uma carga adicional no valor de 22 IOPS 70%/30% Leitura/Escrita Aleatória.
Referência de 300 trabalhadores do conhecimento + 22 IOPS por usuário
Nos testes iniciais, descobriu-se que o fio impõe uma sobrecarga significativa de CPU nas máquinas virtuais. Isso levou a uma rápida sobrecarga da CPU dos hosts e afetou bastante a operação do sistema como um todo.
Carga da CPU do host:
Ao mesmo tempo, os atrasos no sistema de armazenamento também aumentaram naturalmente:
A falta de poder computacional tornou-se crítica em torno de 240 usuários:
Devido aos resultados obtidos, optou-se por realizar testes com menor consumo de CPU.
Referência de 230 funcionários de escritório + 22 IOPS por usuário
Para reduzir a carga na CPU, foi selecionado o tipo de carga Office Workers e também foram adicionados 22 IOPS de carga sintética a cada sessão.
O teste foi limitado a 230 sessões para não ultrapassar a carga máxima da CPU.
O teste foi executado com usuários rodando por 10 horas para verificar a estabilidade do sistema durante operação de longo prazo próximo à carga máxima.
Dados estatísticos VSImax:
VSIbase = 918 ms, o limite VSI não foi atingido.
Dados estatísticos detalhados do VSImax:
O gráfico mostra que não há degradação de desempenho observada durante todo o teste.
Estatísticas de carga da CPU:
Ao realizar este teste, a carga na CPU dos hosts foi quase máxima.
Estatísticas de carga do sistema de armazenamento do monitoramento SimpliVity:
O desempenho do sistema de armazenamento permanece o mesmo durante todo o teste.
A carga no sistema de armazenamento durante o teste foi de aproximadamente 6 IOPS em uma proporção de 500/60 (40 IOPS de leitura, 3 IOPS de gravação), o que equivale a aproximadamente 900 IOPS por estação de trabalho.
O tempo de resposta foi em média de 3 ms para escrita e até 1 ms para leitura.
Total
Ao simular cargas reais na infraestrutura HPE SimpliVity, foram obtidos resultados que confirmam a capacidade do sistema de suportar desktops virtuais de pelo menos 300 máquinas Full Clone em um par de nós SimpliVity. Ao mesmo tempo, o tempo de resposta do sistema de armazenamento foi mantido em um nível ideal durante todo o teste.
Estamos muito impressionados com a abordagem de longos testes e comparação de soluções antes da implementação. Também podemos testar o desempenho de suas cargas de trabalho, se desejar. Incluindo outras soluções hiperconvergentes. O referido cliente está agora finalizando testes em outra solução em paralelo. Sua infraestrutura atual é simplesmente uma frota de PCs, um domínio e software em cada local de trabalho. Mudar para VDI sem testes é, obviamente, bastante difícil. Especificamente, é difícil compreender os recursos reais de um farm VDI sem migrar usuários reais para ele. E esses testes permitem avaliar rapidamente as reais capacidades de um determinado sistema sem a necessidade de envolver usuários comuns. É daí que veio este estudo.
A segunda abordagem importante é que o cliente se comprometa imediatamente com o dimensionamento adequado. Aqui você pode comprar um servidor adicional e adicionar um farm, por exemplo, para 100 usuários, tudo é previsível pelo preço do usuário. Por exemplo, quando precisarem adicionar mais 300 usuários, saberão que precisam de dois servidores em uma configuração já definida, em vez de reconsiderar a atualização de toda a infraestrutura.
As possibilidades da federação HPE SimpliVity são interessantes. A empresa está geograficamente separada, por isso faz sentido instalar seu próprio hardware VDI separado em um escritório distante. Na federação SimpliVity, cada máquina virtual é replicada de acordo com um cronograma com a capacidade de replicar entre clusters geograficamente distantes muito rapidamente e sem carga no canal - este é um backup integrado de muito bom nível. Ao replicar VMs entre sites, o canal é usado o mínimo possível, e isso torna possível construir arquiteturas de DR muito interessantes na presença de um único centro de controle e vários sites de armazenamento descentralizados.
Tudo isso junto permite avaliar detalhadamente o lado financeiro, sobrepor os custos do VDI aos planos de crescimento da empresa e entender a rapidez com que a solução terá retorno e como funcionará. Porque qualquer VDI é uma solução que, em última análise, economiza muitos recursos, mas ao mesmo tempo, muito provavelmente, sem a oportunidade econômica de alterá-la dentro de 5 a 7 anos de uso.
Em geral, se você tiver alguma dúvida que não seja para comentário, escreva-me por e-mail [email protegido].
Fonte: habr.com