Keepalived ubuntu что это

Обновлено: 07.07.2024

Демон keepalived может использоваться для мониторинга сервисов или систем и автоматического перехода на резервный ресурс в режиме ожидания в случае возникновения проблем. В этом мануале вы узнаете, как использовать keepalived для создания высокодоступного веб-сервиса. В настройке используется плавающий IP-адрес, который можно перемещать между двумя поддерживаемыми веб-серверами. Если ведущий сервер прекращает работу, плавающий IP-адрес будет автоматически переназначен второму серверу, что позволит возобновить работу приложения.

Установка и настройка Nginx

Хотя keepalived часто используется для мониторинга и балансировки нагрузки (что упрощает инфраструктуру), в этом мануале вместо него в качестве простого веб-сервера используется Nginx.

Обновите индекс пакетов на каждом из ваших серверов. Затем можно установить Nginx:

В большинстве случаев настройка высокой доступности создается для обслуживания одного и того же контента. Однако в этом мануале Nginx будет обслуживать разный контент: это нужно для того, чтобы видеть, какой из двух серверов обслуживает запросы в тот или иной момент. Для этого нужно изменить страницу index.html по умолчанию на каждом из хостов. Откройте файл:

На первом сервере замените контент файла этой строкой:

На втором сервере файл будет содержать такую строку:

Сохраните и закройте файлы.

Сервер 1 будет теперь первичным, а сервер 2 – вторичным.

Сборка и установка keepalived

Затем нужно установить демон keepalived на все серверы инфраструктуры. В репозиториях Ubuntu по умолчанию есть версия keepalived, но она устарела и содержит несколько ошибок, которые влияют на работу конфигурации. Потому лучше собрать keepalived из исходного кода.

Прежде чем начать, нужно установить все зависимости, требуемые для сборки. Метапакет build-essential предоставит инструменты компиляции, а пакет libssl-dev содержит библиотеки SSL, на которых основан демон keepalived:

После установки зависимостей можно скачать тарбол демона. Посетите эту страницу и найдите последнюю доступную версию keepalived. Кликните правой кнопкой и скопируйте адрес ссылки. Вернитесь на сервер, перейдите в домашний каталог и загрузите пакет:

Распакуйте архив и перейдите в полученный каталог:

Соберите и установите демон:

Создание сценария Upstart для keepalived

Установка keepalived перенесла все бинарные и сопутствующие файлы в систему. Однако среди них нехватает сценария Upstart для системы Ubuntu.

Вы можете создать очень простой сценарий Upstart, который будет обрабатывать сервис keepalived. Откройте файл под названием keepalived.conf в /etc/init:

Для начала добавьте краткое описание сервиса keepalived. Можно использовать описание демона из его справки. Затем укажите уровни запуска, на которых нужно запустить и остановить сервис; в данном случае для запуска используются уровни 2-5, а для остановки – все остальные уровни (например, при перезагрузке, отключении питания или в однопользовательском режиме).

Поскольку этот сервис является неотъемлемой частью обеспечения высокой доступности вашего приложения, его необходимо перезагружать в случае сбоя. Затем нужно добавить строку exec, которая запустит сервис, и добавить в нее опцию —dont-fork, чтобы система Upstart правильно отслеживала pid:

Сохраните и закройте файл.

Такой файл нужно создать на всех серверах инфраструктуры.

Конфигурация keepalived

Теперь можно перейти к настройке keepalived.

Сервис ищет конфигурации в каталоге /etc/keepalived. Создайте этот каталог на обоих серверах:

Поиск внутренних IP-адресов серверов

Прежде чем продолжить работу над конфигурацией, нужно найти IP-адреса серверов инфраструктуры. Его можно найти в метаданных:

Также для этого можно использовать инструменты iproute2:

Значение, которое вы ищете 10.132.7.107:

Скопируйте это значение на обоих серверах. Их нужно будет использовать в конфигурации демона.

Конфигурация первичного сервера

Перейдите на сервер 1 и создайте главный конфигурационный файл keepalived. Демон ищет файл keepalived.conf в каталоге /etc/keepalived.

Начните с определения проверки работоспособности сервиса Nginx, открыв блок vrrp_script. Это настроит мониторинг состояния веб-сервера, что позволяет своевременно обнаружить сбой и начать восстановление.

Эта проверка очень проста. Каждые две секунды демон будет проверять, что процесс nginx все еще требует pid:

Затем откройте блок vrrp_instance. Это основной раздел конфигурации, который определяет, как keepalived будет обеспечивать высокую доступность.

Настройте keepalived для использования частного интерфейса eth1. В настройках первичного сервера в параметре state нужно указать MASTER. Это исходное значение, которое будет использовать keepalived.

Во время голосования для выбора ноды используется опция priority. Это решение основывается на том, какой сервер имеет наибольшее значение этого параметра. Укажите 200 на первичном сервере:

Далее нужно присвоить этой группе кластера ID, который будут совместно использовать обе ноды. В мануале используется ID 33. В параметре unicast_src_ip укажите внутренний IP-адрес первичного сервера, а в unicast_peer – внутренний IP-адрес вторичного сервера.

Затем можно настроить простую аутентификацию для связи демонов друг с другом. Это всего лишь базовая мера предосторожности, которая гарантирует, что в инфраструктуре работают только авторизованные серверы. Создайте подблок authentication. Внутри укажите настройте парольную аутентификацию, установив auth_type. В параметре auth_pass установите общий секретный ключ, который будет использоваться всеми нодами. Здесь имеют значение только первые восемь символов.

Затем нужно использовать подпрограмму chk_nginx, созданную в начале файла, чтобы определить состояние работоспособности локальной системы. После этого нужно создать скрипт notify_master, который будет выполняться всякий раз, когда эта нода будет ведущей. Этот скрипт будет отвечать за запуск переназначения плавающего IP-адреса.

Сохраните и закройте файл.

Конфигурация вторичного сервера

Теперь нужно создать подобный файл на вторичном сервере. Откройте файл в /etc/keepalived/keepalived.conf:

Конфигурационный файл вторичного сервера будет в значительной степени эквивалентен конфигурации первичного сервера. Элементы, которые нужно изменить здесь:

state: измените значение параметра на BACKUP, чтобы нода инициализировалась в режиме резервного копирования до проведения голосования.
priority: здесь нужно указать меньшее значение, чем на первичном сервере, например, 100.
unicast_src_ip: здесь нужно указать внутренний IP-адрес вторичного сервера.
unicast_peer: здесь нужно указать внутренний IP-адрес первичного сервера.

Изменив эти параметры, вы получите такой конфигурационный файл вторичного сервера:

Сохраните и закройте файл.

Создание сценария для переназначения плавающего IP-адреса

Затем нужно создать пару сценариев, которые будут использоваться для переназначения плавающего IP-адреса на текущий сервер, когда локальный экземпляр keepalived становится мастер-сервером.

Загрузка сценария

Загрузите в каталог /usr/local/bin простой сценарий Python, который будет переназначать плавающий IP-адрес с помощью API.

Этот сценарий будет переназначать плавающий IP после запуска команды:

Это будет работать, только если у вас есть переменная окружения TOKEN, в которой указан валидный токен API.

Создайте такой токен и плавающий IP-адрес, если вы не сделали этого ранее.

Если вы запросите свой плавающий IP в браузере, он должен вернуть страницу index.html первичного сервера:

Создание сценария

Теперь у вас есть все компоненты, необходимые для создания сценария /usr/local/bin/assign-ip.

Этот сценарий нужно создать на обоих серверах.

Для начала добавьте переменную TOKEN с токеном API и переменную IP с плавающим IP-адресом.

Затем используйте команду curl, чтобы запросить в метаданных ID текущего сервера. Это значение будет присвоено переменной ID. Также нужно уточнить, имеет ли в настоящее время этот сервер назначенный ему плавающий IP-адрес. Результаты этого запроса сохраняются в переменной HAS_FLOATING_IP

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

Чтобы обработать случаи, когда плавающий IP обслуживает какое-то событие, запустите сценарий assign-ip несколько раз. В данном случае сценарий будет запускаться 10 раз с интервалом в 3 секунды между каждым вызовом. Цикл завершится немедленно, если перемещение плавающего IP-адреса будет выполнено успешно.

Сохраните и закройте файл.

Сделайте сценарий исполняемым:

Запуск keepalived и тестирование настройки

Теперь демон keepalived и все его сопутствующие скрипты полностью настроены. Можно запустить сервис на обеих машинах, набрав:

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

Если оба сервера работают корректно, при посещении плавающего адреса в браузере вы увидите страницу Nginx первичного сервера:

Протестируйте высокую доступность и функцию обработки сбоев инфраструктуры.

Обработка сбоев должна происходить при возникновении любого из следующих условий:

Когда проверка состояния Nginx на первичном сервере указывает на то, что Nginx больше не работает. В этом случае демон keepalived первичного сервера перейдет в состояние «fault». Он уведомит вторичный сервер о том, что он должен взять на себя роль первичного сервера и присвоить себе плавающий IP-адрес.
Когда вторичный сервер теряет свое соединение keepalived с первичным сервером. Если по какой-либо причине вторичный сервер не может связаться с первичным сервером, он перейдет в состояние master и попытается присвоить плавающий IP-адрес.

Если первичный сервер позже восстановится, он вернется в состояние master и вернет плавающий IP-адрес, потому что он инициирует новое голосование (ведь ему по-прежнему принадлежит наивысший приоритет).

Тестирование обработки ошибок Nginx

Проверить обработку ошибок в первой ситуации можно путем остановки Nginx на первичном сервере:

Несколько секунд спустя обновите страницу. Вы должны увидеть, что страница обслуживается вторичным сервером:

Чтобы устранить неполадку, перезапустите сервис Nginx на первичном сервере:

Обновив страницу через несколько секунд, вы обнаружите, что первичный сервер восстановил плавающий IP-адрес:

Тестирование обработки ошибок сервера

Теперь нужно проверить, правильно ли вторичный сервер переходит к состоянию master, если он не может подключиться к первичному серверу. Попробуйте перезагрузить первичный сервер, чтобы проверить это:

Спустя пару секунд первичный сервер завершит перезагрузку и вернет себе плавающий IP-адрес.

VRRP расшифровывается как Virtual Redundancy Router Protocol. Группа физических маршрутизаторов объединяется в один виртуальный. Каждый участник группы может находиться в трех состояниях: неопределенном (initialize), основном (master) и резервном (backup). У всех участников в настройках присутствует один или несколько виртуальных адресов. У основного эти адреса присвоены сетевой карте, а у остальных — просто ждут своего часа.

Прежде всего нужно сказать, что VRRP работает поверх IP, а не напрямую поверх канального уровня. Если быть точным, он использует групповой (multicast) адрес 224.0.0.18. Поскольку multicast по умолчанию не маршрутизируется, взаимодействие возможно только в пределах одной физической сети.

Это значит, что, помимо общего виртуального адреса, каждому маршрутизатору на каждом сетевом интерфейсе, где ты настраиваешь VRRP, должен быть присвоен основной, с которого он будет отправлять соседям служебные пакеты.

Нужно сразу сказать, что основной (служебный) адрес совсем не обязан быть из одной сети с виртуальными. Если у тебя недостаточно публичных адресов для тех сетевых карт, которые смотрят в интернет, ты вполне можешь использовать частные адреса из RFC 1918 в качестве служебных. Ну, если настройки твоего провайдера этого не запрещают.

У каждой группы маршрутизаторов есть VRID — Virtual Router Identifier. Это просто число в диапазоне от 1 до 255. С каждой группой может быть ассоциирован один или несколько виртуальных адресов. На уровне протокола список адресов передается, но только для отладочных целей. Процесс VRRP их никак не использует, тем более что передаются они без маски подсети, так что за идентичностью настроек виртуальных адресов нужно следить самому.

Группы с разным VRID друг с другом не взаимодействуют, поэтому в одной физической сети может быть несколько независимых групп резервирования, главное — настроить.

При загрузке или первичной настройке VRRP участники группы оказываются в неопределенном состоянии (initialize) и выбирают, кому быть основным, а кому резервным. В настройках VRRP можно указать приоритет (priority) — маршрутизатор с наибольшим приоритетом выигрывает выборы.

Если приоритет у нескольких маршрутизаторов одинаковый, выигрывает тот, у кого самый большой адрес IP. Я сам стараюсь не полагаться на случай и всегда указываю приоритет явно.

Маршрутизатор, который выбрали основным, присваивает своей сетевой карте виртуальные адреса и начинает рассылать остальным пакеты VRRP advertisement. Таким способом он сообщает, что еще жив и работоспособен.

Пока эти пакеты приходят, резервные маршрутизаторы ничего не делают. Когда основной упадет и резервные заметят, что пакеты перестали приходить, они инициируют выборы заново и выберут новый основной из оставшихся, по тем же правилам.

Что будет, если бывший основной маршрутизатор вернется к жизни? Все зависит от опции preempt в настройках. Если она включена, то он снова инициирует выборы и вернет себе былую славу. Если нет, так и останется резервным.

Включать или не включать preempt — дело вкуса. С одной стороны, с этой опцией легко предсказать, какой маршрутизатор в данный момент основной, а с другой — переключений состояния, а значит, и потерянных пакетов будет больше. Я обычно включаю, но свое мнение никому не навязываю.

Настраиваем keepalived

Перейдем от теории к практике. В первую очередь нам потребуется пакет keepalived. Его функциональность шире, но сегодня мы сосредоточимся именно на VRRP. Этот пакет есть в репозиториях у всех популярных дистрибутивов, так что с его установкой сложностей быть не должно.

Сценарий будет такой: два маршрутизатора, rtr-master со служебным адресом 192.0.2.1 и rtr-backup с адресом 192.0.2.2. В качестве виртуального адреса возьмем 192.0.2.254, а VRID установим в 10. Будем считать, что служебные адреса настроены на сетевом интерфейсе eth0.

Продолжение доступно только участникам

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Требования

Два сервера Ubuntu 14.04, настроенных по этому мануалу.
Серверы должны находиться в одном ЦОД и иметь частную сеть.
API-токен.
Плавающий IP-адрес.

1: Установка и настройка Nginx

Обновите индекс пакетов на каждом из ваших серверов. Затем можно установить Nginx:

sudo apt-get update
sudo apt-get install nginx

sudo nano /usr/share/nginx/html/index.html

На первом сервере замените контент файла этой строкой:

На втором сервере файл будет содержать такую строку:

Сохраните и закройте файлы.

Сервер 1 будет теперь первичным, а сервер 2 – вторичным.

2: Сборка и установка keepalived

sudo apt-get install build-essential libssl-dev

Распакуйте архив и перейдите в полученный каталог:

tar xzvf keepalived*
cd keepalived*

Соберите и установите демон:

./configure
make
sudo make install

3: Создание сценария Upstart для keepalived

Установка keepalived перенесла все бинарные и сопутствующие файлы в систему. Однако среди них нехватает сценария Upstart для системы Ubuntu 14.04.

sudo nano /etc/init/keepalived.conf

description "load-balancing and high-availability service"
start on runlevel [2345] stop on runlevel [!2345]

description "load-balancing and high-availability service"
start on runlevel [2345] stop on runlevel [!2345] respawn
exec /usr/local/sbin/keepalived --dont-fork

Сохраните и закройте файл.

Такой файл нужно создать на всех серверах инфраструктуры.

4: Конфигурация keepalived

Теперь можно перейти к настройке keepalived.

Сервис ищет конфигурации в каталоге /etc/keepalived. Создайте этот каталог на обоих серверах:

sudo mkdir -p /etc/keepalived

Поиск внутренних IP-адресов серверов

Также для этого можно использовать инструменты iproute2:

ip -4 addr show dev eth1

Значение, которое вы ищете, выделено красным:

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 10.132.7.107/16 brd 10.132.255.255 scope global eth1
valid_lft forever preferred_lft forever

Скопируйте это значение на обоих серверах. Их нужно будет использовать в конфигурации демона.

Конфигурация первичного сервера

sudo nano /etc/keepalived/keepalived.conf

Эта проверка очень проста. Каждые две секунды демон будет проверять, что процесс nginx все еще требует pid:

vrrp_script chk_nginx script "pidof nginx"
interval 2
>

vrrp_script chk_nginx script "pidof nginx"
interval 2
>
vrrp_instance VI_1 interface eth1
state MASTER
priority 200
>

vrrp_script chk_nginx script "pidof nginx"
interval 2
>
vrrp_instance VI_1 interface eth1
state MASTER
priority 200
virtual_router_id 33
unicast_src_ip primary_private_IP
unicast_peer secondary_private_IP
>
authentication auth_type PASS
auth_pass password
>
>

Сохраните и закройте файл.

Конфигурация вторичного сервера

Теперь нужно создать подобный файл на вторичном сервере. Откройте файл в /etc/keepalived/keepalived.conf:

sudo nano /etc/keepalived/keepalived.conf

state: измените значение параметра на BACKUP, чтобы нода инициализировалась в режиме резервного копирования до проведения голосования.
priority: здесь нужно указать меньшее значение, чем на первичном сервере, например, 100.
unicast_src_ip: здесь нужно указать внутренний IP-адрес вторичного сервера.
unicast_peer: здесь нужно указать внутренний IP-адрес первичного сервера.

Изменив эти параметры, вы получите такой конфигурационный файл вторичного сервера:

vrrp_script chk_nginx script "pidof nginx"
interval 2
>
vrrp_instance VI_1 interface eth1
state BACKUP
priority 100
virtual_router_id 33
unicast_src_ip secondary_private_IP
unicast_peer primary_private_IP
>
authentication auth_type PASS
auth_pass password
>
track_script chk_nginx
>
notify_master /etc/keepalived/master.sh
>

Сохраните и закройте файл.

5: Создание сценария для переназначения плавающего IP-адреса

Загрузка сценария

Загрузите в каталог /usr/local/bin простой сценарий Python, который будет переназначать плавающий IP-адрес с помощью API.

Этот сценарий будет переназначать плавающий IP после запуска команды:

python /usr/local/bin/assign-ip floating_ip sever_ID

Это будет работать, только если у вас есть переменная окружения TOKEN, в которой указан валидный токен API.

Создайте такой токен и плавающий IP-адрес, если вы не сделали этого ранее.

Если вы запросите свой плавающий IP в браузере, он должен вернуть страницу index.html первичного сервера:

Создание сценария

Теперь у вас есть все компоненты, необходимые для создания сценария /usr/local/bin/assign-ip.

Этот сценарий нужно создать на обоих серверах.

sudo nano /etc/keepalived/master.sh

Для начала добавьте переменную TOKEN с токеном API и переменную IP с плавающим IP-адресом.

export TOKEN='api_token'
IP='floating_ip_addr'

export TOKEN=' api_token '
IP=' floating_ip_addr '
ID=$(curl -s http://169.254.169.254/metadata/v1/id)
HAS_FLOATING_IP=$(curl -s http://169.254.169.254/metadata/v1/floating_ip/ipv4/active)
if [ $HAS_FLOATING_IP = "false" ]; then
n=0
while [ $n -lt 10 ] do
python /usr/local/bin/assign-ip $IP $ID && break
n=$((n+1))
sleep 3
done
fi

Сохраните и закройте файл.

Сделайте сценарий исполняемым:

sudo chmod +x /etc/keepalived/master.sh

6: Запуск keepalived и тестирование настройки

sudo start keepalived

Протестируйте высокую доступность и функцию обработки сбоев инфраструктуры.

Обработка сбоев должна происходить при возникновении любого из следующих условий:

Когда проверка состояния Nginx на первичном сервере указывает на то, что Nginx больше не работает. В этом случае демон keepalived первичного сервера перейдет в состояние «fault». Он уведомит вторичный сервер о том, что он должен взять на себя роль первичного сервера и присвоить себе плавающий IP-адрес.
Когда вторичный сервер теряет свое соединение keepalived с первичным сервером. Если по какой-либо причине вторичный сервер не может связаться с первичным сервером, он перейдет в состояние master и попытается присвоить плавающий IP-адрес.

Тестирование обработки ошибок Nginx

Проверить обработку ошибок в первой ситуации можно путем остановки Nginx на первичном сервере:

sudo service nginx stop

This webpage is not available
ERR_CONNECTION_REFUSED

Чтобы устранить неполадку, перезапустите сервис Nginx на первичном сервере:

sudo service nginx start

Обновив страницу через несколько секунд, вы обнаружите, что первичный сервер восстановил плавающий IP-адрес:

Тестирование обработки ошибок сервера

This webpage is not available
ERR_CONNECTION_REFUSED

Спустя пару секунд первичный сервер завершит перезагрузку и вернет себе плавающий IP-адрес.

Заключение

Теперь у вас есть простая инфраструктура высокой доступности на основе keepalived, интерфейса API и плавающего IP-адреса. Используйте эту инфраструктуру как шаблон для построения более сложного кластера.

VRRP (Virtual Redundant Router Protocol), несмотря на неясную ситуацию с патентами Cisco, остается стандартным протоколом для горячего резервирования маршрутизаторов. Популярный в системах семейства BSD протокол CARP свободен от патентных ограничений, но статус стандарта и поддержка со стороны многих поставщиков имеют свои преимущества — существует по крайней мере теоретическая возможность сменить поставщика незаметно для пользователей сети.

В сегодняшней статье я расскажу, как настроить отказоустойчивый маршрутизатор на основе Linux и создать отказоустойчивую сеть. В качестве реализации VRRP мы будем использовать keepalived.

Протокол VRRP

неопределенном (initialize)
основном (master)
резервном (backup)

У всех участников группы в настройках присутствует 1 или несколько виртуальных адресов. У основного эти адреса присвоены сетевой карте, а у других — просто ждут своего часа.

Прежде всего надо сказать, что VRRP работает поверх IP, а не напрямую поверх канального уровня. Если быть точным, он использует групповой (multicast) адрес 224.0.0.18. Поскольку multicast по умолчанию не маршрутизируется, взаимодействие возможно только в пределах одной физической сети.

Это значит, что, помимо общего виртуального адреса, каждому маршрутизатору на каждом сетевом интерфейсе, где вы настраиваете VRRP, должен быть присвоен основной, с которого он будет отправлять соседям служебные пакеты.

Надо сразу сказать, что основной (служебный) адрес совсем не должен быть из одной сети с виртуальными. Если у вас недостаточно публичных адресов для тех сетевых карт, которые смотрят в интернет, вы вполне можете использовать частные адреса из RFC 1918 в качестве служебных. Ну, если настройки вашего провайдера этого не запрещают.

У каждой группы маршрутизаторов есть VRID — Virtual Router Identifier. Это просто число в диапазоне от 1 до 255. С каждой такой группой может быть ассоциирован 1 или несколько виртуальных адресов. На уровне протокола список адресов передается, но только для отладочных целей. Процесс VRRP их никак не использует, тем более что передаются они без маски подсети, так что за идентичностью настроек виртуальных адресов надо следить самому.

Группы с разным VRID друг с другом не взаимодействуют, поэтому в одной физической сети может быть любое количество независимых групп резервирования, главное — настроить.

Маршрутизатор, который выбрали основным, присваивает своей сетевой карте виртуальные адреса и начинает посылать остальным пакеты VRRP advertisement. Таким образом он сообщает, что еще функционирует и работоспособен.

Что будет, если бывший основной маршрутизатор вернется к жизни? Все зависит от опции preempt в настройках. Если она включена, то он повторно инициирует выборы и вернет себе былую славу. Если нет, так и останется резервным.

Включать или не включать preempt — вам решать. С одной стороны, с этой настройкой легко предсказать, какой маршрутизатор в данный момент основной, а с другой — переключений состояния, а значит, и потерянных пакетов будет больше. Я как правило включаю, но свое мнение никому не навязываю.

Настраиваем keepalived

Перейдем от теории к практике. В первую очередь нам потребуется пакет keepalived. Его функциональность шире, но в этой статье для настройки отказоустойчивой сети мы сосредоточимся именно на VRRP. Этот пакет есть в репозиториях у всех популярных дистрибутивов, так что с его установкой сложностей быть не должно.

Читайте также: