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