Как настроить аварийное переключение с помощью keepalived для нескольких кластеров в сети?

Question

Я устанавливаю приложение, для которого потребуется 10+ серверов, из них 4 сервера должны быть настроены в режиме высокой доступности с 2 кластерами, каждый из которых имеет 2 сервера.

Допустим, есть 4 сервера A, B, C и D

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

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

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

Проблема в том, что он не работает, аварийное переключение не происходит при выключении служб, а при проверке keepalived.conf у меня есть сомнения, правильны ли сделанные настройки или нет.

Keepalived на сервере A

global_defs {

# Keepalived process identifier

router_id haproxy_DH_passive

}

# Script used to check if HAProxy is running

vrrp_script check_haproxy {

script "killall -0 haproxy"

interval 2

weight 2

}

vrrp_instance VRRP1 {
    state MASTER
#   Specify the network interface to which the virtual address is assigned
   interface ens192
#   The virtual router ID must be unique to each VRRP instance that you define
    virtual_router_id 41
#   Set the value of priority higher on the master server than on a backup server
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1066
    }
    virtual_ipaddress {
        10.4.32.1
    }
    track_script {
         check_haproxy
    }
}

keepalived conf на сервере B того же кластера

global_defs {

# Keepalived process identifier

router_id haproxy_DH_passive

}

# Script used to check if HAProxy is running

vrrp_script check_haproxy {

script "killall -0 haproxy"

interval 2

weight 2

}

vrrp_instance VRRP1 {
    state BACKUP
#   Specify the network interface to which the virtual address is assigned
   interface ens192
#   The virtual router ID must be unique to each VRRP instance that you define
    virtual_router_id 41
#   Set the value of priority higher on the master server than on a backup server
    priority 99
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1066
    }
    virtual_ipaddress {
        10.4.32.1
    }
    track_script {
         check_haproxy
    }
}

конфигурация для другого кластера

на сервере C

global_defs {

# Keepalived process identifier

router_id haproxy_DH_passive

}

# Script used to check if HAProxy is running

vrrp_script check_haproxy {

script "killall -0 haproxy; killall -0 pgpool"

interval 2

weight 2

}

vrrp_instance VRRP1 {
    state MASTER
#   Specify the network interface to which the virtual address is assigned
   interface ens192
#   The virtual router ID must be unique to each VRRP instance that you define
    virtual_router_id 41
#   Set the value of priority higher on the master server than on a backup server                                                
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1066
    }
    virtual_ipaddress {
        10.4.32.2
    }
    track_script {
         check_haproxy
    }
}

и на сервере D

global_defs {

# Keepalived process identifier

router_id haproxy_DH_passive

}

# Script used to check if HAProxy is running

vrrp_script check_haproxy {

script "killall -0 haproxy; killall -0 pgpool"

interval 2

weight 2

}

vrrp_instance VRRP1 {
    state BACKUP
#   Specify the network interface to which the virtual address is assigned
   interface ens192
#   The virtual router ID must be unique to each VRRP instance that you define
    virtual_router_id 41
#   Set the value of priority higher on the master server than on a backup server
    priority 99
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1066
    }
    virtual_ipaddress {
        10.4.32.2
    }
    track_script {
         check_haproxy
    }
}

Таким образом, в первом кластере активный компонент должен получить IP 10.4.32.1, а во втором кластере активный компонент должен получить IP 10.4.32.2.

Теперь у меня вопрос, поскольку они оба соответствуют разным кластерам, не должны ли они быть в разных экземплярах VRRP.

Или, если они могут быть частью разных кластеров и по-прежнему находиться в одном экземпляре VRRP, тогда не должен ли первый набор иметь один и тот же виртуальный идентификатор маршрутизатора, допустим, X, а другой набор должен иметь другой, допустим, Y

т.е. сервер A и B под идентификатором виртуального маршрутизатора X и сервер C и D под идентификатором виртуального маршрутизатора Y

Насколько я понимаю, keepalived продолжает обнаруживать другие службы в своем пуле (я предполагаю, что это определяется экземпляром VRRP), а затем направляет запрос на маршрутизатор (решается через идентификатор маршрутизатора), тогда он не должен создавать конфликт на том же идентификаторе маршрутизатора там есть 2 мастера и 2 резервные копии?