Как использовать ks+lvs для создания идеального кластера

1. Введение

Многие пользователи ks спрашивают, как ks сочетается с LVS для переключения трафика? Как ks работает с keepalived для обеспечения высокой доступности? Как сделать так, чтобы система не останавливалась при обновлении?

С помощью мониторинга состояния и команд переключения состояния, предоставляемых ks, в сочетании с некоторыми сторонними компонентами можно создать идеальный кластер промежуточного программного обеспечения mysql.

2. Совместное использование с LVS для переключения трафика

Рисунок: Схема развёртывания LVS

2.1. LVS отслеживает информацию о состоянии ks с помощью этой команды

admin server(opt,k,v) values('show','proxy','status')

Если результат «online», LVS нормально направляет трафик на этот ks; если результат «offline» или «ошибка подключения», LVS считает, что этот узел реального сервера недоступен, и LVS не будет направлять трафик на этот ks.

2.2. Процесс ручного переключения трафика LVS

admin server(opt,k,v) values('change','proxy','offline')

Используя вышеуказанную команду, LVS обнаружит, что состояние узла реального сервера — offline во время следующего цикла обнаружения, и не будет направлять на него трафик. Когда мы увидим, что текущий узел не обрабатывает запросы, мы сможем внести изменения в конфигурацию ks или обновить код.

3. Совместная работа с keepalived для создания высокодоступной архитектуры

Рисунок: Схема развертывания keepalived

3.1 Сценарий проверки активности реального сервера keepalived выполняется с помощью этой команды:

admin server(opt,k,v) values('show','proxy','status')

Если результат — «online», виртуальный IP-адрес keepalived привязан к основному экземпляру ks и не мигрирует; если статус — «offline» или «ошибка соединения», keepalived считает основной экземпляр ks недоступным, виртуальный IP-адрес мигрирует на резервный экземпляр ks, обеспечивая высокую доступность.

3.2 Процесс ручного запуска высокой доступности

admin server(opt,k,v) values('change','proxy','offline')

С помощью вышеуказанной команды состояние одного из ks устанавливается в автономный режим. Обычно можно увидеть, что виртуальный IP-адрес переносится на другой хост основного ks. Когда мы видим, что текущий узел не обрабатывает запросы, мы можем внести изменения в конфигурацию ks или обновить код.