ZFS: Conselho de configuração 1x NVMe como ARC e ZIL e 4x SSDs para zvols para virtualização

Question

Então, recentemente, ao testarmos um sistema ZoL, descobrimos um desempenho ruim de leituras aleatórias e sequenciais e um desempenho ruim de gravações aleatórias em nossos SSDs.

Nosso sistema é uma faixa de 2x SSDs Samsung 1TB 850Evo para testar o desempenho do ZFS e foi péssimo em comparação com o LVM: as leituras são mais lentas que as HDDs e as gravações não estão no mesmo patamar de 1,7 GB esperadas nos LVMs. É estranho porque nosso servidor de backup do FreeBSD tem HDDs lentos e um tipo mais antigo de SSD e funciona melhor no mesmo teste.

O sistema é um pouco privado da memória RAM (o zfs recebe 4gb para o arco e todo o resto é feito pelas VMs), mas sem cache e sem sincronização, o desempenho ainda não está nem perto de nada.

Portanto, estamos procurando comprar sistemas mais novos baseados no AMD Epyc e configurar NVMe ou NVMe completos com SSDs com a desativação do cache para liberar o RAM do ZFS pelo menos um pouco (queremos usar o máximo de 10 GB para tudo). Nós realmente não precisamos de todos os recursos de segurança do ZFS separados do checksum (mas com SSDs parece ser redundante, já que o SSD executa um sistema de checksum interno) para que os SSDs sejam uma faixa de vdevs.

Preferimos o ZFS for zle em zvols com provisionamento thin e a facilidade de captura instantânea e backups incrementais para o sistema remoto (que também executa o ZFS).

No entanto, a luta pelo desempenho é difícil ...

Agradeceria muito qualquer conselho

    

Answer 1

Se alguém se perguntar. Achamos que o principal problema é a RAM (nosso ARC é limitado a 4 GB e todo o resto é comido pelo sistema). O acordo com o ZFS no momento - ele não está pronto para SSDs e / ou NVMe. Foi feito para HDDs, lentos e volumosos com suas cabeças bobas, mecânica e problemas previsíveis.

Com SSDs e NVMe O ZFS executa coisas bobas de que não precisa e não faz as coisas de que realmente precisam. Quando o ZFS foi inventado, não se pensou em mais nada de cache de RAM não volátil.

Agora podemos colocar 4x SSDs em um sistema com 4 TB de espaço.

Existem duas maneiras de lidar com isso nesse caso. Dê a ele memória suficiente e deixe-o executar adequadamente em seus SSDs com as despesas gerais que ele fornece. Ou não use o ZFS.

É uma pena, porque seus benefícios estruturais são muito bons. Mas ele não pode lidar com SSDs adequadamente sem maior uso de RAM do que com HDDs porque todas as configurações dizem que "os sistemas subjacentes são lentos, o cache é necessário, é pequeno, escreve grande e sequencial" quando os SSDs são rápidos, não precisam cache, pode ler grande e escrever grande e fazer aleatoriamente corretamente. Com a Optane, tais problemas serão óbvios.

Coisas que são mais ou menos desnecessárias são cache extenso, soma de verificação de cada arquivo no nível do registro (não faz sentido porque se você tiver bitrot no nível SSD você deve jogar fora todo o drive, pois existem nenhum uso para tal sistema porque pode ter o controlador quebrado arruinando seus dados inteiros, é similar a RAM ruim). SIL não é necessário a todos. O ARC também é inútil, especialmente com unidades Optane (acrescenta mais sobrecarga à CPU e à RAM). O tamanho do registro deve ser perfeitamente limitado para escrever em transações que o drive entende.

Ou apenas use o LVM para provisionamento do KVM em sistemas. O thin-provisioning não é perfeito, mas pelo menos você não precisa desperdiçar RAM extremamente valiosa para fazer com que seus SSDs tenham o mesmo nível de desempenho esperado.

    

Answer 2

Primeiro, a soma de verificação do ZFS é não redundante: é um cheksum de ponta a ponta (RAM para mídia física), enquanto a soma de verificação HDD / SSD é controlada por erros de "mídia interna". Para ter algo parecido com o sistema de arquivos clássico, você tinha para usar discos e controladores compatíveis com T10 / DIF, que faltam nos dispositivos SATA (você é forçado a usar SAS SSD, que são muito mais caros).

Dito isso, o baixo desempenho de gravação com ZVOLs é geralmente devido ao pequeno tamanho de bloco padrão de 8K, que é pequeno o suficiente para aumentar a sobrecarga de metadados, mas não pequeno o suficiente para evitar ciclos de leitura-modificação-gravação para gravações 4K. / p>

Outro problema com os discos SATA SSD do consumidor (como o seu Samsung 850 EVO) é que eles não têm nenhum cache protegido por powerloss, portanto o ZFS os libera constantemente para gravação de dados síncronos e de metadados.

De qualquer forma, você deve nos fornecer mais detalhes sobre sua metodologia de benchmark para o fim da carga de trabalho esperada do mundo real para obter uma resposta precisa.

    

Answer 3

O desempenho é ruim porque os padrões do ZFS não são ideais para o que você está fazendo. Você tem alguma coisa em /etc/modprobe.d/zfs.conf ? Se não, requer algum ajuste .

• As VMs estarão em execução no mesmo servidor da instalação do ZFS?
• Se sim, o ZIL não é necessário; é útil apenas para atividades de gravação síncrona, como apresentar o NFS ao VMware e alguns bancos de dados.
• Eu uso um tamanho de bloco de 128K para o armazenamento do ZFS em discos nativos.
• Para o Linux, os zvols precisam ser volblocksize=128K
• Eu uso o ashift = 13 para todos os zpools SSD-ZD, ashift = 12 para todo o resto.
• Não desative o ARC. Limite-o se necessário, mas parece que você não tem muita memória RAM.
• Não desative a soma de verificação.
• FAÇA ativar a compactação LZ4! Não há razão para não.
• O que você pretende fazer com o NVMe + 4xSSD?

Answer 4

Especificamente se alguém usa o docker (como eu), o UFS não é uma solução de produção real se você criar regularmente ou tiver muitos contêineres e volumes (como eu faço :)).

Como o docker pode usar um back-end do ZFS, ainda haverá pessoas que desejam usar SSDs & Optane no sistema executando o ZFS.

@Andrew Encontrei alguns dos problemas que você cometeu, & tive que corrigir meus problemas com RAM massiva (32G para ARC). o servidor geral agora tem 128 GB de RAM, mas consegue um desempenho incrível em poucos sistemas.

Outro conjunto de pessoas será o ZFS, na AWS, para contornar o burstIO - essencialmente, todos os volumes do seu EBS SSD estão apenas esperando para começar a mostrar o desempenho do SATA 5.4K assim que seu saldo de burst diminuir. Nesse tipo de situação, vejo o ZFS mudar de repente para IO sequencial grande para acompanhar. contanto que meus aplicativos monitorem o burstbalance & reduz o IO, o ZFS tentará manter as coisas saudáveis.

Espero que algo muito semelhante seja experimentado pelas pessoas da VMWare quando o seu array de armazenamento hierárquico além da sanidade começa a tentar gerir dinamicamente o desempenho em tempos extremos de IO & latência crescente

Estou ciente dos projetos de sistemas de armazenamento nos quais um cache de RAM essencialmente grande é usado como o pool de gravação - isso basicamente significa que o armazenamento relata todas as gravações como ocorrências de cache & o teste para o disco acontece mais tarde

Pelo menos com o ZFS eu sei que programadores reais fizeram isso.

Portanto, ainda resta algum valor com o ZFS em SSDs :) - depende dos tipos de problemas que você encontra.