Альтернативные технологии обеспечения высокой доступности приложений

    При построении High Availability Configuration на базе оборудования RISC-платформ мы выбираем из весьма ограниченного набора кластерного ПО. В первую очередь это вендорские разработки – Oracle Solaris Cluster, PowerHA (IBM), Serviceguard (HP), а также Veritas Cluster Server. Последнее решение по факту является основным предлагаемым на данный момент вариантом построения кластерных конфигураций, причем для разных платформ – Oracle, IBM и т.д.

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

    Pacemaker является opensource-продуктом, который входит в состав многих дистрибутивов Linux. Продукт поддерживает широкий набор кластерных топологий, различные стратегии кворума, определение порядка старта и зависимостей между приложениями, параллельные приложения и т.д. У него нет программы лицензирования, соответственно, лицензии не нужно приобретать, одновременно с этим решение можно поставить на поддержку у ряда вендоров, например у Red Hat.

    Основной целью проекта стала отработка и расширение состава предлагаемых нами продуктов и технологий кластеризации и построения High Availability Configuration, формирование более доступной альтернативы имеющимся решениям.

    Перед собой мы поставили следующие задачи:

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

    Мы определили основные критерии успеха при тестировании конфигураций. Первый – конфигурации должны обеспечивать выполнение основных функций по гарантированию высокой доступности сервисов. Должна быть обеспечена защита от основных видов сбоев оборудования и ПО: отказа сервера (аппаратной части, ОС), сбоя подключения к дисковым ресурсам, сбоя подключения к LAN, сбоя прикладного сервиса. Проверка выполнения функций проводилась согласно ПМИ.

    Второй критерий – тестируемый продукт должен быть выгоден с коммерческой точки зрения по сравнению с Veritas Cluster Server.

    Третий – наличие дополнительных функциональных возможностей продукта, таких как удобный GUI, средства мониторинга и оповещения.

    Мы подготовили тестовый стенд, общая схема которого представлена на рис. 1.

    Рис. 1. Схема тестового стенда



    Для обеспечения целостности конфигурации каждый из узлов кластера имеет по 2 подключения в сети межкластерного взаимодействия. Кроме того, для повышения доступности узлов кластера каждый узел имеет дублированное подключение к public-сегменту сети, предназначенному для передачи данных приложений.

    Кластерная конфигурация была построена для экземпляра СУБД Oracle 11g2. Для резервирования системы применялась схема 1+1. Она подразумевает использование однотипного оборудования и возможность переноса функционала одного из серверов в случае его отказа на резервный узел. Принципиальная схема решения приведена на рис. 2.

    Рис. 2. Схема решения


    Распределение кластерных ресурсов между вычислительными узлами иллюстрирует рис. 3.

    Рис. 3. Конфигурация распределения кластерных ресурсов между вычислительными узлами



    В группу 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 возможно с учетом описанных выше нюансов и ограничений.

    Статья подготовлена Антоном Голощаповым, инженером-проектировщиком вычислительных комплексов компании «Инфосистемы Джет».
    Инфосистемы Джет
    499,00
    Системный интегратор
    Поделиться публикацией

    Комментарии 2

      0
      Ограничение на 16 нод обходится с помощью pacemaker-remote.
        0
        На мой взгляд, несколько некорректное сравнение. VCS — это программный продукт, а pacemaker — просто компонент для поддержки конфигурации кластера. Для адекватного функционального сравнения было бы логичнее сравнивать VCS с сопоставимым продуктом на базе pacemaker, например, со SLEHA.

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

        Самое читаемое