вівторок, 2 вересня 2008 р.

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



Часть 5

В процессе эксплуатации кластера выяснились неприятные особенности.


Итак, приблизительная конфигурация:
2 ноды, общий SAN storage, отсечка проводится через HP iLO карту.
Ноды запитаны независимо, с разных источников, находятся физически в разных стойках.


Случилось следующее. В результате сбоя питания в датацентре одна стойка была полностью обесточена (такое редко, но бывает).




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


Хочу заметить, что при этом был настроен и запущен qdiskd (quorum disk, кворум диск) на отдельном SAN разделе. ПО непонятным мне причинам, резервная нода не сочла достаточным, что кворум диск показал отказ основной ноды, и ,в результате, кластер не справился с одной из своих штатных основных задач - не обеспечил надежность и беcперебойность. :(


Было проведено несколько экспериментов с ручным отключением ноды - результат воспроизводился в точности.


По моему мнению, такая работа кластера недопустима. Возможно, если обеспечить отсечку через дополнительное устройство (например, свич, через который ноды подключаются к SAN storage), запитав его независимым питанием, такого можно избежать. Но в моем случае такойвариант оказался неприемлем.

Вывод - пока RedHat cluster, как это ни печально, для моих задач не подходит, т.к. в первую очередь меня интересует высокая надежность и отказоустойчивость кластера.


В качестве альтернативы было решено провести эксперименты с heartbeat HA-cluster.

6 коментарів:

  1. A если заставить fenced возвращать сообщение о успешном отсечении ноды даже если нет достоверной информации (просто в коде прописать всегда сообщать о успешном отсечении) ?

    ВідповістиВидалити
  2. Тогда есть реальный шанс словить "split brain" на двухнодовом кластере. Это когда каждая нода считает себя единственной уцелевшей от кластера.
    Ну и целостность данных на общем сторадже под бо-о-ольшим вопросом!

    ВідповістиВидалити
  3. Тогда можно написать свой скрипт - проверяющий различные параметры и уж точно гасящий ноду. http://sources.redhat.com/cluster/wiki/EventScripting

    ВідповістиВидалити
  4. Ну, можно вообще свой кластер написать :)
    Я рассчитывал, что RH, как один из лидеров рынка linux-решений, сделает достаточно качественное решение...

    ВідповістиВидалити
  5. Столкнульсь с такой-же проблемой ILO. Радость в том , что RHEL стоит на поддержке HP . Подняли проблему в HP , так что есть шанс её побороть . Если интересно , потом отпишусь.

    ВідповістиВидалити
  6. Это на самом деле проблема кластера RH вообще и fenced в частности :(

    Возможно, предложат альтернативу или патченый fenced ? Если так, было бы довольно интересно увидеть результаты

    ВідповістиВидалити