Однако мы решили не ограничиваться только этими разработками и поискать альтернативное кластерное решение для x86. Так был инициирован внутренний проект по тестированию кластерной конфигурации на базе ПО Pacemaker.
Pacemaker является opensource-продуктом, который входит в состав многих дистрибутивов Linux. Продукт поддерживает широкий набор кластерных топологий, различные стратегии кворума, определение порядка старта и зависимостей между приложениями, параллельные приложения и т.д. У него нет программы лицензирования, соответственно, лицензии не нужно приобретать, одновременно с этим решение можно поставить на поддержку у ряда вендоров, например у Red Hat.
Основной целью проекта стала отработка и расширение состава предлагаемых нами продуктов и технологий кластеризации и построения High Availability Configuration, формирование более доступной альтернативы имеющимся решениям.
Перед собой мы поставили следующие задачи:
- провести стендирование типовых конфигураций, изучить функциональные возможности и ограничения решения, отработать конфигурации, получить навыки внедрения и настройки;
- определить возможность и перспективность дальнейшего продвижения решений в наших проектах.
Мы определили основные критерии успеха при тестировании конфигураций. Первый – конфигурации должны обеспечивать выполнение основных функций по гарантированию высокой доступности сервисов. Должна быть обеспечена защита от основных видов сбоев оборудования и ПО: отказа сервера (аппаратной части, ОС), сбоя подключения к дисковым ресурсам, сбоя подключения к LAN, сбоя прикладного сервиса. Проверка выполнения функций проводилась согласно ПМИ.
Второй критерий – тестируемый продукт должен быть выгоден с коммерческой точки зрения по сравнению с Veritas Cluster Server.
Третий – наличие дополнительных функциональных возможностей продукта, таких как удобный GUI, средства мониторинга и оповещения.
Мы подготовили тестовый стенд, общая схема которого представлена на рис. 1.
Рис. 1. Схема тестового стенда
![](https://habrastorage.org/files/b45/f25/2ce/b45f252ceda441848e49f56e067de7cb.png)
Для обеспечения целостности конфигурации каждый из узлов кластера имеет по 2 подключения в сети межкластерного взаимодействия. Кроме того, для повышения доступности узлов кластера каждый узел имеет дублированное подключение к public-сегменту сети, предназначенному для передачи данных приложений.
Кластерная конфигурация была построена для экземпляра СУБД Oracle 11g2. Для резервирования системы применялась схема 1+1. Она подразумевает использование однотипного оборудования и возможность переноса функционала одного из серверов в случае его отказа на резервный узел. Принципиальная схема решения приведена на рис. 2.
Рис. 2. Схема решения
![](https://habrastorage.org/files/473/f76/234/473f76234b3f4fb3abd53f27aa8e926d.png)
Распределение кластерных ресурсов между вычислительными узлами иллюстрирует рис. 3.
Рис. 3. Конфигурация распределения кластерных ресурсов между вычислительными узлами
![](https://habrastorage.org/files/2aa/e0c/8d6/2aae0c8d66ba4650be6aee9a21ad616c.png)
В группу oracle-grp входят следующие ресурсы:
- res-IP-public – IP-адрес из публичной сети (агент IPaddr2)
- res-ora_dg – ресурс управления дисковой подсистемой (агент LVM)
- res-ora_FS – ресурс управления файловой системой (агент Filesystem)
- res-oracle – экземпляр СУБД Oracle
- res-oralsnr – экземпляр Oracle Listener
Ресурсы вне группы:
- res-ping – ресурс проверки сетевого подключения (агент ping в конфигурации clone)
- scsi-shooter – fencing агент
В решении были выявлены некоторые ограничения. На момент тестирования поддерживаемыми версиями СУБД Oracle для создания отказоустойчивых конфигураций на базе ПО Pacemaker были Oracle Database 10g и 11g. Как уже говорилось выше, тестирование проведено с СУБД Oracle Database 11g2. СУБД Oracle Database 12c не поддерживается.
Подготовленное решение было подвергнуто полному циклу испытаний. Основные из них и результаты испытаний представлены в табл. 1.
Табл. 1. Цикл испытаний и их результаты
№ п/п |
Требования, подлежащие проверке |
Результат испытаний |
|
Методика проверки кластера на базе ПО Pacemaker |
|
1. | Проверка состава и конфигурации технических и программных средств |
Выполнено |
2. | Проверка резервирования сетевого подключения к Public Network |
Выполнено |
3. | Проверка резервирования SAN |
Выполнено |
4. | Проверка доступности СУБД |
Выполнено |
5. | Подключение к консоли управления кластером |
Выполнено |
6. | Проверка состояния ресурсов кластера |
Выполнено |
7. | Проверка состояния узлов кластера |
Выполнено |
8. | Проверка состава кластера |
Выполнено |
9. | Проверка состояния heartbeat |
Выполнено |
10. | Проверка состояния IO Fencing |
Выполнено |
11. | Проверка доступности сервисов (Kernel Panic основного узла кластера) |
Выполнено |
12. | Проверка доступности сервисов (отключение всех Ethernet-соединений основного узла кластера) |
Выполнено |
13. | Проверка доступности сервисов (отключение всех FC-соединений основного узла кластера) |
Выполнено |
14. | Проверка доступности сервисов (kill процесса, управляемого кластерным ПО) |
Выполнено |
15. | Проверка доступности сервисов (reset средствами ILO основного узла кластера) |
Выполнено |
16. | Проверка работы механизмов отказоустойчивости (отключение основного узла кластера от одной сети межкластерного взаимодействия) |
Выполнено |
17. | Проверка работы механизмов отказоустойчивости (отключение основного узла кластера от всех сетей межкластерного взаимодействия) |
Выполнено |
18. | Штатная миграция сервисов на резервный узел |
Выполнено |
Выводы
High Availability Configuration на базе ПО Pacemaker отвечает основным требованиям к отказоустойчивости и может являться альтернативой VCS в продуктивных применениях с учетом ряда следующих ограничений:
- резервирование Ethernet адаптеров (отработка ситуации сбоя физического соединения) необходимо обеспечивать сторонним ПО и применением в конфигурации дополнительного агента «ping», который настраивается на периодическую проверку доступности заданных целей в сети по IP-адресу;
- необходимо использовать последнюю версию кластерного ПО;
- поддержка решения со стороны вендора ограничена базовым составом ПО. Другие агенты пишутся силами Community или собственноручно. Поддержка на данные агенты со стороны вендора не распространяется.
Основные направления развития решения и планы вендора:
- улучшение документации;
- увеличение количества ресурсов в кластере до 100;
- развитие интеграции с контейнерами;
- развитие интеграции с RedHat 7.x.
- отказ от дальнейшего развития решения на базе cman & rgmanger
Возможность масштабирования конфигураций: согласно документации, возможно построение многоузлового кластера на базе Pacemaker (до 16 узлов).
Возможность создания DR-конфигураций: построение полноценных DR-решений на базе ПО Pacemaker невозможно. Поддерживаемым решением является конфигурация с «растянутым» кластером с репликацией средствами DRBD. Нативная интеграция с механизмами репликации от производителей СХД отсутствует.
Основными отличительными особенностями ПО Pacemaker являются:
- отсутствие программы лицензирования, т.е. стоимости лицензий;
- интеграция кластерного ПО с системными службами Linux;
- открытый исходный код.
При этом выявлен и ряд недостатков тестируемого решения:
- ограничение по количеству узлов в кластере – максимум 16;
- применение только на платформе Linux;
- малое число агентов;
- нефункциональный GUI;
- отсутствие функционала Disaster Recovery;
- малая гибкость в настройке;
- нестабильность работы в некоторых релизах ПО (ошибки программного обеспечения);
- отсутствие возможности управления несколькими кластерами с единой графической консоли управления;
- сложность в настройке и эксплуатации;
- отсутствие консолидированного набора документации.
Наш опыт работы с кластерными решениями показывает, что использование кластерного ПО Veritas Cluster Server более предпочтительно с точки зрения наличия экспертизы, надежности и стабильности работы системы, гибкости конфигурации и функциональных возможностей, а также вендорской поддержки. По этим показателем Pacemaker уступает Veritas.
Тем не менее, для случаев, когда цена является решающим фактором, применение ПО Pacemaker возможно с учетом описанных выше нюансов и ограничений.
Статья подготовлена Антоном Голощаповым, инженером-проектировщиком вычислительных комплексов компании «Инфосистемы Джет».
Комментарии (2)
vadimr
31.08.2016 18:43На мой взгляд, несколько некорректное сравнение. VCS — это программный продукт, а pacemaker — просто компонент для поддержки конфигурации кластера. Для адекватного функционального сравнения было бы логичнее сравнивать VCS с сопоставимым продуктом на базе pacemaker, например, со SLEHA.
celebrate
Ограничение на 16 нод обходится с помощью pacemaker-remote.