CentOS: строим отказоустойчивый сервис при помощи протокола carp.

В современном миры, вопрос отказоустойчивой работы сервисов стоит очень остро. По сути в принципе не столь важно - отказоустойчивость какого именно сервиса мы планируем организовать, будь то высоконагруженный веб-сервер или роутер в небольшой компании. Пожалуй ключевым фактором в данном вопросе является стоимость простоя сервиса, отсюда и выливается стоимость технологий, которые будут отвечать за отказоустойчивость сервиса. Одним из бюджетных и одним из самых простых решениям является реализация CARP. Сутью этого протокола является использование одного IP-адреса несколькими машинами. По сути у нас есть несколько хостов, объединённых в группу, которые по определённой технологии занимают указанный IP-адрес и продолжают предоставлять, поднятые на них сервисы. Сегодня такую группу хостов мы и настроим.

Как и всё в последнее время - свои эксперименты я буду проводить на CentOS 7. Для работы нам понадобится пакет ucarp, с которого мы и начнём, а пока небольшая вводная:
допустим нам необходимо организовать безотказную работу офисного proxy-сервера. Как поднять proxy-сервер при помощи squid с авторизацией в Active Directory я уже рассказывал, по этому к этому вопросу я обращаться не буду и будем считать что у нас есть две машины, на которых он уже поднят, настроен и работает.
IP-proxy - 192.168.0.100
IP-master сервер - 192.168.0.55
IP-slave сервер - 192.168.0.56

т.е. в данном случае у нас ip-адрес 10.15.1.1 свободен и не принадлежит ни одной физической машине.
И так - поехали.
Устанавливаем на обеих машинах ucarp.

korp # yum install ucarp

Теперь редактируем конфигурационные файлы на хостах

korp # cd /etc/ucarp

Переименовываем пример конфига

korp # mv vip-001.conf.example vip-001.conf

указываем на обоих хостах какой IP-адрес мы будем занимать

korp # nano vip-001.conf
VIP_ADDRESS="192.168.0.110"

Теперь на каждом из хостов нужно внести изменения к основной конфиг файл

korp # nano vip-common.conf

Master:

PASSWORD="AjWPRwRFt4GrL2"
BIND_INTERFACE="ens192"
SOURCE_ADDRESS="192.168.0.55"
OPTIONS="-k 1 --shutdown --preempt"

Slave:

PASSWORD="AjWPRwRFt4GrL2"
BIND_INTERFACE="ens192"
SOURCE_ADDRESS="192.168.0.56"
OPTIONS="-k 10 --shutdown"

Здесь мы указываем:
PASSWORD - пароль для общения хостов друг с другом
BIND_INTERFACE - имя интерфейса, к которому будем привязывать наш основной IP-адрес
SOURCE_ADDRESS - IP-адрес нашего мастера
OPTIONS - дополнительные параметры. у мастера должен быть параметр --preempt, который заставляет быть его мастерам, если это возможно. у слэйва этого параметра быть не должно. дополнительные опции можно посмотреть при помощи команды ucarp --help

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

korp # systemctl enable ucarp@vip-001.service
korp # systemctl start ucarp@vip-001.service

Конечно в момент переключения хостов пинг и пакеты на несколько будут пропадать, но не думаю что это будет сильно заметно. Конечно не все сервисы удобно поднимать таким образом, весь порой проблема будет не только в настройке серверной части, но и в синхронизации данных. Если настройки сервера перенести на 2-3 хоста проблем особых не составляет, особенно если вы используете что то для развёртывания конфигураций типа Puppet, то переносить данные будет более затруднительно, особенно если это сервис с активно изменяющимися файлами. По этому нужно предварительно взвесить все за и против этого решения, возможно вы сможете найти какое то иное применение этому протоколу для своей работы.
Всем удачи и отказоустойчивости! 🙂

Добавить комментарий