Мониторинг и настройка кластера на Centos7

В предыдущей статье Сборка кластера на Centos 7 мы установили все необходимые пакеты для сборки кластера, а также собрали его. Далее необходимо настроить все необходимые сервисы, самое главное для нас это репликация DRBD и общий виртуальный IP адрес для доступа к нашему кластеру с одного ip адреса.

Сначала я хотел бы рассказать подробнее об утилите pcs. Pcs управляется как через консоль командной строки, так и через веб интерфейс. Веб интерфейс у него располагается по умолчанию  на порту 2224. Давайте его рассмотрим более подробно.

Переходим по адресу https://192.168.32.19:2224

Перед нами откроется веб интерфейс со страницей авторизации. Тут логин будет hacluster и пароль от этой учетной записи.

Введем команду

# pcs cluster status

На скриншоте мы видим следующее:

1. Stack: corosync – кластер построен сиспользованием Corosync

2. Current DC: ha2 (version 1.1.20-5.el7_7.1-3c4c782f70) — partition WITHOUT quorum  — в качестве главного контроллера выбрана вторая нода. Также указана версия контроллера. В конфигурации этого кластера кворум не учавствует. Он отключен.

3. Last updated: Sun Nov  3 14:27:32 2019 – дата последнего обновления

4. Last change: Sun Nov  3 13:02:46 2019 by hacluster via crmd on ha2 – дата последних изменний в конфигурации кластера

2 nodes configured – какое количество нод сконфигурировано. В данном случае 2 ноды.

5. 0 resources configured – данная запись говорит о том, что ни один ресурсу нас не сконфигурирован.

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

# corosync-cfgtool –s 

На скриншоте видно, что ID ноды на которой  была выполнена команда 2.

В следующей строчке указан ее ip адрес 192.168.32.19

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

Если в выводе даной команды вы видите ошибки, то начните диагностику с проверки фаервола и Selinux. Они должны быть выключены.

Далее необходимо проверить правильную работу pacemaker. Сам по себе pacemaker это набор утилит, поэтому проверим корректность запуска всех необходимых сервисов командой:

# ps axf

Из скриншота видно какие сервисы запущены.

Прежде чем приступать к какому либо конфигурированию сервера проверим кластер на возникновение ошибок:

# crm_verify -L –V

Как видно из скриншота у нас обнаружились ошибки. Это связано с тем, что STONITH включен в кластере по умолчанию. Но он не сконфигурирован, поэтому возникают ошибки. Мы отключим STONITH, в будущем его можно будет настроить и включить.

# pcs property set stonith-enabled=false  

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

# pcs resource create ClusterIP ocf:heartbeat:IPaddr2 ip=192.168.32.200 cidr_netmask=32 op monitor interval=15s

Выше написанная команда означает: создать ресурс с именем ClusterIP используя алгоритм ресурсов ocf. Этот рессурс будет виртуальным ip адресом 192.168.32.200 с 32 маской. Также каждые 15 минут необходимо производить мониторинг работы. В случае выхода из строя ноды необходимо виртуальный ip переключить на другую ноду.

• Ocf – это стандарт которому соответствует скрипт ресурта. А также где его нати
• Heartbeat – специфичное для стандарта поле, для ресурсов ocf он сообщает кластеру, в каком пространстве имен OCF находится сценарий ресурса
• IPaddr2 –  это имя сценария ресурса.

Дл того, чтобы увидеть доступные стандарты ресурсов необходимо выполнить команду:

# pcs resource standards

Чтобы отобразить группы сценариев ресурсов выполните команду:

# pcs resource providers

Далее посмотрим статус:

# pcs status

Как видно из скриншота, виртуальный ip запущен на первой ноде.

Теперь давайте сэмитируем отказ ноды,на которой запущен виртуальный ip адрес. Выполним следующую команду на отключение:

# pcs clusterstop ha1

Проверим статус на второй запущенно ноду:

# pcs status

Как видим из скриншота, виртуальный ip адрес поднялся на второй ноде.

Запустим первую ноду:

# pcs cluster start ha1

IP адрес восстановился на первой ноде

Переключение ресурсов между нодами иногда занимает продолжительное время, особенно если речь идет про базы данных. Следовательно не желательно чтобы ресурсы кочевали при восстановлении работы нод. Для этого предотвращения используется так называемая “Липкость” это вес ресурса, который задается на той или иной ноде:

# pcs resource defaults resource-stickiness=100

В этой статье мы рассмотрели базовую диагностику и конфигурирование кластера. В следующей статье мы привяжем к кластеру DRBD.