Melhor compactação para envio / recado do ZFS

Question

Estou enviando instantâneos incrementais do ZFS por meio de uma linha T1 ponto a ponto, e chegamos a um ponto em que os snapshots de um dia mal conseguem ultrapassá-lo antes que o próximo backup seja iniciado. Nosso comando send / recv é:

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | bzip2 -c | \
ssh offsite-backup "bzcat | zfs recv -F tank/vm"

Eu tenho muitos ciclos de CPU para economizar. Existe um algoritmo de compactação melhor ou um método alternativo que eu possa usar para enviar menos dados pela linha?

    

Answer 1

Parece que você tentou todos os melhores mecanismos de compactação e ainda está sendo limitado pela velocidade da linha. Supondo que executar uma linha mais rápida esteja fora de questão, você considerou apenas executar os backups com menos frequência, para que eles tenham mais tempo de execução?

Além disso, existe algum meio de diminuir a quantidade de dados sendo gravados? Sem saber o seu aplicativo, é difícil dizer como, mas apenas fazer coisas como certificar-se de que os aplicativos estão sobrescrevendo os arquivos existentes, em vez de criar novos, pode ajudar. E certificando-se de não salvar backups de arquivos temp / cache que você não precisará.

    

Answer 2

Aqui está o que eu aprendi fazendo exatamente a mesma coisa que você está fazendo. Eu sugiro usar o mbuffer. Ao testar em meu ambiente, ele só ajudava no final do recebimento, sem que o envio diminuísse enquanto o recebimento chegava.

Alguns exemplos: link

Página inicial com opções e sintaxe link

O comando send do meu script de replicação: zfs enviar -i tanque / piscina @ oldsnap tank / pool @ newsnap | ssh -c arcfour remotehostip "mbuffer -s 128k -m 1G | zfs recebe -F tanque / pool"

isso executa o mbuffer no host remoto como um buffer de recebimento para que o envio seja executado o mais rápido possível. Eu corri uma linha de 20mbit e descobri que ter mbuffer no lado de envio também não ajudou, também minha caixa principal do zfs está usando todo o seu ram como cache, então dar até 1g de mbuffer exigiria que eu reduzisse alguns tamanhos de cache.

Além disso, e essa não é realmente minha área de especialização, acho que é melhor deixar o ssh fazer a compactação. No seu exemplo, acho que você está usando o bzip e, em seguida, usando o ssh, que por padrão usa compactação. Então, o SSH está tentando compactar um fluxo compactado. Eu acabei usando o arcfour como o cypher, pois é o menos intensivo da CPU e isso foi importante para mim. Você pode ter melhores resultados com outro cypher, mas eu definitivamente sugiro deixar SSH fazer a compressão (ou desligar a compressão ssh se você realmente quiser usar algo que não suporta)

O que é realmente interessante é que usar o mbuffer ao enviar e receber no host local também acelera: zfs enviar tank / pool @ snapshot | mbuffer -s 128k -m 4G -o - | zfs recebem -F tank2 / pool

Eu descobri que 4g para transferências de localhost parece ser o ponto positivo para mim. Isso mostra que o envio / recebimento do zfs não gosta muito da latência ou de outras pausas no fluxo para funcionar melhor.

Apenas minha experiência, espero que isso ajude. Demorei um pouco para descobrir tudo isso.

    

Answer 3

Esta é uma resposta à sua pergunta específica:

Você pode tentar o rzip , mas ele funciona de maneiras diferentes de compress / bzip / gzip:

O rzip espera poder ler todo o arquivo, portanto não pode ser executado em um pipeline. Isso aumentará muito seus requisitos de armazenamento local e você não poderá executar um backup e enviar o backup por fio em um único canal. Dito isso, os arquivos resultantes, pelo menos de acordo com o teste , são bem menores.

Se a sua restrição de recursos for o seu canal, você estará executando os backups 24x7 de qualquer forma, então você precisará copiar instantâneos constantemente e esperar que você os acompanhe de qualquer maneira.

Seu novo comando seria:

remotedir=/big/filesystem/on/remote/machine/
while 
  snaploc=/some/big/filesystem/
  now=$(date +%s)
  snap=snapshot.$now.zfssnap
  test -f $snaploc/$snap
do
  sleep 1
done

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 > $snaploc/$snap &&
rzip $snaploc/$snap &&
ssh offsite-backup "
        cat > $remotedir/$snap.rzip && 
        rzip -d $remotedir/$snap.rzip && 
        zfs recv -F tank/vm < $remotedir/$snap &&
        rm $remotedir/$snap " < $snaploc/$snap &&
rm $snaploc/$snap

Você vai querer colocar uma melhor correção de erros, e você vai querer considerar usar algo como rsync para transferir os arquivos compactados, então se a transferência falhar no meio, você pode continuar de onde parou.

    

Answer 4

As coisas mudaram nos anos desde que essa pergunta foi postada:

1: O ZFS agora suporta replicação compactada, basta adicionar o sinalizador -c ao comando zfs send e bloquear o que foi compactado no disco permanecerá compactado à medida que eles passam pelo canal até a outra extremidade. Pode ainda haver mais compactação a ser obtida, porque a compactação padrão no ZFS é lz4

2: O melhor compressor para usar neste caso é zstd (ZStandard), agora ele tem um modo 'adaptativo' que mudará o nível de compressão (entre os 19+ níveis suportados, além dos novos níveis zstd-fast de maior velocidade ) com base na velocidade do link entre zfs send e zfs recv. Ele compacta o máximo possível enquanto mantém a fila de dados aguardando para sair do canal até o mínimo. Se o link for rápido, não perderá tempo compactando mais os dados e, se o link estiver lento, ele continuará trabalhando para compactar mais os dados e poupar tempo no final. Ele também suporta compressão encadeada, então eu posso tirar proveito de múltiplos núcleos, que gzip e bzip não, fora de versões especiais como pigzip.

    

Answer 5

Suponho que você simplesmente não pode aumentar a largura de banda bruta do seu site ...

Você pode ver o benefício de não usar a compactação no host.

Se você usar algo como um otimizador wan, ele será capaz de otimizar a transferência muito melhor se você não compactar o arquivo antes de enviá-lo, ou seja, você faz exatamente o que você está fazendo, mas remover o bzip2 do tubo. Depois de algumas execuções do seu backup, o otimizador wan terá em cache uma grande parte das coisas que vê na transferência e você verá grandes melhorias na velocidade de transferência.

Se você estiver com um orçamento limitado, você poderá conseguir uma melhora semelhante usando rsync e rsyncing o instantâneo descompactado , por exemplo:

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 > /path/to/snapshotdir/snapshotfile
rsync /path/to/snapshotdir/snapshotfile offsite-backup:/remote/path/to/snapshotfile
ssh offsite-backup 'zfs recv -F tank/vm < /remote/path/to/snapshotfile'

Isso seria mais rápido porque o rsync só transferiria as diferenças entre o instantâneo de ontem e o de hoje. Dependendo de como o processo de snapshot funciona, ainda pode haver muita redundância entre os dois, mesmo que eles não sejam realmente o mesmo arquivo.

O otimizador wan é de longe a maneira mais provável de corrigir esse problema (bem, metro ethernet é a maneira mais provável de resolver esse problema, mas deixaremos isso de lado). O rsync é apenas um tiro selvagem no escuro que vale a pena testar (localmente; o rsync lhe dirá quanto tempo ele salvou em uma cópia direta) em seus dados locais antes de gravar a grande verificação de fibra ou instalação de leito de rio.

    

Answer 6

Por que vale a pena. Eu não faria um envio direto | comprimir | descomprimir | Receber isso pode levar a problemas no final do recebimento se a linha de transferência se encaixar e seus pools ficarem offline por um longo tempo durante o recebimento. Nós enviamos para um arquivo local, em seguida, gzip o instantâneo e transferir usando rsync (com leito de rio), então recebemos a partir do arquivo. O leito do rio não otimiza o tráfego MAS se houver um problema com a transferência e ele precisar ser reiniciado, o leito do rio acelera o reenvio.

Analisamos a não compactação do snapshot incremental, usando a compactação Rsync e não usando nenhuma compressão diferente do leito do rio. É difícil dizer qual é o melhor, mas quando estamos transferindo archivelogs do oracle com compressão rsync, a taxa de transferência é aproximadamente duas vezes maior que a dos arquivos simples e do leito do rio (com o RSync).

Se você tem um leito de rio, então use rsync não ssh já que o leito do rio entende rsync e tentará otimizá-lo e irá adicionar os dados ao cache (veja acima, reiniciando as transferências).

    

Answer 7

Minha experiência é que zfs send é bastante bursty apesar de ser muito mais rápido (em média) do que a seguinte etapa de compactação. Meu backup insere buffer considerável após zfs send e mais após gzip :

zfs send $SNAP | mbuffer $QUIET -m 100M | gzip | mbuffer -q -m 20M | gpg ... > file

No meu caso, o dispositivo de saída é USB (não conectado à rede), mas o buffer é importante por um motivo semelhante: O tempo total de backup é mais rápido quando a unidade USB é mantida 100% ocupada. Você não pode enviar menos bytes no geral (conforme solicitado), mas ainda pode terminar mais cedo. O armazenamento em buffer impede que a etapa de compactação vinculada à CPU se torne um limite de E / S.

    

Answer 8

Eu uso pbzip2 o tempo todo (bzip2 paralelo) ao enviar pela WAN. Como ele é encadeado, você pode especificar o número de encadeamentos a serem usados com a opção -p. Instale o pbzip2 primeiro nos hosts de envio e recebimento, as instruções de instalação estão no link .

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | pbzip2 -c | \
ssh offsite-backup "pbzip2 -dc | zfs recv -F tank/vm"

A chave principal é criar instantâneos em intervalos freqüentes (~ 10mins) para diminuir o tamanho do instantâneo e enviar cada instantâneo. O ssh não será retomado de um fluxo de snapshot quebrado, portanto, se você tiver um snapshot enorme para enviar, canalize o fluxo para pbzip2 e divida em partes de tamanho gerenciável, em seguida divida os arquivos rsync no host receptor e, em seguida, canalize para zfs recv os arquivos concatenados pbzip2. / p>

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | pbzip2 -c | \
split -b 500M - /somedir/snap-inc-10-to-12.pbzip2--

isso produzirá arquivos nomeados em blocos de 500 MB:

/somedir/snap-inc-10-to-12.pbzip2--aa
/somedir/snap-inc-10-to-12.pbzip2--ab
/somedir/snap-inc-10-to-12.pbzip2--ac
...

rsync para receber o host várias vezes (você pode rsync antes mesmo de zfs enviar concluir ou assim que você ver um pedaço completo de 500MB), pressione ctrl + c a qualquer momento para cancelar:

while [[ true ]]; do rsync -avP /somedir/snap-inc-10-to-12.pbzip2--* offsite-backup:/somedir ; sleep 1; done;

zfs recebem:

cat /somedir/snap-inc-10-to-12.pbzip2--* | pbzip2 -dc | zfs recv -Fv tank/vm

User freind mencionado: Por que vale a pena. Eu não faria um envio direto | comprimir | descomprimir | Receber isso pode levar a problemas no final do recebimento se a linha de transferência se encaixar e seus pools ficarem offline por um longo tempo durante o recebimento. - Eu encontrei problemas antes com versões mais antigas do zfs < 28 no host de recebimento, se um envio / recebimento contínuo for interrompido pela rede, mas não na medida em que os pools forem offlines. Isso é interessante. Reenvie o instantâneo apenas se o "zfs recv" tiver saído no final de recebimento. Mate o "zfs recv" manualmente, se necessário. O zfs send / recv está muito melhor agora no FreeBSD ou no Linux.

    

Answer 9

Você pode pegar uma cifra mais rápida para ssh talvez blowfish-cbc, tente também os switches -123456789

-1 (or --fast) to -9 (or -best)

    

Answer 10

Você precisará testar seus dados. Basta enviá-lo para um arquivo e compactá-lo com cada método.

Para nós, o gzip fez uma grande diferença e nós executamos tudo isso, mas não houve diferença de 1% entre o gzip e o bzip ou o 7z.

Se você estiver em um T1 lento, precisará armazená-lo em um arquivo e rsync-lo.

Para aqueles (não você) que são limitados um pouco mais pela CPU do que pela largura de banda, como o lstvan disse que uma cifra diferente, como o arcfour128, acelera as coisas. Usamos isso internamente quando movemos as coisas.

    

Answer 11

Experimente ativar a dedução para zfs send com -D. A economia depende da quantidade de duplicação nos dados, é claro.

    

Answer 12

O "melhor" algoritmo de compressão depende do tipo de dados que você tem - se você estiver empurrando uma compactação de coleção MP3, provavelmente diminuirá o processo, enquanto textos / arquivos de log podem ser significativamente compactados com gzip -9 .

Quantos dados você está enviando todos os dias?

    

Answer 13

Você já pensou em ajustar sua pilha TCP / IP para que o buffer TCP e os tamanhos de janela sejam um pouco maiores? você pode usar a ferramenta ndd no Solaris para esta ou a ferramenta sysctl no Linux / BSD / Mac OSX. No Solaris, você está procurando os valores /dev/tcp tcp_max_buf e /dev/tcp tcp_cwnd_max , e no sysctl do Linux, você está procurando os valores net.ipv4.tcp_mem , net.ipv4.tcp_rmem e net.ipv4.tcp.wmem .

Além disso, esses links podem ter alguma ajuda adicional:

Ajuste de desempenho TCP do Solaris

Há um conjunto de links na parte inferior da página que explicará como fazer o mesmo para Linux / BSD / OSX também.