Выделенная сеть Keepalived для пульса и vrrp_sync_group

Question

У меня есть требование, чтобы Keepalived запускал VRRP на двух балансировщиках нагрузки (NGINX) с двумя интерфейсами - eth0 (внешний) и eth1 (внутренний). Я пытаюсь настроить настройку, в которой весь трафик VRRP (предпочтительно одноадресный) запускается через выделенный внутренний интерфейс eth1, чтобы снизить риск ситуации с разделением мозга. Однако плавающий IP-адрес (VRRP IP) будет находиться во внешней сети eth0.

Я смотрел [https://github.com/acassen/keepalived/issues/637] и пытался сделать что-то подобное. Моя конфигурация ниже:

global_defs {
   notification_email_from myadmin@myserver
   smtp_server localhost
   smtp_connect_timeout 30
   router_id LVS_DEVEL
}

vrrp_script check_nginx {
    script "/usr/libexec/keepalived/check_nginx.sh"
    interval 3
}

vrrp_sync_group link_instances {
    group {
        real
        stop_duplicate
    }
}

vrrp_instance real {
    state BACKUP
    interface eth0
    virtual_router_id 1
    priority 250               # This will be a lower value on the other router
    version 3                  # not necessary, but you may as well use the current protocol
    advert_int 1
    nopreempt

    track_interface {
        eth1
    }

    track_script {
        check_nginx
    }

    unicast_src_ip 115.197.1.166
    unicast_peer {
    115.197.1.167
    }

     virtual_ipaddress {
          115.197.1.170/32 dev eth0
    }
}

vrrp_instance stop_duplicate {
    state BACKUP
    interface eth1
    virtual_router_id 1
    priority 255             
    version 3
    advert_int 1
    nopreempt

    unicast_src_ip 192.168.0.3
    unicast_peer {
    192.168.0.4
    }

    virtual_ipaddress {
        192.168.0.5/29         
  }
}

Проблемы, которые у меня есть с этой настройкой до сих пор:

1. На мастере принудительно сбил eth1 (внутренний интерфейс). Впоследствии это вызвало аварийное переключение поддержки активности, и состояние перешло в состояние отказа. Не совсем то поведение, которого я ожидал, потому что я думал, что идея состоит в том, чтобы он "использовал" внешний eth0 в этом случае для связи (который все еще работает и работает с внешним VRRP), так что это обеспечит отказоустойчивость. Возможно ли, что, когда eth1 обнаружен как неработающий, аварийное переключение НЕ запускается, а вместо этого ждать выхода eth1 из строя, чтобы он переключился?

2. Я получил предупреждение, что мой track_script check_nginxне используется. Использованиеtrack_scripts все еще не разрешено в vrrp_sync_group? Потому что мне все еще нужно, чтобы это работало в случае отказа NGINX.

3. Могу ли я использовать вытеснение внутри vrrc_sync_group? Потому что я хотел бы предотвратить отказ, когда он переместится.

4. Есть ли лучший способ сделать это? Я хочу добиться: а. Убедитесь, что трафик VRRP используется на внутреннем (выделенном) интерфейсе.eth1 и плавающий IP-адрес VRRP для размещения на eth0. Это значит, что нам не нужно зависеть от внешней сети для проверки пульса. б. В случае сбоя eth0 НЕ переключайтесь на узел BACKUP, если eth1 все еще жив. Только отработка отказа, если он тоже не работает (как и должно).
   c. Еслиcheck_nginxоднако сбой, это вызовет аварийное переключение. d. После сбоя он не вернется - если только с ним не случатся те же сценарии сбоя (например, отключение NGINX)

Хотите знать, возможно ли то, чего я пытаюсь достичь?

Спасибо J