Александр Мутовин
06.11.2019
18680

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

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

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

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

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

Данный ip адрес одной из нод кластера настроенной в предыдущей статье. Управлять можно с любой ноды.

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

Пользователь hacluster был создан автоматически во время установки pcs. После установки пароль мы ему задали самостоятельно.

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

# pcs cluster status
Просмотр статуса кластера.
Просмотр статуса кластера.

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

  1. Stack: corosync – кластер построен сиспользованием Corosync
Corosync является родным и более предпочтительным для построениякластера. Также вместо Corosync можно использовать CMAN или CCM + heartbeat.

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

В конфигурации кластера из 2 нод кворум включать никак нельзя. Кворум применим только от трех нод и выше

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 
Статус работы Corosync
Статус работы Corosync

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

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

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

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

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

# ps axf
Проверка запуска pacemaker
Проверка запуска pacemaker

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

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

# crm_verify -L –V
Проверка на ошибки кластера
Проверка на ошибки кластера

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

# pcs property set stonith-enabled=false  
отключение STONITH
отключение STONITH
В продакшене нельзя использовать конфигурацию с отключенным STONITH. Отключенный параметр на самом деле не отключает функцию, а только лишь эмулирует ее срабатывание при определенных обстоятельствах.

Первым нашим настроенным ресурсом будет виртуальный 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 запущен на первой ноде.

Если при просмотре статуса кластера вы увидите информацию как на скриншоте ниже (UNCLEAN), это свидетельствует о том,что corosync не синхронизировал ноды. В первую очередь необходимо выполнить команду # ss -tulnp|egrep ‘:5405.*corosync’. Проверить какой порт и интерфейс прослушивает corosync. Далее проверить файл /etc/hosts на корректность. Ну и пропинговать обе ноды.
ошибка синхронизации кластера.
ошибка синхронизации кластера.

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

# pcs clusterstop ha1
Остановка первой ноды.
Остановка первой ноды.

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

# pcs status
Статус на второй ноде.
Статус на второй ноде.

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

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

# pcs cluster start ha1

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

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

# pcs resource defaults resource-stickiness=100

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

 
avatar
  Подписаться  
Уведомление о

Остались вопросы?

Я - Виталий Шелест, менеджер компании Voxlink. Хотите уточнить детали или готовы оставить заявку? Укажите номер телефона, я перезвоню в течение 3-х секунд.

VoIP оборудование

ближайшие курсы

ближайшие Вебинары

ONLINE

Why Choose HUGE?

Unlimited pre-designed elements

Each and every design element is designed for retina ready display on all kind of devices

User friendly interface and design

Each and every design element is designed for retina ready display on all kind of devices

100% editable layered PSD files

Each and every design element is designed for retina ready display on all kind of devices

Created using shape layers

Each and every design element is designed for retina ready display on all kind of devices