TOC

Как настроить активно-пассивный кластер Apache с помощью Pacemaker в CentOS 7

Вступление

В настоящее время высокая доступность является важной темой, поскольку перерывы в обслуживании могут быть очень дорогостоящими. Целесообразно принять меры, обеспечивающие работоспособность вашего веб-сайта или веб-приложения в случае сбоя. С помощью стека Pacemaker вы можете настроить кластер высокой доступности.

Pacemaker - менеджер кластерных ресурсов. Он управляет всеми службами кластера (resources) и использует возможности обмена сообщениями и членства базового cluster engine. Мы будем использовать Corosync в качестве нашего кластерного движка. Ресурсы имеют resource agent, который является внешней программой, которая абстрагирует сервис.

В активно-пассивном кластере все службы работают в основной системе. В случае сбоя основной системы все службы переносятся в резервную систему. Активно-пассивный кластер позволяет выполнять работы по техническому обслуживанию без перерыва.

Из этого руководства вы узнаете, как создать активно-пассивный кластер Apache высокой доступности. Веб-кластер будет адресован своим виртуальным IP-адресом и автоматически переключится при сбое узла.

Ваши пользователи будут получать доступ к вашему веб-приложению по виртуальному IP-адресу, которым управляет Pacemaker. Служба Apache и виртуальный IP-адрес всегда расположены на одном хосте. Когда происходит сбой этого хоста, они переносятся на второй хост, и ваши пользователи не заметят сбоя.

Предпосылки

Прежде чем приступить к работе с этим учебником, вам потребуется следующее:

  • Две капли CentOS 7, которые будут узлами кластера. Мы будем называть их webnode01 (IP-адрес: `) и webnode02 (IP-адрес: `).

  • Пользователь на обоих серверах с привилегиями root. Вы можете настроить это, следуя этому учебному руководству Initial Server Setup с CentOS 7.

Вам нужно будет выполнить несколько команд на обоих серверах, а некоторые - только на одном.

Шаг 1 - Настройка разрешения имени

Во-первых, нам нужно убедиться, что оба хоста могут разрешить имя хоста двух узлов кластера. Для этого мы добавим записи в файл + / etc / hosts +. Выполните этот шаг на webnode01 и webnode02.

Откройте + / etc / hosts + с помощью + nano + или вашего любимого текстового редактора.

sudo nano /etc/hosts

Добавьте следующие записи в конец файла.

/ и т.д. / хосты

webnode01.example.com webnode01
webnode02.example.com webnode02

Сохраните и закройте файл.

Шаг 2 - Установка Apache

В этом разделе мы установим веб-сервер Apache. Вы должны выполнить этот шаг на обоих хостах.

Сначала установите Apache.

sudo yum install httpd

Агент ресурсов Apache использует страницу состояния сервера Apache для проверки работоспособности службы Apache. Вы должны активировать страницу состояния, создав файл + / etc / httpd / conf.d / status.conf +.

sudo nano /etc/httpd/conf.d/status.conf

Вставьте следующую директиву в этот файл. Эти директивы разрешают доступ к странице состояния с локального хоста, но не с любого другого хоста.

/etc/httpd/conf.d/status.conf

<Location /server-status>
  SetHandler server-status
  Order Deny,Allow
  Deny from all
  Allow from 127.0.0.1
</Location>

Сохраните и закройте файл.

Шаг 3 - Установка кардиостимулятора

Теперь мы установим стек Pacemaker. Вы должны выполнить этот шаг на обоих хостах.

Установите стек Pacemaker и оболочку кластера ПК. Мы будем использовать последний позже для настройки кластера.

sudo yum install pacemaker pcs

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

sudo systemctl start pcsd.service

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

sudo systemctl enable pcsd.service

После установки этих пакетов в вашей системе появится новый пользователь с именем * hacluster *. После установки удаленный вход в систему для этого пользователя отключен. Для таких задач, как синхронизация конфигурации или запуск служб на других узлах, мы должны установить тот же пароль для этого пользователя.

sudo passwd hacluster

Шаг 4 - Настройка кардиостимулятора

Затем мы разрешим кластерный трафик в FirewallD, чтобы наши хосты могли обмениваться данными.

Сначала проверьте, работает ли FirewallD.

sudo firewall-cmd --state

Если он не работает, запустите его.

sudo systemctl start firewalld.service

Вам нужно будет сделать это на обоих хостах. После запуска добавьте сервис + high-Availability + в FirewallD.

sudo firewall-cmd --permanent --add-service=high-availability

После этого изменения вам необходимо перезагрузить FirewallD.

sudo firewall-cmd --reload

Если вы хотите узнать больше о FirewallD, вы можете прочитать этот guide о том, как настроить FirewallD на CentOS 7.

Теперь, когда два наших хоста могут общаться друг с другом, мы можем настроить аутентификацию между двумя узлами, выполнив эту команду на одном хосте (в нашем случае * webnode01 *).

sudo pcs cluster auth webnode01 webnode02
Username:

Вы должны увидеть следующий вывод:

Выход

webnode01: Authorized
webnode02: Authorized

Далее мы сгенерируем и синхронизируем конфигурацию Corosync на том же хосте. Здесь мы назовем кластер * webcluster *, но вы можете называть его как угодно.

sudo pcs cluster setup --name  webnode01 webnode02

Вы увидите следующий вывод:

Выход

Shutting down pacemaker/corosync services...
Redirecting to /bin/systemctl stop  pacemaker.service
Redirecting to /bin/systemctl stop  corosync.service
Killing any remaining services...
Removing all cluster configuration files...
webnode01: Succeeded
webnode02: Succeeded

Конфигурация corosync теперь создана и распределена по всем узлам. Конфигурация хранится в файле + / etc / corosync / corosync.conf +.

Шаг 5 - Запуск кластера

Кластер можно запустить, выполнив следующую команду на webnode01.

sudo pcs cluster start --all

Чтобы убедиться, что Pacemaker и corosync запускаются при загрузке, мы должны включить службы на обоих хостах.

sudo systemctl enable corosync.service
sudo systemctl enable pacemaker.service

Теперь мы можем проверить состояние кластера, выполнив следующую команду на любом хосте.

sudo pcs status

Убедитесь, что оба хоста отмечены как онлайн на выходе.

Выход

. . .

Online: [ webnode01 webnode02 ]

Full list of resources:


PCSD Status:
 webnode01: Online
 webnode02: Online

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enabled

Шаг 6 - Отключение STONITH и игнорирование кворума

Что такое STONITH?

В выходных данных + pcs status + вы увидите предупреждение о том, что устройства STONITH не настроены и STONITH не отключен:

Предупреждение

. . .
WARNING: no stonith devices and stonith-enabled is not false
. . .

Что это значит и почему вас это должно волновать?

Когда администратор ресурсов кластера не может определить состояние узла или ресурса на узле, fencing используется, чтобы снова привести кластер в известное состояние.

Ограждение на уровне ресурсов обеспечивает главным образом отсутствие повреждения данных в случае сбоя путем настройки ресурса. Вы можете использовать ограждение на уровне ресурсов, например, с DRBD (распределенное реплицированное блочное устройство), чтобы пометить диск на узле как устаревший, когда канал связи не работает.

Node level fencing гарантирует, что узел не запускает никаких ресурсов. Это делается путем сброса узла, и его реализация Pacemaker называется STONITH (что означает «выстрелить другим узлом в голову»). Кардиостимулятор поддерживает большое количество устройств для ограждения, например, источники бесперебойного питания или интерфейсные карты управления для серверов.

Поскольку конфигурация ограждения на уровне узлов сильно зависит от вашей среды, мы отключим ее для этого урока.

sudo pcs property set stonith-enabled=false

Что такое кворум?

Кластер имеет quorum, когда более половины узлов в сети. По умолчанию Pacemaker останавливает все ресурсы, если у кластера нет кворума. Однако это не имеет смысла в кластере с двумя узлами; кластер потеряет кворум, если один узел выйдет из строя.

В этом уроке мы скажем Pacemaker игнорировать кворум, установив + no-quorum-policy +:

sudo pcs property set no-quorum-policy=ignore

Шаг 7 - Настройка виртуального IP-адреса

С этого момента мы будем взаимодействовать с кластером через оболочку + pcs +, поэтому все команды нужно выполнять только на одном хосте; не имеет значения, какой именно.

Кластер Pacemaker запущен и работает, и мы можем добавить к нему первый ресурс - виртуальный IP-адрес. Для этого мы настроим агент ресурса + ocf: heartbeat: IPaddr2 +, но сначала давайте рассмотрим некоторую терминологию.

Каждое имя агента ресурса имеет три или два поля, разделенных двоеточием:

  • Первое поле - это класс ресурса, который является стандартом, которому соответствует агент ресурса. Он также сообщает Pacemaker, где найти скрипт. Агент ресурса + IPaddr2 + соответствует стандарту OCF (Open Cluster Framework).

  • Второе поле зависит от стандарта. Ресурсы OCF используют второе поле для пространства имен OCF.

  • Третье поле - это имя агента ресурса.

Ресурсы могут иметь meta-attribute и instance attribute. Мета-атрибуты не зависят от типа ресурса; Атрибуты экземпляра зависят от агента ресурса. Единственный обязательный атрибут экземпляра этого агента ресурса - это + ip + (виртуальный IP-адрес), но для ясности мы также установим + cidr_netmask + (маска подсети в нотации CIDR).

Операции с ресурсами - это действия, которые кластер может выполнять с ресурсом (например, начать, остановить, контролировать). Они обозначены ключевым словом + op +. Мы добавим операцию + monitor + с интервалом в 20 секунд, чтобы кластер каждые 20 секунд проверял, исправен ли ресурс. Что считается здоровым, зависит от агента ресурса.

Сначала мы создадим ресурс виртуального IP-адреса. Здесь мы будем использовать + 127.0.0.2 + в качестве нашего виртуального IP-адреса и * Cluster_VIP * в качестве имени ресурса.

sudo pcs resource create Cluster_VIP ocf:heartbeat:IPaddr2 ip= cidr_netmask=24 op monitor interval=20s

Далее проверяем статус ресурса.

sudo pcs status

Ищите следующую строку в выводе:

Выход

...
Full list of resources:

Cluster_VIP    (ocf::heartbeat:IPaddr2):   Started webnode01
...

Виртуальный IP-адрес активен на хосте webnode01.

Шаг 8 - Добавление ресурса Apache

Теперь мы можем добавить второй ресурс в кластер, который будет обслуживать Apache. Ресурсным агентом службы является + ocf: heartbeat: apache.

Мы назовем ресурс + WebServer + и установим атрибуты экземпляра + configfile + (расположение файла конфигурации Apache) и + statusurl + (URL-адрес страницы состояния сервера Apache). Мы снова выберем интервал монитора в 20 секунд.

sudo pcs resource create WebServer ocf:heartbeat:apache configfile=/etc/httpd/conf/httpd.conf statusurl="http://127.0.0.1/server-status" op monitor interval=20s

Мы можем запросить статус ресурса, как раньше.

sudo pcs status

Вы должны увидеть * WebServer * в выводе, работающем на webnode02.

Выход

...
Full list of resources:

Cluster_VIP    (ocf::heartbeat:IPaddr2):   Started webnode01
WebServer  (ocf::heartbeat:apache):    Started webnode02
...

Как видите, ресурсы работают на разных хостах. Мы еще не сказали Pacemaker, что эти ресурсы должны работать на одном хосте, поэтому они равномерно распределены по узлам.

Шаг 9 - Настройка ограничений размещения

Почти каждое решение в кластере Pacemaker, например выбор места запуска ресурса, принимается путем сравнения показателей. Баллы рассчитываются для каждого ресурса, и менеджер ресурсов кластера выбирает узел с наивысшей оценкой для конкретного ресурса. (Если узел имеет отрицательную оценку ресурса, ресурс не может работать на этом узле.)

Мы можем манипулировать решениями кластера с ограничениями. У ограничений есть оценка. Если ограничение имеет оценку ниже, чем INFINITY, это только рекомендация. Оценка бесконечности означает, что это необходимо.

Мы хотим, чтобы оба ресурса работали на одном и том же хосте, поэтому мы определим ограничение колокейшна со счетом INFINITY.

sudo pcs constraint colocation add WebServer Cluster_VIP INFINITY

Порядок ресурсов в определении ограничения важен. Здесь мы указываем, что ресурс Apache (+ WebServer +) должен работать на тех же хостах, на которых активен виртуальный IP (+ Cluster_VIP +). Это также означает, что + WebSite + запрещено запускать где-либо, если + Cluster_VIP + не активен.

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

Убедитесь, что оба ресурса работают на одном хосте.

sudo pcs status

Выход

...
Full list of resources:

Cluster_VIP    (ocf::heartbeat:IPaddr2):   Started webnode01
WebServer  (ocf::heartbeat:apache):    Started webnode01
...

Оба ресурса теперь на webnode01.

Заключение

Вы настроили двухузловый активно-пассивный кластер Apache, доступный по виртуальному IP-адресу. Теперь вы можете настроить Apache дальше, но не забудьте синхронизировать конфигурацию между хостами. Вы можете написать собственный скрипт для этого (например, с + rsync +) или вы можете использовать что-то вроде csync2.

Если вы хотите распространять файлы вашего веб-приложения среди хостов, вы можете настроить том DRBD и integrate его с Pacemaker.

Related