Найкраще стиснення для передачі / відправ

Я надсилаю додаткові знімки ZFS по лінії Т1 в точку, і ми доходимо до того, коли знімки, що коштують за день, ледве зможуть перенести це за провід до початку наступної резервної копії. Наша команда 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"

У мене є багато запасних циклів процесора. Чи є кращий алгоритм стиснення або альтернативний метод, який я можу використовувати для просування менше даних по лінії?

Здається, ви спробували всі найкращі механізми стиснення і все ще обмежені швидкістю лінії. Якщо припустити, що запускати більш швидку лінію, не виникає сумніву, чи вважали ви запускати резервні копії рідше, щоб у них було більше часу для запуску?

Незважаючи на це, чи існує якийсь спосіб зменшити кількість записуваних даних? Не знаючи, що у вашому додатку складно сказати, як зробити, але саме такі дії, як переконання, що програми перезаписують наявні файли замість створення нових, можуть допомогти. І переконайтеся, що ви не зберігаєте резервні копії темп / кеш-файлів, які вам не знадобляться.

Ось що я навчився робити саме те, що ви робите. Я пропоную використовувати 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

Команда send з мого сценарію реплікації:

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

це запускає mbuffer на віддаленому хості як буфер прийому, тому надсилання проходить як можна швидше. Я запускаю рядок 20mbit і виявив, що наявність 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

Я виявив, що 4 г для передач з локальних хостів, здається, є солодощами для мене. Це просто показує, що zfs відправляти / отримувати не дуже подобається затримка або будь-які інші паузи в потоці, щоб найкраще працювати.

Просто мій досвід, сподіваюся, що це допомагає. Мені знадобилося деякий час, щоб зрозуміти все це.

Це відповідь на ваше конкретне запитання:

Ви можете спробувати rzip , але він працює способами, які трохи відрізняються від компресії / 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 для передачі стислих файлів, тож якщо передача не вдасться посередині, ви зможете знайти там, де ви зупинилися.

Все змінилося за роки, коли це питання було розміщено:

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

2: Найкращий компресор, що використовується в цьому випадку, - zstd (ZStandard), тепер у ньому є "адаптивний" режим, який змінить рівень стиснення (між підтримуваними рівнями 19+, плюс новий швидкий zstd-швидкий рівень) на основі швидкість зв'язку між zfs send та zfs recv. Він стискає стільки, скільки може, зберігаючи чергу даних, які чекають виходу з труби до мінімуму. Якщо ваше посилання швидке, воно не витрачає час на стиснення даних більше, а якщо ваше посилання повільне, воно продовжуватиме працювати над тим, щоб більше стискати дані та економити час. Він також підтримує різьбове стиснення, тому я можу скористатися декількома ядрами, яких gzip та bzip не мають, поза спеціальними версіями, такими як pigzip.

Я припускаю, що ви просто не можете збільшити пропускну здатність вашого веб-сайту ...

Можливо, ви побачите користь від не використовувати компресію на хості.

Якщо ви використовуєте щось на кшталт wan optimizer, він зможе оптимізувати передачу набагато краще, якщо ви не стиснете файл, перш ніж надсилати його, тобто ви робите саме те, що робите, але виймаєте bzip2 з труби. Після декількох запусків вашої резервної копії, оптимізатор wan буде кешувати дуже велику частину речей, які він бачить у передачі, і ви побачите величезні покращення швидкості передачі.

Якщо ви перебуваєте на обмеженому Бадж, ви можете бути в змозі бачити подібне поліпшення за допомогою 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 передавав би лише відмінності між вчорашнім знімком та сьогоднішнім. Залежно від того, як працює процес зйомки, все ще може бути багато надмірності між ними, навіть якщо вони взагалі не є тим самим файлом.

Оптимізатор WAN - це набагато імовірніший спосіб вирішити цю проблему (ну, метро Ethernet - це найбільш вірогідний спосіб вирішити цю проблему, але ми залишимо це поза столом). Rsync - це просто дикий знімок у темряві, який варто перевірити (локально; rsync підкаже, скільки часу він заощадив на прямій копії) на ваших локальних даних, перш ніж написати великий чек на встановлення волокна або русла річки.

За свою ціну. Я б не робив прямого надсилання | компрес | декомпресувати | отримання цього може призвести до проблем на кінці прийому, якщо лінія передачі перерветься, і ваші пули будуть тривалий час перебувати в режимі офлайн під час прийому. Ми відправляємо в локальний файл, потім gzip знімок і передаємо за допомогою rsync (з руслом річки), потім отримуємо з файлу. Русло річки не оптимізує трафік, АЛЕ, якщо є проблема з передачею, і її потрібно перезапустити, русло річки швидше відновлює.

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

Якщо у вас є русло ріки, тоді використовуйте rsync not ssh, оскільки русло розуміє rsync і спробує оптимізувати його та додасть дані в кеш (див. Вище, перезапуск перезавантаження).

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

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

У моєму випадку пристрій виводу підключений через USB (не мережа), але буферизація важлива з аналогічної причини: Загальний час резервного копіювання проходить швидше, коли накопичувач USB зберігається на 100%. Ви можете не надсилати менше байтів у цілому (за вашим запитом), але ви все одно можете закінчити швидше. Буферизація запобігає стадії стиснення, пов’язаної з процесором, переходу до IO.

Я весь час використовую 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 recv об'єднані файли 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 отримують:

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

Користувач Freind згадав: Для чого це варто. Я б не робив прямого надсилання | компрес | декомпресувати | отримання цього може призвести до проблем на кінці прийому, якщо лінія передачі перерветься, а ваші пули будуть тривалий час перебувати в режимі офлайн під час прийому. - У мене раніше виникали проблеми зі старими версіями zfs <28 у приймаючому хості, якщо поточне відправлення / recv перерване мережевими краплями, але не в тій мірі, в якій пули є зафіксованими. Це цікаво. Знову надсилайте знімок лише у тому випадку, якщо "zfs recv" вийшов у кінці прийому. Убийте "zfs recv" вручну, якщо потрібно. zfs send / recv значно вдосконалено зараз у FreeBSD або Linux.

Ви можете підібрати більш швидкий шифр для ssh, можливо, blowfish-cbc, а також спробувати перемикачі -123456789

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

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

Для нас gzip зробив величезну різницю, і ми проходимо все через це, але не було навіть 1% різниці між gzip та bzip або 7z.

Якщо ви перебуваєте на повільному T1, вам потрібно буде зберегти його у файлі та rsync його.

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

Експериментуйте з увімкненням дедупу для zfs відправляйте з -D. Економія залежить, звичайно, від кількості копій у ваших даних.

Алгоритм стиснення "найкращий" залежить від того, який тип даних у вас є - якщо ви натискаєте на стиснення колекції MP3, швидше за все, сповільниться процес, в той час як текст / журнали можуть бути значно стиснені gzip -9.

Скільки даних ви щодня наштовхуєте?

Чи обдумали ви настроїти стек 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.