Как стать автором
Обновить

Тысяча и один бэкап: как мы ускорили создание резервных копий на OpenStack в 10 раз

Время на прочтение15 мин
Количество просмотров8.4K
Всего голосов 41: ↑41 и ↓0+41
Комментарии12

Комментарии 12

Скажите пожалуйста, в сам опенстек переданы Ваши наработки, или они остаются проприетарными?

Сформирован ли отдельный продукт для выполнения бэкапа?

В паблик не выкладывали.

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

А в каком формате делаете бэкапы? Это какой то архивный формат или что то типа зеркала тома.

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

А как работает application awareness? И работает ли, или консистентность данных на дисках не гарантированна?

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

Может сравните расходы load average на получение чексумм и и расходы на сравнение через diff, приведенные к одной величине данных, Гб, как привыкли? По смыслу обе операции отвечают на один вопрос, "что изменилось?" и одна выделена как "дорогая". А вторая не исследована. Может ли быть diff единственной операцией и заменить подсчет чексумм?

DiffHandler выбирает изменившиеся блоки на основании контрольных сумм, расчитанных на предыдущем этапе. Поэтому как-то "сравнивать" здесь КМК бессмысленно. Одна задача делает расчет, вторая фильтрует данные. Для бэкапа L0 diffhandler вообще просто пропускает через себя сообщения не изменяя их, для L1 копирует некоторые (изменившиеся) блоки из одного сегмента shared memory в другой. memcpy не самая тяжелая задача

Было бы здорово превратить это в отдельный продукт (какой-нибудь "VK Backup") или в модуль для CyberProtect или ruBackup. Он же может резервировать машины не только из самого OpenStack-а, но и Тионикса с руСтэком, верно?

Есть такие идеи, да. Как минимум насчёт отдельного продукта.

Теперь он учитывает схему с зонами доступности: бэкап делается всегда рядом с СХД, в которой расположен диск

image

Если я правильно понял смысл вашей картинки, то проясню, что бэкап делается и бэкап хранится это несколько разные понятия

Зарегистрируйтесь на Хабре, чтобы оставить комментарий