Corosync + Pacemaker. Как правильно развернуть кластер высокой отказоустойчивости

Рассмотрим несколько возможных решений.

• Oracle Clusterware для Oracle Unbreakable Linux — достаточно дорогой вариант, его стоит использовать, только если имеешь дело с продуктами Oracle.
• Veritas Infoscale Availabilty — коммерческое решение, ранее известное как Veritas Cluster Server. Лицензия VCS Access на узловой кластер из четырех нод будет стоить порядка 20–30 тысяч долларов.
• Red Hat Cluster Suite — решение с открытым исходным кодом. Но для его грамотного использования необходимо изучить большой объем документации, на что у тебя уйдет куча времени.

Я же хочу рассказать, как создать кластеризацию на уровне приложений с высокой отказоустойчивостью в сжатые сроки, с ограниченным бюджетом и без глубоких познаний в построении кластеров. Оптимальным решением, на мой взгляд, будет использование Corosync и Pacemaker. Эта связка бесплатна, ее легко освоить, и на развертывание не уйдет много времени.

Corosync — программный продукт, который позволяет создавать единый кластер из нескольких аппаратных или виртуальных серверов. Corosync отслеживает и передает состояние всех участников (нод) в кластере.

Этот продукт позволяет:

• мониторить статус приложений;
• оповещать приложения о смене активной ноды в кластере;
• отправлять идентичные сообщения процессам на всех нодах;
• предоставлять доступ к общей базе данных с конфигурацией и статистикой;
• отправлять уведомления об изменениях, произведенных в базе.

Pacemaker — менеджер ресурсов кластера. Он позволяет использовать службы и объекты в рамках одного кластера из двух или более нод. Вот вкратце его достоинства:

• позволяет находить и устранять сбои на уровне нод и служб;
• не зависит от подсистемы хранения: можем забыть общий накопитель, как страшный сон;
• не зависит от типов ресурсов: все, что можно прописать в скрипты, можно кластеризовать;
• поддерживает STONITH (Shoot-The-Other-Node-In-The-Head), то есть умершая нода изолируется и запросы к ней не поступают, пока нода не отправит сообщение о том, что она снова в рабочем состоянии;
• поддерживает кворумные и ресурсозависимые кластеры любого размера;
• поддерживает практически любую избыточную конфигурацию;
• может автоматически реплицировать конфиг на все узлы кластера — не придется править все вручную;
• можно задать порядок запуска ресурсов, а также их совместимость на одном узле;
• поддерживает расширенные типы ресурсов: клоны (когда ресурс запущен на множестве узлов) и дополнительные состояния (master/slave и подобное) — актуально для СУБД (MySQL, MariaDB, PostgreSQL, Oracle);
• имеет единую кластерную оболочку CRM с поддержкой скриптов.

Идея заключается в том, что с помощью Corosync мы построим кластер, а следить за его состоянием будем с помощью Pacemaker.

В теории

Попробуем решить следующие задачи.

1. Развернуть кластер высокой отказоустойчивости из двух нод для обработки забросов от клиентов при условии, что они используют общий сетевой адрес и службу веб-сервера nginx.
2. Протестировать отказ одной из нод в кластере, убедиться, что ресурсы передаются на рабочую ноду, когда активная нода упала.
3. Время проверки сбоя на активной ноде 30 секунд.

INFO

Перед началом любых работ настоятельно советую нарисовать схему взаимодействия узлов сети. Это упростит понимание и принципы взаимодействия и работы узлов.

На практике

Настала пора реализовать намеченные задачи. Я в своем примере использовал дистрибутив Red Hat Enterprise Linux 7. Ты можешь взять любой другой Linux, принципы построения кластера будут те же.

Для начала установим пакеты, которые требуются для нормальной работы ПО на обеих нодах (ставим пакеты на обе ноды).

$ sudo yum install -y python3-devel ruby-devel gcc libffi-devel libffi-dev fontconfig coreutils rubygems gcc-c++ wget

Следующую команду тоже нужно исполнять с правами рута, но если использовать sudo, то скрипт установщика отработает неверно и не создастся пользователь hacluster.

$ yum install -y pacemaker pcs resource-agents corosync

Проверяем пользователя hacluster (Pacemaker) и меняем пароль:

$ sudo cat /etc/passwd | grep hacluster

Авторизуемся на нодах под именем пользователя hacluster. Если выходит ошибка доступа к ноде (Error: Unable to communicate with ha-node1), то, скорее всего, из-под Linux-УЗ наложены запреты на использование удаленных оболочек. Необходимо снять ограничение SUDO на время установки.

Когда увидишь следующее, можешь двигаться дальше:

$ sudo -l

Теперь проверяем на обеих нодах установленные пакеты corosync, pacemaker и pcs, добавляем в автозагрузку и запускаем службу конфигурации pacemaker.

$ sudo yum info pacemaker pcs resource-agents corosync
$ sudo systemctl enable pcsd.service; sudo systemctl start pcsd.service

Авторизуемся на нодах под пользователем hacluster:

$ sudo pcs cluster auth ha-node1 ha-node2 -u hacluster

Создаем кластер из двух нод:

$ sudo pcs cluster setup --force --name HACLUSTER ha-node1 ha-node2

Включаем и запускаем все кластеры на всех нодах:

$ sudo pcs cluster enable --all; sudo pcs cluster start --all

При использовании двух нод включаем stonith. Он нужен для «добивания» серверов, которые не смогли полностью завершить рабочие процессы. Игнорируем кворум.

$ sudo pcs property set stonith-enabled=true
$ sudo pcs property set no-quorum-policy=ignore

Запрашиваем статус на обеих нодах ($ sudo pcs status) и видим:

Добавляем виртуальный сетевой адрес и nginx как ресурсы (надеюсь, ты помнишь про тайм-аут в 30 секунд) и запрашиваем статус кластера.

$ sudo pcs resource create virtual_ip ocf:heartbeat:IPaddr2 ip=10.10.10.1 cidr_netmask=24 op monitor interval=30s
$ sudo pcs resource create nginx ocf:heartbeat:nginx op monitor interval=30s timeout=60s
$ sudo pcs status

Выключаем первую ноду на несколько минут. Запрашиваем статус второй ноды, чтобы убедиться, что первая недоступна.

Как только первая нода будет доступна, вручную переключаем на нее виртуальный IP и nginx командой

$ sudo pcs resource move virtual_ip ha-node1; sudo pcs resource move nginx ha-node1

Осталось запросить статус кластера и убедиться, что адрес присвоен первой ноде.

$ sudo pcs resource show

Список всех поддерживаемых сервисов можно посмотреть c помощью команды $ sudo crm_resource --list-agents ocf.

Кластеризация на базе nginx

На обеих нодах должен быть установлен и настроен nginx. Подключаемся к кластеру и создаем следующий ресурс:

$ sudo pcs cluster auth ha-node1 ha-node2 -u hacluster
$ sudo pcs resource create nginx ocf:heartbeat:nginx op monitor interval=30s timeout=30s

Здесь мы создаем ресурс из службы, которая будет каждые 30 секунд проверяться, и в случае минутного тайм-аута ресурс будет включен на другой ноде.

INFO

Чтобы удалить ноду из кластера, воспользуйся командой $ sudo pcs cluster node remove <node_name>.

Выводы

Мы построили простой, но очень отказоустойчивый кластер для фронтенда приложения. Помни, что построение кластера — задача творческая и все зависит только от твоих смекалки и воображения. Невыполнимых задач для системного администратора не бывает!