Привет, Хабр. Сегодня расскажем о том, как обеспечить высокую доступность сервера управления Кибер Бэкапа путем настройки отказоустойчивого кластера.
Роль сервера управления
Сервер управления является ключевым компонентом СРК Кибер Бэкап. Он предназначен для управления агентами, узлами хранения, хранилищами, планами защиты и групповыми планами, отсылки уведомлений, сбора диагностических данных, формирования отчетов и других операций. Сервер управления предоставляет веб‑интерфейс, с помощью которого выполняется управление инфраструктурой Кибер Бэкапа, настройка всех операций, связанных с резервным копированием и восстановлением данных, а также операции с резервными копиями.
Ключевые компоненты Кибер Бэкапа показаны на диаграмме ниже.
Агенты, установленные на защищаемых объектах, получают от сервера управления задания по резервному копированию и могут выполнять их автономно, не обращаясь к серверу управления в течение достаточно долгого времени (порядка 1 мес.). Таким образом, в случае «падения» сервера, на котором был развернут сервер управления Кибер Бэкапа, резервное копирование продолжает выполняться по расписанию, но статусы операций, данные о защищаемой инфраструктуре и возможность управления и формирования новых заданий или модификации существующих становятся недоступными.
Как было
До недавнего времени выход из строя сервера, на котором расположен сервер управления Кибер Бэкапа, приводил к тому, что требовалось загрузиться со специального загрузочного носителя, созданного средствами Кибер Бэкапа — см. https://docs.cyberprotect.ru/ru‑RU/CyberBackup/16.5/user/#bootable‑media.html, и использовать расположенную на этом носителе утилиту восстановления для развертывания операционной системы и сервера управления на существующем или новом железе. Да, это был рабочий вариант, но крайне неудобный. И, помимо всего прочего, было необходимо не забывать создавать регулярную резервную копию сервера, на котором был развернут сервер управления Кибер Бэкапа и всегда иметь под рукой загрузочный носитель.
Ряд заказчиков использует средства повышения доступности, предоставляемые платформами виртуализации. Это самый простой, с точки зрения администрирования, вариант. Но при этом, если мы бэкапим сами себя, по получается «кольцевая зависимость» — упала среда виртуализации — упал сервер управления Кибер Бэкапа, который требуется для восстановления Кибер Бэкапа.
Как сейчас
Вместе с выходом Кибер Бэкапа 16.5 мы представили решение по созданию отказоустойчивого кластера для сервера управления, позволяющее настроить двухузловой отказоустойчивый кластер на базе двух бесплатных компонентов — Corosync и Pacemaker. Эти компоненты — часть открытого программного стека ClusterLabs для организации кластеров высокой доступности. Компоненты поддерживают огромное количество вариантов внедрений и интеграций с различным ПО.
Данное решение позволяет создать кластер из нескольких узлов (минимум 2) и каждый узел может содержать сервер управления, но функционирует только тот узел, который находится в активном состоянии. Решение не сложное в установке, простое в настройке и может быть развернуто за короткое время.
Данный сценарий можно применить как при построении отказоустойчивых кластеров целиком расположенных на одной площадке, так и при построении устойчивых к катастрофам кластеров распределенных по нескольким центрам обработки данных.
В нашем решении приведен сценарий для:
Двух физических серверов с выделенными IPMI интерфейсами (требуется для удаленного управления аппаратной платформой);
Внешней блочной системы хранения, доступной по протоколу iSCSI;
Виртуальной машины с сервером для кворумного устройства (т. н. «свидетель» или «арбитр»);
Получаемый в результате кластер является классическим отказоустойчивым кластером с общими разделяемыми дисками и виртуальным IP адресом сервиса. Целостность кластера обеспечивается механизмами Stonith с использованием функционала IPMI и защитой от split brain (ошибки, которая возникает при обрыве соединения между арбитром и кластером, когда и активный, и пассивный серверы попытаются взять на себя роль активного сервера, что приведет к «разделению мозгов»)при помощи внешнего арбитра.
Схема функционирования нашего решения показана на диаграмме ниже.
Для того чтобы все файлы настроек сервера управления и базы данных были доступны из любого узла кластера, они хранятся на разделяемом блочном устройстве, которое динамически монтируется к активному узлу. Помимо этого обеспечивается двунаправленная синхронизация ряда системных файлов между узлами кластера. Это необходимо для того, чтобы назначенные пользователи, группы, пароли и пр. были одинаковыми у узлов и сервер управления продолжал правильно работать в случае динамической смены активного узла.
Как это работает
Если узел кластера становится недоступным (произошел сбой в работе сервисов Кибер Бэкапа и т. п.), то в кластере автоматически выбирается другой узел, который назначается активным и к нему переходят все разделяемые ресурсы и запускаются сервисы сервера управления Кибер Бэкапа. Таким образом обеспечивается высокая доступность СРК, устойчивость к отказу сервера управления и соответствие привычным отраслевым практикам СРК для корпоративных заказчиков.
На практике
Сценарий настройки отказоустойчивого кластера их двух узлов приведен для Ред ОС 7.3 Муром, но может быть развернут практически на любой ОС семейства Linux
Подробнее о настройке см. в документе https://docs.cyberprotect.ru/ru‑RU/CyberBackup/16.5/CMSFailover.pdf
Решение протестировано для Кибер Бэкап версий 16.0 и 16.5.
Как будет
Мы продолжаем работу над обеспечением отказоустойчивости сервера управления. В следующих версиях Кибер Бэкапа сервер управления сможет хранить свои данные в СУБД PostgreSQL (в дополнение к SQLite и MS SQL как сейчас). Это позволит обеспечить отказоустойчивость сервера управления и его настроек на уровне файловой системы (как было описано выше), и служебной БД Кибер Бэкап.
Вопросы и ответы
Завершая наш обзор, ответим на несколько вопросов, которые задали участники вебинара, посвященного выходу Кибер Бэкапа 16.5
Вопрос Почему отказоустойчивость реализована только на базе Ред ОС Муром? Как сделать отказоустойчивое решение на базе Windows и на базе Astra Linux?
Ответ: В руководстве описан пример инсталляции на базе Ред ОС Муром. Вы можете построить отказоустойчивый кластер на любой Linux системе, для которой явно заявлена поддержка сервера управления Кибер Бэкапа, подробнее — здесь. На Windows такая реализация недоступна.
Вопрос: В инструкции приведен случай с установкой на аппаратные серверы. Можно ли использовать виртуальные машины?
Ответ: Можно. В составе дистрибутива есть 78 различных способов интеграции с разными устройствами, включая гипервизоры vmware, proxmox, ovirt, xen, RHEV и пр. Справка по настройке и эксплуатации есть на сайте clusterlabs.org и у производителя ОС. Рекомендуем перед внедрением составить перечень возможных отказов и спроектировать метод противодействия, т.к. зачастую установка кластера Кибер Бэкап в ВМ на одном вычислительном кластере неоправданна.
Вопрос: У нас сервер управления совмещен с узлом хранения на одной физической машине. Кластер в версии 16.5 будет возможен в такой конфигурации?
Ответ: Такая конфигурация не является рекомендованной. В сценарии кластеризации сервер управления и узел хранения должны быть разнесены по разным машинам.
Вопрос: Можно ли создать резервную копию существующей инфраструктуры Кибер Бэкапа, включая планы, конфигурации, и восстановить её на вновь поднятый с нуля «чистый» сервер?
Ответ: Да, есть два варианта: через загрузочный носитель или настройку кластера.
Вопрос: Сохранится ли поддержка на Кибер Бекап если я настрою его иначе?
Ответ: Документ по настройке — это референсная архитектура, содержащая пример настройки кластерного ПО и способ интеграции с Кибер Бэкапом. Вы можете настроить все части за исключением описания ресурсов сервисов КБ по своему усмотрению, но не забудьте провести тестирование кластера. Также наша поддержка не оказывает консультаций и не поддерживает сам pacemaker / corosync.
Вопрос: Сейчас кластеризация Кибер Бэкапа требует разделяемого блочного хранилища. Планируется ли реализация кластеризации без требования наличия блочного хранилища?
Ответ: Да, в одном из будущих релизов мы планируем реализовать кластеризацию продукта без обязательного требования к блочному хранилищу. Использование блочного хранилища связано с тем, что в текущей версии сервер управления хранит данные в SQLite и MS SQL, при переходе на поддержку PostgreSQL это требование станет не актуальным.
Вопрос: С какими вопросами следует обращаться в техподдержку Киберпротекта?
Ответ: Мы можем помочь вам с вопросами, связанными с обновлением сервера управления Кибер Бэкапа в кластере, в случаях, когда сервер управления или агент работает некорректно в кластерном окружении и по вопросам интеграции Кибер Бэкапа с кластерным ПО.
Пользуясь случаем хочу поблагодарить Ивана Смирнова и Дмитрия Ермолаева за помощь в подготовке данного материала.
На этом сегодня все, до новых встреч!
