ZFS Sync по ненадежной, медленной WAN. Репликация ZFS или rsync?

10

Передо мной была поставлена задача сделать резервное копирование вне сети через WAN. Оба хранилища - это хранилища NAS на базе FreeBSD, на которых работает ZFS.

Один или два раза в неделю 15–60 гигабайт данных с фотографий сбрасываются в офис NAS. Моя работа состоит в том, чтобы выяснить, как получить эти данные как можно более надежно, используя соединение VERY SLOW DSL (загрузка ~ 700 Кбит / с). Приемная коробка имеет гораздо лучшую форму: скорость 30 Мбит / с, скорость 5 Мбит / с.

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

Мои варианты кажутся либо:

ZFS инкрементная отправка через ssh
Rsync

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

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

Меня беспокоит производительность репликации ZFS [1] (хотя этой статье уже год). Я также обеспокоен возможностью перезапуска передачи, если что-то пойдет не так - возможности моментальных снимков, кажется, не включают это. Вся система должна быть полностью автономной.

[1] http://wikitech-static.wikimedia.org/articles/z/f/s/Zfs_replication.html

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

Так что ... это мое мнение по этому вопросу. Я пропустил какие-либо хорошие варианты? Кто-нибудь еще настраивал что-то подобное?

— Пол Макмиллан
источник

Рассмотрим Унисон .

— Сампаблокупер

8

Если вы можете передавать максимум 6 ГБ в день (при условии отсутствия накладных расходов и нулевого конкурирующего трафика) и вам необходимо перемещать «15–60 гигабайт» с частотой «один или два раза в неделю», это составляет 15–120 ГБ в неделю или от 2 до 17 ГБ в день. Поскольку необходимо планировать пиковый спрос, а 17 ГБ намного превышают даже ваш теоретический максимум в 6 ГБ, вполне вероятно, что у вас очень серьезная проблема с пропускной способностью. Что потребуется для обновления соединения? Если обновление соединения невозможно, рассмотрите возможность рассылки физического носителя по расписанию (например, еженедельно).
Предполагая, что вы можете получить статистику пропускной способности, чтобы сделать ее более понятной, rsync , вероятно, будет лучшим вариантом. Осведомленность о дедупликации была бы чрезвычайно полезна при репликации сильно избыточных данных (например, образов виртуальных машин), но она не принесла бы никакой пользы, если речь шла об уникальном цифровом контенте (аудио, видео, фото) ... если, конечно, пользователи не непреднамеренное хранение дубликатов копий идентичных файлов.

— штурмовик типа "Скайхки"
источник

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

— Пол Макмиллан

И да, рассылка физических носителей намного лучше ... Хотелось бы, чтобы это был вариант.

— Пол Макмиллан

Хороший вопрос о дедупликации. Большая часть того, что копируется, не будет дублироваться - пользователи не настолько плотны.

— Пол Макмиллан

1

Единственное, что я хотел бы добавить, это, возможно, не использовать rsync. Я также испытал медлительность rsync, потому что я использовал его как процесс передачи, а не как процесс синхронизации. Затем я понял, что большинство моих существующих данных не изменилось, и нужно было копировать только новые данные, для себя я использовал cp только для новых файлов, и это было намного быстрее. Если бы у меня были измененные файлы (или только части файлов), я бы использовал rsync. Поэтому я предлагаю выделить новые файлы и выбрать возобновляемый метод передачи. Кроме того, сжатие будет компромиссом между ЦП и ОЗУ / пропускной способностью (на обоих концах).

— Скотт МакКленнинг

Хм ... Я читал, что при правильной конфигурации rsync можно заставить работать относительно быстро. Сколько оптимизации вы пытались?

— Пол Макмиллан

13

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

Вот несколько источников, которые я использовал:

Oracle Solaris Руководство администратора ZFS страница 211 (или веб - версия здесь ) начинает говорить о об этом.
Я также нашел сообщение в блоге, которое дало простой пример этого. Этот блог также показал передачу потока битов через bzip2 и его отправку.

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

Многие на сайте говорили о создании cron-работы, чтобы делать это часто. Если это так, вы можете выполнять репликацию / резервное копирование с меньшим влиянием на пропускную способность и пользователей и быть хорошей функцией аварийного восстановления, поскольку внешние данные более актуальны. (То есть после начальной порции данных при начале работы.)

Опять же , я думаю , что вы имели право идеи отправки снимков там , кажется, много преимуществ использования SEND/ RECEIVE.

EDIT: Просто смотрел video1 video2 , что может помогает suports использование SEND/ RECEIVEи переговоры о Rsync (начинается в 3m49s). Бен Роквуд был спикером, и вот ссылка на его блог .

— Скотт МакКленнинг
источник

1

Я предполагаю, что использование rsync там ограничено функциональностью паузы / возобновления, а не фактическим различием файла. Это имеет смысл, поскольку сама файловая система (и генерируемые файлы изменений) лучше, чем rsync, знает, что происходит.

— Пол Макмиллан

В качестве дополнительного примечания: ZSTD, современная более быстрая замена gzip и bzip, поддерживает несколько потоков и более 20 уровней сжатия. Он также имеет дополнительную опцию, называемую «адаптивное сжатие». В этом режиме уровень сжатия автоматически настраивается вверх и вниз по мере необходимости, чтобы поддерживать заполнение сетевого канала, и в то же время выполнять максимально возможное сжатие, чтобы сэкономить время. Это препятствует тому, чтобы вы выполняли такое сильное сжатие, что оно становится узким местом или пропускает сжатие, которое вы могли бы делать из-за слишком медленной сети.

— Аллан Джуд

2

Какова цель резервных копий и как они должны быть доступны?

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

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

С rsync вы можете использовать флаг --backup для сохранения резервных копий файлов, которые были изменены, а с помощью флага --suffix вы можете контролировать, как старые версии файлов переименовываются. Это позволяет легко создать резервную копию, где вы могли бы датировать старые версии файлов, такие как

file_1.jpg
file_1.jpg.20101012
file_1.jpg.20101008
etc.

Вы можете легко объединить это с помощью cronjob, содержащего команду find для очистки любых старых файлов по мере необходимости.

Оба решения должны сохранять достаточную метаинформацию о файлах для работы в качестве резервной копии (rsync предоставляет флаги --perms, --owner и т. Д.). Я использую rsync для резервного копирования больших объемов данных между центрами обработки данных и очень доволен настройкой.

— Deutsch
источник

2

ZFS должна получить функцию «возобновляемой отправки», которая позволит продолжить прерванную репликацию примерно в марте этого года. Эта функция была завершена Мэттом Аренсом и некоторыми другими людьми, и вскоре должна быть обновлена.

— Аллан Джуд
источник

Просто отметим, что «возобновляемая отправка» уже давно существует в OpenZFS (во FreeBSD, Linux, MacOS и т. Д.). Теперь также есть функция «сжатой отправки», где данные будут оставаться сжатыми, как на диске, как часть потока репликации.

— Аллан Джуд

0

Может быть WAN устройство сжатия будет решением ...? мы используем Riverbed, и мы им очень довольны (например, NetApp SnapMirror очень хорошо сжимается, до 80-90%)

— toffitomek
источник