Melhor compactação para envio / recv do ZFS

Estou enviando instantâneos incrementais do ZFS por uma linha T1 ponto a ponto e chegamos a um ponto em que um dia de instantâneos mal consegue passar por cima do fio antes do início do próximo backup. 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 de sobra. Existe um algoritmo de compactação melhor ou um método alternativo que eu possa usar para enviar menos dados pela linha?

Parece que você tentou todos os melhores mecanismos de compactação e ainda está sendo limitado pela velocidade da linha. Supondo que a execução de 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 para executar?

Além disso, existe algum meio de diminuir a quantidade de dados sendo gravados? Sem saber que seu aplicativo é difícil dizer como, mas fazer coisas como garantir que os aplicativos substituam os arquivos existentes em vez de criar novos pode ajudar. E verifique se você não está salvando backups de arquivos temporários / de cache que você não precisa.

Aqui está o que eu aprendi fazendo exatamente a mesma coisa que você está fazendo. Eu sugiro usar o mbuffer. Ao testar no meu ambiente, ele apenas ajudava no recebimento, sem ele o envio diminuiria enquanto o recebimento chegasse.

Alguns exemplos: http://everycity.co.uk/alasdair/2010/07/using-mbuffer-to-speed-up-slow-zfs-send-zfs-receive/

Página inicial com opções e sintaxe http://www.maier-komor.de/mbuffer.html

O comando send do meu script de replicação:

zfs send -i tank/pool@oldsnap tank/pool@newsnap | ssh -c arcfour remotehostip "mbuffer -s 128k -m 1G | zfs receive -F tank/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 corro uma linha de 20mbit e descobri que ter o mbuffer no lado do envio também não ajudou, minha caixa zfs principal está usando todo o seu ram como cache, portanto, fornecer 1g ao mbuffer exigiria que eu reduzisse alguns tamanhos de cache.

Além disso, e essa não é realmente minha área de especialização, acho melhor deixar o ssh fazer a compactação. No seu exemplo, acho que você está usando o bzip e depois o ssh, que por padrão usa compactação, então o SSH está tentando compactar um fluxo compactado. Acabei usando o arcfour como cifra, pois é o menos intensivo em CPU e isso foi importante para mim. Você pode ter melhores resultados com outra cifra, mas eu definitivamente sugeriria deixar o SSH fazer a compactação (ou desativar a compactação ssh se você realmente quiser usar algo que não é compatível).

O que é realmente interessante é que o uso do mbuffer ao enviar e receber no host local também acelera:

zfs send tank/pool@snapshot | mbuffer -s 128k -m 4G -o - | zfs receive -F tank2/pool

Descobri que 4G para transferências de host local parece ser o sweetspot para mim. Isso mostra que o envio / recebimento de zfs não gosta muito de latência ou de qualquer outra pausa no fluxo para funcionar melhor.

Apenas minha experiência, espero que isso ajude. Levei um tempo para descobrir tudo isso.

Esta é uma resposta para sua pergunta específica:

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

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

Se a sua restrição de recursos é o seu canal, você estará executando backups 24x7 de qualquer maneira, portanto, você precisará apenas copiar instantâneos constantemente e esperar que você continue assim.

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ê deseja inserir uma correção de erro melhor e considere usar algo como o rsync para transferir os arquivos compactados. Portanto, se a transferência falhar no meio, você poderá continuar de onde parou.

As coisas mudaram nos anos desde que esta pergunta foi publicada:

1: O ZFS agora suporta replicação compactada, basta adicionar o sinalizador -c ao comando zfs send e os blocos que foram compactados no disco permanecerão compactados à medida que passam pelo pipe para a outra extremidade. Ainda pode haver mais compactação a ser obtida, porque a compactação padrão no ZFS é lz4

2: O melhor compressor a ser usado neste caso é zstd (ZStandard), agora possui um modo 'adaptável' que alterará o nível de compactação (entre os mais de 19 níveis suportados, mais os novos níveis zstd-fast de velocidade mais alta) com base em a velocidade do link entre o zfs send e o zfs recv. Ele comprime o máximo possível, mantendo a fila de dados esperando para sair do tubo ao mínimo. Se o seu 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 economizar tempo no final. Ele também suporta compactação encadeada, para que eu possa tirar proveito de vários núcleos, os quais gzip e bzip não, fora de versões especiais como pigzip.

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

Você pode se beneficiar ao não usar a compactação no host.

Se você usar algo como um otimizador de WAN, ele poderá otimizar a transferência muito melhor se você não compactar o arquivo antes de enviá-lo, ou seja, você fará exatamente o que está fazendo, mas removerá o bzip2 do tubo. Após algumas execuções de seu backup, o otimizador de wan armazenará em cache uma fração muito grande do material que vê na transferência e você verá grandes melhorias nas velocidades de transferência.

Se você estiver em uma mudança limitada, poderá ver uma melhoria semelhante usando o rsync e o sincronizando novamente o snapshot não compactado , ou seja:

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 apenas transferia as diferenças entre o instantâneo de ontem e o de hoje. Dependendo de como o processo de captura instantânea funciona, ainda pode haver muita redundância entre os dois, mesmo que eles não sejam realmente o mesmo arquivo.

O otimizador de wan é, de longe, a maneira mais provável de corrigir esse problema (bem, o metro ethernet é a maneira mais provável de resolver esse problema, mas vamos deixar isso de fora da mesa). O rsync é apenas um tiro no escuro que vale a pena testar (localmente; o rsync lhe dirá quanto tempo economizou em uma cópia direta) nos dados locais antes de fazer a verificação geral de fibra ou uma instalação no leito do rio.

Pelo que vale a pena. Eu não faria um envio direto | comprimir | descomprimir | receber isso pode causar problemas no final do recebimento, se a linha de transferência se romper e seus pools ficarem offline por um longo período durante o recebimento. Enviamos para um arquivo local, compactamos o snapshot e transferimos usando o rsync (com riverbed) e depois recebemos do arquivo. O leito do rio não otimiza o tráfego, MAS, se houver um problema com a transferência e precisar ser reiniciado, o leito do rio acelera o reenvio.

Vimos não compactar o instantâneo incremental, usando a compressão Rsync e não usando nenhuma outra compressão além do leito do rio. É difícil dizer qual é o melhor, mas quando estamos transferindo archivelogs do oracle com compactação rsync, a taxa de transferência é aproximadamente o dobro da dos arquivos simples e do leito do rio (com o RSync).

Se você tiver um leito de rio, use rsync not ssh, pois o leito de rio entende rsync e tentará otimizá-lo e adicionará os dados ao cache (veja acima, reiniciando as transferências).

Minha experiência é zfs sendbastante explosiva, apesar de ser muito mais rápida (em média) do que a seguinte etapa de compactação. Meu backup insere um buffer considerável depois zfs sende mais depois gzip:

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

No meu caso, o dispositivo de saída está conectado via USB (não na 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 buffer impede que a etapa de compactação vinculada à CPU se torne vinculada a E / S.

Eu uso o pbzip2 o tempo todo (bzip2 paralelo) ao enviar pela WAN. Como está 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 em http://compression.ca/pbzip2/ .

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 frequentes (~ 10 minutos) para diminuir o tamanho do instantâneo e enviar cada instantâneo. O ssh não será retomado a partir de um fluxo de snapshot quebrado, por isso, se você tiver um snapshot enorme para enviar, canalize o fluxo para pbzip2, depois divida em pedaços de tamanho gerenciável, em seguida, rsync divida os arquivos no host de recebimento e, em seguida, envie para o zfs recv os arquivos pbzip2 concatenados.

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 que o envio do zfs seja concluído ou assim que vir um fragmento completo de 500 MB), 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;

O zfs recebe:

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

O amigo do usuário mencionou: Para o que vale a pena. Eu não faria um envio direto | comprimir | descomprimir | receber isso pode causar problemas no final do recebimento, se a linha de transferência se romper e seus pools ficarem offline por um longo período durante o recebimento. - Eu encontrei problemas antes com as versões mais antigas do zfs <28 no host de recebimento, se um envio / recv em andamento for interrompido por quedas na rede, mas não na medida em que os pools estejam off-line. 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 melhorado agora no FreeBSD ou Linux.

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

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

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

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

Se você estiver em um T1 lento, será necessário armazená-lo em um arquivo e sincronizá-lo novamente.

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 ao mover as coisas.

Experimente ativar o dedup para zfs send com -D. A economia depende da quantidade de duplicação existente em seus dados, é claro.

O "melhor" algoritmo de compactação depende do tipo de dados que você possui - se você estiver pressionando uma compilação de uma coleção de MP3 provavelmente atrasará o processo, enquanto os arquivos de texto / log podem ser significativamente compactados gzip -9.

Quantos dados você está enviando por dia?

Você já pensou em ajustar sua pilha TCP / IP para que o tamanho do buffer e da janela TCP seja um pouco maior? você pode usar a nddferramenta no Solaris para isso ou a sysctlferramenta no Linux / BSD / Mac OSX. No Solaris, você está olhando para o /dev/tcp tcp_max_bufe /dev/tcp tcp_cwnd_maxvalores, e no Linux sysctl, que você está procurando net.ipv4.tcp_mem, net.ipv4.tcp_rmeme net.ipv4.tcp.wmemvalores.

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

Ajuste de desempenho do TCP do Solaris

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