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 - инфраструктура должна на это реагировать и подстраиваться. Использовать сторонние услуги невозможно из-за высоких требований к низким задержкам.

а mariadb + galera — не?

anonymous ()

Слишком сложная система, плохо будет работать я думаю. Лучше сделать master-slave кластер на Pacemaker, где второй сервер будет на себя реплицировать данные (либо mysql репликация, либо вообще drbd) и оживать когда основной помрёт.

Увеличения производительности не будет, но надежность самое то. Можно подумать над перекрёстной репликацией, чтобы второй сервер не простаивал.

blind_oracle ★★★★★ ()

По задумке, если мониторинг фиксирует проблемы, то просто меняется IP-адрес хоста на DNS-сервере

Это бред. Тебе нужен virtual ip. Адрес сервиса, в общем.

Настраиваем master-master репликацию mysql.

Забудь сразу, мускул еще та кака. И забудь про mysql-proxy.

4) Вообще кто-то такое использует, или я фигню написал?

Извини, но фигню.

P.S Сначала напиши какие приложения будут крутится, фреймворки, вордпресы или что? Возможно ли в приложениях на логическом уровне отделить запросы SELECT от INSERT/UPDATE ?

kukara4 ()
Последнее исправление: kukara4 (всего исправлений: 3)

Тебе подойдет вот такая архитектура:

http://yadi.sk/d/QTpt21h_LmzWD

Не был бы я ораклистом если бы не предложил Oracle Linux:)

Добавлю что, в сервисы навесить еще http, и сделать интерконнекты между серверами.

Будет интересно - добавляйся.

P.S У мускула есть только 1 более-менее номральный вариант кластера - NDB. Но там есть много условий. Галеры, шмалеры - все хрень. Плавали, знаем.

kukara4 ()
Последнее исправление: kukara4 (всего исправлений: 1)

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

делаешь кластер типа мастер-слейв с lvm поверх drbd, на lvm разворачиваешь виртуалку(виртуалки) kvm с мускулом и nginx(для панель управления услугами (ПУ)), для надежности под drbd можно подложить raid10, в качестве переключалки между нодами heartbeat

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

kvm с мускулом и nginx
lvm поверх drbd, на lvm разворачиваешь виртуалку

Ты серьезно?

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

Эм, какими средствами вы предлагаете реализовать virtual ip, способный пережить UDP DDoS в 50Гбит? UDP естественно зафильтирован ЦОД'ом, только его аплинки тоже не резиновые, и IP регулярно улетают в блекхолл.

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

IP регулярно улетают в блекхолл

Что это? IP перестают маршрутизироваться?

kukara4 ()

По задумке, если мониторинг фиксирует проблемы, то просто меняется IP-адрес хоста на DNS-сервере на вторую машину

Я предлагаю ip-адрес на интерфейсе менять.

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

Это когда ЦОД не рад входящему трафику в 50Гбит на 1 IP и блокирует его. Ясен пень, что при переключении на второй IP злоумышленники могут и его бахнуть, но вероятность этого мала - они тупые.

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

По задумке, если мониторинг фиксирует проблемы, то просто меняется IP-адрес хоста на DNS-сервере на вторую машину

От программных ошибок не спасет. Ошибки в таком подходе реплицируеются между узлами.

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

В этой ситуации я бы добавил еще 1 сервер в качестве шлюза. 2 нодам дать локальные айпи, + 1 плавающий сервиса. Ну а на шлюзе можно разрулить либо dst натом, либо проксирующим nginx.

ДЦ залочил IP? Не страшно, меняешь на шлюзе на новый и все опять работает. Но тут конечно смотря как написана эта панель и как она обращается к сервисам.

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

Ты серьезно?

Наверное дело в деталях? Именно их Вы подразумеваете, не посвящая нас. Я эксплуатировал такую схему - работает. (но не ЦОД конечно)

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

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

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

Идея ясна, но в чем тогда HA? Шлюз подвиснет, и все Х нод встанут.

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

Я об этом думал, но на второй машине ставить IP 1-го, то, во-первых, пока обновится arp кэш, во-вторых, если 1-й частично подвис и продолжает отвечать на who-is запросы в сети, то ничего не выйдет.

Amoled ()

- Настраиваем master-master репликацию mysql.

Однозначное нафиг.

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

если 1-й частично подвис и продолжает отвечать на who-is запросы в сети, то ничего не выйдет.

Cвязать их по com портам и с того который адрес менять будем давать команду выключить сбойный узел!

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

Не был бы я ораклистом если бы не предложил Oracle Linux:)

В чем же его преимущество? %)

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

А что так все сливают Master-master репликацию? Она же Active/Passive, никто на обоих серверах в те же базы писать одновременно не планирует. Идея позаимствовал у ребят из Битрикс24, говорят работает нормально ... http://habrahabr.ru/company/bitrix/blog/146490/

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

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

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

Можно взять второй шлюз еще конечно, но это усложнит все. А сам ДЦ не может такой NAT сделать?

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

Идея позаимствовал у ребят из Битрикс24

*истерика в зале*

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

Это тонкости вашей топологии. их надо учитывать, но вообщем для ваших нужд, в большей части, что Вы описали, подойдет pacemaker, его можно научить и ip-адресами жонглировать и arp чистить и сбойный узел в нокдаун отправлять и все что угодно. К нему Вам останется определится только с тем как быть с MySQL (Сам я от MySQL ухожу).

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

Вообще, все зависит от того, какой кровью хотите отделаться. Все дело в деньгах и ресурсах.

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

Идея позаимствовал у ребят из Битрикс24

Боже упаси от идей Битрикса и 1С

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

В сравнении с чем?

С любым другим дистрибутивом.

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

Я тут подумал немного и понял, что в предложенной схеме со шлюзами как-то не видно рационального зерна. Ну есть у меня шлюз, ну балансирует он трафик. Все равно все запросы идут на один конкретный IP, IP попадает в бан - трафика нет. Шлюз ломается - все упало. В чем профит? В предложенной мной схеме с DNS все делается автоматически, и помимо как через DNS этого сделать нельзя, на сколько я знаю.

Относительно переписывания приложений под использование двух master'ов - они проприетарные и их тысячи.

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

С любым другим дистрибутивом.

Я у тебя могу то же самое спросить. Конкретней.

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

Если есть деньги, я бы сделал вариант таки, что я предлагал раньше а трафик пустил бы через qrator какой-то. Из-за частой смены айпи мне кажется тут любой вариант будет не очень.

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

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

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

Я у тебя могу то же самое спросить. Конкретней.

Почему ты его рекомендуешь? (достаточно конкретно?)

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

Там задержки будут, моя цель не убить систему, и так работающую на 100% загрузке ...

Amoled ()

то просто меняется IP-адрес хоста на DNS-сервере на вторую машину

Открой для себя pacemaker/corosync и плавающий айпишник, который кидается между серверами по мере надобности.

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

работающую на 100%

Вертикально масштабнуться не?

В любом случае тут основная проблема с этими локами ip. Можно конечно внешний ip прописывать виртуальным адресом а дальше нат или прокси, но это будет кластер на коленке и полу ручное переключение.

Там задержки будут, моя цель не убить систему, и так работающую на 100%

А чем qrator убьет систему и на сколько критичны задержки? И это, какой допустимый даунтайм?

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

Классная аватарка.

Окей, допустим настроили pacemaker на использование плавающего IP. Что посоветуете с остальным? Схема с mysql-proxy на обоих машинах и master-master репликацией Active/Passive жизнеспособна? Как-то не хочется держать постоянно сервер с нулевой загрузкой под Slave.

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

Вообще, это была шутка, просто на первой попавшейся картинке был Oracle Linux, оказия какая :)

Если тебе так интересны преимущества, то тыц

Мне стало интеерсно как же решить проблему ТС'а. Расскажи лучше что можно сделать с помощью виртуализации в этом случае? Реально интересно, ты же, как я понял, с ней много опыта имеешь.

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

С локами IP я думаю поступить просто - поднять на машине несколько плавающих IP, в DNS прописать сразу все, отдаваться будет каждый раз какой-то один. Естественно все IP ведут на одну машину. Недоступные извне адреса просто исключать из DNS.

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

Просьба ваше обсуждение с виртуализацией провести за рамками топика, а то я совсем запутаюсь.

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

Схема с репликацией master-master вполне себе нормальна. Используется например у нас (Percona XtraDB Cluster и haproxy).

Хапрокся мониторит ноды по http, соответствующий костыль (на баше для xinetd и на питоне со standalone вебсервером) есть в поставке перконы.

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

Мне стало интеерсно как же решить проблему ТС'а. Расскажи лучше что можно сделать с помощью виртуализации в этом случае? Реально интересно, ты же, как я понял, с ней много опыта имеешь.

Учитывая, что вылезли всякие «блокировки» ip адресов у ТС, сдается мне, что он кардер или ботовод очередной. Помогать желания нету.

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

А haproxy разве умеет смотреть к какой базе идет запрос? Если нет, то получается у вас схема Active/Active, и запись возможна в одни и те же базы/таблицы одновременно?

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

Схема с mysql-proxy на обоих машинах и master-master репликацией Active/Passive жизнеспособна

тут неплохо написано. А особо смешно будет, если слейв не будет успевать писать за мастером. Бери DRBD. По собственному опыту скажу что рулит шардинг, но он не в твоем случае.

Как-то не хочется держать постоянно сервер с нулевой загрузкой под Slave

Жадность фраера сгубила. Если нагрузишь 2 ноды, это будет костыль на костыле.

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

и запись возможна в одни и те же базы/таблицы одновременно

Это приведет к рассинхронизации данных, индексов, автоинкрементов.

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

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

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

PS: Аватарка как аватарка, в жожо и втентакле ровно тот же персонаж. Разве что другие художники рисовали.

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