Análise Western Digital Ultrastar DC SN630 VMware vSAN

western digital lançou o Ultrastar DC SN630 em fevereiro deste ano, como parte de uma atualização e rebranding de sua linha Ultrastar (anteriormente HGST) de unidades de data center. Dentro deste portfólio, a Western Digital tem várias ofertas de SSD NVMe empresariais, com o SN200 assumindo o trono como líder de desempenho e o novo SN630 substitui o SN620 no espaço NVMe de porta única mainstream, que é uma alternativa cada vez mais popular aos SSDs SATA e SAS. O SN630, que é o SSD NVMe da Western Digital, vem ajustado para cargas de trabalho centradas na leitura ou cargas de trabalho de uso misto de alta resistência. A construção da unidade em ambos os casos é a mesma, a diferença funcional no nível de superprovisionamento que entra na unidade, que por sua vez produz a classificação de resistência desejada.

western digital lançou o Ultrastar DC SN630 em fevereiro deste ano, como parte de uma atualização e rebranding de sua linha Ultrastar (anteriormente HGST) de unidades de data center. Dentro deste portfólio, a Western Digital tem várias ofertas de SSD NVMe empresariais, com o SN200 assumindo o trono como líder de desempenho e o novo SN630 substitui o SN620 no espaço NVMe de porta única mainstream, que é uma alternativa cada vez mais popular aos SSDs SATA e SAS. O SN630, que é o SSD NVMe da Western Digital, vem ajustado para cargas de trabalho centradas na leitura ou cargas de trabalho de uso misto de alta resistência. A construção da unidade em ambos os casos é a mesma, a diferença funcional no nível de superprovisionamento que entra na unidade, que por sua vez produz a classificação de resistência desejada.

Do ponto de vista do design do SSD, o Ultrastar SN630 usa o controlador interno e a construção do firmware da Western Digital e o próprio BiCS64 3D NAND de 3 camadas da Western Digital. Do ponto de vista da engenharia, uma solução integrada verticalmente como essa está se tornando o padrão para SSDs empresariais de ponta. Embora certamente seja possível usar NAND, controladores e firmware de fontes diferentes, tendemos a ver soluções de melhor desempenho e mais confiáveis ​​de fornecedores que podem fazer todo o trabalho por conta própria. A unidade em si usa um fator de forma U.7 de 2.5" de 2 mm e, como outros SSDs oferecidos pela Western Digital, o SN630 oferece algoritmos proprietários de nivelamento de desgaste e proteção contra perda de energia.

Conforme observado, o SN630 vem em SKUs de uso misto e leitura intensiva. O primeiro vem com capacidades de 6.40 TB, 3.20 TB, 1.60 TB e 800 GB, enquanto o último vem com capacidades de 7.68 TB, 3.84 TB, 1.92 TB e 960 GB. Todas as unidades oferecem Instant Secure Erase (ISE), que usa chaves de criptografia nos bastidores para lidar com a reimplantação e desativação da unidade. A Western Digital também fornece downloads seguros de firmware com autenticação RSA para garantir que o SN630 execute apenas o firmware autêntico. Por último, as unidades são apoiadas por uma garantia limitada de 5 anos.

Nesta revisão, examinamos o desempenho do SN630 no contexto do VMware vSAN. A configuração de revisão usa um chassi Supermicro SuperServer BigTwin 2029BT-HNR de 4 nós, 24 SSDs Ultrastar DC SN630 NVMe e VMware vSAN 6.7 Atualização 1 para aprofundar o desempenho do SN630 com uma perspectiva mais ampla do sistema.

Especificações Western Digital Ultrastar DC SN630

Western Digital Ultrastar DC SN630 VMware vSAN Design e construção

O Western Digital Ultrastar DC SN630 é uma unidade NVMe de 2.5” destinada ao data center. A unidade varia em capacidade de 800 GB a 7.68 TB. O SN630 é envolto em metal preto com um adesivo na parte superior que contém informações como nome, marca, capacidade, número do modelo e certificações.

A frente do chassi Supermicro SuperServer BigTwin possui 24 compartimentos de unidade NVMe de 2.5″, com 6 alocados por nó. Cada nó oferece seu próprio botão LED de localização, bem como um botão liga/desliga discreto.

A parte traseira do BigTwin mostra as quatro bandejas do nó de computação. Cada um vem com uma porta IPMI para gerenciamento fora de banda, VGA, duas portas USB 3, bem como uma NIC configurável pelo usuário. Com nossa configuração, estamos usando uma NIC de quatro portas, com duas portas 10GBase-T e duas portas SPF28 25G. Nossa configuração de teste aproveitou as conexões 25G para o cluster vSAN. Todos os nós compartilham uma plataforma de energia dual-PSU comum como parte do design do chassi.

Western Digital Ultrastar DC SN630 Configuração VMware vSAN

Para testar os 24 SSDs SN630 em um ambiente vSAN, usamos um sistema de quatro nós Supermicro SuperServer BigTwin 2029BT-HNR. A configuração por nó é a seguinte:

• 2 x CPUs Intel Gold 6150 (2.7 GHz, 18 núcleos)
• 12 x 32 GB de RAM DDR2666 ECC de 4 MHz
• 2 SSDs Western Digital Ultrastar DC SN800 NVMe de 630 GB para cache vSAN
• 4 SSDs Western Digital Ultrastar DC SN1.92 NVMe de 630 TB para capacidade vSAN
• 1 x SSD SATA Western Digital Blue de 500 GB para unidade de inicialização
• Porta dupla 25 Gb Mellanox ConnectX-4 NIC
• VMware ESXi 6.7u1 (10302608)

Aproveitamos uma construção de servidor bastante modesta para nosso teste VMware vSAN em torno do Western Digital Ultrastar DC SN630. Os servidores usaram CPUs Intel Gold 6150 de médio porte, com uma velocidade de clock de 2.7 GHz e uma contagem de núcleo de 18. Por servidor, isso nos dá 97.2 GHz de potência de computação ou 388.8 GHz no nível do cluster. Também usamos 384 GB de RAM por nó, o que nos deu bastante memória para nossas cargas de trabalho sintéticas e de aplicativos.

Em nossa configuração de teste, usamos um layout de dois grupos de discos por nó, cada um com um SSD SN800 NVMe de 630 GB para cache e dois SSDs SN1.92 NVMe de 630 TB para capacidade. A capacidade utilizável se resume a como as VMs são provisionadas no cluster, bem como ao nível de espelhamento que você usa. O armazenamento bruto mede 27.95 TB em nosso cluster, mas com a política de VM de espelhamento bidirecional padrão com sobrecarga do vSAN, ficamos com 13.79 TB de capacidade utilizável. A redução de dados, no entanto, estende isso drasticamente para determinados tipos de carga de trabalho.

Embora nossas cargas de trabalho de aplicativos se concentrem no desempenho do cluster com a redução de dados desativada, incluiremos benchmarks sintéticos que mostram o desempenho do cluster com e sem a redução de dados ativada. Embora a redução de dados tenha um componente de sobrecarga de desempenho associado a ela, ela aumentará drasticamente a capacidade utilizável do cluster vSAN em determinadas implantações.

Análise de desempenho do Western Digital Ultrastar DC SN630 VMware vSAN

Desempenho do SQL Server

O protocolo de teste OLTP do Microsoft SQL Server da StorageReview emprega o rascunho atual do Benchmark C (TPC-C) do Transaction Processing Performance Council, um benchmark de processamento de transações on-line que simula as atividades encontradas em ambientes de aplicativos complexos. O benchmark TPC-C chega mais perto do que os benchmarks sintéticos de desempenho para medir os pontos fortes de desempenho e os gargalos da infraestrutura de armazenamento em ambientes de banco de dados.

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 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 da Dell para bancos de dados. 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 em nossos servidores.

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

Para nosso benchmark SQL Server transacional, o Western Digital Ultrastar DC SN630 VMware vSAN no Supermicro BigTwin conseguiu atingir uma pontuação agregada de 12,610.3 TPS com VMs individuais executando de 3,152.01 TPS a 3,153.2 TPS.

Com o SQL Server, vimos uma pontuação agregada de 14.75ms com VMs individuais variando de 14ms a 15ms.

Desempenho do Sysbench MySQL

Nosso primeiro benchmark de aplicativo de armazenamento local consiste em um banco de dados Percona MySQL OLTP medido via SysBench. Este teste mede o TPS (transações por segundo) médio, a latência média e também a latência média do 99º percentil.

Cada VM do Sysbench é 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.

Configuração de teste do Sysbench (por VM)

• CentOS 6.3 64 bits
• 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

Com o Sysbench OLTP, testamos 8VM e obtivemos uma pontuação agregada de 11,739.7 TPS com VMs individuais variando de 1,326 TPS a 1,552.3 TPS.

Com a latência do Sysbench o servidor teve uma média de 21.86ms.

Em nosso pior cenário (99º percentil), a latência das unidades Western Digital nos deu 38.71ms.

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.

perfis:

• 4K Random Read: 100% Read, 128 threads, 0-120% iorate
• 4K Random Write: 100% Write, 64 threads, 0-120% iorate
• 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

Em todos os nossos testes VDBench, testamos as unidades Western Digital com o DR ativado e desativado. Com leitura aleatória de 4K, ambas as configurações começaram com menos de 1 ms, com a versão DR aparecendo e atingindo o pico de 387,937 IOPS com uma latência de 7.5 ms. Com a DR desativada, as unidades permaneceram abaixo de 1ms até pouco mais de 350 IOPS e atingiram o pico de 442,089 IOPS com uma latência de 4.8ms.

Para gravação em 4K novamente, ambas as configurações começaram logo abaixo de 1ms. A versão DR tinha latência abaixo de milissegundos até cerca de 90 IOPS e atingiu o pico de 182,791 IOPS com uma latência de 7.4 ms. Com o DR desativado, vimos as unidades permanecerem abaixo de 1 ms até cerca de 110 IOPS e atingirem o pico de 196,027 IOPS com cerca de 7 ms de latência antes de cair um pouco.

Em seguida, temos nossas cargas de trabalho sequenciais. Na leitura de 64K, a versão DR começou acima de 1 ms e atingiu o pico de 132,918 IOPS ou 8.3 GB/s com latência de 3.7 ms. Com a DR desligada, as unidades permaneceram abaixo de 1ms até cerca de 130K IOPS ou cerca de 8GB/s e atingiram o pico de 159,681 IOPS ou 9.98GBs com latência de 2.87ms.

Na gravação de 64K, ambas as configurações começaram com latência abaixo de milissegundos, mas rapidamente passaram de 1 ms. Com o DR ativado, vimos um pico de apenas 22.7 K IOPS ou cerca de 1.4 GB/s e uma latência de 1.32 ms antes de uma queda no desempenho e um grande pico de latência. Com a DR desligada, as unidades atingiram um pico de 63,347 IOPS ou cerca de 4 GB/s a 3.3 ms antes de cair um pouco.

Nosso próximo conjunto de testes são nossas cargas de trabalho SQL: SQL, SQL 90-10 e SQL 80-20. Para SQL, ambas as configurações começaram abaixo de 1 ms com a versão DR indo acima e abaixo de 1 ms, chegando ao pico de 349,851 IOPS com latência de 2.6 ms. Com a DR desligada, as unidades tiveram latência abaixo de milissegundos até cerca de 255 IOPS e atingiram o pico de 358,787 IOPS com uma latência de 2.24 ms antes de uma ligeira queda.

Com o SQL 90-10, vimos novamente a versão habilitada para DR aparecer acima e cair abaixo da linha de 1 ms algumas vezes antes de atingir o pico de 283,524 IOPS com latência de 3.42 ms. A versão não DR ficou abaixo de 1ms até cerca de 275K IOPS e atingiu o pico de 334,737 IOPS com uma latência de 2.45ms.

O SQL 80-20 viu ambas as configurações começarem com latência abaixo de milissegundos com a versão DR passando de 1ms a cerca de 155K IOPS e atingindo um pico de 256,926 IOPS a uma latência de 3.5ms. A versão não DR atingiu cerca de 210 IOPS abaixo de 1 ms e atingiu o pico de 281,562 IOPS com uma latência de 2.83 ms.

A seguir estão nossas cargas de trabalho Oracle: Oracle, Oracle 90-10 e Oracle 80-20. Com o Oracle, a versão habilitada para DR oscilou abaixo e acima de 1ms e atingiu um pico de cerca de 264K IOPS a 3.7ms antes de cair ligeiramente. A versão não DR tinha latência abaixo de milissegundos até cerca de 250 IOPS e atingiu o pico de 314,954 IOPS 3.17 ms.

O SQL 90-10 viu a versão habilitada para DR ficar abaixo de 1ms até cerca de 225K IOPS e atingir o pico de 252,034 IOPS com uma latência de 2.44ms. O não DR teve desempenho de latência abaixo de milissegundos até cerca de 300 IOPS e atingiu o pico de 338,146 IOPS com uma latência de 1.72 ms.

Com SQL 80-20 A versão DR faz algumas oscilações em torno de 1 ms e atingiu um pico de 225,327 IOPS com uma latência de 2.64 ms. A versão não DR tinha latência abaixo de milissegundos até cerca de 211K IOPS e chegou ao pico de 278,051 IOPS e uma latência de 2ms.

Em seguida, mudamos para nosso teste de clone VDI, Full and Linked. Para VDI Full Clone (FC) Boot, ambas as configurações começaram abaixo de 1ms com a versão DR indo acima da latência abaixo de milissegundos em cerca de 85K IOPS e chegando ao pico de 250,209 IOPS e uma latência de 4.04ms. A versão não DR permaneceu abaixo de 1 ms até cerca de 200 IOPS e atingiu um pico de 283,786 IOPS e uma latência de 3.31 ms antes de cair ligeiramente.

Com o VDI FC Initial Login, a versão DR atingiu um pico de cerca de 129K IOPS a 4.2 ms antes de diminuir o desempenho e aumentar significativamente a latência. A versão não DR começou abaixo de 1ms e permaneceu lá até cerca de 75K IOPS e atingiu o pico de 139,401 IOPS com uma latência de 6.3ms com uma ligeira queda.

O VDI FC Monday Login teve a versão DR iniciada com menos de 1 ms, mas rapidamente superou e atingiu o pico de 108,611 IOPS com uma latência de 2.22 ms. A versão não DR permaneceu abaixo de 1 ms até quase 90 IOPS e atingiu o pico de 152,516 IOPS com uma latência de 3.25 ms.

Para VDI LC Boot, ambas as configurações começaram abaixo de 1ms com o DR aparecendo imediatamente e chegando ao pico de 214,327 IOPS com latência de 2.34ms. A versão não DR permaneceu abaixo de 1ms até cerca de 205K IOPS e atingiu o pico de 255,235 IOPS e uma latência de 1.85ms.

VDI LC Initial Login viu o pico da versão DR em cerca de 95K IOPS com uma latência de 2.2 ms antes de cair significativamente. A versão não DR ficou abaixo de 1ms até aproximadamente 65K IOPS e atingiu o pico de 112,182 IOPS com uma latência de 2.23ms.

Finalmente, o VDI LC Monday Login pintou uma imagem semelhante à anterior, com a versão DR atingindo cerca de 108K IOPS com uma latência de cerca de 3.7ms antes de cair um pouco. A versão não DR tinha latência abaixo de milissegundos até cerca de 65 IOPS e atingiu o pico de 126,656 IOPS com uma latência de 3.91 ms.

Conclusão

O Western Digital Ultrastar DC SN630 é o novo SSD NVMe de data center que vem em dois tipos: centrado na leitura e de uso misto. As unidades vêm em intervalos de capacidade de 800 GB a 6.4 TB para uso misto e 960 GB a 7.68 TB para leitura centrada. A unidade aproveita o controlador, o firmware e o NAND BiCS 64D de 3 camadas da Western Digital. Todas as unidades oferecem ISE, o que é ótimo para reimplantação ou aposentadoria. Outro recurso de segurança é o uso de downloads seguros de firmware com autenticação RSA para garantir que o SN630 execute somente o firmware autêntico. Como o SN630 é certificado pelo vSAN, nós o testamos no contexto do VMware vSAN para ver seu desempenho.

Para desempenho, executamos o SSD Western Digital DC SN630 NVMe por meio de nossa análise de carga de trabalho de aplicativo e nossa análise de carga de trabalho VDBench. Para análise de carga de trabalho de aplicativos, as unidades apresentam alguns bons números. No SQL Server, o SN630 teve uma pontuação transacional agregada de 12,610.3 TPS e uma latência média agregada de 14.8 ms. Com o Sysbench, o SN630 atingiu 11,739.7 TPS, uma latência média de 21.86ms e, em nosso pior cenário, os drives nos deram uma pontuação agregada de 38.71ms.

Em nossas cargas de trabalho VDBench, testamos as unidades com o DR ativado e desativado. Obviamente, o DR desligado resultará em melhor desempenho, no entanto, vários clientes precisam executar o DR e é bom ter uma ideia de como as unidades funcionarão com o DR ativado. Os destaques para DR desativado incluem 442K IOPS em leitura de 4K, gravação de 196K IOPS em 4K, 9.98GB/s em leitura de 64K e gravação de 4GB/s em 64K. Em nossas cargas de trabalho SQL, vimos 359 IOPS, 335 IOPS no SQL 90-10 e 282 IOPS no SQL 80-20. Para Oracle, vimos desempenho máximo de 315 IOPS, 338 IOPS no Oracle 90-10 e 278 IOPS no Oracle 80-20. Em nosso teste de clone VDI, o SN630 nos deu 284 IOPS na inicialização, 139 IOPS no login inicial e 153 IOPS no login de segunda-feira para o clone completo. No clone vinculado, o SN630 atingiu 255 IOPS de inicialização, 112 IOPS no login inicial e 127 IOPS no login de segunda-feira.

Para nossas cargas de trabalho VDBench com habilitação de DR, o SN630 teve destaques de 388K IOPS em leitura de 4K, 183K IOPS de gravação em 4K, 8.3GB/s em leitura de 64K e 1.4GB/s em gravação de 64K. Em nossas cargas de trabalho SQL, vimos 350 IOPS, 283 IOPS no SQL 90-10 e 257 IOPS no SQL 80-20. Para Oracle, vimos desempenho máximo de 264 IOPS, 252 IOPS no Oracle 90-10 e 225 IOPS no Oracle 80-20. Em nosso teste de clone VDI, o SN630 nos deu 220 IOPS na inicialização, 129 IOPS no login inicial e 109 IOPS no login de segunda-feira para o clone completo. No clone vinculado, o SN630 atingiu 214 IOPS na inicialização, 95 IOPS no login inicial e 108 IOPS no login na segunda-feira.

Quando usado no VMware vSAN, o SSD Western Digital DC SN630 oferece desempenho impressionante mesmo com o DR ativado. Nesse caso, aproveitamos uma construção de servidor modesta e ainda assim vimos resultados impressionantes. O SN630 seria uma boa escolha para aqueles que utilizam o vSAN.

Página do produto WD Ultrastar DC SN630

Discuta esta avaliação

Inscreva-se no boletim informativo StorageReview

*O teste de desempenho no qual esta análise foi baseada foi encomendado pela Western Digital