Комментарии 12
Если будет интерес, в следующей статье могу написать про использование shared storage и fencing в данной системе.
Однозначно будет интересно!
Когда я смотрел эту тему в RedHat 5, там все было довольно убого. Piranha на основе heartbeat с кривоватой вебмордой. В 6-ке афаир уже и сам pacemaker появился.
Что-то не получается залогиниться с юзером root, luci, admin.
Разве у pacemaker низкая стабильность? На мой взгляд стабильно работает. Может просто пакеты в CentOS плохо поддерживаются?
Можно пару примеров из жизни, для чего такой кластер нужен и что он умеет делать?
Если позволите, отвечу.
Ну например, У вас есть сервер 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 символов. Кластер будет вести себя очень непредсказуемо (это по опыту)
Ну например, У вас есть сервер 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 символов. Кластер будет вести себя очень непредсказуемо (это по опыту)
После очередного обновления 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 настраивать :)
Я на своем кластере Rocks Cluster Linux (на основе CentOS) поставил, скоро тоже по ней обзор напишу. Что понравилось, InfiniBand заработал из коробки :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кластер высокой доступности на Red Hat Cluster Suite