No ano passado, analisamos a série QSAN XCubeSAN XS1200 que consideramos ter bom desempenho, bons recursos e um bom preço para os mercados SMB e ROBO que eram seu alvo. Para esta revisão, veremos o mesmo dispositivo com o controlador XS5226 de ponta. Como o design, a construção e o gerenciamento são idênticos (estamos usando o mesmo chassi), os leitores podem consultar o comentário anterior.
No ano passado, analisamos a série QSAN XCubeSAN XS1200 que consideramos ter bom desempenho, bons recursos e um bom preço para os mercados SMB e ROBO que eram seu alvo. Para esta revisão, veremos o mesmo dispositivo com o controlador XS5226 de ponta. Como o design, a construção e o gerenciamento são idênticos (estamos usando o mesmo chassi), os leitores podem consultar o comentário anterior.
Dentro da família XS5200 (muito parecido com a família XS1200), o QSAN oferece vários fatores de forma e um controlador único ou duplo – novamente com S para single ou D para Dual. O XS5226D é um controlador duplo que é ativo-ativo e voltado para maior desempenho para ambientes de missão crítica com os casos de uso ideais sendo HPC, integração de virtualização e M&E. A empresa alega desempenho de até 12 GB/s de leitura sequencial e 8 GB/s de gravação sequencial com mais de 1.5 milhão de IOPS.
Conforme declarado, estamos usando o mesmo chassi, o que significa que há várias áreas de sobreposição entre as duas análises e, portanto, serão ignoradas aqui. No entanto, veremos as principais diferenças de especificação, pois elas afetam diretamente o desempenho.
Especificações do QSAN XCubeSAN XS5226D
| Controlador Raid | Dual-ativo |
| CPU | Intel Xeon D-1500 Quad Core |
| Memória | até 128 GB de DDR4 ECC |
| Tipo de drive | |
| 2.5″ SAS, NL-SAS, SED HDD | |
| SAS de 2.5”, SATA SSD (placa MUX de 6 Gb necessária para unidades SATA de 2.5” em sistema de controlador duplo) | |
| Capacidades de expansão | 2U 26 baias, SFF |
| Unidades máximas suportadas | 286 |
Desempenho
Análise de carga de trabalho do aplicativo
Os benchmarks de carga de trabalho do aplicativo para o QSAN XCubeSAN XS5226D consistem no desempenho do MySQL OLTP via SysBench e no desempenho do Microsoft SQL Server OLTP com uma carga de trabalho TPC-C simulada. Em cada cenário, tínhamos o array configurado com 26 SSDs Toshiba PX04SV SAS 3.0, configurados em dois grupos de discos RAID12 de 10 unidades, um fixado em cada controlador. Isso deixou 2 SSDs como sobressalentes. Dois volumes de 5 TB foram então criados, um por grupo de discos. Em nosso ambiente de teste, isso criou uma carga balanceada para nossas cargas de trabalho SQL e Sysbench.
Desempenho do SQL Server
Cada VM do SQL Server é configurada com dois vDisks: volume de 100 GB para inicialização e um volume de 500 GB para o banco de dados e arquivos de log. Do ponto de vista dos recursos do sistema, configuramos cada VM com 16 vCPUs, 64 GB de DRAM e aproveitamos o controlador LSI Logic SAS SCSI. Embora nossas cargas de trabalho Sysbench testadas anteriormente tenham saturado a plataforma tanto em E/S de armazenamento quanto em capacidade, o teste de SQL procura desempenho de latência.
Este teste usa o SQL Server 2014 em execução em VMs convidadas do Windows Server 2012 R2 e é enfatizado pelo Benchmark Factory para bancos de dados da Quest. Embora nosso uso tradicional desse benchmark tenha sido testar grandes bancos de dados de escala 3,000 em armazenamento local ou compartilhado, nesta iteração nos concentramos em distribuir quatro bancos de dados de escala 1,500 uniformemente no QSAN XS5200 (duas VMs por controlador).
Configuração de teste do SQL Server (por VM)
- Windows Server 2012 R2
- Ocupação de armazenamento: 600 GB alocados, 500 GB usados
- SQL Server 2014
- Tamanho do banco de dados: escala 1,500
- Carga de cliente virtual: 15,000
- Memória RAM: 48 GB
- Duração do teste: 3 horas
- 2.5 horas de pré-condicionamento
- período de amostra de 30 minutos
Equipamento LoadGen de referência de fábrica SQL Server OLTP
- Dell EMC PowerEdge R740xd Cluster SQL virtualizado de 4 nós
- 8 CPU Intel Xeon Gold 6130 para 269 GHz em cluster (dois por nó, 2.1 GHz, 16 núcleos, cache de 22 MB)
- 1 TB de RAM (256 GB por nó, 16 GB x 16 DDR4, 128 GB por CPU)
- 4 x Emulex 16GB FC HBA de porta dupla
- 4 x NIC de porta dupla Mellanox ConnectX-4 rNDC 25GbE
- VMware ESXi vSphere 6.5 / Enterprise Plus 8 CPUs
Para nossos testes, compararemos o novo controlador com o testado anteriormente. Isso é menos um “qual é o melhor” e mais uma “observação do desempenho que se obtém dependendo de suas necessidades”.
Com o SQL Server, a diferença nos controladores realmente não fez muita diferença geral no desempenho. O XS1226 com 4VMs atingiu 12,634.3 TPS e o XS5226 com 4VMs atingiu 12,634.7 TPS.
Com a latência média do SQL, vimos mais do mesmo. O XS1226 teve uma latência de 5.8ms e o XS5226 teve uma latência de 5.0ms.
Desempenho do Sysbench
Cada sysbench A VM é configurada com três vDisks, um para inicialização (~92 GB), um com o banco de dados pré-construído (~447 GB) e o terceiro para o banco de dados em teste (270 GB). Do ponto de vista dos recursos do sistema, configuramos cada VM com 16 vCPUs, 60 GB de DRAM e aproveitamos o controlador LSI Logic SAS SCSI. Sistemas de geração de carga são servidores Dell R740xd.
Dell PowerEdge R740xd MySQL virtualizado cluster de 4 nós
- 8 CPUs Intel Xeon Gold 6130 para 269 GHz em cluster (dois por nó, 2.1 GHz, 16 núcleos, cache de 22 MB)
- 1 TB de RAM (256 GB por nó, 16 GB x 16 DDR4, 128 GB por CPU)
- 4 x Emulex 16GB FC HBA de porta dupla
- 4 x NIC de porta dupla Mellanox ConnectX-4 rNDC 25GbE
- VMware ESXi vSphere 6.5 / Enterprise Plus 8 CPUs
Configuração de teste do Sysbench (por VM)
- CentOS 6.3 64 bits
- Pegada de armazenamento: 1 TB, 800 GB usados
- Percona XtraDB 5.5.30-rel30.1
- Tabelas de banco de dados: 100
- Tamanho do banco de dados: 10,000,000
- Segmentos de banco de dados: 32
- Memória RAM: 24 GB
- Duração do teste: 3 horas
- 2 horas de pré-condicionamento 32 tópicos
- 1 hora 32 tópicos
Em nosso benchmark Sysbench, testamos vários conjuntos de 4VMs, 8VMs, 16VMs e 32VMs. No desempenho transacional, o XS5226D mostrou um forte desempenho com 6,889 TPS para 4 VMs, 13,023 TPS em 8 VMs, 21,645 TPS em 16 VMs e 26,810 TPS em 32 VMs.
Com latência média, o 4VM XS1226 teve um desempenho um pouco melhor que o XS5226D, 18.1ms a 18.6ms, mas o XS5226D superou o controlador anterior nas outras configurações de VM com 19.7ms para 8VM, 23.9ms para 16VM e 41ms para 32VM.
Em nosso benchmark de latência de pior cenário, vemos o mesmo que com latência média: melhor em 4 VM para a série XS1200 e melhor no restante com a série XS5200. Para o XS5226D, vimos latência de 32.7ms para 4VM, 34.8ms para 8VM, 47ms para 16VM e 76.9ms para 32VM.
Análise de Carga de Trabalho do VDBench
Quando se trata de matrizes de armazenamento de comparação, o teste de aplicativo é o melhor e o teste sintético vem em segundo lugar. Embora não seja uma representação perfeita das cargas de trabalho reais, os testes sintéticos ajudam a estabelecer a linha de base dos dispositivos de armazenamento com um fator de repetibilidade que facilita a comparação entre soluções concorrentes. Essas cargas de trabalho oferecem uma variedade de perfis de teste diferentes, desde testes de "quatro cantos", testes de tamanho de transferência de banco de dados comuns, bem como capturas de rastreamento de diferentes ambientes VDI. Todos esses testes utilizam o gerador de carga de trabalho vdBench comum, com um mecanismo de script para automatizar e capturar resultados em um grande cluster de teste de computação. Isso nos permite repetir as mesmas cargas de trabalho em uma ampla variedade de dispositivos de armazenamento, incluindo arrays flash e dispositivos de armazenamento individuais. No lado da matriz, usamos nosso cluster de servidores Dell PowerEdge R740xd:
perfis:
- Leitura aleatória em 4K: 100% de leitura, 128 threads, 0-120% de atualização
- Gravação aleatória em 4K: 100% de gravação, 64 threads, 0-120% de atualização
- Leitura sequencial de 64K: 100% de leitura, 16 threads, 0-120% iorado
- Gravação sequencial de 64K: 100% gravação, 8 threads, 0-120% iorado
- Banco de Dados Sintético: SQL e Oracle
- Clone completo de VDI e rastreamentos de clone vinculados
No desempenho de leitura de pico de 4K, o XS5226D teve desempenho de latência abaixo de milissegundos de até pouco menos de 400K IOPS, com um desempenho máximo de 442,075 IOPS com uma latência de 8.03 ms. Isso superou o XS1200, que atingiu o pico de 284K IOPS e 13.82ms de latência.
Com desempenho de gravação de pico de 4K, o novo controlador teve desempenho de latência abaixo de milissegundos até cerca de 270K IOPS com um pico de 294,255 IOPS com uma latência de 6.27 ms. Para comparação, o controlador antigo tinha desempenho máximo de cerca de 246K com latência de 7.9 ms.
Mudando para o desempenho sequencial, na leitura de 64K, o XS5226D rodou abaixo de 1 ms até cerca de 38K IOPS ou 2.3 GB/s e atingiu o pico de 95,762 IOPS ou 5.99 GB/s com uma latência de 5.34 ms. O XS1200 nem sequer tinha desempenho abaixo de um milissegundo.
Para gravação de pico sequencial de 64K, o XS5226D teve desempenho abaixo de 1ms até cerca de 63K IOPS ou 3.9GB/s. Ele atingiu um pico de cerca de 80K IOPS ou 4.95 GB/s com uma latência de 2.68 ms.
Em nossa carga de trabalho SQL, o novo controlador superou facilmente seu equivalente. O XS5226D teve desempenho de latência abaixo de milissegundos até cerca de 380 IOPS e atingiu o pico de 425,327 IOPS com uma latência de 2.27 ms. Portanto, o controlador XS5226D tinha cerca de 200 mil IOPS a mais com 1 ms de latência menor.
No SQL 90-10, o XS5226D ficou abaixo de 1ms até cerca de 350K IOPS e atingiu o pico de 407,661 IOPS com uma latência de 2.36ms. Mais uma vez, superou o outro controlador que teve toda a sua performance acima de 1ms.
O SQL 80-20 mostrou o XS5226D com desempenho de latência abaixo de milissegundos até cerca de 340K IOPS e um desempenho máximo de 387,085 IOPS com latência de 2.4 ms. Novamente, foi um grande salto de desempenho no XS1200 que teve um desempenho máximo de cerca de 247K IOPS com latência de 3.26ms.
Com o Oracle Workload, o XS5226D chegou a quase 310 IOPS antes de quebrar 1 ms e atingir o pico de 381,444 IOPS com 3.1 ms. O XS1200 atingiu um pico de 246,186 IOPS com uma latência de 4.2 ms.
Com o Oracle 90-10, o XS5226D ficou abaixo de 1ms até cerca de 360K IOPS e atingiu o pico de 407,763 IOPS com uma latência de 1.56ms. Para comparação, o XS1200 atingiu um pico de 248,759 IOPS com latência de 2.2 ms e nunca caiu abaixo de 1 ms durante sua execução.
Para a execução do Oracle 80-20, o XS5226D chegou a quase 350 mil IOPS antes de quebrar 1 ms e atingir o pico de 386,844 IOPS com uma latência de 1.66 ms. O XS1200 ficou acima de 1 ms com um pico de 242,000 IOPS e uma latência de 4.16 ms.
Em seguida, mudamos para nosso teste de clone VDI, Full and Linked. Para VDI Full Clone Boot, o XS5226D ultrapassou a linha de 1ms por um tempo antes de cair em aproximadamente 225K IOPS e atingir o pico de 367,665 IOPS com uma latência de 2.78ms. Um salto impressionante no desempenho em comparação com os 1200K IOPS e a latência de 218ms do XS4.26.
Para o VCI FC Initial Login, o XS5226D teve desempenho de latência abaixo de milissegundos até cerca de 200 IOPS e atingiu o pico em cerca de 260 IOPS com latência de 3ms. O XS1200 atingiu o pico de 185,787 IOPS com latência de 3.91 ms no mesmo teste.
O VDI Full Clone Monday Login viu o XS5226D chegar a cerca de 163K IOPS abaixo de 1 ms e atingindo um pico de 269,724 IOPS com uma latência de 1.86 ms. O controlador anterior conseguiu atingir o pico de 182,376 IOPS com latência de 2.55 ms.
Mudando para VDI Linked Clone, o teste de inicialização mostrou que o XS5226D atingiu aproximadamente 110K com desempenho de latência abaixo de milissegundos e atingiu o pico de 216,579 IOPS com uma latência de 2.36ms. O XS1200 atingiu um pico de 149,488 IOPS com uma latência de 3.39ms.
O login inicial do VDI Linked Clone também viu o XS5226D chegar a aproximadamente 110K com desempenho de latência abaixo de um milissegundo e, em seguida, atingiu o pico de 182,425 IOPS com uma latência de 1.39ms. Compare isso com o XS1200, que teve desempenho máximo de 147,423 IOPS com latência de 1.71 ms.
Por fim, o VDI Linked Clone Monday Login fez com que o XS5226D mais uma vez chegasse a aproximadamente 110K com desempenho de latência abaixo de um milissegundo e, em seguida, atingiu o pico de cerca de 220K IOPS com uma latência de 2.3 ms. O XS1200 atingiu um pico de 148,738 IOPS com uma latência de 3.2ms.
Conclusão
O QSAN XCubeSAN XS5226D é um SAN duplo ativo-ativo que promete mais desempenho do que o XS1226D voltado para SMBs. Para esta revisão, aproveitamos o mesmo chassi com um controlador atualizado. Dito isto, o projeto, a construção e o gerenciamento foram os mesmos e podem ser encontrados em nosso crítica original. O XS5226D destina-se a mais cargas de trabalho de missão crítica e tem casos de uso de destino mais elevados do que o XS1226D, como HPC, M&E e virtualização. Usar o mesmo chassi significa que todos os benefícios de conectividade e alta disponibilidade são os mesmos.
Olhando para o desempenho, em nossa análise de carga de trabalho do aplicativo, a diferença nos controladores realmente não se traduziu em muita diferença de desempenho para nossos benchmarks do SQL Server, embora em outras áreas tenhamos visto ganhos massivos. O TPS para o XS1226 foi de 12,634.3 e para o XS5226 a pontuação foi apenas 0.4 TPS maior em 12,634.7. Vimos uma ação semelhante com latência média com o controlador menor atingindo 5.8ms e o maior atingindo 5.0ms. Com o Sysbench, vimos um desempenho muito melhor do XS1226 em configurações de 4 VMs, mas o XS5226 teve melhor desempenho com mais VMs com desempenho de 32 VMs de 26,810.4 TPS, latência média de 41 ms e pior cenário de 76.9 ms.
Com nossas cargas de trabalho VDBench, houve uma tremenda diferença em quase todos os nossos testes com o XS5226D claramente oferecendo muito mais desempenho. Em nosso 4K, vimos os controladores XS5226D atingirem pontuações acima de 442K IOPS de leitura e 294K IOPS de gravação com latência tão baixa quanto 8.03ms e 6.27ms, respectivamente. O desempenho de 64K mostrou o controlador atingindo quase 6 GB/s de leitura e quase 5 GB/s de gravação. Com nossa carga de trabalho SQL, o controlador teve desempenho máximo em 425 IOPS, 407 IOPS para 90-10 e 387 IOPS para 80-20. A carga de trabalho da Oracle também mostrou alguns números realmente bons com desempenho máximo acima de 381K IOPS, 407K IOPS para 90-10 e 386K IOPS para 80-20 com latências entre 1.56ms e 3.1ms. Para nosso VDI Full Clone e Linked Clone, examinamos Boot, Initial Login e Monday Login. Para desempenho de inicialização, o XS5226D atingiu mais de 367 mil IOPS em FC e mais de 216 mil IOPS em LC. O login inicial mostrou cerca de 260 IOPS de desempenho máximo FC e mais de 182 IOPS para LC. E o Monday Login tinha o controlador XS5226D com mais de 269K IOPS FC e 220K IOPS LC.
No geral, o XS5200 se saiu muito bem, aproveitando ao máximo os SSDs Toshiba PX04 SAS3 que instalamos. O desempenho no total é muito impressionante, pois 6 GB/s de leitura e 5 GB/s de gravação (64K sequencial) de uma SAN SMB é muito bom. Claro, há um certo meio-termo; o conjunto de recursos, a interface e as integrações de software com pacotes populares como o VMware deixam um pouco a desejar, pois você olha para as necessidades corporativas mais sofisticadas. Seja como for, o XS5200 oferece um perfil fantástico de desempenho/custo que fará o trabalho muito bem para grande parte do público-alvo.
Concluindo!
O QSAN XCubeSAN com o controlador XS5226D oferece desempenho muito maior para as cargas de trabalho necessárias, ainda com um preço relativamente bom.
Inscreva-se no boletim informativo StorageReview
