Por que o ZFS envia / recebe o envio de tantos dados pela minha LAN?

Question

No último fim de semana, configurei um novo servidor de backup (instalação limpa) para minha máquina principal do FreeNAS e iniciei um backup completo do pool manual entre eles. Ambas as máquinas são de hardware empresarial e rodam rápido, o link entre elas é uma LAN Ótica 10G direta (Chelsio), ambas as máquinas possuem bastante NVMe ZIL / cache rápido e 128GB fast ddr4, com rodapés Xeon v4 e Supermicro. O pool que estou replicando / copiando é de 14 GB de dados reais, deduzido com dados referenciados de 35 GB (2.5x dedup). As piscinas são espelhos listrados (4 conjuntos de espelhos de 3 vias com discos de 6 + TB 7200 da empresa) não RaidZ para que eles não têm sequer paridade para retardá-los. Nada mais está sendo executado nos servidores ou sua conexão, exceto as conexões SSH para as transferências. O comando zfs send inclui os argumentos necessários para enviar os dados deduzidos (embora por supervisão, não compactados).

Comando remetente:

zfs send -vvDRLe mypool@latest_snapshot | nc -N BACKUP_IP BACKUP_PORT

Comando no destinatário:

nc -l PORT | zfs receive -vvFsd my_pool

Eu esperava que uma de duas coisas acontecesse - ou envia 14TB e termina, ou envia 35TB, mas os 21TB que já são enviados (dados deduzidos) são muito rápidos, e apenas 14 e um pouco de TB precisam ser enviados. Mas, em vez disso, parece ter a intenção de enviar todos os 35 TB na íntegra, e incrivelmente devagar - eu fiz algo errado ou entendi mal?

O que eu não entendo é que mesmo com a serialização dos snapshots / datasets, os discos dos servidores de backup estão rodando em quase 100% de acordo com gstat e estão fazendo isso por 4 dias completos agora. Os dados estão chegando corretamente (eu posso montar os snaps / conjuntos de dados que foram concluídos). Mas o envio de todo o conjunto parece demorar cerca de 7 dias, com quase 100% de atividade de disco o tempo todo.

A transferência de 14TB ou até 35TB em um link de 10G entre 2 servidores rápidos - seja qual for a informação de status exibida no console - não deve demorar tanto, a menos que seja incrivelmente ineficiente, o que parece improvável.

Ambos os sistemas podem ler / gravar até mesmo os spinners de HDD em quase 500 MB / s, e o ZFS otimiza o acesso ao disco e não precisa redenpencilhar os dados à medida que são enviados já deduzidos.

Por que está demorando tanto? Por que não está enviando apenas uma vez apenas os blocos brutos da piscina?

Respondendo a alguns pontos dos comentários:

1. netcat (nc): netcat (nc) fornece um transporte não criptografado transparente tcp / túnel para enviar dados entre dois sistemas (entre outros usos) - um pouco como ssh / VPN, mas sem lentidão ou reempacotamento diferente de nu Apertos de mão TCP no fio. No que se refere a zfs send / zfs receive , eles estão em comunicação direta e, além de uma minúscula latência, o link netcat deve ser executado na velocidade máxima que o envio / recebimento pode manipular.
2. Espelhar a velocidade do disco: Um espelho grava na velocidade mais lenta de qualquer disco, mas o ZFS trata os discos como um striped striped (faixas de dados em 4 vdevs em ambos os sistemas, e cada vdev é um espelho). Com o pool de origem 55% cheio e o conjunto de destino vazio, e supondo que as CPUs possam acompanhar, o zfs deve ser capaz de ler simultaneamente de 12 discos e gravar em 4 discos, e as gravações devem ser sequenciais, não há outra atividade de IO. Eu acho que o disco mais lento em qualquer espelho pode seq escrever em > = 125MB / s, o que está muito abaixo da taxa para um HD 7200 empresarial moderno, e o backup pode ser preenchido sequencialmente em vez de IO aleatório. É aí que obtenho uma taxa de replicação sustentada de > > 500MB / s.
3. Tabela Dedup / adequação RAM: A tabela de deduplicação é de cerca de 40 GB na RAM (de bytes por entrada x total de blocos no conjunto de origem por zdb ). Eu configurei um sysctl em ambos os sistemas para reservar 85 GB de RAM para a tabela de deduplicação e outros metadados, portanto cerca de 35 GB para dados em cache, antes de qualquer uso de L2ARC (se usado com send / rcv). Portanto, a dedução e os metadados não devem ser despejados da RAM em nenhuma das máquinas.

Atualização de velocidade e progresso:

• Após o período de execução de 5 dias, tenho algumas estatísticas de progresso atualizadas. Ele está enviando dados com uma média de 58 MB / s. Não completamente desastroso, mas ainda assim, sustenta a questão acima. Eu esperaria uma taxa de cerca de 10 x que, uma vez que os conjuntos de discos podem ler até 12 HDDs de cada vez (quase 2 GB / seg) e gravar até 4 discos de cada vez (cerca de 500 GB / s). Ele não precisa deduzir ou re-deduzir os dados (AFAIK), ele está rodando em Xeon v4 de 3,5 GHz 4 + 8 núcleos com toneladas de RAM em ambos os sistemas, e uma LAN que pode fazer 1GB / s.

Answer 1

Do que você mencionou sobre compactação, presumo que todos os tamanhos / velocidades de armazenamento descritos por você estavam em tamanhos não compactados. Se não, isso poderia tornar os tempos de transferência mais longos por um fator igual à taxa média de compactação (mas não se o acesso ao disco for o gargalo, pois a descompactação / compactação ocorre após a leitura do disco em zfs send e antes de gravar no disco em zfs receive ).

Com base nas informações coletadas até o momento, parece que você tem um gargalo na largura de banda do disco, e não na conexão de rede. Você mencionou que cada sistema pode ler / gravar a ~ 500MB / s, então seu melhor tempo de transferência para 35TB é de cerca de 20 horas (cerca de 2,5x mais lento do que apenas transferir através da rede de 10Gb / s). Mas, com base na sua configuração de espelhamento, surpreende-me que as leituras e gravações recebam o mesmo rendimento - você tem certeza disso? No sistema de envio, você só precisa ler de um disco (para poder fazer a paralelização de leituras em três discos), mas no sistema de recebimento você precisa gravar em todos os três discos (assim você está vinculado à taxa de transferência do disco mais lento). qualquer momento). Para testar a taxa de transferência no lado da recepção, você pode executar dd if=/dev/urandom of=some_file_in_pool bs=1M count=1024 conv=fdatasync .

Como você disse que os discos de recebimento estão 100% ocupados, meu palpite é que ele não alcança a largura de banda de gravação de 500 MB / s. Isso pode ser porque o limite de gravação real é menor do que esse (o comando dd acima deve confirmar), ou pode ser que o sistema tenha que fazer leituras de metadados durante o recebimento, e isso está quebrando suas boas tamanho escrever carga de trabalho, adicionando um monte de procura de disco na mistura. Você deve investigar a segunda hipótese mais profundamente usando o DTrace para ver o que o provedor io acha que seus tamanhos de leitura / gravação são.