Eu tenho um zpool de 24 unidades composto por 3 vdevs RAIDZ1 executando 8 unidades Seagate Exos X18 de 16 TB por vdev. Isso está em um Supermicro MB com um AMD Threadripper Pro de 64 núcleos (128 threads) e 256 GB de RAM ECC.
A utilização do sistema durante as limpezas mostra no máximo 2 CPUs utilizadas por vez, e o tempo total de limpeza parece levar de cinco a sete dias.
Existe uma maneira de fazer com que todos os núcleos da CPU trabalhem em paralelo no matagal para acelerá-lo?
Responder1
Muito provavelmente a CPU não é o fator limitante do desempenho. Os fusos de 7200 RPM têm cerca de 60 a 70 IOPS aleatórios. Mesmo 24 discos não deixam muito desempenho sobressalente para uma verificação de integridade de prioridade mais baixa.
Planeje o desempenho atual de talvez uma limpeza por semana. Se o objetivo do seu ponto de recuperação for um backup noturno, a fonte de restauração não terá sido totalmente limpa. Algum instantâneo, talvez. O que pode ser aceitável para você.
Considere fazer os backups alinhados aos esfregamentos. Se você fizesse um backup completo toda semana e iniciasse uma limpeza nesse ponto, ele poderia terminar antes do backup completo da próxima semana. Dando garantia extra da integridade do array e, por proxy, do backup. No entanto, não é muito tempo para ter um backup com uma boa verificação de integridade do sistema de arquivos. Considere manter vários backups completos convenientes. A utilidade dos arquivos antigos para seus objetivos de restauração depende de você, mas pelo menos a limpeza associada deve ser concluída.
Responder2
Parece que o trabalho está em andamento na paralelização das operações de leitura/gravação de disco para ZFS, mas o trabalho não está pronto para teste.
Parâmetros e um pouco de matemática para orientar as respostas:
Capacidade por unidade: 16.000.000.000.000 bytes (não 16 TB).
Leitura/gravação sustentada: 270 MB/s (258 MiB/s).
Tempo médio entre falhas: 285 anos.
Erros de leitura de setor não recuperáveis por bit lido: erro de 1 bit por 116.415 TB de dados lidos.
Leitura aleatória 4K QD16 QCD: 170 IOPS.
Gravação aleatória 4K QD16 QCD: 550 IOPS.
Cada vdev RAIDZ1 de 8 unidades está conectado a um HBA PCIe 3.0x de 8 canais que suporta taxa de transferência sustentada de 512 MB/s por unidade conectada.
O HBA está conectado a um slot PCI4.0 x16 em uma placa-mãe de 128 pistas.
Executando em paralelo, o sistema suporta uma leitura completa de todas as 24 unidades de 16 TB em 22 horas.
Minha expectativa é que a esfoliação seja concluída em menos de 24 horas; portanto, o gargalo é a utilização da CPU para verificação da soma de verificação. Dada a disponibilidade de 5 threads/drive computacionais (este é um sistema de 128 threads/24 drives), a paralelização de somas de verificação deve resolver o problema de gargalo.
Por confiabilidade:
A teoria estocástica prevê que a falha da unidade é improvável, dado o MTBF do fabricante de 285 anos e assumindo um intervalo de confiança de seis desvios padrão. No entanto, tenho quatro unidades comprometidas com correção de erros e recuperação de desastres.
A podridão de bits (erros de leitura de setor irrecuperáveis por leitura de bit) é uma preocupação separada, e é por isso que estou preocupado com as operações de limpeza. A taxa de erro esperada é de 1 bit de erro por 116.415 TB de dados lidos. Isso sugere um erro de leitura de bit a cada 14 anos. As leituras contínuas do IFF com taxa de transferência total de 270 MB/s são mantidas 24 horas por dia, 7 dias por semana, por 14 anos.
Esta máquina faz parte de um cluster de hot failover de 1.024 nós e 1 petabyte.