Pool de SSD SATA vs Array de HDD para Milhões de Ficheiros Pequenos: Qual Responde Mais Rápido?

Um pool de SSD SATA é geralmente a melhor escolha quando um NAS tem de abrir repetidamente diretórios, atualizar metadados, indexar bibliotecas, sincronizar árvores de projetos ou servir muitos utilizadores a trabalhar com ficheiros pequenos. Um conjunto de HDDs é geralmente a melhor relação qualidade-preço quando esses ficheiros são principalmente armazenados em vez de constantemente modificados, o conjunto de dados é muito grande e o custo da capacidade é mais importante do que a resposta imediata.

A distinção importante não é simplesmente “SSD é mais rápido que HDD.” O armazenamento de ficheiros pequenos exige latência, metadados, profundidade da fila, travessia de diretórios e comportamento do sistema de ficheiros. Um ficheiro sequencial grande pode ser transmitido bem a partir de discos rígidos, enquanto uma pasta contendo centenas de milhares de ficheiros minúsculos pode parecer lenta mesmo numa rede rápida. O pool certo depende da frequência com que o NAS tem de localizar e modificar esses ficheiros, não apenas da quantidade de terabytes que contém.

O Compromisso Principal: Baixa Latência ou Capacidade Acessível?

Um pool de SSD SATA e um conjunto de HDDs podem ambos fornecer redundância, snapshots, pastas partilhadas e acesso multiutilizador. Diferem no que cada disco tem de fazer antes de os dados começarem a mover-se.

Um HDD tem de rodar um prato e posicionar uma cabeça mecânica sobre a localização solicitada. Num trabalho com ficheiros grandes, esse atraso ocorre relativamente poucas vezes porque o disco pode continuar a ler blocos adjacentes. Num trabalho com ficheiros pequenos, o sistema pode saltar repetidamente entre dados de ficheiros, entradas de diretório, permissões, carimbos de data/hora, somas de verificação, índices e outros metadados. O número de operações torna-se mais importante do que o tamanho de cada transferência.

Um SSD SATA não tem movimento mecânico de procura. Embora o SATA limite a taxa máxima sequencial em comparação com NVMe, um SSD SATA ainda pode processar muito mais operações aleatórias pequenas do que um disco rígido. A Samsung lista dezenas de milhares de IOPS aleatórios 4K para a sua família 870 EVO, ilustrando porque a interface pode ser “apenas SATA” e ainda assim parecer dramaticamente mais responsiva do que discos giratórios durante trabalhos intensivos em metadados. Veja as especificações oficiais de I/O aleatório e resistência do SSD SATA para a diferença entre velocidade sequencial, IOPS aleatórios, consumo de energia e TBW.

Um conjunto de HDDs responde com paralelismo. Espelhos, vdevs RAIDZ ou vários espelhos em striping podem servir mais operações do que um único disco rígido. O cache de RAM também pode tornar as leituras repetidas muito mais rápidas. No entanto, adicionar discos não elimina a latência mecânica, e os layouts de paridade podem adicionar trabalho extra durante pequenas escritas aleatórias.

Quando um Pool de SSD SATA é Melhor para Ficheiros Pequenos

Um pool de SSD SATA encaixa melhor quando ficheiros pequenos estão ativos. Exemplos incluem repositórios de código-fonte, pastas de escritório sincronizadas, arquivos de correio, miniaturas de fotos, ativos de aplicações, raízes web, sistemas de gestão documental, volumes de contentores, repositórios de pacotes e conjuntos de dados com grande número de ficheiros auxiliares.

O benefício aparece primeiro em operações que não se parecem com cópias convencionais de ficheiros. Abrir um diretório, calcular o tamanho da pasta, procurar nomes de ficheiros, verificar permissões, procurar alterações, gerar miniaturas, deduplicar e executar backups incrementais podem todos tocar em metadados ou blocos dispersos. A latência de armazenamento mais baixa reduz a pausa entre essas operações.

Um pool de SSD SATA também pode tornar o acesso multiutilizador mais consistente. Um utilizador a copiar um ficheiro grande é uma carga de trabalho sequencial simples. Dez utilizadores a abrir, renomear, guardar e sincronizar pequenos documentos simultaneamente criam uma fila de operações não relacionadas. Os SSDs lidam com essa fila mista de forma mais elegante porque não reposicionam fisicamente uma cabeça para cada pedido.

Os SSDs SATA são especialmente sensatos quando a rede é 1GbE ou 2.5GbE. A sua velocidade sequencial pode já exceder a largura de banda útil dessas ligações, enquanto o seu I/O aleatório continua valioso para navegação e cargas de trabalho de aplicações. Pagar por números sequenciais ao nível NVMe pode não alterar a velocidade de cópia remota se a rede for o limite.

A limitação é a economia da capacidade. Um pool de SSD redundante que armazena dezenas de terabytes pode custar muito mais do que um conjunto de HDDs. Os SSDs também têm classificações finitas de resistência à escrita. Um conjunto de dados de ficheiros pequenos que reescreve constantemente bases de dados, logs, ficheiros temporários e snapshots deve ser dimensionado com base no TBW ou DWPD, em vez de assumir que qualquer SSD de consumidor é adequado para escritas pesadas indefinidas.

Escolha o modelo de SSD e o nível de redundância como um design de pool, não como unidades isoladas. A correspondência de capacidade e desempenho simplifica a substituição. Mantenha espaço livre disponível, monitorize os indicadores SMART e de desgaste, e mantenha um backup independente. O flash elimina a latência mecânica; não elimina riscos do controlador, firmware, NAND, perda de energia ou operador.

Quando um Array HDD Continua a Ser a Melhor Opção

Um array HDD continua atraente quando os pequenos ficheiros são numerosos mas maioritariamente frios. Um arquivo legal, coleção de pesquisa histórica, árvore de projeto antigo, exportação de fotos concluída, espelho de software ou backup a longo prazo pode conter milhões de ficheiros sem exigir acesso interativo constante.

Para essas cargas de trabalho, a questão chave é com que frequência os utilizadores precisam enumerar ou atualizar o conjunto de dados. Se o NAS grava os ficheiros uma vez, verifica-os e raramente os abre novamente, pagar preços de SSD para toda a capacidade pode oferecer pouco valor diário. Os discos rígidos podem armazenar muito mais dados dentro do mesmo orçamento, deixando mais dinheiro para redundância e backup.

Um array HDD também beneficia da memória. Metadados e pequenos ficheiros frequentemente usados podem ser servidos a partir da RAM após o primeiro acesso. Um sistema com memória suficiente pode, portanto, parecer muito mais rápido durante navegações repetidas do que um teste de arranque a frio sugere. O benefício desaparece quando o conjunto de trabalho é maior que a cache ou quando uma verificação, backup, indexador e carga de trabalho do utilizador competem pelos mesmos discos.

A disposição do array é importante. Múltiplos vdevs espelhados geralmente fornecem mais caminhos de I/O independentes do que um vdev de paridade largo, embora sacrifiquem capacidade utilizável. A paridade pode ser uma escolha forte para armazenamento com prioridade na capacidade, mas escritas síncronas pequenas e atividade intensiva em metadados podem expor o seu overhead. Não existe um “melhor RAID” universal sem conhecer o número de ficheiros, a mistura de leitura/escrita, a profundidade da fila e o objetivo de tolerância a falhas.

Um design híbrido ZFS pode reduzir a diferença sem tornar todo o pool em flash. O OpenZFS documenta que um vdev especial redundante pode conter metadados e, opcionalmente, pequenos blocos de ficheiros. Isto pode mover a travessia de diretórios e blocos pequenos selecionados para SSD enquanto os dados em massa permanecem em HDD. O vdev especial não é um cache descartável; perdê-lo pode significar perder o pool, por isso deve ser protegido pelo menos tão fortemente quanto os vdevs normais.

Para utilizadores que ainda estão a decidir o que deve estar em flash e o que deve estar em discos, o guia da ZimaSpace sobre HDD vs SSD para planeamento de armazenamento NAS oferece um quadro mais amplo de capacidade versus latência.

Como se Comparam em Cargas de Trabalho Reais com Ficheiros Pequenos?

O teste mais útil não é um único benchmark sequencial. Teste as ações que os seus utilizadores realmente realizam. Crie uma árvore de pastas representativa e depois meça a listagem de diretórios a frio e a quente, criação de ficheiros, operações de renomeação, pesquisa de metadados, geração de miniaturas, backup incremental, restauração, varredura antivírus e arranque de aplicações.

Teste também do lado do cliente. Um pool de discos rápido não pode eliminar todas as viagens de ida e volta por ficheiro do SMB, NFS, permissões, encriptação e antivírus do cliente. O guia da ZimaSpace sobre transferências diretas NAS e gargalos de ficheiros pequenos explica porque é que uma pasta de ficheiros pequenos pode mover-se muito mais lentamente do que um único ficheiro de teste grande mesmo quando a ligação de rede está saudável.

Compare em níveis iguais de proteção. Um único SSD SATA não deve ser comparado com um array redundante de quatro discos HDD como se o custo e o risco de falha fossem iguais. Uma comparação justa usa a mesma capacidade utilizável, objetivo de redundância, cobertura de backup e caminho de rede.

Uma plataforma com baias para discos e expansão NVMe torna esta separação mais fácil. O ZimaCube 2 pode combinar a capacidade de vários discos HDD com armazenamento flash mais rápido para aplicações, metadados, índices e conjuntos de dados ativos. O layout correto ainda depende da redundância, backup, velocidade da rede e comportamento medido dos ficheiros.

Qual Layout de Armazenamento Deve Escolher?

Escolha um Pool de SSD SATA Quando

• Os utilizadores interagem com os ficheiros pequenos todos os dias.
• A principal queixa é a navegação por diretórios, indexação, pesquisa, miniaturas ou latência de sincronização.
• A capacidade utilizável necessária é modesta o suficiente para ser protegida com SSDs redundantes e backup.
• O NAS executar bases de dados, contentores, VMs ou outros serviços com I/O aleatório intenso.
• For importante uma operação silenciosa perto de uma secretária ou área de estar.

Escolha um array de HDD quando

• O conjunto de dados for grande e maioritariamente frio.
• Capacidade, redundância e cópia de segurança consumirem a maior parte do orçamento.
• As varreduras interativas de diretórios forem ocasionais em vez de contínuas.
• Puder fornecer RAM suficiente e aceitar operações mais lentas com cache frio.
• O NAS puder estar num local onde o ruído e a vibração dos discos sejam aceitáveis.

Escolha um layout híbrido quando

• O mesmo sistema armazena um grande arquivo e executa aplicações ativas.
• Pode colocar bases de dados, índices, miniaturas, metadados e ficheiros quentes em flash.
• Compreende que um vdev especial ZFS deve ser redundante e ter cópia de segurança.
• Quer a economia dos HDD sem forçar cada operação de pequeno ficheiro para discos giratórios.

Lista de verificação para compra

• Estime o número de ficheiros assim como a capacidade total.
• Meça o tamanho médio dos ficheiros e as taxas diárias de criação, atualização e eliminação de ficheiros.
• Separe a capacidade de arquivo frio do conjunto de trabalho ativo.
• Compare a capacidade utilizável após redundância, não a capacidade bruta do disco.
• Verifique a resistência do SSD e as classificações de carga de trabalho do HDD.
• Teste o comportamento com cache frio e cache quente.
• Mantenha uma cópia de segurança independente independentemente do tipo de pool.

Perguntas frequentes

NVMe vence sempre o SSD SATA para pequenos ficheiros?

Não. NVMe pode fornecer maior profundidade de fila, largura de banda e IOPS, mas um SSD SATA pode já eliminar a latência mecânica que domina a carga de trabalho. Se a rede, aplicação, CPU ou profundidade de fila de utilizador único for o limite, a diferença entre SSD SATA e NVMe pode ser muito menor do que a diferença entre qualquer SSD e HDD.

Mais HDDs podem igualar um pool SSD?

Mais HDDs melhoram a taxa de transferência agregada e fornecem mais caminhos de I/O independentes, especialmente com vdevs espelhados. Eles não eliminam a latência de procura. Um array suficientemente grande pode servir cargas de trabalho pesadas, mas normalmente requer mais discos, energia, refrigeração, espaço e afinação do que um pool SSD de capacidade modesta.

 Será que o Cache SSD é suficiente?

Por vezes, mas o cache só ajuda dados que são acedidos repetidamente e retidos com sucesso. Um conjunto de dados SSD dedicado, volume de aplicação SSD ou vdev especial devidamente concebido oferece uma colocação mais previsível. O cache não deve ser tratado como uma solução universal para uma carga de trabalho fundamentalmente pesada em metadados.

Conclusão final

escolha um pool de SSD SATA quando milhões de pequenos ficheiros forem um conjunto de trabalho ativo. Escolha um array de HDD quando esses ficheiros forem principalmente um problema de capacidade. Escolha armazenamento híbrido quando precisar da economia dos HDD para o arquivo e da latência do flash para as partes que os utilizadores e aplicações tocam todos os dias.