Привет, Хабр!
Сегодня поговорим о важной теме — как ускорить восстановление рабочих копий серверов OpenStack. Длительное восстановление рабочих копий серверов OpenStack может приводить к простоям сервисов и финансовым потерям. Эта статья объяснит, какие приемы использует СРК RuBackup для ускорения восстановления рабочих копий серверов и томов OpenStack.
1. Введение
Часто при обзорах эффективности работы СРК можно услышать, что СРК настроена на максимальную скорость создания резервных копий. Этому есть свое объяснение: в ЦОД окно резервного копирования, то есть тот период времени, который отводится на создание резервных копий работающих сервисов, стараются сделать максимально коротким. Это связано с тем, что в процессе создания резервных копий задействуется большой пул ресурсов ЦОД, что может привести к деградации производительности продакшн-сервисов, расположенных в ЦОД. Но, с другой стороны, время восстановления какого-либо ресурса из резервной копии может быть еще более важным, так как фактически это может быть временем даунтайма какого-либо сервиса, который находится в процессе восстановления. Увеличению скорости и, как следствие, уменьшению времени восстановления серверов OpenStack посвящена данная статья.
2. Восстановление системных дисков openstack
Если пользователь среды виртуализации openstack запросил создание нового сервера, то изначально создается системный том заданного пользователем размера. Затем на него разворачивается образ той операционной системы, которую выбрал пользователь. Далее уже непосредственно создается новый сервер openstack с томом, созданным на предыдущем шаге и сервер начинает свою работу. При восстановлении резервной копии сервера OpenStack СРК RuBackup в начале повторяет те же шаги: создается новый системный том. Но далее есть отличие: этот том подключается к клиенту СРК для того, чтобы записать на него данные системного тома из резервной копии. И тут появляется вопрос: зачем развертывать контент образа на только что созданный системный том, если эти данные все равно будут перезаписаны в процессе развертывания резервной копии? Образы операционных систем могут иметь большой объем, и при их развертывания на среду виртуализации OpenStack может создаваться большая нагрузка, которая замедляет выполнение операций OpenStack. Было бы хорошо избавится от этого шага.
3. Ускорение процедуры восстановления томов
Самый простой способ исключить развертывание образа на вновь создаваемый том OpenStack — это не указывать идентификатор образа при создании тома. Но в этом случае вновь создаваемый том, и, как следствие, восстанавливаемый сервер не получит метаинформацию об образе, который был использован при создании сервера. Информация об образе, использованным для создания тома, отображается в поле Image Name в веб-интерфейсе OpenStack:
Многие платформы виртуализации на основе OpenStack используют эту метаинформацию для своих собственных нужд, а это значит, что подобного рода информация критически важна для полноценной работы вновь создаваемого сервера. Добавить такого рода метаинформацию в уже существующий том можно с помощью специального POST запроса REST API openstack: "https://openstack.local:8776/v3/<ProjectID>/volumes/<VolumeID>/action"
Таким образом для восстановления системного тома новым ускоренным способом потребуется:
Создать новый том требуемого размера без указания идентификатора образа;
Пометить только что созданный том как загрузочный;
Взять метаинформацию у образа, идентификатор которого был сохранен для этого сервера в резервной копии. Также этот идентификатор может быть указан пользователем СРК как параметр восстановления резервной копии image_uuid;
С помощью POST запроса REST API OpenStack https://openstack.local:8776/v3/<ProjectID>/volumes/<VolumeID>/action записать метаинформацию образа в только что созданный том.
Далее процедура восстановления тома проходит в прежнем режиме.
4. Практический пример
В качестве примера приведем логи восстановления сервера openstack с нашего локального стенда, который имеет системный том размером 10 ГБ и использует образ размером 576 МБ.
Часть лога версии модуля rb_module_openstack, которая ещё не содержит изменений по ускорению восстановления системного тома сервера:
[2025-05-23 07:14:20] Info: Creating a copy of backed up volume 'c88f135d-6417-4a4a-b038-419d3f485e26' ...
[2025-05-23 07:14:21] Info: Wait while new volume '9bba2f13-2c5f-455f-87d0-69e93a5aa863' becomes available...
[2025-05-23 07:14:39] Info: New volume '9bba2f13-2c5f-455f-87d0-69e93a5aa863' is available nowЧасть лога модуля rb_module_openstack версии с новым подходом к восстановлению системного тома:
[2025-05-23 06:36:13] Info: Creating a copy of backed up volume 'c88f135d-6417-4a4a-b038-419d3f485e26' ...
[2025-05-23 06:36:13] Info: Wait while new volume '7d8c0681-1085-4e88-9b55-c52f44da4f24' becomes available...
[2025-05-23 06:36:14] Info: New volume '7d8c0681-1085-4e88-9b55-c52f44da4f24' is available nowКак вы можете увидеть, на нашем тестовом стенде предыдущая версия модуля затратила на создание тома 19 секунд, в то время как обновленная версия модуля — 1 секунду.
За более конкретными результатами мы обратились в отдел QA, сотрудники которого обладают полной информацией по производительности СРК RuBackup. Они предоставили результат одного из своих тестов:
Восстановление резервной копии со старой логикой работы с томами | Время референса | Восстановление резервной копии с новой логикой работы с томами | Время после улучшения | Ускорение относительно новой логики работы с томами |
|---|---|---|---|---|
Восстановление полной резервной копии (13 гб диск) на старой логике | 9 минут 25 секунд | Восстановление полной резервной копии (13 гб диск) на новой логике | 8 минут 54 секунды | 31 секунда (5,49%) |
Читатели статьи легко могут повторить этот опыт в своих средах виртуализации openstack в веб-интерфейсе openstack, создавая тома различного размера. Сначала создайте том нужного размера на основе какого-либо образа. Затем создайте том такого же размера, не используя образ. Сравните время, за которое тома получат статус Available. Также можно варьировать используемые образы различных размеров, чтобы получить график зависимости времени готовности тома от размера используемого образа.
5. Заключение
Благодаря этой доработке, при восстановлении системных томов серверов openstack долгая и ресурсоемкая операция развертывания системного тома из образа была заменена на несколько вызовов REST API, что снизило нагрузку на среду виртуализации openstack и ускорило операцию восстановления серверов из резервной копии. В данный момент это улучшение реализовано в модулях rb_module_openstack и rb_module_tionix. В дальнейшем это планируется добавить в модули rb_module_openstack_vol и rb_module_rustack.
