Привет, Хабр! Меня зовут Иван, я системный архитектор в компании Киберпротект. Сегодня, как и обещали во вводной статье, расскажем про платформу OpenStack и как мы сделали ее поддержку в нашем Кибер Бэкапе 16.
Задача
OpenStack – популярная облачная операционная система с открытым исходным кодом, управляющая большими пулами ресурсов – для вычислений, хранения и организации сетей. Платформа OpenStack (а также платформы, построенные на ее основе) нашла широкое применение на рынке, и, как следствие, спрос на системы резервного копирования (СРК) для этой платформы достаточно высок. Кибер Бэкап поддерживает резервное копирование для широкого спектра платформ виртуализации, поэтому добавление поддержки OpenStack в релизе Кибер Бэкап 16 стало логичным и востребованным расширением поддерживаемых платформ.
При добавлении поддержки OpenStack, мы стремились не только реализовать резервное копирование и восстановление конфигураций и данных виртуальных машин («инстансов» в терминологии OpenStack), но и обеспечить бесшовную интеграцию с сервисами и функциями Кибер Бэкап. Такая интеграция позволила бы использовать фирменные «фишки» нашего продукта, такие как простота и удобство развертывания СРК для любой платформы, возможность гибкой настройки планов резервного копирования и восстановления, поддержка полного, дифференциального и инкрементного резервного копирования в любые типы хранилищ (локальные и сетевые папки, SFTP, ленточные библиотеки, специализированные ноды-хранилища), кроссплатформенное восстановление виртуальных машин между платформами виртуализации и т.д.
Коротко об OpenStack
OpenStack представляет собой решение класса «инфраструктура как услуга» (IaaS) на базе набора взаимосвязанных сервисов, каждый из которых использует общий механизм аутентификации и предоставляет публичный API для интеграции как с другими сервисами OpenStack, так и со сторонними приложениями. Помимо стандартной функциональности IaaS, компоненты OpenStack предоставляют широкий набор сервисов - оркестрация, управление оборудованием, управление приложениями и рабочей нагрузкой, мониторинг и т.д.
Ядро OpenStack составляют следующие сервисы:
Keystone – “краеугольные камень” OpenStack, сервис идентификации, предоставляющий единую точку для аутентификации, авторизации и обнаружения сервисов OpenStack.
Nova – ключевой сервис вычислительной системы OpenStack, обеспечивающий предоставление вычислительных инстансов (compute instances) - виртуальных серверов на базе различных гипервизоров.
Cinder – сервис блочного хранилища для хранения виртуальных дисков (volumes) виртуальных машин Nova (а также дисков для bare metal хостов, контейнеров и т.д). Сервис виртуализирует управление блочными устройствами и предоставляет API для использования блочных хранилищ без привязки к деталям реализации и развертывания хранилища. Детали реализации определяются в драйвере конкретного блочного хранилища (LVM, NAS/SAN, NFS, iSCSI, Ceph и многие другие).
Glance – сервис, предоставляющий услуги регистрации, обнаружения и загрузки образов виртуальных машин и сопутствующих мета-данных.
Neutron – сервис "сеть как услуга" между сетевыми интерфейсами, управляемыми другими сервисами OpenStack. Отвечает за предоставление виртуальных или физических сетевых соединений, к которым подключаются вычислительные инстансы.
Placement - служебный сервис, позволяющий другим сервисам OpenStack вести учет и распределение ресурсов (например, CPU и RAM вычислительных нод, дискового пространства, IP адресов из внешнего пула и т.д.)
Важная черта OpenStack – представление вычислительных, дисковых и других ресурсов в виде абстрактных сущностей, не привязанных к платформе виртуализации или СХД. Взаимодействие с конкретной платформой реализовано посредством драйверов, которые реализуют определенный набор обязательной функциональности, доступной через API OpenStack. Поэтому, интегрируясь с OpenStack через его API, мы получаем решение, практически не зависящее от того, какая платформа виртуализации/СХД будет у OpenStack «под капотом». (Необходимо, однако, оговориться, что, здесь, как обычно, «дьявол кроется в мелочах»: фичи, которые считаются в OpenStack опциональными, могут оказаться реализованы не для всех платформ виртуализации и СХД, поэтому не все методы API OpenStack будут работать абсолютно одинаково на всех платформах)
Подходы к СРК для OpenStack
При построении СРК для любой платформы виртуализации можно идти двумя путями: устанавливать агента СРК в каждую защищаемую ВМ (т.н. бэкап с использованием агентов) или, если позволяют возможности платформы и предоставляемый ею API управления, использовать схему без агентов, т.е. устанавливать агента отдельно от защищаемых ВМ на вычислительную ноду или в отдельную виртуальную машину (т.н. «виртуальное устройство», ВУ), и интегрироваться с платформой виртуализации на уровне ее API. Подробное сравнение двух подходов, их плюсы и минусы можно найти в нашей статье «Так с агентом или без?»
Поскольку инсталляции OpenStack могут обслуживать десятки и сотни ВМ, основной упор был сделан на реализацию именно схемы без использования агентов, т.к. она дает бОльшую гибкость и удобство в администрировании, а также обеспечивает защиту «рабочих» ВМ с меньшими накладными расходами и нагрузкой на платформу.
Второй момент – определение степени «инвазивности» интеграции, т.е. достаточно ли API OpenStack для реализации всего функционала СРК, так что все процессы можно изолировать внутри отдельной виртуальной машины с предустановленным агентом Кибер Бэкап или же необходима установка каких-либо компонентов непосредственно на физические ноды (вычислительные и/или СХД). С одной стороны, использование компонентов, установленных непосредственно на физических нодах, позволило бы взаимодействовать с гипервизором или СХД «теснее», чем это возможно только через API OpenStack, что, потенциально, дает бОльшее пространство для оптимизации и ускорения процессов резервного копирования и восстановления. Но, с другой стороны, изоляция в пределах ВУ существенно упрощает развертывание и последующее обслуживание СРК, а также позволяет контролировать нагрузку на платформу, поскольку ВУ, как и любая другая ВМ, контролируется гипервизором и ограничивается выделенными ей лимитами ресурсов, поэтому (при правильной настройке) в процессе работы не сможет «положить» вычислительную ноду. Кроме того, интеграция в обход API OpenStack – это потенциальная завязка на детали реализации той или иной инсталляции OpenStack (т.е. «подкапотные» платформу виртуализации/СХД), и, как следствие, усложнение и удорожание последующего сопровождения и развития СРК для OpenStack.
Изучив возможности OpenStack, мы выбрали наименее «инвазивный» путь – интеграцию через API OpenStack c изоляцией агента Кибер Бэкап в ВУ (так, по крайней мере, сделано в первой версии поддержки OpenStack в Кибер Бэкап).
Особенности и технические ограничения OpenStack
В процессе разработки поддержки резервного копирования и восстановления OpenStack мы столкнулись с рядом особенностей и технических ограничений платформы (причем, некоторые из них оказались достаточно неожиданными), которые повлияли на функционал, который мы реализовали в Кибер Бэкап. Ниже мы обсудим подробности наиболее существенных особенностей и ограничений платформы.
Image-backed vs Volume-backed инстансы
OpenStack поддерживает два класса инстансов, отличающихся реализацией управления их загрузочными дисками:
Инстансы на основе загрузочного образа (image-backed)
Инстансы на основе загрузочного диска (volume-backed).
Для image-backed инстансов загрузочный диск является так называемым «эфемерным» диском. Он управляется сервисом Nova и автоматически удаляется при удалении инстанса, т.е. время жизни эфемерных дисков совпадает со временим жизни инстанса. Поскольку диск является локальным для инстанса, он, потенциально, может обеспечить бОльшую производительность, однако при выходе вычислительной ноды из строя, данные на диске могут быть утеряны. Поэтому обычно такие диски используются только для запуска OC, а данные приложений в инстансе хранятся на дополнительных «постоянных» дисках, управляемых сервисом Cinder.
Для volume-backed инстансов загрузочный диск создается и управляется сервисом Cinder. Время жизни дисков не ограничено временем жизни инстанса (хотя при создании volume-backed инстанса можно настроить автоматическое удаление диска вместе с инстансом). Обычно такие диски создаются и управляются специализированной СХД.
Управление image-backed и volume-backed инстансами имеет ряд существенных различий - их необходимо учитывать при создании СРК для OpenStack.
Для создания резервной копии инстанса прежде всего необходимо сделать его снапшот, в котором будет «заморожено» состояние дисков инстанса на некоторый момент времени. Процессы внутри инстанса могу продолжать работу и далее, читать/писать на диски без риска повредить данные, предназначенные для резервного копирования, т.к. СРК будет работать с данными, «замороженными» в снапшоте. И для image-backed, и для volume-backed инстансов создание снапшота – это создание нового образа в сервисе Glance, однако его содержимое коренным образом отличается для image- и volume-backed инстансов.
Снапшот image-backed инстанса – это новый образ виртуальной машины, в котором захвачено текущее состояние корневого диска инстанса.
Снапшот volume-backed инстанса – это просто запись в сервисе Glance (образ нулевого размера), в свойствах которого прописано соответствие созданных снапшотов дисков дисковым устройствам в исходном инстансе (плюс некоторые дополнительные свойства исходных дисков, необходимые для восстановления инстанса из этого образа).
Второе ключевое отличие при создании снапшота image-backed и volume-backed инстансов – это обработка дополнительных дисков, подключенных к инстансу. Так, при создании снапшота image-backed инстанса, OpenStack не создает снапшоты подключенных к инстансу дополнительных дисков. API OpenStack позволяет сделать снапшоты дисков отдельно, однако в этом случае данные в снапшоте корневого диска и в снапшотах дополнительных дисков не будут скореллированы по времени, что может оказаться критичным при восстановлении инстанса, особенно в случае, если в нем установлены приложения, активно производящие чтение/запись на дополнительные диски.
Для volume-backed инстансов, OpenStack автоматически создает снапшоты всех дисков, подключенных к инстансу, т.е. как загрузочного корневого, так и всех дополнительных.
По умолчанию, снапшот инстанса будет crash-consistent, но если в качестве платформы виртуализации используется QEMU/KVM, в инстансе установлен гостевой QEMU-aгент, а в метаданных образа, из которого был создан инстанс или его загрузочный диск, было выставлено свойство 'hw_qemu_guest_agent=yes’, то перед созданием снапшотов будет произведена подготовка гостевой OS к созданию снапшота (quiesce) - это дает возможность получить application-consistent снапшот всех дисков инстанса.
Особенности работы с дисками в OpenStack
В ходе изучения API OpenStack выяснилось, что, в отличие от других платформ виртуализации, OpenStack позволяет подключить к инстансу только диски, но не их снапшоты. Поэтому для создания резервной копии инстанса, после создания снапшотов его дисков, из этих снапшотов требуется создать временные копии дисков, и уже их подключать к ВУ для копирования данных. Производительность этой операции зависит от используемой СХД, и, хорошо, если она поддерживает быстрое создание снапшотов и клонирование дисков из снапшотов. Кроме того, создание временных копий дисков будет «отъедать» квоту на доступное для проекта дисковое пространство, поэтому для создания резервной копии инстанса у проекта должно быть достаточно доступной дисковой квоты.
Второй критической особенностью оказалась невозможность отключить/заменить у volume-backed инстанса корневой (т.е. оригинальный загрузочный) диск. У этой проблемы давняя история, и, к сожалению, пока она не имеет хорошего решения, а без этой функциональности возможность восстановления в существующий volume-backed инстанс средствами API OpenStack имеет серьезные ограничения. Да, OpenStack, в принципе, позволяет одновременно подключить один диск к нескольким инстансам (multi-attach), но эта функциональность является опциональной и поддерживается далеко не всеми Cinder-драйверами, а главное – требует специальной настройки Cinder и изначального создания диска c возможностью множественного подключения, поэтому закладываться на наличие этой функциональности в общем случае было бы слишком сильным допущением.
Однако есть и хорошие новости: не так давно в OpenStack была исправлена «пересборка» volume-backed инстансов на произвольном образе, что, в принципе, открывает возможность восстановления в существующий volume-backed инстанс, однако эта функциональность доступна только начиная с релиза Zed (октябрь 2022г), тогда как в Кибер Бэкап поддерживаются версии OpenStack, начиная с Ussuri (2020г). Но тем не менее, в будущих версиях Кибер Бэкап мы планируем добавить поддержку восстановления в существующий инстанс.
Изменения в RBAC
Еще одной особенностью OpenStack оказалась непрерывная эволюция такой, казалось бы, фундаментальной вещи, как реализация ролевой модели доступа (RBAC). В разных релизах OpenStack RBAC-модель оказывалась либо слишком «снисходительной», когда администратор проекта автоматически получал административные привилегии на уровне всей инсталляции OpenStack, либо слишком «ограничивающей», и, в результате, администратор проекта не имел возможности полноценно управлять ресурсами в своей зоне ответственности, не обращаясь к администратору всей инсталляции OpenStack. Нам пришлось учесть эти различия, т.к. одни и те же вызовы API OpenStack, в зависимости от релиза платформы, начинали вести себя по-разному. Прежде всего, это отразилось на лицензировании OpenStack в Кибер Бэкап. Дело в том, что Кибер Бэкап лицензирует платформы виртуализации по количеству физических вычислительных хостов, обнаруженных агентом Кибер Бэкап в защищаемой платформе. Но в случае с OpenStack, информация о физических вычислительных хостах доступна только пользователю с правами не меньше reader на уровне всей инсталляции OpenStack (а в некоторых релизах – только администратору всей инсталляции).
Для полноценного функционирования агенту Кибер Бэкап достаточно прав на уровне администратора защищаемого проекта. Поэтому, чтобы не требовать предоставления излишне высоких привилегий, агент Кибер Бэкап пробует получить информацию о доступных физических вычислительных нодах, а если эта информация недоступна, строит список т.н. «виртуальных» вычислительных нод, исходя из уникальных идентификаторов хостов, полученных от OpenStack в свойствах инстансов. Нюанс состоит в том, что этот идентификатор уникален в рамках одного проекта OpenStack, т.е. для двух инстансов, расположенных на одной и той же физической ноде, но принадлежащих разным проектам, идентификатор хоста также окажется разным, т.е. с точки зрения лицензионного движка Кибер Бэкап инстансы будут находиться на разных вычислительных хостах, каждому из которых будет выдана своя лицензия.
Эту особенность необходимо учитывать при развертывании Кибер Бэкап для OpenStack, и либо выдавать аккаунту, под которым агент Кибер Бэкап будет обращаться к API OpenStack достаточно прав для получения информации о физических вычислительных хостах, либо, если это по каким-либо причинам невозможно, планировать количество необходимых лицензий для «виртуальных» вычислительных хостов, количество которых, в пределе, будет равно произведению количества защищаемых проектов на количество физических вычислительных нод.
Что в итоге и что дальше?
В итоге, в Кибер Бэкап 16 была реализована поддержка OpenStack (минимальная поддерживаемая версия - Ussuri) по схеме без агентов, т.е. с развертыванием агента/агентов Кибер Бэкап в виде отдельных инстансов (виртуальных устройств) в защищаемых проектах OpenStack. В ВУ изолированы все процессы, осуществляющие взаимодействие с OpenStack через его публичное API, что позволяет минимизировать и контролировать нагрузку со стороны ВУ на платформу по сравнению со схемой, когда агент устанавливается в каждый защищаемый инстанс или с установкой агента на физические хосты. Развертывание ВУ осуществляется в несколько кликов непосредственно из централизованной панели управления Кибер Бэкап. После развертывания ВУ в инсталляции OpenStack, все проекты, к которым имеет доступ аккаунт, из-под которого агент Кибер Бэкап взаимодействует с API OpenStack, автоматически отображаются в дереве защищаемых ресурсов в панели Кибер Бэкап, вместе со всеми находящимися в них инстансами.
Реализация взаимодействия с платформой OpenStack исключительно через его API, без установки дополнительных компонентов на физические вычислительные ноды и/или ноды СХД, а также учет мультитенантной архитектуры OpenStack, позволяет применять СРК Кибер Бэкап как для локальных инсталляций OpenStack (где администратор может настроить интеграцию максимально гибко), так и в случае аренды мощностей на базе платформы OpenStack в публичном облаке (где административный доступ к платформе будет ограничен).
Бесшовная интеграция с сервисами Кибер Бэкап позволяет получить «из коробки» большинство фич Кибер Бэкап: централизованное управление планами резервного копирования и восстановления инстансов, поддержка полного, дифференциального и инкрементного резервного копирования на различные носители, включая ленточные накопители, возможность кроссплатформенного P2V, V2V и V2P восстановления данных из/в инстансы OpenStack, а также возможность восстановить каталоги/файлы непосредственно из резервной копии.
В первом релизе с поддержкой OpenStack не обошлось без ограничений: поддерживается резервное копирование и восстановление только volume-backed инстансов, причем восстановление возможно только в новый инстанс. Поддержка image-backed инстансов и восстановление в существующий инстанс планируется в будущих версиях Кибер Бэкап.