Por que grandes exclusões, cópias, movimentações no meu NAS do ZFS bloqueiam todos os outros pedidos de veiculação?

Question

Eu tenho um dispositivo NAS baseado em ZFS do Solaris 11 com unidades SATA de 12,2 TB e 7,2k rpm em uma configuração espelhada.

Ele fornece dois serviços do mesmo pool - um servidor NFS para um farm de VM pequeno e um servidor CIFS para uma pequena equipe para hospedar arquivos compartilhados. O CIFS ZFS tem dedução, enquanto o sistema de arquivos NFS ZFS desclassifica. A compressão está em todos os lugares. Estou capturando instantaneamente cada sistema de arquivos todos os dias e mantendo os últimos 14 instantâneos.

Eu me deparei com um problema de desempenho em casos em que eu estou movendo, copiando ou excluindo uma grande quantidade de dados enquanto estiver diretamente conectado ao SSH no NAS. Basicamente, o processo parece bloquear todas as outras operações de E / S, até o ponto de parada das máquinas virtuais, porque elas recebem tempos limite de disco.

Eu tenho algumas teorias sobre por que isso deveria ser o caso, mas gostaria de ter algumas dicas sobre o que eu poderia fazer em seguida.

Ou:

1) o hardware não é bom o suficiente. Eu não estou tão convencido disso - o sistema é um HP X1600 (single Xeon CPU) com 30GB de RAM. Embora as unidades tenham apenas 7,2k SATA, elas devem empurrar um máximo de 80 IOPS cada, o que deve me dar mais do que o suficiente. Feliz por ser provado errado.

2) Eu configurei errado - mais do que provável. Vale a pena transformar o dedup off em todos os lugares? Eu estou trabalhando sob a suposição de que RAM = bom para dedup, portanto, dando-lhe uma razoável splodge de RAM.

3) Solaris sendo estúpido em programar IO. É possível que um comando local rm bloqueie completamente o IO para o nfsd? Se sim, como eu mudo isso?

    

Answer 1

A opção nº 2 é provavelmente o motivo. O Dedup executa melhor quando a tabela de dedução (DDT) se ajusta totalmente na memória. Caso contrário, transbordará para o disco, e as pesquisas de DDT que precisam ir para o disco são muito lentas e isso produz o comportamento de bloqueio.

Eu acho que 30G de RAM é suficiente, mas o tamanho do DDT depende diretamente da quantidade de dados sendo deduzidos e de como a dedup funciona nos dados. A propriedade de dedução é definida no nível do conjunto de dados, mas as pesquisas são feitas em todo o pool, portanto, há apenas um DDT de todo o pool.

Veja este tópico do zfs-discuss sobre como calcular o tamanho do DDT. Essencialmente, é uma entrada DDT por bloco único no conjunto, portanto, se você tiver uma grande quantidade de dados, mas uma baixa taxa de desclassificação, isso significa mais blocos únicos e, portanto, um DDT maior. O sistema tenta manter o DDT na RAM, mas parte dele pode ser despejada se a memória for necessária para os aplicativos. Ter cache L2ARC pode ajudar a impedir que o DDT vá para os discos do pool principal, pois ele será despejado da memória principal (ARC) para o L2ARC.

    

Answer 2

Uma coisa a ter em mente com o ZFS e os instantâneos é que nada é gratuito e, como você remove grandes quantidades de dados, espera que os instantâneos continuem mantendo esses dados, especialmente se você tiver um grande número de instantâneos À medida que você realiza suas exclusões, as capturas instantâneas precisam ser atualizadas de acordo para refletir as alterações feitas no sistema de arquivos. Eu estou supondo que você tem 6 VDEVs, basicamente 6 espelhos no pool, o que significa que você realmente tem que realizar essas mudanças em todos os discos, já que os dados são bastante uniformemente distribuídos em cada VDEV. Com a dedup, a situação fica muito mais complicada, especialmente se a relação é boa, e se a relação é ruim, não a use. Em essência, se a proporção for boa ou ótima, você terá um grande número de referências, todas elas, é claro, metadados e todas elas precisam ser atualizadas, junto com instantâneos e metadados relacionados a snapshots. Se os sistemas de arquivos possuem pequenos blocos, as situações ficam ainda mais complexas, devido à quantidade de referências. é muito maior para um conjunto de dados de 4K quadsize contra um conjunto de dados de 128K.

Basicamente, há poucas coisas que você pode fazer, além de: 1) Adicionar SSDs de alto desempenho como dispositivos de cache e ajustar seu sistema de arquivos para usar dispositivos de cache apenas para metadados; 2) reduzir grandes operações de exclusão / destruição; ) reconsidere o uso da deduplicação. Mas você não pode simplesmente desabilitar a desduplicação em um pool ou em um sistema de arquivos. Se habilitado em todo o pool, você terá que recriar o pool ou, se definido em um sistema de arquivos individual, a destruição e a recriação do sistema de arquivos resolverá o problema.

Na Nexenta, temos muito cuidado com a desduplicação quando a recomendamos aos clientes. Há muitos casos em que é uma solução brilhante e o cliente não poderia viver sem ela. E nesses casos, geralmente temos clientes que usam 96 GB de RAM ou mais, para manter mais metadados e o DDT na RAM. Assim que os metadados do DDT são enviados para a mídia, tudo literalmente chega a um ponto insuportável. Espero que isto ajude.