Încercarea de a utiliza keepalived pentru failover și redirecționare, dar obținerea „Keepalived_healthcheckers[1706]: legarea socketului TCP a eșuat. Reprogramare”.

Scopul este de a obține două VM CentOS 7 diferite cu keepalived instalat pentru a efectua failover-ul cu VIP 192.168.1.11 și, de asemenea, să redirecționeze traficul http (pentru a deveni https la scurt timp după ce funcționează) către un server http corespunzător.

192.168.1.11 vm1 (MASTER) --> fwd http la 192.168.1.71
192.168.1.11 vm2 (BACKUP) --> fwd http la 192.168.1.72

Partea de failover a acesteia (cu keepalived) funcționează anterior, dar cu haproxy (pe fiecare vm) care gestionează redirecționarea. Acum că încerc să mă asigur de redirecționare (sau, în acest caz, modul pe care încerc să îl folosesc este rutarea directă, cred), primesc erori de legare la socket în ieșirea de stare și failover-ul nu funcționează.

Iată vm1 keepalived.conf:

global_defs { 
    rădăcină script_user 
} 

vrrp_instance VIP01 {
    stat MAESTRU 
    interfata eth0
    virtual_router_id 101
    prioritatea 101
    advert_int 1

    autentificare {
         auth_type PASS
         auth_pass [snip]
    }

    adresa_virtuală {
        192.168.1.11/24
    }
}
    virtual_server 192.168.1.11 8080 {
        bucla_întârziere 10
        protocolul TCP
        lb_algo rr
        lb_kind DR
        persistence_timeout 7200

        real_server 192.168.1.71 8080 {
           greutate 1
           TCP_CHECK {
            connect_timeout 5
            connect_port 8080
           }
        }
    }

și vm2:

global_defs { 
    rădăcină script_user 
} 

vrrp_instance VIP01 {
    stare BACKUP     
    interfata eth0
    virtual_router_id 101    
    prioritate 100   
    advert_int 1

    autentificare {
         auth_type PASS
         auth_pass [snip]
    }

    adresa_virtuală {
        192.168.1.11/24   
        }
}

virtual_server 192.168.1.11 80 {
    bucla_întârziere 10
    protocolul TCP
    lb_algo rr
    lb_kind DR
    persistence_timeout 7200

    real_server 192.168.1.72 8080 {
        greutate 1
        TCP_CHECK {
          connect_timeout 5
          connect_port 8080
        }
    }
}

ieșirea de la starea systemctl păstrată (pe ambele vms):

...
20 iulie 07:52:16 [nume gazdă] Keepalived_healthcheckers[1738]: legarea socketului TCP a eșuat. Reprogramare.
20 iulie 07:52:26 [nume gazdă] Keepalived_healthcheckers[1738]: legarea socketului TCP a eșuat. Reprogramare.
20 iulie 07:52:36 [nume gazdă] Keepalived_healthcheckers[1738]: legarea socketului TCP a eșuat. Reprogramare.

Am încercat să adaug următoarele la /etc/sysctl.conf:

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

și au confirmat că au luat-o interogând după repornire.

Îmi dau seama că utilizarea echilibrării încărcăturii cu round robin cu un server din listă nu este cu adevărat echilibrarea încărcăturii, dar am văzut-o doar ca o modalitate de a face redirecționarea, dacă există o modalitate mai concisă/mai bună de a face acest lucru, sunt interesat.

editii:

dacă comentez verificarea TCP, se pare că eșecul de a lega mesajele dispare. Am verificat IP-ul/portul de destinație navigând la http://192.168.1.71:8080 în browser și funcționează conform așteptărilor, totuși nu funcționează trecând prin VIP .11. Se pare că ar trebui să fie o verificare HTTP_GET oricum.

Pot curba pagina din curl http://192.168.1.71:8080 din linia cmd a vm1, așa că știu că are acces la serverul http .71.

Navigarea într-un browser către http://192.168.1.11:8080 duce totuși la un timeout. starea nu prezintă semne de problemă, vom căuta o opțiune de jurnal mai detaliată...

Aici am luat cea mai mare parte din ceea ce am...

Conform aceasta (pagina de jos 6) șansele sunt keepalived este eliminarea serverului real din listă. Se pare că poate exista ceva care să împiedice serviciul keepalived să poată atinge serverul real cu verificarea TCP sau HTTP get. poate politica selinux?

/var/log/audit/audit.log a fost plin de întregi păstrate...

găsite acest și am încercat să setez permisiunea de conectare a oricărui boolean care nu mi-a schimbat rezultatele.

am incercat si eu sa folosesc audit2allow pentru a genera reguli și apoi a le aplica și deși jurnalul de audit pare să fi oprit înregistrarea mesajelor refuzate, redirecționarea de la 11 la 71 încă nu funcționează.

încă nu văd nimic care să indice erori:

20 iulie 12:46:59 [nume gazdă] Keepalived[1951]: Pornește Keepalived v1.3.5 (19/03/2017), git commit v1.3.5-6-g6fa32f2
20 iulie 12:46:59 [nume gazdă] Keepalived[1951]: Deschiderea fișierului „/etc/keepalived/keepalived.conf”.
20 iulie 12:46:59 [nume gazdă] Keepalived[1952]: pornirea procesului copil Healthcheck, pid=1953
20 iulie 12:46:59 [nume gazdă] Keepalived[1952]: pornirea procesului copil VRRP, pid=1954
20 iulie 12:46:59 [nume gazdă] Keepalived_healthcheckers[1953]: Deschiderea fișierului „/etc/keepalived/keepalived.conf”.
20 iulie 12:46:59 [nume gazdă] Keepalived_healthcheckers[1953]: Activarea verificatorului de sănătate pentru serviciu [192.168.1.11]:8080
20 iulie 12:46:59 [hostname] systemd: S-a pornit LVS și VRRP High Availability Monitor.
20 iulie 12:46:59 [nume gazdă] Keepalived_vrrp[1954]: se înregistrează reflectorul netlink kernel
20 iulie 12:46:59 [nume gazdă] Keepalived_vrrp[1954]: Înregistrarea canalului de comandă netlink Kernel
20 iulie 12:46:59 [nume gazdă] Keepalived_vrrp[1954]: Înregistrarea canalului partajat ARP gratuit
20 iulie 12:46:59 [nume gazdă] Keepalived_vrrp[1954]: Deschiderea fișierului „/etc/keepalived/keepalived.conf”.
20 iulie 12:46:59 [nume gazdă] Keepalived_vrrp[1954]: trunchierea auth_pass la 8 caractere
20 iulie 12:46:59 [nume gazdă] Keepalived_vrrp[1954]: VRRP_Instance(VIP01) elimină VIP-urile de protocol.
20 iulie 12:46:59 [nume gazdă] Keepalived_vrrp[1954]: se utilizează reflectorul netlink al nucleului LinkWatch...
20 iulie 12:46:59 [nume gazdă] Keepalived_vrrp[1954]: VRRP sockpool: [ifindex(2), proto(112), unicast(0), fd(10,11)]
20 iulie 12:47:00 [nume gazdă] Keepalived_vrrp[1954]: VRRP_Instance(VIP01) Tranziție la MASTER STATE
20 iulie 12:47:01 [nume gazdă] Keepalived_vrrp[1954]: VRRP_Instance(VIP01) Se intră în MASTER STATE
20 iulie 12:47:01 [nume gazdă] Keepalived_vrrp[1954]: VRRP_Instance(VIP01) setarea protocolului VIP.
20 iulie 12:47:01 [nume gazdă] Keepalived_vrrp[1954]: se trimite ARP gratuit pe eth0 pentru 192.168.1.11
20 iulie 12:47:01 [nume gazdă] Keepalived_vrrp[1954]: VRRP_Instance(VIP01) Trimiterea/punerea în coadă ARP-uri gratuite pe eth0 pentru 192.168.1.11
20 iulie 12:47:01 [nume gazdă] Keepalived_vrrp[1954]: se trimite ARP gratuit pe eth0 pentru 192.168.1.11
20 iulie 12:47:01 [nume gazdă] Keepalived_vrrp[1954]: se trimite ARP gratuit pe eth0 pentru 192.168.1.11
20 iulie 12:47:01 [nume gazdă] Keepalived_vrrp[1954]: se trimite ARP gratuit pe eth0 pentru 192.168.1.11
20 iulie 12:47:01 [nume gazdă] Keepalived_vrrp[1954]: se trimite ARP gratuit pe eth0 pentru 192.168.1.11
20 iulie 12:47:06 [nume gazdă] Keepalived_vrrp[1954]: Se trimite ARP gratuit pe eth0 pentru 192.168.1.11
20 iulie 12:47:06 [nume gazdă] Keepalived_vrrp[1954]: VRRP_Instance(VIP01) Trimiterea/punerea în coadă ARP-uri gratuite pe eth0 pentru 192.168.1.11
20 iulie 12:47:06 [nume gazdă] Keepalived_vrrp[1954]: Se trimite ARP gratuit pe eth0 pentru 192.168.1.11
20 iulie 12:47:06 [nume gazdă] Keepalived_vrrp[1954]: Se trimite ARP gratuit pe eth0 pentru 192.168.1.11
20 iulie 12:47:06 [nume gazdă] Keepalived_vrrp[1954]: Se trimite ARP gratuit pe eth0 pentru 192.168.1.11
20 iulie 12:47:06 [nume gazdă] Keepalived_vrrp[1954]: Se trimite ARP gratuit pe eth0 pentru 192.168.1.11

De asemenea, merită menționat că anterior am dezactivat firewall-urile pentru a le exclude...

ping 192.168.1.11 și tragerea conexiunii de rețea la vm1 duce la failover, așa cum era de așteptat. deci problema este într-adevăr cu configurarea serverului meu virtual/real cumva...