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