Кластер высокой доступности на Red Hat Cluster Suite

В поисках решения для построения HA кластера на linux, я наткнулся на довольно интересный продукт, который, по моим наблюдениям, несправедливо обделен вниманием уважаемого сообщества. Судя по русскоязычным статьям, при необходимости организации отказоустойчивости на уровне сервисов, более популярно использование heartbeat и pacemaker. Ни первое, ни второе решение у нас в компании не прижилось, уж не знаю почему. Может сыграла роль сложность конфигурации и использования, низкая стабильность, отсутствие подробной и обновляемой документации, поддержки.

После очередного обновления centos, мы обнаружили, что разработчик pacemaker перестал поддерживать репозиторий для данной ОС, а в официальных репозиториях была сборка, подразумевающая совершенно другую конфигурацию (cman вместо corosync). Переконфигурировать pacemaker желания уже не было, и мы стали искать другое решение. На каком-то из англоязычных форумов, я прочел про Red Hat Cluster Suite, мы решили его попробовать.

Общая информация


RHCS состоит из нескольких основных компонентов:
  • cman — отвечает за кластеризацию, взаимодействие между нодами, кворум. По сути, он и собирает кластер.
  • rgmanager — менеджер ресурсов кластера, занимается добавлением, мониторингом, управлением групп ресурсов кластера.
  • ricci — демон для удаленного управления кластером
  • luci — красивый веб интерфейс, который подключается к ricci на всех нодах и предоставляет централизованное управление через веб-интерфейс.


Как и в heartbeat и pacemaker, ресурсы кластера управляются стандартизированными скриптами (resource agents, RA). Кардинальное отличие от pacemaker состоит в том, что redhat не подразумевает добавления пользовательских кастомных RA в систему. Но это с лихвой компенсируется тем, что есть универсальный resource agent для добавления обычных init скриптов, он называется script.

Управление ресурсами идет только на уровне групп сервисов. Сам по себе ресурс невозможно включить или выключить. Для распределения ресурсов по нодам и приоритезации запуска на определенных нодах используются failover domains, домен представляет собой правила запуска групп ресурсов на определенных нодах, приоритезацию и failback. Одну группу ресурсов можно привязать к одному домену.


Гайд по настройке:

Данная инструкция тестировалась на centos 6.3 — 6.4.
  1. Весь набор пакетов, которые будут необходимы для полноценной работы одной ноды удобно объединен в группу «High Availability» в репозитории. Ставим их, используя yum, отдельно ставим luci. На момент написания статьи, luci надо ставить из base репозитория, если устанавливать со включенным epel, ставится некорректная версия python-webob и luci стартует неправильно.
    yum groupinstall "High Availability"
    yum install --disablerepo=epel* luci
    

  2. Чтобы первоначально запустить первую ноду, нужно прописать конфиг cluster.conf (в centos по умолчанию /etc/cluster/cluster.conf). Для первоначального запуска нам хватит такой конфигурации:
    <?xml version="1.0"?>
    <cluster config_version="1" name="cl1">
      <clusternodes>
        <clusternode name="node1" nodeid="1"/>
      </clusternodes>
    </cluster>
    

    Где node1 это FQDN ноды, по которому другие ноды будут с ней общаться.
    Это единственный конфиг, который я правил из консоли при настройке этой системы.
  3. Устанавливаем пароль для пользователя ricci. Этот пользователь создается при установке пакета ricci, и будет использоваться для подключения нод в веб-интерфейсе luci.
    passwd ricci
    

  4. Запускаем сервисы:
    service cman start
    service rgmanager start
    service modclusterd start
    service ricci start
    service luci start
    

    Тут надо заметить, что luci лучше ставить на отдельный сервер, не задейстованный в кластере, чтобы при недоступности ноды, luci была доступна.

    Также, удобно сразу включить сервисы в автозагрузку:
    chkconfig ricci on
    chkconfig cman on
    chkconfig rgmanager on
    chkconfig modclusterd on
    chkconfig luci on
    

  5. Теперь можно зайти в веб-интерфейс luci, который при правильном старте сервиса поднимается по https на порту 8084. Залогиниться можно под пользователем root.
    Видим довольно красивый веб-интерфейс:

    В котором добавляем наш кластер из одной ноды, нажав Manage clusters -> Add, указываем имя ноды, пароль пользователя ricci и нажимаем Add cluster. Осталось только добавить ноды.
  6. Чтобы добавить сервер как ноду, на нем должна быть установлена группа пакетов «High Availability» и запущен ricci. Ноды добавляются в управлении кластером на вкладке Nodes, указывается имя сервера и пароль пользователя ricci на нем. После добавления ноды, ricci синхронизирует на нее cluster.conf, после чего запускает на ней все нужные сервисы.


Если будет интерес, в следующей статье могу написать про использование shared storage и fencing в данной системе.

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

    +3
    Если будет интерес, в следующей статье могу написать про использование shared storage и fencing в данной системе.

    Однозначно будет интересно!
      0
      +1 особенно про fencing
        0
        Тоже хотел бы почитать про fencing, смотрел по диагонали доку и написанное заставило ужаснуться. Возможно в жизни всё не так страшно?
      0
      Когда я смотрел эту тему в RedHat 5, там все было довольно убого. Piranha на основе heartbeat с кривоватой вебмордой. В 6-ке афаир уже и сам pacemaker появился.
      • НЛО прилетело и опубликовало эту надпись здесь
        0
        Что-то не получается залогиниться с юзером root, luci, admin.
          0
          Ложная тревога. С другого браузера норм залогинился))
          +1
          Разве у pacemaker низкая стабильность? На мой взгляд стабильно работает. Может просто пакеты в CentOS плохо поддерживаются?
            0
            Можно пару примеров из жизни, для чего такой кластер нужен и что он умеет делать?
              +1
              Если позволите, отвечу.
              Ну например, У вас есть сервер 1 (IP 10.0.0.10) и сервер 2 (IP 10.0.0.20) и есть некий сервис (например апач), вам надо сделать, что бы к вашему апачу снаружи могли подключаться люди, например на IP 10.0.0.50. Создаете сервис, в котором прописываете путь к init.d скрипту апача, говорите кластеру, что надо поднимать этот сервис на вирт IP, в нашем случае это 10.0.0.50 и всё, сервис при падении на одной ноде, будет рестартовать на этой ноде или переезжать на другую ноду, причем с вирт IP. Между какими нодами будет кататься сервис прописывается в Failover Domain, там же выставляются приоритеты, ну например какая нода основная (приоритет 1), какая резервная (приоритет 2) и т.д. (приоритет 3 и .....)

              Это самое простое, что можно сделать в RHCS.

              Прим.: никогда,!!! НИКОГДА!!! не используйте имена нод кластера более 15 символов. Кластер будет вести себя очень непредсказуемо (это по опыту)
              0
              После очередного обновления centos, мы обнаружили, что разработчик pacemaker перестал поддерживать репозиторий для данной ОС, а в официальных репозиториях была сборка, подразумевающая совершенно другую конфигурацию (cman вместо corosync).

              В шестой версии никто ничего не выпиливал. RedHat сами активно смотрят на pacemaker + corosync и пилят эту сборку в Fedora, но пилят для нового corosync 2.x (в rhel/centos 6 только 1.x).
              После крайнего обновления pacemaker в шестой ветке от туда выкинули crm шелл (в пользу нового pcs, который же сами и пилят). И добавили варнингов что мол связка pacemaker + corosync 1.х (pacemaker как плагин к corosync) уже устарела и скоро будет удалена — пользуйтесь плагином для cman. Таким образом достаточно установить только cman, corosync, pacemaker и оно снова заработает, даже конфиги pacemaker'a не нужно править — сам подтянет старые конфигурации. Что поменяется — corosync будет подниматься как «плагин» cman (и pacemaker тоже) и конфигурить corosync теперь нужно в настройках cman. Ну и crmsh нужно будет установить от куда-то, если не охота pacemaker через xml настраивать :)
                0
                Я на своем кластере Rocks Cluster Linux (на основе CentOS) поставил, скоро тоже по ней обзор напишу. Что понравилось, InfiniBand заработал из коробки :)

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

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