ArmazenamentoReview.com

Orçamento TrueNAS CORE System Showdown

Empreendimento  ◇  NAS pequeno

Há alguns meses, iniciamos nossa competição de montagem de TrueNAS por US$ 800. Resumindo, Brian, Ben e Kevin pegaram US$ 800 e montaram seus próprios sistemas NAS usando o TrueNAS CORE como sistema operacional. Graças à Western Digital, eles não precisaram se preocupar com o armazenamento, pois a WD forneceu diversas opções de SSDs e HDDs para que pudessem escolher. Queríamos ver o que nossa equipe seria capaz de fazer montando cada sistema diferente e como eles se comparariam entre si. Eles gastaram o dinheiro, trocaram farpas e testaram seus sistemas. Vamos descobrir como se saíram.

Para quem não está acompanhando, fizemos um vídeo sobre nossa pequena competição, que você pode encontrar aqui ou em nosso canal do YouTube :

Orçamento TrueNAS CORE Systems

O projeto do estagiário Ben foi provavelmente o mais "faça você mesmo" de todos. Ele foi à Cincinnati Computer Cooperative e à MicroCenter, comprou todas as peças separadamente e montou tudo sozinho. As peças incluíam uma fonte de alimentação OCZ GSX600, uma placa-mãe ASRock B550, 64 GB de memória RAM G.Skill Ripjaws V (2 x 32 GB) DDR4-3600, um processador Ryzen 5 3600, um cooler Chelsio 111-00603+A0 e um gabinete Lian Li Liancool 205. Com o dinheiro extra que sobrou, ele adicionou algumas fitas de LED ao seu computador.

orçamento truenas core

Kevin aproveitou o HPE MicroServer Gen10 Plus com seu processador Xeon e memória ECC. Ele também adicionou uma placa Mellanox ConnectX-5 de 100GbE para obter vantagem sobre as outras configurações e facilitar a configuração de rede. Enquanto as outras configurações usam uma placa de rede de duas portas, Kevin só precisa configurar uma interface de 100GbE.

NAS de Kevin com uma unidade Western Digital

A configuração do Brian fica em algum lugar entre as outras duas. Ele começou com a placa-mãe Supermicro M11SDV-8CT-LN4F, que oferece um processador AMD EPYC 3201 SoC e quatro portas 1GbE, o que representou um gasto considerável. Para a memória RAM, Brian utilizou dois módulos SK hynix PC4-2400T-RD1-11 DDR4 ECC de 8GB. Ele também instalou uma fonte de alimentação Thermaltake de 500W e uma placa de rede 10GbE. Tudo isso foi colocado dentro de um gabinete Fractal Design Node 304. Embora a placa de rede 10GbE que Brian encontrou a um preço fantástico, ela acabou não sendo reconhecida ou funcionando com o software TrueNAS, então ele teve que recorrer a uma placa de rede Emulex reserva do laboratório. A memória RAM usada, importada da China, também apresentou problemas e precisou ser substituída.

Frente TrueNAS CORE AMD EPYC

Orçamento TrueNAS CORE System - Desempenho

Vamos ao que interessa: qual dos três é o melhor? Além dos nossos três sistemas montados por nós mesmos, também temos um TrueNAS Mini que, por acaso, estamos sorteando. O sistema da iXsystems utiliza RAIDZ2, já que veio com 5 HDDs. A plataforma iXsystems TrueNAS Mini X+ oferece a melhor combinação de tamanho do chassi e suporte a discos. Ela suporta cinco HDDs de 3.5" e ainda possui duas baias de 2.5" para SSDs. Então, por que não testá-la como base de comparação? Simples: o Mini X+ foi projetado para máxima resiliência de dados, não para desempenho. Os outros três foram otimizados para serem os mais rápidos neste comparativo, embora isso traga alguns riscos. Se a iXsystems quisesse superar nossos concorrentes, poderia simplesmente esmagá-los com um sistema.

Mini compartimentos iXsystems TrueNAS

Uma palavra rápida sobre as configurações de RAID: o TrueNAS suporta vários, dependendo da compilação. Como usamos compilações radicalmente diferentes, haverá diferentes configurações de RAID. As compilações de Ben e Kevin usam RAIDZ em quatro SSDs, e a compilação de Brian usa Mirror em quatro HDDs.

Examinamos apenas o protocolo de compartilhamento de arquivos SMB para este confronto. Um elemento interessante a ser mencionado é quanta importância vai para a configuração da placa-mãe e do chassi. A plataforma de desktop de Ben, que sem dúvida parece a mais legal, tem apenas duas baias de unidade de 3.5 ″ e também é o maior gabinete de longe.

O gabinete de Brian suporta até seis baias de 3.5″ com atenção ao resfriamento, mas sua placa-mãe tem apenas quatro portas SATA integradas. A compilação do microsservidor HPE de Kevin como uma compilação de estoque tem quatro baias e quatro portas, mas é assim que a plataforma é projetada.

O armazenamento também varia um pouco entre os modelos. No computador do Brian, havia quatro HDDs WD Red de 10 TB, mas infelizmente a porta M.2 NVMe não funcionou como esperado. Já os computadores do Ben e do Kevin usavam quatro SSDs WD Red de 4 TB.

É importante observar na seção de desempenho que a configuração do RAID tem um grande papel em como o desempenho é medido, além da própria seleção da unidade. O RAIDZ terá menos sobrecarga do que o RAIDZ2 e o Mirror terá ainda menos sobrecarga do que o RAIDZ. Com isso dito, a configuração do RAID deve levar em consideração qual é o aplicativo final final, quanta capacidade você precisa e quão resistente a falhas você deseja que sua construção. No final, esses resultados não são voltados para mostrar qual NAS é mais rápido, mas sim como as configurações do TrueNAS funcionam em compilações semelhantes, algumas usando as mesmas unidades, em diferentes configurações de RAID.

Análise de Carga de Trabalho Sintética Corporativa

Nosso armazenamento compartilhado corporativo e processo de benchmark de disco rígido pré-condiciona cada unidade em estado estacionário com a mesma carga de trabalho com a qual o dispositivo será testado sob uma carga pesada de 16 threads com uma fila pendente de 16 por thread e, em seguida, testado em intervalos definidos em vários perfis de profundidade de thread/fila para mostrar o desempenho sob uso leve e pesado. Uma vez que as soluções NAS atingem seu nível de desempenho nominal muito rapidamente, apenas representamos graficamente as seções principais de cada teste.

Testes de pré-condicionamento e estado estacionário primário:

  • Rendimento (Agregado de IOPS de Leitura+Gravação)
  • Latência média (latência de leitura+gravação calculada em conjunto)
  • Latência máxima (latência máxima de leitura ou gravação)
  • Desvio padrão de latência (desvio padrão de leitura + gravação calculado em conjunto)

Nossa Enterprise Synthetic Workload Analysis inclui quatro perfis baseados em tarefas do mundo real. Esses perfis foram desenvolvidos para facilitar a comparação com nossos benchmarks anteriores, bem como valores amplamente publicados, como velocidade máxima de leitura e gravação de 4k e 8k 70/30, que é comumente usado para unidades corporativas.

  • 4K
    • 100% de leitura ou 100% de gravação
    • 100% 4K
  • 8K 70/30
    • 70% de leitura, 30% de gravação
    • 100% 8K
  • 8K (Sequencial)
    • 100% de leitura ou 100% de gravação
    • 100% 8K
  • 128K (Sequencial)
    • 100% de leitura ou 100% de gravação
    • 100% 128K

O primeiro é nosso teste de taxa de transferência de leitura/gravação de 4K. Para leitura, o melhor desempenho foi de Ben com 14,865 IOPS. Kevin ficou em segundo lugar com 11,476. Brian atingiu o terceiro lugar com 595 IOPS. Para gravação, Kevin ficou em primeiro lugar com 3,868 IOPS. Ben ficou em segundo lugar com 2,517 IOPS. Brian ficou em terceiro com 923 IOPS.

Muito disso se resume ao tipo de RAID implantado, embora, com o microsservidor de Kevin versus a construção DIY de Ben, a diferença de IOPS afeta a velocidade da CPU em cada compilação.

O próximo passo é a latência média de 4K. Aqui vemos o mesmo posicionamento acima. Na leitura, Ben vence com 17.2 ms, Kevin fica em segundo com 22.31 ms e Brian fica bem atrás com 429.2 ms. Mudando para a escrita, Kevin conquistou o primeiro lugar com 66.21ms, Ben ficou em segundo com 101.66ms e Brian ficou um pouco mais perto com 276.89ms em terceiro.

A latência máxima de 4K sofreu uma pequena mudança na colocação. Para ler, Ben assumiu o primeiro lugar com 263.96ms, Kevin estava logo atrás dele com 273.44ms e Brian foi o terceiro com 1,091.3ms. Para escrever, Kevin ficou em primeiro com 1,195ms, Brian ficou em segundo para variar com 2,092.5ms e Ben caiu para terceiro com 2,431.7ms.

Nosso último teste 4K é o desvio padrão. Para leitura, Ben ficou em primeiro com 5.94ms, Kevin estava logo atrás com 7.11ms e Brian estava bem atrás de Kevin com 171.75ms. Com gravações, Kevin teve o primeiro lugar com 117.02, Ben não ficou muito atrás com 201.58ms e Brian não ficou muito atrás com 271.13ms.

Nosso próximo benchmark mede 100% de taxa de transferência sequencial de 8K com uma carga de 16T16Q em operações 100% de leitura e 100% de gravação. A compilação de Ben assumiu a liderança na leitura com 47,699 IOPP, Kevin estava logo atrás com 44,848 IOPS e Brian tinha 29,767 IOPS. Para gravação, Ben novamente conquistou o primeiro lugar com 83,866 IOPS, Kevin ficou em segundo lugar com 51,020 IOPS e Brian manteve o terceiro lugar com 33,448 IOPS.

Em comparação com a carga de trabalho fixa de 16 encadeamentos e 16 filas que executamos no teste de gravação 100% 4K, nossos perfis de carga de trabalho mistos dimensionam o desempenho em uma ampla variedade de combinações de encadeamento/fila. Nesses testes, expandimos a intensidade da carga de trabalho de 2 threads/2 filas até 16 threads/16 filas. O tipo de unidade e a configuração de RAID desempenham um papel importante aqui. A paridade adicionada para dar suporte à falha da unidade afeta o desempenho. Com a taxa de transferência, Ben começou o mais alto e alcançou o pico mais alto com 17,317 IOPS, embora sua construção tenha caído um pouco perto do final. Enquanto a construção de Brian começou mais alta que a de Kevin, Kevin foi capaz de ultrapassá-lo em segundo.

Com latência média, todas as três compilações do StorageReview começaram com latência abaixo de um milissegundo. Enquanto eles correm bastante perto, você pode ver a construção de Ben gradualmente à frente de Kevin e ambos se afastando da construção de Brain. Ben terminou com 15.8ms, Kevin com 18.3ms e Brian com 31.2ms.

Para latência máxima, Kevin começou melhor e ele e Ben trocaram o primeiro lugar de um lado para o outro. No final, a construção de Kevin tinha 221ms e a de Ben tinha 285ms. Brian estava bem atrás em terceiro o tempo todo.

O desvio padrão mostrou claramente a construção de Ben à frente o tempo todo. Kevin teve cerca de 3 vezes a latência e Brian teve cerca de 4 vezes.

O último benchmark Enterprise Synthetic Workload é nosso teste de 128K, que é um teste sequencial de blocos grandes que mostra a maior velocidade de transferência sequencial para um dispositivo. Na leitura, Kevin ficou em primeiro lugar com 2.32 GB/s, Ben estava logo atrás dele com 1.81 GB/s e a construção de Brian deve ter perdido a pistola inicial com 734 MB/s. Na gravação, Kevin mais uma vez ficou em primeiro lugar com 2.77 GB/s, Ben e Brian quase empataram com 1.42 GB/s e 1.41 GB/s, respectivamente.

Escolhendo a configuração certa para suas necessidades…

Então, quem ganhou? Realmente depende do que você valoriza mais para sua implantação. A construção mais rápida em relação ao desempenho de E/S tinha apenas dois compartimentos de unidade e uma CPU/RAM de consumo. Com o ZFS, você realmente deseja que os componentes corporativos, como a memória ECC, façam uso da pilha de integridade de dados avançada, portanto, é praticamente desqualificado para todas as implantações, exceto para produção.

Em seguida, olhamos para a construção de Brian, que se aproxima muito do que você precisa do lado do hardware e aumenta as baias de unidade no chassi, mas a placa-mãe suporta apenas quatro discos rígidos. Também estava cheio até a borda com excesso de cabos da fonte de alimentação. Acontece que a chamada para ir ao eBay para NIC e DRAM usados ​​​​foi ruim e a estabilidade geral do sistema foi claramente um passo e meio nas categorias “desviado” e/ou “instável”.

Para o pessoal do DIY, tudo se resumia à construção de Kevin usando um Microserver pronto para uso. O Microserver tem uma pegada menor e preço de entrada mais baixo. Há também todos os componentes corporativos e coisas como o iLo para gerenciamento fora de banda. O sistema limita o armazenamento, porém, com apenas 4 baias e todas elas são SATA, portanto, sem vantagens de alta velocidade. Mesmo assim, oferece o caminho de menor resistência quando se trata de lançar um sistema TrueNAS CORE de orçamento DIY.

Talvez um TrueNAS Mini?

Onde o TrueNAS Mini X+ se encaixa nisso? Em termos de desempenho, não se encaixa. A configuração específica que temos é voltada para resiliência de dados. No entanto, o Mini X+ possui vários recursos interessantes, como 10GbE integrado. O Mini X+ também oferece, sem dúvida, o maior suporte e flexibilidade de armazenamento, com um total de 7 baias para discos.

Além de classificar os sistemas DIY em termos de desempenho, este concurso também mostra uma imagem clara do que se pode fazer no TrueNAS CORE OS e com um orçamento limitado (além de termos armazenamento da WD como parte deste trabalho). Obter uma unidade pronta para uso é sempre a aposta mais segura para pequenas empresas que precisam de garantias (suporte) de fornecedores. Claramente, algumas de nossas construções sofreram um pouco ao seguir a rota DIY.

O valor de um sistema pronto para uso não pode ser enfatizado o suficiente se for para um caso de uso de produção. O iXsystems Mini + tem um preço mais alto, mas suporta 3 discos adicionais do que as plataformas DIY e não teve problemas com o suporte do driver do componente. Claro, também há suporte empresarial para hardware e software, algo que nenhuma das compilações de bricolage poderia fornecer. No final, só depende do que você quer. O TrueNAS CORE é flexível o suficiente para lidar com praticamente qualquer hardware.

Graças à iXsystems, estamos sorteando um TrueNAS Mini. Saiba mais sobre como se cadastrar aqui.

Obtenha os destaques em nosso vídeo de destaques de desempenho abaixo.

Recursos TrueNAS

Envolva-se com a StorageReview

Newsletter | YouTube | Podcast iTunes / Spotify | Instagram | Twitter | TikTok | Feed RSS

Adam Armstrong

Adam é o editor-chefe de notícias da StorageReview.com, gerenciando nossas equipes de conteúdo interno e freelance.