Как добиться высокой доступности с кластером MySQL?
Этот вопрос не о том, как установить серверы или его возможности, а скорее о дизайне.
Итак, у меня есть кластер серверов MySQL.
У меня также есть запись DNS " data.example.com ".
Кластер MySQL имеет ТРИ узла MySQL/ запроса (конечные точки кластера, к которым подключаются приложения).
За этим стоят остальные серверы этого кластера (данные / управление).
Цель состоит в том, чтобы рассматривать этот кластер как единое целое (с внешней точки зрения).
Теперь внешнее приложение (скажем, веб-сервер) хочет действовать (писать / читать) в базе данных. Вот шаги:
1) Разрешить DNS "data.example.com".
2) Подключитесь к IP (это узел SQL).
3) Делай работу.
Первая проблема, которая возникает, проще:
Как открыть все три узла SQL через этот единственный DNS?
Циклический перебор на уровне DNS-сервера?
Установить эту запись DNS, чтобы указать три IP-адреса узлов SQL?
Вторая проблема, которая возникает, скажем, что DNS разрешен до 10.0.0.7, который является только одним из трех узлов SQL: что, если этот узел не работает?
Весь кластер все еще в порядке, но теперь приложение, которое пытается подключиться к этому узлу, видит кластер как "выключенный", потому что этот узел действительно не работает, поэтому я теряю "высокую доступность".
Так что мой вопрос прост:
Что бы вы сделали, чтобы решить проблему? Пожалуйста, опишите подробно, и сложность меня не пугает:)
Обратите внимание, что я хотел бы спросить здесь о балансировке нагрузки или о чем-то подобном, но я предпочитаю оставить этот вопрос "открытым" и услышать более широкий спектр решений. Спасибо!
2 ответа
Высокая доступность обычно достигается с помощью так называемого VIP (виртуального IP-адреса). Таким образом, этот IP-адрес должен отличаться от "статически" назначенного IP-адреса для каждого узла кластера. Этот VIP должен назначаться "динамически" с помощью решения высокой доступности, которое вы используете. Таким образом, только один узел будет обслуживать запросы в этом случае, и в случае сбоя этого узла программное обеспечение высокой доступности назначит VIP другому узлу в кластере. Таким образом, вы не будете страдать от простоев, за исключением очень небольшой части времени при переключении с одного узла на другой.
Если вы выполняете балансировку нагрузки, вам потребуется два узла балансировки нагрузки и как минимум два узла кластера. VIP будет назначен одному из узлов балансировки нагрузки. Запросы приложений будут направлены на узлы кластера через один из узлов балансировки нагрузки.
Важным моментом для беспокойства является синхронизация данных между узлами кластера, особенно в сценариях балансировки нагрузки. Например, представьте, что вы пишете на один узел, а читаете с другого. Конечно, это не будет работать, если не будет применен хороший механизм синхронизации / балансировки нагрузки.
РЕДАКТИРОВАТЬ:
VIP обычно является частным IP-адресом, назначаемым программным обеспечением высокой доступности активному узлу в кластере. Это просто другой IP-адрес, чем исходный IP-адрес каждого узла. Его можно просто назначить из той же подсети. Если узлы кластера должны быть доступны через NATing, общедоступный IP-адрес должен быть преобразован в NAT для VIP. Это важно, чтобы иметь возможность доступа к услуге независимо от того, какой из них является активным узлом.
Вам нужно будет развернуть балансировщик нагрузки, чтобы разделить нагрузку на узлы sql, преобразовать DNS в IP-адрес этого балансировщика нагрузки.