LINUX.ORG.RU
ФорумAdmin

Оценка схемы HA-кластера


2

3

Всем доброе утро!

В наличии сервер с Dual Xeon, на нем вертится панель управления услугами (ПУ) и MySQL для этих услуг. В настоящее время сервер забит под завязку. Т.к. сама ПУ и MySQL являются достаточно критичными (от их доступности зависит работа связанных услуг на других машинах), то решил масштабировать не добавлением новых серверов, а созданием кластера из двух.

Особенности тут такие:
1) Связанные услуги имеют постоянное подключение к MySQL (такова специфика приложения);
2) Все услуги с указанной машиной в локальной сети, обращаются к ней по имени хоста.

Планируется, что кластер будет защищать от:
1) Аппаратного или программного отказа одной из машин;
2) Недоступности одной из машин с внешних сетей.

Сам кластер планируется реализовывать следующим образом:
- На оба сервера ставим одинаковый набор по: apache c ПУ, mysql-proxy, mysql.
- Настраиваем master-master репликацию mysql.
- Настраиваем mysql-proxy на статическое распределение запросов между серверами по базам (чтобы разделить нагрузку ~50/50, и не писать в одну базу одновременно), на каждом сервере.

По задумке, если мониторинг фиксирует проблемы, то просто меняется IP-адрес хоста на DNS-сервере на вторую машину, а она уже готова принять все запросы, т.к. благодаря master-master данные актуальны (ну, почти) и, дальше, в зависимости от ситуации:
1) В случае проблем аппаратных, mysql-proxy это зафиксирует и перестанет отправлять запросы на проблемную машину, обрабатывая все локально;
2) В случае недоступности IP с внешних сетей, mysql-proxy будет иметь связь с проблемной машиной локально, и будет её использовать как обычно.

Просьба тех, кто имеет опыт, оценить чудо-схему и дать комментарии. Я понимаю прекрасно, что в случае аварий вторая машина будет загружена под полку, это в данном случае не имеет значения (решим другим способом). Отдельно следующее:
1) Я слышал, что mysql-proxy дает больше геморроя, чем пользы, так ли это?
2) Какой TTL стоит использовать на DNS сервере для этой записи? Если слишком маленький, боюсь это убьет всю производительность на ожидание ответа от DNS-серверов.
«В случае недоступности IP с внешних сетей» - это значит, что ЦОД просто отправит их в блекхолл, бывает такое.
3) Как посоветуете определять внешнюю доступность IP-адреса? Не хотелось бы ставить внешние точки мониторинга, если там будут проблемы со связью до ЦОД-а, то пойдут свистопляски ...
4) Вообще кто-то такое использует, или я фигню написал?

Спасибо.

UDP: Естественно, схема с переключением IP на DNS выбрана не случайно. Возможны реальные отключения IP-адресов ЦОД'ом, никакие virtual ip в ЦОД'е не реализованы и их реализация в данной ситуации невозможна, когда ЦОД специально блокирует IP - инфраструктура должна на это реагировать и подстраиваться. Использовать сторонние услуги невозможно из-за высоких требований к низким задержкам.



Последнее исправление: Amoled (всего исправлений: 6)
Ответ на: комментарий от Amoled

Там попросту одна нода указана как backup. Если основная упала (что видно через мониторинг - вместо 200 начинает отдавать 503) - то все запросы перекидываются на вторую.

svr4
()
Ответ на: комментарий от kukara4

Статью с хабра читал. С рассинхронизацией понятно, потому и удивляюсь. У них видимо не Active/Active, а постоянный Active/Passive без распределения нагрузки между нодами, а haproxy вместо плавающего IP, если я все верно понял ...

Amoled
() автор топика
Ответ на: комментарий от Yur4eg

Самого mysql. https://dev.mysql.com/doc/refman/5.0/en/ha-drbd.html

Но ты видимо лучше за их разработчиков знаешь как их продукт работает. Поделись опытом, расскажи почему это неправильно

kukara4 ★★
()
Последнее исправление: kukara4 (всего исправлений: 1)
Ответ на: комментарий от kukara4

Поделись опытом, расскажи почему это неправильно

Присоединяюсь. Yur4eg почему?

petav ★★★★★
()
Ответ на: комментарий от kukara4

Самого mysql. https://dev.mysql.com/doc/refman/5.0/en/ha-drbd.html

Но ты видимо лучше за их разработчиков знаешь как их продукт работает. Поделись опытом, расскажи почему это неправильно

Падение производительности это первое. drbd тормозит и сам по себе это не секрет, но еще хуже, что надо синхронизировать с жестким диском каждую операцию изменяющую БД иначе неконсистентные данные на резервной ноде.

Появляется еще лишняя сущность-прокладка ввиде файловой системы на drbd, которая тоже реплицирует свои метаданные, в случае резкого выключения ведущей ноды кластера, файлик с таблицей БД может быть помечен как сбойный и вместо продолжения работы в штатном режиме запускаем fsck

Ну и самое страшное это автоматический выход из split-brain в такой схеме это гарантированная попаболь. drdb ничего не знает про структуры БД, она же работает на блочном уровне. Можно потерять все данные или часть.

Yur4eg ★★
()
Ответ на: комментарий от Yur4eg

Падение производительности это первое.

К гадалке не ходи. Закладывайте overhead.

drbd тормозит и сам по себе это не секрет, но еще хуже, что надо синхронизировать с жестким диском каждую операцию изменяющую БД иначе неконсистентные данные на резервной ноде.

см. первое

Появляется еще лишняя сущность-прокладка ввиде файловой системы на drbd, которая тоже реплицирует свои метаданные, в случае резкого выключения ведущей ноды кластера, файлик с таблицей БД может быть помечен как сбойный и вместо продолжения работы в штатном режиме запускаем fsck

Вы про метаданные наверное

Ну и самое страшное это автоматический выход из split-brain в такой схеме это гарантированная попаболь. drdb ничего не знает про структуры БД, она же работает на блочном уровне. Можно потерять все данные или часть.

Единственное с чем соглашусь, что если эксплуатрируешь DRBD то знать надо что это, его логику и особенности.

petav ★★★★★
()
Ответ на: комментарий от Amoled

Дык какбе все запросы идут на одну ноду. Для кворума ещё болтается арбитр на третьей тачке. Или ты про что?

svr4
()
Ответ на: комментарий от svr4

Да забыл что у вас там только база в кластере. И не боитесь, что сервер с haproxy откажет и все ляжет вместе с ним? И почему не стали использовать master-master (active/passive) с балансировкой по базам?

Amoled
() автор топика
Ответ на: комментарий от Amoled

haproxy под коросинком (вместе с айпишником прыгает с тачки на тачку по мере надобности). Смысла большого в разгоне нагрузки нет, а вот availability сильно важно.

svr4
()
Последнее исправление: svr4 (всего исправлений: 1)
Ответ на: комментарий от svr4

Ммм, интересно. А зачем вообще тогда нужен haproxy, если corosync и так перемещает IP. Почему сразу не перемещать их между нодами с mysql?

Amoled
() автор топика
Ответ на: комментарий от Amoled

Смысл в мониторинге нод на предмет успели ли они синхронизироватся. Ну и попутно в том что под самим коросинком mysql работает не очень. Во всяком случае, такое решение было и от него отказались.

svr4
()
Последнее исправление: svr4 (всего исправлений: 1)
Ответ на: комментарий от Amoled

clustercheck/pyclustercheck. Уже писал выше, что оба костыля входят в поставку pxc. Хотя в принципе первый элементарен, его можно и на баше написать самому.

svr4
()

Настраиваем mysql-proxy на статическое распределение запросов между серверами по базам (чтобы разделить нагрузку ~50/50, и не писать в одну базу одновременно)

Если это master-master, оно всегда будет писаться в обе базы одновременно. Нельзя сделать систему из двух машин с пишущей данные БД, одновременно и отказоустойчивую, и с разделением нагрузки.

если мониторинг фиксирует проблемы, то просто меняется IP-адрес хоста на DNS-сервере
Возможны реальные отключения IP-адресов ЦОД'ом

По-человечески это делается с помощью VRRP/CARP. Вариант с DNS - извращение. Лучше разберитесь с ЦОД, что такое «отключения IP-адресов ЦОД'ом»? Меняйте ЦОД

selivan ★★★
()
Ответ на: комментарий от selivan

Если это master-master, оно всегда будет писаться в обе базы одновременно.

И даже если это мастер-слэйв - тоже.

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

NiTr0 ★★★★★
()
Ответ на: комментарий от NiTr0

Кстати да, именно мастер-мастер нужен только если оба сервера должны писать данные, или если простой даже в доли секунды неприемлем, а переход слейв -> мастер слишком долгий(за мускуль не скажу, постгрес настраивал).

selivan ★★★
()
Ответ на: комментарий от selivan

Мускуль довольно легко переходит. В любом случае, при полусинхронной репликации лаг будет при отпадании слэйва. Да и pacemaker не мгновенно слэйва в мастер переводит...

NiTr0 ★★★★★
()
Ответ на: комментарий от Amoled

arp кеш в ЦОД'е от этого моментально не обновится, понадобится время для этого, достаточно большое.

Gratuitous ARP спасёт отца русской демократии

zolden ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.