Ссылки
Моя история
Задача — сделать отказоустойчивый кластер из двух серверов, на одом из которых есть несколько 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.