Наши турецкие клиенты попросили нас правильно настроить бэкап для дата-центра. Мы делаем подобные проекты в России, но именно здесь история была больше про исследование того, как лучше сделать.

Дано: есть локальное S3-хранилище, есть Veritas NetBackup, который обзавёлся новым расширенным функционалом по перемещению данных в объектные хранилища теперь уже с поддержкой дедупликации, и есть проблема со свободным местом в этом локальном хранилище.

Задача: сделать всё так, чтобы процесс хранения резервных копий был быстр и дешев.

Собственно, до этого в S3 всё складывалось просто файлами, причём это были полные слепки критичных машин дата-центра. То есть не так, чтобы очень оптимизированно, но зато всё работало на старте. Сейчас же пришло время разобраться и сделать правильно.

На картинке то, к чему мы пришли:

Как видно, первый бэкап делался медленно (70 Мб/с), а последующие бэкапы тех же систем — значительно быстрее.

В чём проблема

Заказчики хотят делать бекапы как можно чаще и хранить как можно дешевле. Дёшево хранить их лучше всего в объектных хранилищах типа S3, потому что они обходятся дешевле всего по цене обслуживания на Мегабайт из того, откуда можно накатить бэкап обратно в разумные сроки. Когда бэкапа много, это становится не очень дёшево, потому что большую часть хранилища занимают копии одних и тех же данных. В случае HaaS турецких коллег можно уплотнить хранение примерно на 80-90%. Понятное дело, что это относится именно к их специфике, но минимум на 50% дедупа я бы точно рассчитывал.

Для решения проблемы основные вендоры уже давно сделали гейтвеи на S3 Амазона. Все их методы совместимы с локальными S3, если они поддерживают API Амазона. В турецком ЦОДе бэкап делается в нашу S3, как и в T-III «Компрессоре» в России, поскольку такая схема работы хорошо себя показала у нас.

А наша S3 полностью совместима с методами бэкапа в Амазон S3. То есть все средства для бэкапа, которые поддерживают эти методы, позволяют копировать всё в подобное хранилище «из коробки».

В Veritas NetBackup сделали фичу CloudCatalyst:

То есть между машинами, которые надо бэкапить, и гейтвеем встал промежуточный Linux-сервер, через который проходит бэкапный трафик с агентов СРК и делается их дедупликация «налету» перед передачей их в S3. Если раньше там было 30 бэкапов по 20 Гб с компрессией, то теперь (из-за похожести машин) их стало по объёму на 90% меньше. Движок дедупликации используется тот же, что и при хранении на обычных дисках средствами Netbackup.

Вот что происходит до промежуточного сервера:

Мы протестировали и пришли к выводу, что при внедрении в наших ЦОДах это даёт экономию места в хранилищах S3 для нас и для заказчиков. Как владелец коммерческих ЦОДов, конечно, тарифицируем по занимаемому объёму, но всё равно это очень выгодно для нас тоже — потому что зарабатывать мы начинаем на более масштабируемых местах в софте, а не на аренде железа. Ну, и это сокращение внутренних издержек.

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

Промежуточный сервер имеет своё хранилище, куда он пишет «кэш» данных и держит базу для дедупликации.

В полной архитектуре выглядит так:

  1. Мастер-сервер управляет конфигурацией, обновлениями и прочим и находится в облаке.
  2. Медиа-сервер (промежуточная *nix-машина) должен находиться наиболее близко к резервируемым системам в плане сетевой доступности. Здесь делается дедупликация бекапов со всех резервируемых машин.
  3. На резервируемых машинах есть агенты, которые в общем случае отправляют на медиа-сервер только то, чего нет в его хранилище.

Начинается всё с полного сканирования — это полноценный полный бекап. В этот момент медиа-сервер забирает всё, делает дедупликацию и передает в S3. Скорость до медиа-сервера низкая, от него — повыше. Главное ограничение — вычислительная мощность сервера.

Следующие бэкапы делаются с точки зрения всех систем полными, но на деле это что-то вроде синтетических полных бэкапов. То есть фактическая передача и запись на медиа-сервер идёт только тех блоков данных, которые ещё не встречались в резервных копиях ВМ раньше. А передача и запись в S3 идёт только тех блоков данных, хэша которых нет в базе дедупликации медиа-сервера. Если более простыми словами — что не встречалось ни в одном бэкапе ни одной ВМ раньше.

При ресторе медиа-сервер запрашивает нужные дедуплицированные объекты с S3, регидрирует их и передает агентам СРК, т.е. надо учитывать объем траффика при ресторе, который будет равен реальному объему восстанавливаемых данных.

Вот как это выглядит:

Целостность данных обеспечивается защитой самого S3 — там есть хорошая избыточность для защиты от аппаратных сбоев типа погибшего шпинделя жёсткого диска.

Медиа-серверу нужно 4 Тб кэша — это рекомендация Веритаса по минимальному объёму. Лучше больше, но мы делали именно так.

Итог

Когда партнёр кидал в наше S3 20 Гб, мы хранили 60 Гб, потому что обеспечиваем трёхкратное георезервирование данных. Сейчас трафика куда меньше, что хорошо и для канала, и для тарификации по хранению.

В данном случае маршруты закрыты мимо «большого Интернета», но можно гонять трафик и через VPN L2 через Интернет, но только медиа-сервер лучше ставить до провайдерского входа.

Если интересно узнать про эти фичи в наших российских ЦОДах или есть вопросы по реализации у себя — спрашивайте в комментариях или в почте ekorotkikh@croc.ru.

C оригиналом статьи можно ознакомиться на Хабре