В прошлом посте мы начали говорить о проблематике резервного копирования в контейнерных средах на базе Kubernetes. Тогда мы подробно рассмотрели реализацию систем резервного копирования (СРК) на базе внутрикластерных решений, таких как Kasten. Сегодня мы продолжаем эту тему и рассматриваем сценарий внешнего резервного копирования на примере продукта Commvault Backup & Recovery.
Внешнее резервное копирование
Альтернатива внутрикластерным механизмам бэкапа, о которых мы говорили в прошлый раз — применение классических систем резервного копирования. Например, мы для бэкапа контейнерных сред часто используем Commvault, разработчики которого также прилично вложились в возможности создания бэкапа Kubernetes. Последние версии продукта уже интегрированы с популярными оркестраторами и поддерживают важные функции, как например, копирование ETCD (при помощи резервного копирования с файловой шары или S3), драйверов CSI и другой «обвязки», необходимой для нормального восстановления Kubernetes. Рассмотрим на его примере бэкап и восстановление контейнерных приложений.
Преимуществ у внешних СРК много. Например, они не зависят от доступности кластера, а также являются единой точкой входа для бэкапа всей инфраструктуры. Поэтому компаниям, у которых в ИТ-инфраструктуре уже налажены процессы резервного копирования (РК), правильнее адаптировать для работы с Kubernetes используемое коммерческое решение. У того же Commvault есть эффективная система дедупликации, которая по своей результативности не уступает аппаратным решениям. Когда в кластере запущено сотни и даже тысячи контейнеров, такой механизм позволит сэкономить десятки процентов полезной емкости хранилищ. Еще одно достоинство такого подхода в том, что специалисту не нужно глубоко понимать принципы работы кластера Kubernetes. Если администратор настроил сервер Commvault, то он точно справится с настройками резервного копирования Kubernetes.
Схема работы внешних СРК строится иначе, чем тех, которые устанавливаются внутри кластера. Например, Commvault использует для сбора информации для резервной копии специальный узел в своей инфраструктуре, так называемый Access Node. И именно через него СРК общается с оркестратором Kubernetes по стандартному API, получает данные о конфигурациях и настройках. Но в случае с Persistent Volume интеграция происходит на уровне подов. При резервном копировании контейнеров происходит «разделение обязанностей» между Access Node и Commvault подами: первые отвечают за резервное копирование конфигурации контейнера (YAML, PVC, secret, CRD), а Commvault поды выполняют резервное копирование Persistent Volume.
Для подключения к данным в кластере Kubernetes может быть создано любое необходимое количество Access Node и Commvault подов. Служебные Commvault поды автоматически создаются по количеству защищаемых Persistent Volumes и удаляются по завершению задания бэкапа. Но управляются они централизованно, из то же консоли, что и весь остальной корпоративный бэкап. Благодаря этому автоматизированные механизмы Commvault обеспечивают балансировку нагрузки и помогают установить лимит ресурсов на выполнение каждой из операций.
Управление параметрами РК происходит через веб-консоль. Возможность работы с Kubernetes появилась в Commvault недавно и доступна только через новый интерфейс.
Чтобы настроить бэкап Kubernetes, нужно добавить кластер: указать URL для доступа к API, а также предоставить доступ на уровне администратора. Вам потребуется предоставить системе сервис-аккаунт или ввести учетные данные: имя пользователя и пароль.
Необходимый компонент для работы внешней СРК — это Access Node. Через него данные забираются из Kubernetes. После подключения кластера необходимо добавить в Commvault защищаемые приложения в виде Application Group. Это объект Commvault, который позволяет выбрать один или несколько Namespace для защиты.
Вы определяете расписание, тип (полная копия или инкрементальная), время хранения, а также устройства, на которых будут размещаться копии. Далее всё работает автоматически.
На уровне Kubernetes, как и в случае с Kasten создаются Snapshot’ы.
Теперь рассмотрим вариант резервного копирования при помощи Side-car-контейнера. На уровне OpenShift мы уже работаем со специальным набором контейнеров — самим сервером СУБД и это заранее подготовленным образом, в котором установлен агент Commvault. В каком-то смысле мы получаем аналог агента, установленного на уровне ОС: он командует «сбросить кэш», «остановиться», «продолжить работу». Это позволяет сохранить консистентность СУБД при бэкапировании.
Stateful set настраивается таким образом, что в нем работает не один, а два контейнера. После запуска, второй контейнер подключается к Commvault. В этом случае имя клиента совпадает с именем пода, а доступ настраивается по логину и паролю к Postgres SQL. У такого подхода есть ещё одно важное преимущетво: не нужно открывать доступ к кластеру Kubernetes. Инициатором подключения между сервером РК и агентом является сам агент.
После настройки можно создавать два типа резервных копий: на уровне дампов (логические) и на уровне файлов. Это удобно, потому что можно делать как полное РК, так и инкрементальное на основе логов транзакций.
Восстановление с Commvault
В Commvault можно выбрать точку, а также тип восстановления. Вы можете восстановить контейнер в тот же Namespace или «рядом», а также выбрать отдельные объекты в виде YAML-файлов, которые будут восстановлены на Access Node. Кроме этого, система позволяет восстановить отдельные файлы, которые существовали внутри персистентного хранилища. Благодаря этому контейнерное приложение можно действительно вернуть в исходное состояние.
Копирование по файлам бывает полезно, если нужно восстановить, например, одну страничку сайта, которая по какой-либо причине перестала работать. Вместо переразвертывания кластера и восстановления нескольких гигабайт можно просто заменить пару файлов в персистентном хранилище, и сайт снова работает!
К счастью, есть обходной путь. Мы создаем новую папку, в которую восстанавливаются все данные резервной копии. А потом с помощью СonfigMap меняем путь к данным PostgreSQL. Дальше нужно просто дать контейнеру команду Terminate, чтобы он перезапустился.
В консоли Commvault можно выбрать нужную резервную копию и запустить восстановление. Мы снимаем галочку с опции перезапуска сервера СУБД, чтобы процесс прошел успешно.
В параметрах надо указать переадресацию на новый каталог. Это придется делать в «толстой» консоли, потому что в веб-консоли пока нет функции redirect.
Уведомление подтверждает, что сервер должен быть остановлен, а папка данных — удалена
Теперь данные восстанавливаются в новой папке. Их создание видно в OpenShift, а также через Job Controller в Commvault.
После пересоздания подa можно подключиться к СУБД и убедиться в том, что она работает с новой папкой данных. Проверить корректность восстановления также можно через консоль Commvault.
Какой же из методов лучше и выгоднее?
Если вы прочитали оба поста, то можете сопоставить два разных подхода к бэкапу с точки зрения технической реализации. Но есть еще одна плоскость сравнения этих способов резервирования — финансовая. Стоимость Commvault по привычной схеме складывается из бюджета на лицензии, развертывание и поддержку. Kasten, хотя и может быть использован как бесплатное решение, но с рядом ограничений: до 10 нод в кластере и никакой поддержки. А это рискованно, когда мы говорим о критически важных для бизнеса сервисах и приложениях. Чтобы противостоять серьезным проблемам для продуктива обычно выбирают Enterprise-лицензию с поддержкой от разработчиков. А это уже платная опция.
Оба метода исправно работают и при правильной настройке обеспечивают сохранность состояния важных сервисов и персистентных хранилищ в Kubernetes. Каждый из инструментов подойдет для определенных сценариев. Kasten, например, будет хорош для нативных контейнерных сред, а Commvault больше подойдет компаниям, которые уже используют эту СРК для остальной инфраструктуры — в этом случае появляется возможность сэкономить на развертывании и содержании СРК, а также воспользоваться «общими» инструментами, как например, дедупликация.
А как вы бэкапите кластеры Kubernetes, если в нем запущены СУБД и другие, совсем не контейнерные приложения?
Авторы:
Вячеслав Детинников, инженер-проектировщик систем хранения данных «Инфосистемы Джет»
Ренат Мустафин, архитектор DevOps-решений «Инфосистемы Джет»