Настройка отказоустойчивого роутера на Linux c keepalived

Автор: | 19.09.2014

Ссылки

Моя история

Задача — сделать отказоустойчивый кластер из двух серверов, на одом из которых есть несколько ip, которые надо перекидывать на резервный сервер в случае отказа.

Установка Keepalived

Тут все просто

aptitude install -R keepalived

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

Вот пример конфигурационного файла для мастера:

# Configuration File for keepalived
 
global_defs {
        notification_email {
                admin@mydomain.com
        }
        notification_email_from server1@mydomain.com
        smtp_server                     x.x.x.x
        smtp_connect_timeout            30
# Именное обозначение этого сервера
        router_id                       server1
}
 
 
# Группа интерфейсов. Если хотя бы один из этих интерфейсов перейдет в состояние FAULT, то будет считаться, что все перешли в состояние FAULT
# и все ip перейдут на резервный сервер
vrrp_sync_group common-int {
    group {
        external_interface
        internal_interface
        another_interface
    }
}
 
vrrp_instance external_interface {
	# Интерфейс, для которого будет работать VRRP
	interface eth0
	# Режим в котором будет запускаться демон
	state MASTER
	# Уникальное значения для различия между разными vrrp-instance
	virtual_router_id 1
	# Приоритет - чем выше число, тем выше приоритет
	priority 100
	# Интервал опроса VRRP
	advert_int 1
	# Блок аутентификации - PASS - по паролю. Возможен еще IPSEC, но судя по докам его не рекомендуется использовать
        # Также стоит принять во внимание, что keepalived обрезает пароль до 8 символов. Так что делать пароль длиннее не имеет смысла.
	authentication {
		auth_type PASS
		auth_pass somepass
	}
	# Виртуальные адреса, которые будут перекидываться на BACKUP в случае фэйла
	virtual_ipaddress {
		10.0.0.1 dev eth0
	}
 
	# Тут можно на всякий случай указать наш broadcast, чтобы на него шел ответ, но я просто закомментил это, так как не понял для чего это может понадобиться
	# mcast_src_ip 10.0.0.255
 
 
	# Адреса для исключения из резервирования (если нужно резервировать,
	# например, всю /24 сеть кроме 2-х адресов)
	# virtual_ipaddress_excluded  {
        #        <IPADDR>/<MASK> brd <IPADDR> dev <STRING> scope <SCOPE>
        #        <IPADDR>/<MASK> brd <IPADDR> dev <STRING> scope <SCOPE>
        #           ...
        #      }
	smtp_alert
}

Для остальных интерфейсов (internal_interface и another_interface) делается точно такая же настройка, только в обязательном порядке меняется interface, virtual_router_id.
Пример конфигурационного файла резевного сервера:

# Configuration File for keepalived
 
global_defs {
        notification_email {
                admin@mydomain.com
        }
        notification_email_from server2@mydomain.com
        smtp_server                     x.x.x.x
        smtp_connect_timeout            30
# Именное обозначение этого сервера
        router_id                       server2
}
 
 
# Группа интерфейсов. Если хотя бы один <syntaxhighlight lang='bash'>из этих интерфейсов перейдет в состояние FAULT, то будет считаться, что все перешли в состояние FAULT
# и все ip перейдут на резервный сервер
vrrp_sync_group common-int {
    group {
        external_interface
        internal_interface
        another_interface
    }
}
 
vrrp_instance external_interface {
	# Интерфейс, для которого будет работать VRRP
	interface eth0
	# Режим в котором будет запускаться демон
	state BACKUP
	# Уникальное значения для различия между разными vrrp-instance
	virtual_router_id 1
	# Приоритет - чем выше число, тем выше приоритет
	priority 50
	# Интервал опроса VRRP
	advert_int 1
	# Блок аутентификации - PASS - по паролю. Возможен еще IPSEC, но судя по докам его не рекомендуется использовать
        # Также стоит принять во внимание, что keepalived обрезает пароль до 8 символов. Так что делать пароль длиннее не имеет смысла.
	authentication {
		auth_type PASS
		auth_pass somepass
	}
	# Виртуальные адреса, которые будут приниматься от мастера в случае фэйла
	virtual_ipaddress {
		10.0.0.1 dev eth0
	}
 
	# Тут можно на всякий случай указать наш broadcast, чтобы на него шел ответ, но я просто закомментил это, так как не понял для чего это может понадобиться
	# mcast_src_ip 10.0.0.255
 
 
	# Адреса для исключения из резервирования (если нужно резервировать,
	# например, всю /24 сеть кроме 2-х адресов)
	# virtual_ipaddress_excluded  {
        #        <IPADDR>/<MASK> brd <IPADDR> dev <STRING> scope <SCOPE>
        #        <IPADDR>/<MASK> brd <IPADDR> dev <STRING> scope <SCOPE>
        #           ...
        #      }
	smtp_alert
}

Из второго пример видно, что изменилось только начальное состояние, с которым будет запускаться резервный сервер и приоритет. Стоит отметить, что после запуска в режиме резерва, сервера все равно начнут «меряться» приоритетами «у кого больше» и выбирать альфа-самца.

После перезапуска демона на мастере в логах должно быть что-то типа такого:

Keepalived_vrrp[27182]: VRRP_Instance(external_interface) Transition to MASTER STATE
Keepalived_vrrp[27182]: VRRP_Instance(external_interface) Entering MASTER STATE
Keepalived_vrrp[27182]: VRRP_Instance(internal_interface) Transition to MASTER STATE
Keepalived_vrrp[27182]: VRRP_Instance(internal_interface) Entering MASTER STATE
Keepalived_vrrp[27182]: VRRP_Instance(another_interface) Transition to MASTER STATE
Keepalived_vrrp[27182]: VRRP_Instance(another_interface) Entering MASTER STATE
Keepalived_vrrp[27182]: VRRP_Group(common-int) Syncing instances to MASTER state
Keepalived_vrrp[27182]: Remote SMTP server [x.x.x.x]:25 connected.
Keepalived_vrrp[27182]: SMTP alert successfully sent.

На резевном сервере сначала должно быть то же самое, а потом такое

Keepalived_vrrp[19071]: VRRP_Instance(external_interface) Received higher prio advert
Keepalived_vrrp[19071]: VRRP_Instance(internal_interface) Received higher prio advert
Keepalived_vrrp[19071]: VRRP_Instance(another_interface) Received higher prio advert
Keepalived_vrrp[19071]: VRRP_Instance(external_interface) Entering BACKUP STATE
Keepalived_vrrp[19071]: VRRP_Instance(internal_interface) Entering BACKUP STATE
Keepalived_vrrp[19071]: VRRP_Instance(another_interface) Entering BACKUP STATE
Keepalived_vrrp[19071]: VRRP_Group(common-int) Syncing instances to BACKUP state
Keepalived_vrrp[19071]: Remote SMTP server [x.x.x.x]:25 connected.
Keepalived_vrrp[19071]: SMTP alert successfully sent.

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

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

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