Комментарии 12
Скажите пожалуйста, в сам опенстек переданы Ваши наработки, или они остаются проприетарными?
Сформирован ли отдельный продукт для выполнения бэкапа?
А в каком формате делаете бэкапы? Это какой то архивный формат или что то типа зеркала тома.
Ни то, ни другое. На выходе получается большой блоб который является конкатенацией независимо сжатых сегментов исходного тома, а также отдельными объектами метаданные, список контрольных сумм и два отображения - в каком месте блоба искать какой сегмент тома и обратное, какой сегмент блоба отвечает за какой сегмент тома.
А как работает application awareness? И работает ли, или консистентность данных на дисках не гарантированна?
При необходимости специальной подготовки ВМ к резервному копированию можно поручить соответствующие задачи гостевому агенту, который сделает всё что надо для подготовки консистентного снапшота. Если гостевого агента нет, то используются обходные механизмы, так что восстановленый бэкап выглядит как включение после отключения питания. То есть снапшот ВМ либо не атомарный но всё равно консистентный за счет гостевого агента (который просигнализирует сервисам внутри ВМ подготовиться), либо как минимум атомарный (все диски в одном моменте времени).
Может сравните расходы load average на получение чексумм и и расходы на сравнение через diff, приведенные к одной величине данных, Гб, как привыкли? По смыслу обе операции отвечают на один вопрос, "что изменилось?" и одна выделена как "дорогая". А вторая не исследована. Может ли быть diff единственной операцией и заменить подсчет чексумм?
DiffHandler выбирает изменившиеся блоки на основании контрольных сумм, расчитанных на предыдущем этапе. Поэтому как-то "сравнивать" здесь КМК бессмысленно. Одна задача делает расчет, вторая фильтрует данные. Для бэкапа L0 diffhandler вообще просто пропускает через себя сообщения не изменяя их, для L1 копирует некоторые (изменившиеся) блоки из одного сегмента shared memory в другой. memcpy не самая тяжелая задача
Было бы здорово превратить это в отдельный продукт (какой-нибудь "VK Backup") или в модуль для CyberProtect или ruBackup. Он же может резервировать машины не только из самого OpenStack-а, но и Тионикса с руСтэком, верно?
Теперь он учитывает схему с зонами доступности: бэкап делается всегда рядом с СХД, в которой расположен диск
Тысяча и один бэкап: как мы ускорили создание резервных копий на OpenStack в 10 раз