Лучшее сжатие для ZFS send/recv

Это - ответ на Ваш конкретный вопрос:

Можно попробовать rzip, но он работает способами, которые несколько отличаются от compress/bzip/gzip:

rzip ожидает мочь перечитать по целому файлу, таким образом, он не сможет быть выполнен в конвейере. Это значительно увеличит Ваши локальные требования устройства хранения данных, и Вы не сможете выполнить резервное копирование и отправить резервное копирование по проводу в одном единственном канале. Тем не менее получающиеся файлы, по крайней мере, согласно этому тесту, вполне немного меньше.

Если Ваше ограничение ресурсов будет Вашим каналом, то Вы будете выполнять резервные копии 24x7 во всяком случае, таким образом, необходимо будет просто копировать снимки постоянно и надеяться, что Вы поддерживаете на высоком уровне во всяком случае.

Ваша новая команда была бы:

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

Вы захотите вставить лучшую коррекцию ошибок, и Вы захотите рассмотреть использование чего-то как rsync для передачи сжатых файлов поэтому, если передача перестанет работать в середине, можно взять, где Вы кончили.

Я предполагаю, что Вы просто не можете увеличить необработанную пропускную способность своего сайта...

Можно видеть преимущество от не использования сжатия на хосте.

При использовании чего-то как бледный оптимизатор он сможет оптимизировать передачу намного лучше, если Вы не сожмете файл перед отправкой его, т.е. Вы делаете точно, что Вы делаете, но удаляете bzip2 из канала. После пары выполнений Вашего резервного копирования бледный оптимизатор будет кэшировать очень большую часть материала, который это видит в передаче, и Вы будете видеть огромные улучшения скоростей передачи.

Если Вы находитесь на ограниченном, сдвигаются с места, Вы можете видеть подобное улучшение при помощи rsync и rsyncing несжатый снимок, т.е.:

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'

Это было бы быстрее, потому что rsync только передаст различия между вчерашним снимком и сегодняшний. В зависимости от того, как работает процесс создания снимков, может все еще быть большое дублирование между двумя, даже если они не действительно тот же файл вообще.

Бледный оптимизатор является безусловно более вероятным способом решить эту проблему (хорошо, метро, Ethernet является наиболее вероятным способом решить эту проблему, но мы оставим это от таблицы). rsync является просто диким выстрелом в темноте, который это стоит протестировать (локально; rsync скажет Вам, сколько времени он сэкономил по прямой копии) на Ваших локальных данных прежде, чем выписать большой чек на волокно или установку русла.

Можно взять более быстрый шифр для ssh, возможно, CBC шифра, также попробовать-123456789 переключателей

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

"Лучший" алгоритм сжатия зависит от того, какие данные Вы имеете - при продвижении сжатия набора MP3, вероятно, замедлит процесс, в то время как текст/файлы журнала может быть значительно сжат с gzip -9.

Сколько данных Вы продвигаете каждый день?

Если это имеет значение. Я не сделал бы, прямое отправляет | сжатие |, распаковка | получает, это может привести к проблемам в принимающем конце, если снимки строки передачи и Ваши объединения будут в режиме офлайн в течение долгого времени во время получения. Мы отправляем в локальный файл затем gzip снимок и передачу с помощью rsync (с руслом), затем мы получаем из файла. Русло не оптимизирует трафик, НО если существует проблема с передачей, и оно должно быть перезапущено, русло ускоряет снова посылание.

Мы посмотрели на не сжатие возрастающего снимка, с помощью сжатия Rsync и не используя сжатия кроме русла. Трудно сказать, который является лучшим, но когда мы передаем archivelogs от оракула с rsync сжатием, скорость передачи примерно дважды больше чем это простых файлов и русла (с RSync).

Если у Вас есть русло, затем используют rsync не ssh, поскольку русло понимает rsync и попытается оптимизировать его и добавит данные к кэшу (см. выше, передачи перезапуска ре).

Вам нужно будет проверить свои данные. Просто отправьте его в файл и сожмите его каждым методом.

Для нас gzip имел огромное значение, и мы все пропускали через него, но не было даже 1% разницы между gzip и bzip или 7z.

Если у вас медленный T1, вам нужно будет сохранить его в файл и выполнить rsync.

Для тех (не вы), кто немного больше ограничен процессором, чем пропускной способностью, например, lstvan сказал другой шифр как arcfour128, ускоряет работу. Мы используем это для внутренних целей при перемещении вещей.

Вот чему я научился, делая то же самое, что и вы. Предлагаю использовать mbuffer. При тестировании в моей среде это помогло только на принимающей стороне, без нее отправка замедлялась бы, а прием - догонял.

Некоторые примеры: http://everycity.co.uk/alasdair/2010/07/using-mbuffer-to-speed-up-slow-zfs-send-zfs-receive/

Домашняя страница с параметрами и синтаксисом http://www.maier-komor.de/mbuffer.html

Команда отправки из моего сценария репликации:

zfs send -i tank/pool@oldsnap tank/pool@newsnap | ssh -c arcfour remotehostip "mbuffer -s 128k -m 1G | zfs receive -F tank/pool"

это запускает mbuffer на удаленном хосте в качестве буфера приема, поэтому отправка выполняется так быстро, как возможное. Я запустил 20-мегабитную строку и обнаружил, что наличие mbuffer на отправляющей стороне также не помогло, также мой основной zfs-блок использует всю свою оперативную память в качестве кеша, поэтому предоставление даже 1g для mbuffer потребует от меня уменьшения некоторых размеров кеша.

Кроме того, и это не моя область знаний, я думаю, что лучше просто позволить ssh выполнять сжатие. В вашем примере я думаю, что вы используете bzip, а затем используете ssh, который по умолчанию использует сжатие, поэтому SSH пытается сжать сжатый поток. В итоге я использовал arcfour в качестве шифра, поскольку он наименее требователен к процессору, и это было важно для меня. У вас могут быть лучшие результаты с другим шифром, но я Я определенно предлагаю разрешить SSH выполнять сжатие (или отключить сжатие ssh, если вы действительно хотите использовать то, что он не поддерживает).

Что действительно интересно, так это то, что использование mbuffer при отправке и получении на localhost также ускоряет работу:

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

Я обнаружил, что 4g для передачи localhost мне больше всего нравится. Это просто показывает, что zfs send / receive на самом деле не любит задержки или любые другие паузы в потоке, чтобы работать лучше всего.

Просто мой опыт, надеюсь, это поможет. Мне потребовалось некоторое время, чтобы разобраться во всем этом.

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

Я обнаружил, что 4g для передачи localhost мне больше всего нравится. Это просто показывает, что zfs send / receive на самом деле не любит задержки или любые другие паузы в потоке, чтобы работать лучше всего.

Просто мой опыт, надеюсь, это поможет. Мне потребовалось некоторое время, чтобы разобраться во всем этом.

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

Я обнаружил, что 4g для передачи localhost мне больше всего нравится. Это просто показывает, что zfs send / receive не любит задержки или любые другие паузы в потоке, чтобы работать лучше всего.

Просто мой опыт, надеюсь, это поможет. Мне потребовалось некоторое время, чтобы во всем этом разобраться.

Поэкспериментируйте с включением дедупликации для отправки zfs с -D. Конечно, экономия зависит от того, насколько сильно дублируются ваши данные.

По моему опыту, zfs send довольно прерывистый, несмотря на то, что он намного быстрее (в среднем), чем следующий этап сжатия. Моя резервная копия вставляет значительную буферизацию после zfs send и более после gzip :

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

В моем случае устройство вывода подключено через USB (не к сети), но буферизация важна для аналогичного Причина: общее время резервного копирования меньше, если USB-накопитель загружен на 100%. Вы не можете отправить меньше байтов (по вашему запросу), но вы все равно можете закончить раньше. Буферизация не позволяет этапу сжатия, связанному с ЦП, становиться привязанным к вводу-выводу.

Рассматривали ли вы возможность настройки стека TCP / IP так, чтобы размер буфера и окна TCP был немного больше? вы можете использовать инструмент ndd в Solaris для этого или инструмент sysctl в Linux / BSD / Mac OSX. В Solaris вам нужны значения / dev / tcp tcp_max_buf и / dev / tcp tcp_cwnd_max , а в Linux sysctl вы ищете net.ipv4 Значения .tcp_mem , net.ipv4.tcp_rmem и net.ipv4.tcp.wmem .

Кроме того, эти ссылки могут оказать дополнительную помощь:

Настройка производительности TCP Solaris

Внизу страницы есть набор ссылок, которые объяснят, как сделать то же самое для Linux / BSD / OSX.

Я постоянно использую pbzip2 (параллельный bzip2) при отправке по WAN. Поскольку он является многопоточным, вы можете указать количество используемых потоков с помощью опции -p. Сначала установите pbzip2 на отправляющем и принимающем узлах, инструкции по установке находятся на 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"

Основной ключ - создавать снимки с частыми интервалами (~ 10 минут), чтобы уменьшить размер снимка, а затем отправлять каждый снимок. ssh не возобновит работу из неработающего потока моментальных снимков, поэтому, если у вас есть огромный снимок для отправки, направьте поток в pbzip2, затем разделите его на блоки управляемого размера, затем разделите файлы rsync на принимающий хост, затем перенаправьте в zfs для получения объединенных файлов pbzip2.

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--

, это создаст файлы с именами кусками по 500 МБ:

/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 для принимающего хоста несколько раз (вы можете rsync даже до завершения отправки zfs или как только вы увидите полный фрагмент 500 МБ), нажмите ctrl + c в любое время, чтобы отменить:

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

zfs receive:

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

User freind упомянул: Для чего это стоит. Я бы не стал делать прямую отправку | сжать | распаковать | получить это может привести к проблемам на принимающей стороне, если линия передачи оборвется, и ваши пулы будут отключены в течение длительного времени во время приема. - Раньше я сталкивался с проблемами со старыми версиями zfs <28 на принимающем узле, если текущая отправка / получение прерывается из-за сброса сети, но не до такой степени, что пулы отключены. Это интересно. Повторно отправьте моментальный снимок только в том случае, если "zfs recv" завершился на принимающей стороне. При необходимости убейте "zfs recv" вручную. zfs send / recv теперь значительно улучшен во FreeBSD или Linux.

За годы, прошедшие с момента публикации этого вопроса, все изменилось:

1: ZFS теперь поддерживает сжатую репликацию, просто добавьте флаг -c в zfs send, и блоки, которые были сжаты на диске, останутся сжатыми при прохождении через конвейер на другой конец. Еще может быть получено большее сжатие, потому что сжатие по умолчанию в ZFS - lz4

2: лучший компрессор для использования в этом случае - zstd (ZStandard), теперь у него есть «адаптивный» режим, который изменит сжатие level (между 19+ поддерживаемыми уровнями плюс новые более высокие уровни zstd-fast) на основе скорости связи между zfs send и zfs recv. Он сжимает настолько, насколько может, при этом сводя к минимуму очередь данных, ожидающих выхода из конвейера. Если ваша ссылка быстрая, она не будет тратить время на дополнительное сжатие данных, а если ваша ссылка медленная, она будет продолжать работать, чтобы сжимать данные еще больше и в конечном итоге сэкономить ваше время. Он также поддерживает многопоточное сжатие, поэтому я могу использовать преимущества нескольких ядер, которых нет в gzip и bzip, за исключением специальных версий, таких как pigzip.

После выполнения zfs отправьте tank@datasnapshot > /dev/ null Я понял, что в любом случае не собираюсь перенасыщать свою 10-гигабитную сеть, поэтому решил просто позволить резервному пулу использовать zfs set Compression=gzip.

Цифры оказались похожими.

Это довольно тяжело для ЦП, но использование mbuffer очень помогает.

отправитель: zfs send -v dank/data@snapshot | mbuffer -s 128k -m 10G -O s2dna:9090

приемник: mbuffer -s 128k -m 10G -I 9090 | zfs receive -s -v backuppool/engram/data

Этот большой буфер нужен, когда ЦП занят сжатием... иногда он переполняется, так что он может быть больше.

В целом я доволен пропускной способностью, которая без mbuffer выражалась двузначными числами: