Попытка использовать keepalived для отработки отказа и переадресации, но получаю сообщение «Keepalived_healthcheckers[1706]: сбой привязки TCP-сокета. Перепланирование».

Цель состоит в том, чтобы получить две разные виртуальные машины CentOS 7 с установленным keepalived для выполнения аварийного переключения с помощью VIP 192.168.1.11, а также перенаправить трафик http (который вскоре после этого станет https) на соответствующий http-сервер.

192.168.1.11 vm1 (ГЛАВНЫЙ) --> переадресация http на 192.168.1.71
192.168.1.11 vm2 (РЕЗЕРВНАЯ КОПИЯ) --> переадресация http на 192.168.1.72

У меня была часть аварийного переключения (с поддержкой активности), которая ранее работала, но вместо этого haproxy (на каждой виртуальной машине) обрабатывал переадресацию. Теперь, когда я пытаюсь получить поддержку активности для переадресации (или в этом случае режим, который я пытаюсь использовать, это прямая маршрутизация, я полагаю), я получаю ошибки привязки сокета в выводе состояния, и аварийное переключение не работает.

Вот файл keepalived.conf vm1:

global_defs { 
    root_user_script 
} 

vrrp_instance VIP01 {
    состояние МАСТЕР 
    интерфейс eth0
    виртуальный_роутер_id 101
    приоритет 101
    advert_int 1

    аутентификация {
         auth_type ПАРОЛЬ
         auth_pass [фрагмент]
    }

    виртуальный_ipaddress {
        192.168.1.11/24
    }
}
    виртуальный_сервер 192.168.1.11 8080 {
        delay_loop 10
        протокол TCP
        lb_algo rr
        lb_kind DR
        persistence_timeout 7200

        реальный_сервер 192.168.1.71 8080 {
           вес 1
           TCP_CHECK {
            connect_timeout 5
            connect_port 8080
           }
        }
    }

и вм2:

global_defs { 
    root_user_script 
} 

vrrp_instance VIP01 {
    резервная копия состояния     
    интерфейс eth0
    виртуальный_роутер_id 101    
    приоритет 100   
    advert_int 1

    аутентификация {
         auth_type ПАРОЛЬ
         auth_pass [фрагмент]
    }

    виртуальный_ipaddress {
        192.168.1.11/24   
        }
}

виртуальный_сервер 192.168.1.11 80 {
    delay_loop 10
    протокол TCP
    lb_algo rr
    lb_kind DR
    persistence_timeout 7200

    реальный_сервер 192.168.1.72 8080 {
        вес 1
        TCP_CHECK {
          connect_timeout 5
          connect_port 8080
        }
    }
}

выход из статус systemctl (на обеих ВМС):

...
20 июля, 07:52:16 [имя хоста] Keepalived_healthcheckers[1738]: сбой привязки TCP-сокета. Перепланировка.
20 июля, 07:52:26 [имя хоста] Keepalived_healthcheckers[1738]: сбой привязки TCP-сокета. Перепланировка.
20 июля, 07:52:36 [имя хоста] Keepalived_healthcheckers[1738]: сбой привязки TCP-сокета. Перепланировка.

Я также попытался добавить следующее в /etc/sysctl.conf:

net.ipv4.ip_forward = 1
net.ipv4.ip_nonlocal_bind = 1

и подтвердили, что они взяли, запросив их после перезагрузки.

Я понимаю, что использование балансировки нагрузки с циклическим перебором с одним сервером в списке на самом деле не является балансировкой нагрузки, но я просто рассматривал это как способ переадресации, если есть более лаконичный/лучший способ сделать это, я заинтересован.

правки:

если я закомментирую проверку TCP, похоже, что ошибка привязки сообщений исчезнет. Я проверил IP/порт назначения, перейдя к http://192.168.1.71:8080 в браузере, и он работает как положено, однако не работает через VIP .11. Похоже, в любом случае это должна быть проверка HTTP_GET.

Я могу свернуть страницу из завиток http://192.168.1.71:8080 из строки cmd vm1, поэтому я знаю, что у него есть доступ к http-серверу .71.

Переход в браузере к http://192.168.1.11:8080 по-прежнему приводит к тайм-ауту. статус не показывает никаких признаков проблемы, мы собираемся изучить более подробный вариант журнала...

Здесь я собрал большую часть того, что у меня есть...

Согласно с это (нижняя страница 6) скорее всего, keepalived удаляет реальный сервер из списка. Похоже, что может быть что-то, препятствующее тому, чтобы служба поддержки активности могла поразить реальный сервер с проверкой TCP или получением HTTP. может политика selinux?

/var/log/аудит/audit.log был полон keepalived целых...

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

также пытался использовать аудит2разрешить чтобы сгенерировать правила, а затем применить их, и хотя журнал аудита, похоже, перестал регистрировать отказные сообщения, переадресация с 11 на 71 все еще не работает.

до сих пор не вижу ничего, что указывало бы на ошибки:

20 июля, 12:46:59 [имя хоста] Keepalived[1951]: запуск Keepalived v1.3.5 (19 марта 2017 г.), git commit v1.3.5-6-g6fa32f2
20 июля, 12:46:59 [имя хоста] Keepalived[1951]: открытие файла '/etc/keepalived/keepalived.conf'.
20 июля, 12:46:59 [имя хоста] Keepalived [1952]: запуск дочернего процесса Healthcheck, pid = 1953
20 июля, 12:46:59 [имя хоста] Keepalived[1952]: запуск дочернего процесса VRRP, pid=1954
20 июля, 12:46:59 [имя хоста] Keepalived_healthcheckers[1953]: открытие файла '/etc/keepalived/keepalived.conf'.
20 июля, 12:46:59 [имя хоста] Keepalived_healthcheckers[1953]: Активация проверки работоспособности для службы [192.168.1.11]:8080
20 июля, 12:46:59 [имя хоста] systemd: запущен монитор высокой доступности LVS и VRRP.
20 июля, 12:46:59 [имя хоста] Keepalived_vrrp [1954]: регистрация отражателя сетевой ссылки ядра
20 июля, 12:46:59 [имя хоста] Keepalived_vrrp [1954]: регистрация командного канала сетевой ссылки ядра
20 июля, 12:46:59 [имя хоста] Keepalived_vrrp[1954]: Регистрация бесплатного общего канала ARP
20 июля, 12:46:59 [имя хоста] Keepalived_vrrp[1954]: открытие файла '/etc/keepalived/keepalived.conf'.
20 июля, 12:46:59 [имя хоста] Keepalived_vrrp[1954]: усечение auth_pass до 8 символов
20 июля, 12:46:59 [имя хоста] Keepalived_vrrp[1954]: VRRP_Instance(VIP01) удаляет виртуальные IP-адреса протокола.
20 июля, 12:46:59 [имя хоста] Keepalived_vrrp[1954]: использование отражателя сетевых ссылок ядра LinkWatch...
20 июля, 12:46:59 [имя хоста] Keepalived_vrrp[1954]: пул VRRP: [ifindex(2), proto(112), unicast(0), fd(10,11)]
20 июля, 12:47:00 [имя хоста] Keepalived_vrrp[1954]: VRRP_Instance(VIP01) Переход в ГЛАВНОЕ СОСТОЯНИЕ
20 июля, 12:47:01 [имя хоста] Keepalived_vrrp [1954]: VRRP_Instance (VIP01) входит в ГЛАВНОЕ СОСТОЯНИЕ
20 июля 12:47:01 [имя хоста] Keepalived_vrrp[1954]: VRRP_Instance(VIP01) настройка протоколов VIP.
20 июля, 12:47:01 [имя хоста] Keepalived_vrrp[1954]: Отправка безвозмездного ARP на eth0 для 192.168.1.11
20 июля, 12:47:01 [имя хоста] Keepalived_vrrp[1954]: VRRP_Instance(VIP01) Отправка/постановка в очередь необоснованных ARP на eth0 для 192.168.1.11
20 июля, 12:47:01 [имя хоста] Keepalived_vrrp[1954]: Отправка безвозмездного ARP на eth0 для 192.168.1.11
20 июля, 12:47:01 [имя хоста] Keepalived_vrrp[1954]: Отправка безвозмездного ARP на eth0 для 192.168.1.11
20 июля, 12:47:01 [имя хоста] Keepalived_vrrp[1954]: Отправка безвозмездного ARP на eth0 для 192.168.1.11
20 июля, 12:47:01 [имя хоста] Keepalived_vrrp[1954]: Отправка безвозмездного ARP на eth0 для 192.168.1.11
20 июля, 12:47:06 [имя хоста] Keepalived_vrrp[1954]: Отправка безвозмездного ARP на eth0 для 192.168.1.11
20 июля, 12:47:06 [имя хоста] Keepalived_vrrp[1954]: VRRP_Instance(VIP01) Отправка/постановка в очередь необоснованных ARP на eth0 для 192.168.1.11
20 июля, 12:47:06 [имя хоста] Keepalived_vrrp[1954]: Отправка безвозмездного ARP на eth0 для 192.168.1.11
20 июля, 12:47:06 [имя хоста] Keepalived_vrrp[1954]: Отправка безвозмездного ARP на eth0 для 192.168.1.11
20 июля, 12:47:06 [имя хоста] Keepalived_vrrp[1954]: Отправка безвозмездного ARP на eth0 для 192.168.1.11
20 июля, 12:47:06 [имя хоста] Keepalived_vrrp[1954]: Отправка безвозмездного ARP на eth0 для 192.168.1.11

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

проверка связи 192.168.1.11 и извлечение сетевого подключения к vm1 приводит к аварийному переключению, как и ожидалось. так что проблема действительно в настройке моего виртуального/реального сервера...