Мне было поручено сделать резервное копирование за пределами площадки через глобальную сеть. Оба хранилища представляют собой NAS-устройства на базе FreeBSD и ZFS.
Один или два раза в неделю на офисный NAS сбрасывается 15-60 гигабайт фотографий. Моя задача - выяснить, как максимально надежно передавать эти данные за пределы объекта, используя ОЧЕНЬ МЕДЛЕННОЕ соединение DSL (загрузка ~ 700 Кб / с). Приемная коробка в гораздо лучшей форме, 30 Мбит / с вниз, 5 Мбит / с вверх.
Я знаю, что перенос жесткого диска за пределы предприятия позволит перемещать данные намного быстрее, но в данном случае это не вариант.
Возможны следующие варианты:
rsync - это проверенное временем решение, которое обладает исключительно важной способностью возобновить отправку, если что-то будет прервано. Его недостатком является перебор многих файлов и незнание о дедупликации.
Отправка моментальных снимков ZFS может передавать немного меньше данных (он знает гораздо больше о файловой системе, может выполнять дедупликацию, может упаковать изменения метаданных более эффективно, чем rsync) и имеет преимущество правильного дублирования состояния файловой системы, а не простого копирования файлы по отдельности (что требует более интенсивного использования диска).
Меня беспокоит производительность репликации ZFS [1] (хотя этой статье уже год). Меня также беспокоит возможность перезапустить передачу, если что-то выйдет из строя - возможность создания снимков, похоже, этого не включает. Вся система должна быть полностью отключена.
[1] http://wikitech-static.wikimedia.org/articles/z/f/s/Zfs_replication.html
Используя любой из этих вариантов, я должен иметь возможность снизить приоритет трафика, направив его через указанный порт, а затем используя QOS на маршрутизаторах. Мне нужно избегать серьезного негативного воздействия на пользователей обоих сайтов во время каждого переноса, так как это займет несколько дней.
Итак ... это я думаю по этому поводу. Пропустил ли я хорошие варианты? Кто-нибудь еще что-то подобное настраивал?
Проведя небольшое исследование, я считаю, что вы правы насчет отправки снимков. ZFS SEND и RECEIVE команды могут быть переданы в bzip2, а затем этот файл может быть синхронизирован с другим компьютером.
Вот несколько источников, которые я использовал:
В Руководство администратора Oracle Solaris ZFS стр. 211 (или веб-версия Вот) начинает об этом говорить.
Я также нашел Сообщение блога это дало простой пример этого. Этот блог также показал передачу битового потока через bzip2 и его отправку.
Я не нашел ни одной публикации с опубликованными сценариями репликации, но я нашел кого-то, кто опубликовал свои сценарий резервного копирования. Тем не менее, я этого не понял, так что это может быть хлам.
Многие на веб-сайте говорили о настройке задания cron, чтобы делать это часто. В этом случае вы могли бы реплицировать / создавать резервные копии с меньшим влиянием на полосу пропускания и пользователей и быть хорошей функцией аварийного восстановления, поскольку внешние данные более актуальны. (То есть после начального блока данных при запуске.)
Опять же, я думаю, что вы правильно поняли, отправляя снимки, кажется, что использование SEND / RECEIVE.
РЕДАКТИРОВАТЬ: Только что смотрел видео1 видео2 что может помочь в использовании SEND/RECEIVE и говорит о rsync (начинается с 3:49). Бен Роквуд был спикером, и вот ссылка на его блог.
Если вы можете передавать максимум 6 ГБ в день (при нулевых накладных расходах и нулевом конкурирующем трафике), и вам нужно перемещать «15-60 гигабайт» с частотой «один или два раза в неделю», это составляет 15-120 ГБ в неделю или от 2 до 17 ГБ в день. Потому что необходимо спланировать пиковый спрос, а 17 ГБ намного превышают даже ваш теоретический максимум 6 ГБ, вероятно, у вас очень серьезная проблема с пропускной способностью. Что потребуется для обновления соединения? Если обновление соединения невозможно, рассмотрите возможность рассылки физических носителей по расписанию (например, еженедельно).
Предполагая, что вы можете получить более понятную математику пропускной способности, rsync скорее всего будет лучшим вариантом. Осведомленность о дедупликации будет чрезвычайно ценной при репликации данных с высокой степенью избыточности (например, образов виртуальных машин), но она не принесет особой выгоды или не принесет никакой пользы, когда дело доходит до уникального цифрового контента (аудио, видео, фотографии) ... если, конечно, пользователи не непреднамеренное хранение дубликатов идентичных файлов.
ZFS должна получить функцию возобновляемой отправки, которая позволит продолжить прерванную репликацию примерно в марте этого года. Эта функция была завершена Мэттом Аренсом и некоторыми другими людьми, и в ближайшее время она будет обновлена.
Для чего нужны резервные копии и как к ним нужно обращаться?
Если ваши резервные копии предназначены в основном для аварийного восстановления, то моментальные снимки ZFS могут быть предпочтительнее, так как вы сможете вернуть файловую систему в то состояние, в котором она находилась во время последнего инкрементного восстановления.
Однако, если ваши резервные копии также должны предоставлять пользователям доступ к файлам, которые могли быть случайно удалены, повреждены и т. Д., Тогда rsync может быть лучшим вариантом. Конечные пользователи могут не понимать концепцию моментальных снимков или, возможно, ваш NAS не предоставляет конечным пользователям доступ к предыдущим снимкам. В любом случае вы можете использовать rsync для создания резервной копии, которая легко доступна пользователю через файловую систему.
С помощью rsync вы можете использовать флаг --backup для сохранения резервных копий файлов, которые были изменены, а с помощью флага --suffix вы можете контролировать, как старые версии файлов переименовываются. Это упрощает создание резервной копии, в которой вы могли устаревать старые версии файлов, например
file_1.jpg
file_1.jpg.20101012
file_1.jpg.20101008
etc.
Вы можете легко совместить это с заданием cron, содержащим команду find для очистки любых старых файлов по мере необходимости.
Оба решения должны иметь возможность сохранять достаточно метаинформации о файлах для работы в качестве резервной копии (rsync предоставляет флаги --perms, --owner и т. Д.). Я использую rsync для резервного копирования больших объемов данных между центрами обработки данных и очень доволен настройкой.
Может быть, устройство сжатия WAN будет решением ...? мы используем Riverbed, и мы им очень довольны (например, NetApp SnapMirror очень хорошо сжимается, до 80-90%)