Nginx: Установка и настройка HA-кластера с pacemaker и corosync
Введение
В данной статье будет рассказано о том, как настроить на базовом уровне отказоустойчивый кластер из двух серверов с Nginx на борту, используя Pacemaker и Corosync с применением Virtual IP.
Необходимость настройки кластера возникает тогда, когда появляется реальная потребность в обеспечении отказоустойчивости сервисов и приложений. Есть много различных вариантов по организации отказоустойчивости: начиная от планирования архитектуры в целом, железа, софта и заканчивая комплексным подходом с резервированием серверов, каналов связи, оборудования и даже дата-центров.
В данном же случае будет описан частный случай организации базовой отказоустойчивости посредством использования открытого программного обеспечения. Я не зря уточнил про реальную необходимость применения кластерного решения, т.к. кластер – это дополнительный уровень сложности, и при возникновении с ним проблем и не знании всех нюансов, время на траблшутинг может возрасти в несколько раз по сравнению с тем случаем, если бы кластер не применялся.
Это всё к тому, что решений по настройке кластера может быть много, но нужно с умом подходить к выбору стека и осознанно понимать, что, для чего и когда стоит настраивать, а когда – нет.
Принцип работы кластера
Часто Nginx используют в качестве обратного прокси: в таком случае Nginx обычно является первичной точкой входа для L7\L4 трафика, который уже распределяется до бэкендов. Соответственно, первым шагом обеспечения базовой и относительно простой отказоустойчивости будет резервирование Nginx, чтобы в случае возникновения проблем трафик мог дойти до конечного сервера с приложением.
Для примера я нарисовал простую архитектуру условного приложения, в которой отображен схематично принцип работы кластера:
Пусть будет простое приложение: трафик приходит с сетевого оборудования (для нас это чёрный ящик и про это не думаем) на Nginx, с него попадает на backend и бэк обращается к СУБД в Master-Slave репликации. В данной схеме базово настроен горячий резерв: всегда есть запасной сервер приложений и slave-сервер БД. С этим понятно – просто два сервера приложений и обычная репликация для базы.
А вот суть резервирования точки входа трафика заключается в использовании протокола VRRP. VRRP может настраиваться как на сетевом оборудовании, которое располагается перед сервером с Nginx, так и непосредственно на Linux-сервере с использованием различных реализаций VRRP – про второй случай и будет описано далее. Отвечать за всю логику будет pacemaker и corosync в связке между собой на обоих серверах (т.е. организуется кластер). Соответственно, Nginx устанавливается на оба сервера, которые должны быть абсолютно идентичны: с одинаковыми настройками и конфигурационными файлами.
В кластере настраивается “общий” виртуальный IP-адрес (далее – Virtual IP, VIP), помимо уже существующих IP-адресов на серверах с Nginx. Этот VIP назначается одному из серверов кластера и в текущий момент времени будет работать только один сервер. Как только сервер с VIP выходит из строя, его адрес VIP сразу же забирает себе второй сервер кластера, т.к. в фоновом режиме, условно говоря, будет происходить постоянный healthcheck: каждый из серверов кластера будет проверять, жив ли его сосед.
Принцип работы достаточно прост: работает всегда один сервер, а второй на подхвате и моментально вступает в работу. Но есть всякого рода нюансы относительно кластерного решения в целом, о которых в рамках данной статьи я рассказывать не буду, но очень советую ознакомиться в документации pacemaker. В частности, с таким понятием, как fencig (STONITH).
Ресурсы Pacemaker
Сам Pacemaker, настройка которого будет описана далее, по сути оперирует ресурсами: например, файловая система – ресурс, виртуалка – ресурс, nginx – ресурс. И все эти ресурсы управляются с помощью скриптов, большая часть которых уже готова к использованию.
В терминологии Pacemaker есть простые ресурсы – это могут быть юниты systemd и т.п., т.е. на уровне системы инициализации. Тут всё просто: сервис может быть запущен, остановлен, перезагружен, в некоторых случаях поддерживается мягкая перезагрузка и вывод статуса. Но в случае с Nginx мало запустить ресурс в кластере. Как минимум нужно убедиться, что Nginx отдаёт 200 код ответа.
И тут в игру вступают OCF – некий формат скриптов для Pacemaker, с помощью которых можно более гибко получать данные мониторинга ресурса. А так как под капотом обычные скрипты (которые должны быть написаны с соблюдением стандарта OCF), то есть возможность реализовать очень много всего.
Для более подробного изучения работы Pacemaker лучше обратиться к оф. документации.
Архитектура Pacemaker
Весь конфиг кластера хранится в XML-формате в CIB (Cluster Information Base) и хранится на активной ноде, в терминологии pacemaker – это DC (Designated Controller). В случае аварии роль DC подхватывает моментально доступный сервер в кластере.
Сам Pacemaker состоит из множества компонентов (причем от версии 1 к версии 2 наименования компонентов изменялись). Опишу основные из них с актуальными наименованиями для второй версии Pacemaker:
- pacemaker-based (CIB) – как уже было сказано, хранилище конфигурации;
- pacemaker-attrd – хранит мета-атрибуты самого кластера, ресурсов, нод, агентов;
- pacemaker-controld – DC, главный сервер в кластере на текущий момент времени;
- pacemaker-execd (lrmd) – используется для локального ограждения (fencing);
- pacemaker-fenced – используется для локального и удаленного ограждения.
Corosync
Для синхронизации состояния кластера, получении информации о кворуме и сервисных сообщениях используется corosync. По сути он представляет из себя API для Pacemaker, и в большинстве случаев вручную настраивать его не приходится, т.к. всё делает сам Pacemaker при настройке кластера.
Настройка
Подготовительные работы
- На всех балансировщиках в /etc/hosts добавить записи:
- Установить Pacemaker и Corosync со всеми зависимостями из дефолтных репозиториев centos:
- Установить Nginx из официальных репозиториев nginx.repo
- Выполнить установку и запуск:
- Определиться с Virtual IP. В данном случае будет 10.10.4.30.
Настройка HA
Выполнить на всех нодах:
- Задать пароль кластерного пользователя на всех нодах (желательно должен быть одинаковый):
- Сделать enable для Pacemaker и Corosync (последний на данном этапе не запустится – это нормально):
- Выполнить на любой одной ноде:
- Создать логический кластер, указав DNS-имена из /etc/hosts:
- Проверить, что кластер создан и corosync теперь запущен:
- Отключить Shoot-The-Other-Node-In-The-Head (обратить внимание, для продакшена желательно не отключать):
- Игнорировать кворум (обратить внимание, для продакшена желательно не игнорировать):
- Создать ресурс с указанием VIP и 24 маски:
- Запустить VIP:
- Запустить crm_mon -Af для проверки, что VIP успешно запущен на одной из нод.
- Переместить явно VIP на другую ноду и проверить, что VIP пингуется:
- Создать ресурс для nginx с соответствующим именем (:
- Клонировать на все ноды:
- Сделать привязку агента, чтобы nginx запускался всегда на том же сервере, где и VIP:
- Добавить порядок запуска агента:
- Очистить кластер от ошибок:
- Для мониторинга состояния можно использовать команду:
- Для получения всех настроек ресурса в XML:
Если кластер внезапно разъехался и ноды в статусе UNCLEAN (offline), то необходимо пересобрать кластер, предварительно выполнив:
pcs cluster destroy
rm /var/lib/corosync/ringid_*
Ошибки при эксплуатации
В процессе работы кластера могут возникать различные ошибки. Здесь я опишу некоторые из них, с которыми приходилось сталкиваться.
- A processor failed, forming new configuration
Данная ошибка возникает, когда узлы теряют друг друга из поля зрения, т.е. не могут получить нужный токен. Это означает, что нужно применять политики ограждения, т.н. fencing, и “отстреливать” потерявшиеся узлы. Причиной возникновения таких ситуаций в моём случае являлось перемещение виртуальных машин с одного хоста гипервизора на другой при нехватке памяти на гипервизоре. Для меня, как для админа со стороны эксплуатации, это происходило совсем незаметно, т.к. ВМ и виртуализацией заведуют в ЦОД, где всё располагается, но при миграции это косвенно сказывается на работе кластера pacemaker&corosync.
Заключение
В рамках данной статьи был настроен простой кластер из Pacemaker+Corosync и Nginx, который после понимания теории просто настраивается и сразу же готов к работе. Для production стоит настроить fencig, т.е. ресурсы ограждения, а также использовать три сервера в кластере как минимум, чтобы был кворум, т.е. согласованность. Кворум определяет минимальное число активных нод в кластере, при котором кластер считается работоспособным. Обычно кластер считается неработоспособным, если количество активных нод меньше половины от общего числа узлов.
Также для кворума не обязательно использовать нечетное количество серверов с аналогичными характеристиками. Так, например, при наличии двух серверов в кластере, на которых запущены ресурсы, можно создать третий сервер в качестве арбитра с минимальными ресурсами, т.е. сервер будет исполнять только роль наблюдателя для кворума.
Помимо Nginx в Pacemaker может быть любое другое ПО в качестве ресурса, которое можно “обвесить” скриптами и использовать для failover или чего-либо ещё. Например, по этой же статье можно настроить такой же кластер из Nginx, но уже в docker:
Возможности тут не сильно ограничены и можно этот кейс использовать там, где нет нативного failover.
В документации компании ClusterLabs есть примеры с настройками различных сервисов в кластере, а также ресурсы, которые можно добавить к себе на сервер.
Источник
Linux HA на основе Pacemaker
Pacemaker
Согласно официальной документации, Pacemaker — это менеджер ресурсов кластера со следующими основными фичами:
- Обнаружение и восстановление сбоев на уровне узлов и сервисов;
- Независимость от подсистемы хранения: общий диск не требуется;
- Независимость от типов ресурсов: все что может быть заскриптовано, может быть кластеризовано;
- Поддержка STONITH (Shoot-The-Other-Node-In-The-Head) — лекарства от Split-Brain ;);
- Поддержка кластеров любого размера;
- Поддержка и кворумных и ресурсозависимых кластеров;
- Поддержка практически любой избыточной конфигурации;
- Автоматическая репликация конфига на все узлы кластера;
- Возможность задания порядка запуска ресурсов, а также их совместимости на одном узле;
- Поддержка расширенных типов ресурсов: клонов (запущен на множестве узлов) и с дополнительными состояниями (master/slave и т.п.);
- Единый кластерный шелл (crm), унифицированный, скриптующийся.
Проект кроме собственно своих демонов, поддерживающих конфиг кластера и указанный выше шелл, также использует сторонние, тот же heartbeat и corosync. Я лично (собственно авторы тоже) рекомендую использовать corosync. В общем-то он поддерживает скрипты от heartbeat, поэтому проблем возникнуть не должно.
Установка
На RHEL/CentOS нет ничего проще.
Затем редаектируем /etc/corosync/corosync.conf (там есть corosync.conf.sample) и стартуем.
Да, крайне необходимо иметь правильно настроенный DNS, чтобы резолвились в обе стороны все узлы.
Как добавить узлы? Нет ничего проще, ставим Pacemaker, копируем /etc/corosync/corosync.conf и /etc/ais/authkeys (если настраивали) и запускаем. Узел будет автоматически включен в кластер. Конфиг кластера будет также автоматически скопирован.
Если узел вышел из строя и вы заменили железо? Тоже самое, даем новому узлу то же имя, копируем конфиги и стартуем. Лепота.
Конфигурация
Конфигурация кластера представляет собой простой XML. Однако вручную его править НЕЛЬЗЯ. Все изменения конфига подвергаются автоматическому версионированнию, узлы получают не весь конфиг разом, а только дельты от того, о чем они знают. Т.е. если узел вышел из строя, а в это время вы поменяли конфиг, то когда он вернется, он получит все изменения, которые вы сделали.
Для работы с конфигом можно использовать либо cibadmin, либо собственно сам шелл crm. Посмотреть конфиг можно например так:
Кроме собственно опций кластера, конфигурированию подлежат также:
- Узлы (Nodes);
- Ресурсы (Resources);
- Связи (Constraints).
Как добавлять узлы мы уже разобрались. Удаляются узлы не многим сложнее: останавливаем corosync на узле, а затем удаляем узел из конфига.
Не забывайте, что кворум достигается когда в строю более половины узлов. Поэтому если у вас кластер всего из 2-х, то эту опцию стоит отключить, иначе при падении любого из них, кластер будет считать себя развалившимся.
Ресурсы
Что есть ресурс с точки зрения corosync? Все, что может быть заскриптовано! Обычно скрипты пишутся на bash, но ничто не мешает вам писать их на Perl, Python или даже на C. Все, что требуется от скрипта, это выполнять 3 действия: start, stop и monitor. В общем-то скрипты должны соответствовать LSB (Linux Standard Base) или OCF (Open Cluster Framework) — последнее несколько расширяет LSB, требуя также передачи параметров через переменные окружения с особым названием.
Как мы видим, довольно много уже готовых агентов (Resource Agents). Впрочем, написать самому новый тоже вряд ли составит большого труда.
При создании ресурса нам потребуется задать его класс, тип, провайдера и собственно имя с дополнительными параметрами. В списке выше: ocf — класс, heartbeat — провайдер, IPaddr — тип агента.
Ресурсы поддерживают множество дополнительных параметров, вроде привязки к узлу (resource-stickiness), роли по умолчанию (started, stoped, master) и т.д. Есть возможности по созданию групп ресурсов, клонов (работающих на нескольких узлах) и т.п.
Связи
Начнем с того, что любая связь имеет свой вес — целое число в пределах от -INFINITY до +INFINITY. При этом если вес связи ± INFINITY, то она считается жесткой, в противном случае — мягкой, т.е. если веса других связей окажутся выше, она может быть проигнорирована.
Связи определяют привязку ресурсов к узлу (location), порядок запуска ресурсов (ordering) и совместное их проживание на узле (colocation).
Здесь мы создали еще один ресурс — WebSite, задали совместное проживание его с ClusterIP (кстати, -INFINITY означало бы, что ресурсы НЕ должны находиться на одном узле), определили порядок запуска: сначала ClusterIP, потом WebSite, а потом задали, что WebSite очень желательно находиться на узле pcmk-1, с весом 50. При задании порядка также можно указать, можно ли стартовать ресурсы параллельно или делать это последовательно.
В общем таким образом можно строить довольно сложные цепочки зависимостей ресурсов. Все становиться еще интереснее, если учесть, что можно задавать более сложные правила (rules), срабатывающие, например, только в определенное время суток или в зависимости от состояния компонентов кластера.
Кстати, для облегчения понимая авторы наделили Pacemaker возможностью строить графики в формате Graphviz — см. утилиту ptest.
Источник
