пятница, 7 мая 2010 г.

Отказоустойчивость и балансировка нагрузки в кластере

Вот уже с неделю размышляю над дальнейшей стратегией построения веб-систем. А также, как водится, перелопачиваю документацию. Наконец-то нашлось время сформулировать многое из того, о чем раньше некогда было всерьез подумать. В том числе, нашел проект и одноименный деб-пакет keepalived. Почему именно этот проект, хотя есть намного более известные аналоги (heartbeat)? Все просто - именно keepalived рекомендует автор HAProxy, предлагая в документации варианты совместного использования и примеры конфигурации. Сам я давно и успешно использую HAProxy и с его автором общался, неизменно получая точные и ясные ответы на вопросы продакшен конфигурации и защиты от сбоев и атак различных видов. Это была первая причина. А вторая - на мой взгляд, конфигурационные параметры heartbeat придуманы точно не гуманоидами, вот пусть эти головоногие (в лучшем случае) ими и пользуются. Третья причина - костыли в heartbeat для предотвращения одновременного использования разделяемых дисков несколькими узлами - при пропадании связи между узлами данные на таких дисках все равно будут повреждены (каждый узел будет считать себя мастером и работать с дисками), так стоило ли городить огород, когда вместо реализации балансировки между узлами система вынуждает узлы простаивать, да еще есть ощутимая вероятность потери данных на разделяемых дисках! Такой подход разработчиков дискредитирует всю систему - лучше бы сразу сказали, что их решение не может гарантировать монопольный доступ к разделяемым дискам.

Вкратце, keepalived реализует протокол VRRP (Virtual Router Redundancy Protocol) для создания виртуального linux-маршрутизатора на основе LVS. Описание LVS - Linux Virtual Server можно посмотреть на одноименном сайте. Вот краткое введение в системы высокой доступности на этом же сайте: High Availability И там же смотрим примеры конфигурация для Keepalived и heartbeat и пары других систем.

Погуглим, что еще пишут про практическое использование:

Статья целиком или почти целиком цитирует документацию HAProxy, но все же: Setting Up A High-Availability Load Balancer (With Failover and Session Support) With HAProxy/Keepalived On Debian Etch

А вот и пошаговая инструкция с небольшим теоретическим экскурсом в предмет: Improving Network Reliability with Keepalived

И, как было упомянуто выше, примеры реализации отказоустойчивого кластера на основе HAProxy + keepalived можно найти в документации HAProxy.

10 комментариев:

Евгений комментирует...

проблема с haproxy! Проект написаный на php при смене сервера балансировщиком обнуляет php сессию. Как с этим бороться?

Стоит 2 физических сервера OS Debian 6 + Apache2 + PHP5

Печников Алексей комментирует...

Например, хранить сессии в общем memcached-сервере. Если вы храните сессии на узлах кластера раздельно, откуда один узел может знать о сессиях с другого узла?..

995533 комментирует...

Я до этого пробовал memcache с плагином репликации тоже не получалось, в итоге поставил параллельную файловую систему GlusterFS и это тоже не помогло.

Проблема решилась гораздо проще, а именно установкой php5-suhosin и все стало так как должно было быть!

Сейчас еще вопрос умеет ли haproxy разруливать виртуальные хосты?

то есть есть сайт site.ru при обращении на него балансер использует одну ферму а при запросе sub.site.ru другую ферму. В PerlBal это реализовано а вот в haproxy не смог найти! есть ли такое? и если есть можно пример или где посмотреть.
Спасибо.

995533 комментирует...

Спасибо! С виртуальными хостами тоже разобрался)!

Печников Алексей комментирует...

А кроме виртуальных хостов, еще можно как угодно обрабатывать запрос и ответ. Например, удалить информацию о сервере для всех хостов одной строчкой конфигурации в HAProxy, вместо того, чтобы настраивать все веб-сервера. Можно делать балансировку с помощью javascript, к примеру, вот как здесь:
https://offline.mts.mobigroup.ru/
Для такой балансировки добавляем в конфиг HAProxy секцию, переадресующую запросы с определенным URI к соответствующему хосту, а как только запрос приходит на указанный хост, HAProxy ставит ему сеансовую куку и дальше сессия обрабатывается именно этим хостом.

995533 комментирует...

Круто! Совсем недавно столкнулся с балансировкой возможностей много, особенно для бизнес решений!

Созрел новый вопрос!) Тестирую на стенде проект. Постоянно возникает следующее, если не обращаться с к странице какое то время, а потом обратиться, то выдается чистая страница со статусом "готово"... После кнопки F5 загружается норм!

Печников Алексей комментирует...

По такому описанию предположить можно все, что угодно :-) Потому просто скажу так - у меня в проекте с миллионами запросов в сутки и сотнями гиг траффика в месяц ничего подобного не наблюдается, HAProxy работает великолепно (проект поддерживает дилерскую сеть компании МТС примерно на трети территории России).

А по вашим симптомам похоже на ошибку создания страницы на бэкенде, проблему с интернет соединением или ошибку браузера - примерно в таком вот порядке.

995533 комментирует...

С пустой страницей проблема решилась, заменил heartbeat на keepalived! Стало намного лучше!
Спасибо за ответы.

Сейчас предстоит связать haproxy с tomcat6 на двух серверах с репликацией.. нет опыта? )
Точнее haproxy с tomcat уже связал, но репликацию немогу заставить работать

Печников Алексей комментирует...

Что реплицируете? Когда-то давно tomcat я в тестовых целях поставил, поизучал и выбросил нафиг :-) Может кому и по вкусу, но имхо томкат (да и ява как таковая, впрочем) в unix way не вписывается совсем.

995533 комментирует...

Уже поставил все! Все работает!
Томкат нужен для серлветов в проекте есть клиент сервер, клиент сделан на яве с целью кросплатформы.


(C) Alexey Pechnikov aka MBG, mobigroup.ru