Часть 5
В процессе эксплуатации кластера выяснились неприятные особенности.
Итак, приблизительная конфигурация:
2 ноды, общий SAN storage, отсечка проводится через HP iLO карту.
Ноды запитаны независимо, с разных источников, находятся физически в разных стойках.
Случилось следующее. В результате сбоя питания в датацентре одна стойка была полностью обесточена (такое редко, но бывает).
В результате того, что пропало питание, iLO карта стала недоступна. Кластерное ПО в этой ситуации среагировало не совсем адекватно - "живая" нода попыталась провести отсечку, ей, естественно, это не удалось (другая нода недоступна никоим образом). В результате нода, на которую должны были смигрировать сервисы, "зациклилась" на попытках отсечки, сервисы, разумеется, не смигрировали.
Хочу заметить, что при этом был настроен и запущен qdiskd (quorum disk, кворум диск) на отдельном SAN разделе. ПО непонятным мне причинам, резервная нода не сочла достаточным, что кворум диск показал отказ основной ноды, и ,в результате, кластер не справился с одной из своих штатных основных задач - не обеспечил надежность и беcперебойность. :(
Было проведено несколько экспериментов с ручным отключением ноды - результат воспроизводился в точности.
По моему мнению, такая работа кластера недопустима. Возможно, если обеспечить отсечку через дополнительное устройство (например, свич, через который ноды подключаются к SAN storage), запитав его независимым питанием, такого можно избежать. Но в моем случае такойвариант оказался неприемлем.
Вывод - пока RedHat cluster, как это ни печально, для моих задач не подходит, т.к. в первую очередь меня интересует высокая надежность и отказоустойчивость кластера.
В качестве альтернативы было решено провести эксперименты с heartbeat HA-cluster.
A если заставить fenced возвращать сообщение о успешном отсечении ноды даже если нет достоверной информации (просто в коде прописать всегда сообщать о успешном отсечении) ?
ВідповістиВидалитиТогда есть реальный шанс словить "split brain" на двухнодовом кластере. Это когда каждая нода считает себя единственной уцелевшей от кластера.
ВідповістиВидалитиНу и целостность данных на общем сторадже под бо-о-ольшим вопросом!
Тогда можно написать свой скрипт - проверяющий различные параметры и уж точно гасящий ноду. http://sources.redhat.com/cluster/wiki/EventScripting
ВідповістиВидалитиНу, можно вообще свой кластер написать :)
ВідповістиВидалитиЯ рассчитывал, что RH, как один из лидеров рынка linux-решений, сделает достаточно качественное решение...
Столкнульсь с такой-же проблемой ILO. Радость в том , что RHEL стоит на поддержке HP . Подняли проблему в HP , так что есть шанс её побороть . Если интересно , потом отпишусь.
ВідповістиВидалитиЭто на самом деле проблема кластера RH вообще и fenced в частности :(
ВідповістиВидалитиВозможно, предложат альтернативу или патченый fenced ? Если так, было бы довольно интересно увидеть результаты