Cisco HyperFlex vs. concorrentes: testando o desempenho

Continuamos apresentando o sistema Hyper-Converged Cisco HyperFlex.

Em abril de 2019, a Cisco realizou novamente uma série de demonstrações da nova solução hiperconvergente Cisco HyperFlex nas regiões da Rússia e do Cazaquistão. Você pode se inscrever para uma demonstração através do formulário de comentários clicando no link. Inscreva-se agora!


Publicamos anteriormente um artigo sobre testes de estresse realizado pelo laboratório independente ESG Lab em 2017. Em 2018, os recursos do Cisco HyperFlex (HX versão 3.0) melhoraram significativamente. Além disso, soluções competitivas também continuam a melhorar. É por isso que estamos publicando uma versão mais recente e mais recente dos testes de carga comparativa do ESG.

No verão de 2018, o laboratório ESG realizou uma comparação repetida do Cisco HyperFlex com os concorrentes. Dada a tendência atual de usar soluções definidas por software, fabricantes de plataformas similares também foram adicionados à análise comparativa.

Configurações de teste


Durante o teste, o HyperFlex foi comparado com dois sistemas hiperconvergentes totalmente de software instalados em servidores x86 padrão, bem como com uma solução de software e hardware. Os testes foram realizados usando o software padrão para sistemas hiperconvergentes - HCIBench, que utiliza a ferramenta Oracle Vdbench e automatiza o processo de teste. Em particular, o HCIBench cria automaticamente máquinas virtuais, coordena a carga entre elas e gera relatórios convenientes e compreensíveis.

140 máquinas virtuais por cluster foram criadas (35 no nó do cluster). Cada máquina virtual usava 4 vCPUs, 4 GB de RAM. O disco da VM local tinha 16 GB e um disco adicional de 40 GB.

As seguintes configurações de cluster participaram do teste:

  • um cluster de quatro nós do Cisco HyperFlex 220C SSD de 1 x 400 GB para cache e HDD SAS de 6 x 1,2 TB para dados;
  • Fornecedor rival Um cluster de quatro nós SSD de 2 x 400 GB para cache e HDD SATA de 4 x 1 TB para dados;
  • cluster rival do Fornecedor B de quatro nós SSD de 2 x 400 GB para cache e HDD SAS de 12 x 1,2 TB para dados;
  • um cluster concorrente do Fornecedor C com quatro nós SSD de 4 x 480 GB para cache e HDD SAS de 12 x 900 GB para dados.

Os processadores e RAM de todas as soluções eram idênticos.

Teste para o número de máquinas virtuais


Os testes começaram com uma carga de trabalho projetada para emular um teste OLTP padrão: leitura / gravação (RW) 70% / 30%, 100% FullRandom com um valor-alvo de 800 IOPS por máquina virtual (VM). O teste foi realizado em 140 VMs em cada cluster por três a quatro horas. O objetivo do teste é economizar atrasos ao gravar no número máximo de VMs a 5 milissegundos ou menos.

Como resultado do teste (veja o gráfico abaixo), o HyperFlex foi a única plataforma que concluiu esse teste com as 140 VMs iniciais e com atrasos abaixo de 5 ms (4,95 ms). Para cada um dos outros clusters, o teste foi reiniciado para ajustar experimentalmente o número de VMs para um atraso de destino de 5 ms em várias iterações.

Fornecedor A tratou com êxito 70 VMs com um tempo médio de resposta de 4,65 ms.
O fornecedor B forneceu os atrasos necessários de 5,37 ms. com apenas 36 VMs.
O fornecedor C conseguiu suportar 48 máquinas virtuais com um tempo de resposta de 5,02 ms



Emulação de carga do SQL Server


Em seguida, o ESG Lab emulou a carga do SQL Server. O teste usou vários tamanhos de bloco e taxas de leitura / gravação. O teste também foi executado em 140 máquinas virtuais.

Conforme mostrado na figura abaixo, o cluster Cisco HyperFlex quase duplicou as IOPS do fornecedor A e B e do fornecedor C em mais de cinco vezes. O tempo médio de resposta do Cisco HyperFlex foi de 8,2 ms. Para comparação, o tempo médio de resposta do fornecedor A foi de 30,6 ms, o fornecedor B foi de 12,8 ms e o fornecedor C foi de 10,33 ms.



Uma observação interessante foi feita durante todos os testes. O fornecedor B mostrou uma variação significativa no desempenho médio no IOPS em diferentes VMs. Ou seja, a carga foi distribuída de maneira extremamente desigual, algumas VMs funcionaram com um valor médio de 1000 IOPS + e outras com um valor de 64 IOPS. O Cisco HyperFlex, nesse caso, parecia muito mais estável, todas as 140 VMs receberam uma média de 600 IOPS do subsistema de armazenamento, ou seja, a carga entre as máquinas virtuais foi distribuída de maneira muito uniforme.



É importante observar que uma distribuição tão desigual de IOPS entre máquinas virtuais para o fornecedor B foi observada em cada iteração de teste.

Na produtividade real, esse comportamento do sistema pode ser um grande problema para os administradores; de fato, máquinas virtuais individuais aleatoriamente "travam" e praticamente não há como controlar esse processo. A única maneira não muito bem-sucedida de balanceamento de carga, ao usar uma solução do fornecedor B, é usar uma ou outra implementação ou balanceamento de QoS.

Conclusão


Vamos pensar, o que são 140 máquinas virtuais no Cisco Hyperflex para 1 nó físico versus 70 ou menos em outras soluções? Para os negócios, isso significa que, para manter o mesmo número de aplicativos no Hyperflex, você precisa de 2 vezes menos nós que as soluções dos concorrentes, ou seja, o sistema final será muito mais barato. Se adicionarmos aqui o nível de automação de todas as operações para atender à rede, servidores e plataforma de armazenamento da HX Data Platform, fica claro por que as soluções Cisco Hyperflex estão ganhando popularidade tão rapidamente no mercado.

Em geral, o ESG confirmou que as versões híbridas do Cisco HyperFlex HX 3.0 oferecem desempenho mais alto e mais estável do que outras soluções semelhantes.

Ao mesmo tempo, os clusters híbridos HyperFlex também superaram seus concorrentes em termos de IOPS e latência. Igualmente importante, o desempenho do HyperFlex foi garantido com uma carga muito bem distribuída em todo o armazenamento.

Lembre-se de que você pode ver a solução Cisco Hyperflex e seus recursos agora. O sistema está disponível para demonstração para todos:

Source: https://habr.com/ru/post/pt446638/


All Articles