Кластер RedHat: некоторые аспекты и тонкости реализации и использования

Итак, для того, чтобы обеспечить бесперебойную работу важных сервисов (как минимум, в режиме 24х7), в нашей организации было решено провести ряд экспериментов с кластерным решением от RedHat (RedHat Cluster Suite).

Исходные условия:
в датацентре выделили два компьютера HP Proliant DL380
- CPU: 4 Intel Xeon 3Ghz
- RAM 4Gb
- 4 гигабитных сетевых карты (задействовано только две)
- OS: Enterprise Linux Server release 5.1 (Carthage), он же Oracle Unbreakable Linux 5.1
- внешний SAN storage для кластерных сервисов, подключение через 2хгигабитную карту emulex, fiber optic.
- кластерная FS была выбрана ocfs2 (GFS2 показала себя очень нестабильной)

На все это была установлена RedHat Cluster Suite из стандартного комплекта.

Самой первой проблемой оказался, как ни странно, недостаток документации. Официальная документация на сайте RedHat содержит только настройку кластера через GUI или web интерфейс (фи!). К счастью, на страничке разработчиков Cluster Suite нашлась кое-какая толковая документация, хотя со многими моментами пришлось разбираться "методом тыка" и собирать обрывки информации и советы в рассылках и форумах (гугль рулит!).

Самое главное, на что нужно обратить с самомго начала внимание - демон fenced. Дело в том, что сугубо из идеологических соображений разработчики не поддерживают программную "отсечку" отпавшей ноды кластера. Точнее, чуть-чуть там инструментов есть (fence_manual + fence_ask_manual), но это нельзя использовать, разве что "на поиграться", потому что проблем исключительно ручная отсечка создает множество. Fenсed работает только с аппаратной частью. Список поддерживаемого оборудования не очень велик, зато само оборудование - не очень-то и дешево. Поэтому большинству небольших фирм на территории СНГ, которые мечтают о дешевом решении с высокой надежностью и балансингом, кластер от RedHat в кустарных и полукустарных условиях увы, не собрать.

К счастью, меня эта проблема не коснулась. Кроме того, в серверах от HP обычно устанавливается iLO карточка (integrated LightOut), с помощью которой можно управлять питанием сервера и работать на серверной консоли.

Кластер собирался в режиме "повышенная надежность", когда сервисы работают на одной ноде и мигрируют на другую в аварийной ситуации. Для экономных и бережливых :) можно использовать это решение в несколько расширенном варианте: когда часть сервисов работает на одной ноде, вторая часть - на другой, распределяя таким образом нагрузку. В случае отказа одной ноды, сервисы, находящиеся на ней, смигрируют.

Собранный и запущенный кластер тестировался по простой схеме:

• Штатное выключение активной ноды. Сервисы должны смигрировать на пассивную ноду. Оценить время миграции.


• Штатное выключение пассивной ноды. Никаких изменений в работе сервисов быть не должно


• Аварийное выключение активной ноды (по питанию). Сервисы должны смигрировать на пассивную ноду. Оценить время миграции.


• Аварийное выключение пассивной ноды (по питанию). Никаких изменений в работе сервисов быть не должно


• Поочередное отключение сетевых интерфейсов на активной ноде


• Поочередное отключение сетевых интерфейсов на пассивной ноде


• Последовательное отключение сетевых интерфейсов на активной ноде (вплоть до отключения всех)


• Последовательное отключение сетевых интерфейсов на пассивной ноде (вплоть до отключения всех)


• Отключение emulex контроллера на активной ноде (имитация отказа доступа к SAN storage)


• Отключение emulex контроллера на пассивной ноде (имитация отказа доступа к SAN storage)


• принудительная остановка запущенного процесса, входящего в сервис (kill -9 ), с целью проверки и ситуации с багами в программах и неожиданным падением в core.

Продолжение следует...