МАСШТАБная интеграция или как мы подружили ECP VeiL с Кибер Бэкап
Привет Хабр! Сегодня мы рассмотрим кейс интеграции системы резервного копирования Кибер Бэкап с платформой виртуализации ECP VeiL от НИИ «Масштаб». Скажу сразу, что это был непростой путь, и нам пришлось приложить немало усилий с обеих сторон, чтобы продукты действительно начали взаимодействовать друг с другом так, как надо. Но, как говорят психологи, «над отношениями надо работать». Что же, мы работали и продолжаем работать. А под катом — небольшой рассказ том, как развивались взаимоотношения Кибер Бэкап и ECP VeiL.
Меня зовут Захар Карлин, и я занимаюсь разработкой в компании «Киберпротект». Мы создаем решения для резервного копирования, поддержки корпоративной инфраструктуры и защиты от утечки данных. Наше решение для резервного копирования Кибер Бэкап часто используется вместе с разработками других российских компаний. И именно запросы заказчиков, использующих систему виртуализации ECP VeiL, стали отправной точкой для проработки интеграции.
Скажу также несколько слов о НИИ Масштаб и их продукте. Как и большинство систем виртуализации, появившихся в последние 10 лет, EСP VeiL разработан на базе гипервизора KVM с открытым исходным кодом. Однако в случае с VeiL, гипервизор претерпел достаточно сильные доработки, а весь набор ПО для менеджмента был разработан вообще «с нуля». И, пожалуй, именно это делает систему виртуализации интересным решением на фоне многочисленных KVM c «нескучными обоями».
Так, управление кластером происходит через web-интерфейс собственной разработки VeiL. Это достаточно удобная утилита для настройки как гипервизора, так и других виртуальных сервисов. Она позволяет контролировать работу виртуальной сети, а также конвергентного хранилища. И, что интересно, система сопровождается защитой от ошибок «человеческого фактора». То есть разработчики из НИИ Масштаб позаботились о том, чтобы VeiL не давал совершить типичные ошибки конфигурирования, от которых KVM может просто упасть.
Логично, что пользователи решения хотели получить столь же удобную и простую систему резервного копирования, которую, с одной стороны, можно просто развернуть вместе с VeiL, а с другой — легко было бы использовать для восстановления рабочих процессов.
Какой должна быть интеграция с гипервизором?
Когда речь заходит об интеграции, самый большой и важный вопрос заключается в том, как именно должны взаимодействовать между собой система виртуализации и система резервного копирования.
Вариант 1 — агентный бэкап:
Можно просто установить бэкап-агент на каждой виртуальной машине и настроить создание резервной копии куда угодно: на внешний накопитель, дисковый массив, сетевую папку или вообще в облако. В этом случае формально бэкап будет работать, но потребует больших трудозатрат по настройке и администрированию. В этом отношении можно выделить три ключевых аспекта:
Управляемость — настраивать резервное копирование придется для каждой машины в отдельности. Хорошо, если будет работать общая консоль для централизованного управления, но даже в этом случае администрирование бэкапов, а также запуск и настройка агентов должны быть реализованы на уровне каждой ВМ.
Надежность — в случае если что-то пойдет не так, возникнут ошибки или виртуальная машина будет атакована, процесс создания резервной копии может быть не завершен, а компания — потерять важные данные.
Производительность — агенты, запущенные на уровне ВМ, потребляют ресурсы этой самой виртуальной машины. Таким образом, процесс создания резервной копии с одной стороны оказывается ограничен и может не укладываться в «окно резервного копирования», а с другой стороны, при большом потоке данных он будет мешать пользователю работать, отнимая его ресурсы.
Вариант 2 — безагентный бэкап:
Этот вариант подразумевает интеграцию/подключение к гипервизору. Благодаря этому не требуется устанавливать бэкап-агенты на каждую ВМ. Интеграция происходит на уровне системы виртуализации, и тут плюсы снова очевидны:
Управляемость — можно бекапить любую ВМ одним щелчком мышки
Производительность — не потребляются ресурсы внутри ВМ
К тому же лучшие практики резервного копирования которые существуют уже много лет и отработаны, например, в VMware ESX или Microsoft Hyper-V, используют именно такой подход. Наверное, не случайно. :)
Как именно работает безагентный бэкап
На первый взгляд, взаимодействие между гипервизором и системой резервного копирования выглядит достаточно просто. Система резервного копирования запускается в качестве отдельной виртуальной машины и через API получает доступ к тем данным, которые необходимо скопировать и зарезервировать. А в случае экстренного восстановления данных может, с одной стороны, обеспечить доступ непосредственно к рабочим файлам, а с другой — запустить из резервной копии саму виртуальную машину, прямо в той же среде виртуализации.
В случае нашей интеграции с ECP VeiL, чтобы реализовать такой подход от гипервизора требовались следующие возможности по запросу через API:
Сделать снапшот системы с дисками (с отправкой запроса freeze и flush через Guest Agent).
Подключить диски из снапшота.
Предоставить доступ к снапшоту.
Создать новую виртуальную машину.
Создать диск для ВМ из общего конвергентного хранилища.
Создать виртуальную сеть.
Создать ВМ.
Предоставлять возможность полной конфигурации ВМ (BIOS, тип шины, последовательность загрузки и т.д.).
Провести логин и аутентификацию.
Подключить кластер/дата-центр/пул ресурсов.
Для этого мы использовали API, который сотрудники НИИ Масштаб разрабатывали самостоятельно — с нуля. Основанные на базе проекта KVM инструменты требовали доработки… и именно этим мы занялись вместе с командой «Масштаба».
В общем схема бэкапа выглядит следующим образом:
мы находим VM которую нас попросили забэкапить — допустим на схеме это VM2.
Далее создается её снапшот (то есть снапшот дисков).
Подключаем заснапшотенные диски к ВМ с установленным VA (virtual appliance).
Производим их бэкап.
По завершению бэкапа мы отключаем диски.
Удаляем снапшот, чтобы он без дела не лежал и лишнего места не занимал.
Плюс интеграции Кибер Бэкапа с ECP VeiL заключается в том, что нам не нужно делать шаг №2. Вместо этого мы совершаем вызов
/api/domains/{{ va_vm_id}}/attach-vdisk/
В этом вызове мы передаем id диска, и если VeiL видит, что диск уже подключен к другой ВМ, он делает снапшот этой ВМ.
Тоже самое с шагом №6. Если после выполнения /api/domains/{{va_vm_id}}/detach-vdisk/ гипервизор VeiL видит, что этот диск подключен к другой vm то при отключении удаляет и снапшот.
От сложностей интеграции к новым фичам
В процессе разработки интеграции периодически что-то ломалось — то API работало неверно, то документация по API оказывалась неполной, то падала вся система виртуализации из-за новых видов нагрузок, то выявлялись проблемы релизного qemu agent… в общем, проблем хватало. В общей сложности совместно с коллегами из НИИ Масштаб было сделано более 80 исправлений в API, включая улучшения существующих и создание новых методов. Команда на стороне НИИ Масштаб отрабатывала наши запросы с невероятной скоростью, выпуская по несколько сборок с фиксами каждую неделю. Такой подход позволил нам наладить стабильную работу безагентного резервного копирования через 4 месяца после начала проекта. Но расскажем про несколько самых интересных ситуаций, с которыми мы столкнулись.
Тюнинг guest-агента QEMU
Одна из самых интересных задач, с которыми мы столкнулись на раннем этапе — это организация бэкапа для Windows-машин. В ходе работ мы столкнулись с интересной особенностью работы QEMU при взаимодействии с ВМ, укомплектованных Windows: снапшоты ломались, а машины падали как будто случайным образом. Но глубокий анализ собранного дампа показал, что это баг в открытом исходном коде QEMU Guest Agent.
Оказалось, что этот баг есть, про него давно знают…и он УЖЕ ИСПРАВЛЕН. Он просто не попал в мастер-ветку, и большинство дистрибутивов на тот момент содержали в себе эту же проблему. В результате, получив эту информацию, коллеги из Масштаба пересобрали Qemu Guest Agent (на базе подписанной Red Hat версии) и решили проблему взаимодействия на уровне снапшота.
Асинхронные вызовы
Хорошо, когда вызовы через API обрабатываются синхронно. Но есть такие операции, которые могут происходить очень долго, например, создание снапшота или удаление снапшота. И, что самое интересное, иногда они происходят быстро и все работает хорошо.
Поэтому при синхронном запросе, спустя некоторое время, Gateway Nginx (именно такой используется в VeiL) возвращает Timeout. По мере углубления, интеграции между нашими продуктами и более тщательного тестирования, эта особенность стала периодически проявляться. Сначала было вообще неясно, откуда растут ноги у этих «Таймаутов». Но когда мы начали проверять работу при достаточно большой нагрузке, все встало на свои места.
Чтобы избежать этой неприятности, часть вызовов, для которых потенциально возможны задержки, мы перевели в асинхронный режим. Теперь уже наш плагин делает запрос, ставит задачу, а потом постоянно пингует Gateway, проверяя, не обработан ли запрос.
Избыточное журналирование сессий
Мы активно взаимодействовали с VeiL через свои API. Через некоторое время активного взаимодействия наших продуктов мы стали замечать увеличение времени пинга…, а потом и вовсе сбои при получении ответов. Оказалось, что на диске разрасталась база транзакций Postgres. Изначально никто не рассчитывал на такое количество данных. Система просто забивалась данными о транзакциях и виртуальные машины переставали работать.
При этом очистка кэша таких данных была предусмотрена в системе, но после дополнительных процедур по очистке СУБД с данными о транзакциях, которые внедрили в работу коллеги из Масштаба, проблема была решена.
Отрицательное количество дисков
Интересно, что наследие API из open-source проекта заставило разбираться с целым рядом нестыковок. Одним из показательных примеров было неверно указанное количество возможных дисков. В документации указано, что «вы можете создать 255 дисков». Создаем 250 дисков, а в консоли отображается »-25». Как вы можете догадаться, разбираться дальше с настройками виртуальной машины, которая оснащена -25 дисками, будет сложно любому пользователю. И таких мелких недочетов и неточностей мы исправили вместе с ребятами из Масштаба достаточно много.
Сущности и разграничения
Одна из интересных возможностей ECP VeiL — разные варианты организации хранения данных. Это очень полезно при развертывании виртуализации во всяческих закрытых контурах, на предприятиях и для обслуживания критической инфраструктуры.
Обычно в KVM создается кластер, в котором все ресурсы доступны каждому хосту. Дальнейшие разграничения происходят верхнеуровнево. Но в ECP VeiL есть интересная возможность — разворачивать хранилища, доступные только в рамках локального хоста.
Это нужно, когда на определенном хосте установлено много дисков, которые должны быть доступны ВМ только с этого сервера. Даже если сервер состоит в кластере, его локальные диски не видны и не доступны другим хостам.
Но мы этого сначала не учли, и, когда начинали взаимодействовать с API, чтобы получить список дисков для бэкапа, наступала коллизия на уровне прав доступа. Чтобы этого не происходило, а также не нарушались эти хитрые правила-разграничения, нам пришлось добавить целый раздел в часть API, отвечающую за доступ к хранилищам данных. После этого в консоли стало четко видно, какие диски мы можем бэкапить, а какие — нет. И для резервного копирования дисков локального хоста нужно просто поднять еще один VA —, но уже на этом конкретном сервере.
Результаты
На сегодняшний день API ECP VeiL представляет собой хорошо задокументированное решение. Для удобства документация была встроена в сам продукт. Странички функций теперь представлены в swagger, так что можно работать с API, ориентируясь на те описания, которые были сделаны коллегами — как самостоятельно, так и в процессе нашего проекта интеграции. Это полезно, потому что только в процессе нашей работы было выпущено более 10 минорных версий API, и для финальной версии хотелось получить удобную и четкую документацию.
Тем не менее, мы продолжаем работу с коллегами по вылавливанию возможных багов и стараемся улучшить интеграцию. Но самое главное, что благодаря проделанной работе, резервное копирование на базе Кибер Бэкап 15 стабильно работает с ECP VeiL, обеспечивая резервирование виртуальных машин и сервисов, автоматическое восстановление, а также была реализована гранулярная работа с данными.
В конечном счете, сегодня пользователь может получить весь спектр виртуальных машин VeiL прямо в веб-консоли нашего продукта и просто выбрать, что и как ему бэкапить — ради этого все и затевалось.
