0

Реализация VRRP на Linux (Keepalived)

Достигаем избыточности доступности сервиса на основе Keepalived — реализация протокола VRRP (Virtual Router Redundancy Protocol) на линукс
В моём случае резервировали маршрут по умолчанию.

Итак, есть два linux сервера, один из них выполняет роль шлюза в Интернет для клиентов, задача при его недоступности перетащить роль шлюза на другой.
Устанавливаем Keepalived, установка простая и одинаковая на обоих серверах, не вызовет никаких затруднений, небольшие отличия идут далее, в файлах конфигурации для MASTER-сервера и BACKUP.

выделяем три ip адреса (по одному на каждый LAN сетевой интерфейс серверов и один «virtual-ip»)

Пример конфигурации MASTER-сервера

# vim /etc/keepalived/keepalived.conf
vrrp_instance VI_1 { # объявляем instance "VI_1"
state MASTER # указывает на то, что демон стартует в состоянии MASTER и сразу перетягивает на себя виртуальный адрес
# (обратите внимание на то что этот параметр указывает только на начальное состояние демона,
# сразу после старта все сервера из одной VRRP группы будут выбирать мастера на основе наивысшего значения priority)
interface eth0 # интерфейс на котором будет работать VRRP
virtual_router_id 1 # ID для создания VRRP группы (соответственно одинаковый на обоих серверах для резервируемых интерфейсов)
priority 100 # Приоритет (выше выигрывает)
virtual_ipaddress { 192.168.1.1 } # виртуальный ip-адрес
}[/cceWN_bash]
[cceWN_bash width="100%"]# /sbin/service keepalived start[/cceWN_bash]
[cceWN_bash width="100%"]# ip addr show[/cceWN_bash]
должны увидеть что-то подобное:
[cceWN_bash width="100%"]2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 00:e0:81:2b:aa:b5 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.253/24 brd 192.168.1.255 scope global eth0
inet 192.168.1.1/24 brd 192.168.1.255 scope global eth0

Пример конфигурации BACKUP-сервера

# vim /etc/keepalived/keepalived.conf
vrrp_instance VI_1 { # объявляем instance "VI_1"
state BACKUP # указывает на то, что демон стартует в состоянии BACKUP и начинает слушать мультикаст анонсы от мастера
# (обратите внимание на то что этот параметр указывает только на начальное состояние демона,
# сразу после старта все сервера из одной VRRP группы будут выбирать мастера на основе наивысшего значения priority)
interface eth0 # интерфейс на котором будет работать VRRP
virtual_router_id 1 # ID для создания VRRP группы (соответственно одинаковый на обоих серверах для резервируемых интерфейсов)
priority 50 # Приоритет (выше выигрывает), должен быть как минимум на 50% меньше мастера
virtual_ipaddress { 192.168.1.1 } # виртуальный ip-адрес
}

Как только BACKUP не услышит анонсы от MASTER он посчитает его недоступным и отправит самообращенный ARP запрос (gratuitous ARP), тем самым обновив ARP-кеш у клиентов.
В сислоге появится запись вида:

Keepalived_vrrp: VRRP_Instance(VI_1) Transition to MASTER STATE
Keepalived_vrrp: VRRP_Instance(VI_1) Entering MASTER STATE
Keepalived_vrrp: VRRP_Instance(VI_1) setting protocol VIPs.
Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARP on eth0

По возвращению мастера

Keepalived_vrrp: VRRP_Instance(VI_1) Received higher prio advert
Keepalived_vrrp: VRRP_Instance(VI_1) Entering BACKUP STATE
Keepalived_vrrp: VRRP_Instance(VI_1) removing protocol VIPs

 

По скольку я имел дело со шлюзом мне потребовались две VRRP группы, для каждого из интерфейсов (LAN и WAN) и

vrrp_sync_group G1 {
group { VI_1
VI_2 }

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

Настройка и администрирование Windows/Linux, сетевого оборудования D-link, cisco | hotbits.ru

XpycT

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *