☰

Keepalived + LVS funktionieren nicht von anderen Hosts, aber vom lokalen Host auf LB

tag-icon • tag-icon linux lvs keepalived
Keepalived + LVS funktionieren nicht von anderen Hosts, aber vom lokalen Host auf LB

Ich habe ein Keepalived + LVS eingerichtet, das ich zum Laufen bringen möchte

Clients, LB und reale Server befinden sich alle im selben Subnetz.

Keepalived-Konfiguration:

global_defs {
    notification_email {
        [email protected]
    }
    notification_email_from [email protected]
    smtp_server 127.0.0.1
    smtp_connect_timeout 30
    router_id ukld5p500x
}

vrrp_instance some_service {
    state             MASTER
    interface         em1
    virtual_router_id 100
    priority          100
    virtual_ipaddress {
        10.0.0.75
    }

    track_script {
        chk_fail
    }
}

virtual_server 10.0.0.75 58563 {
    delay_loop      10
    lb_algo     rr
    lb_kind     DR

    protocol        TCP

    real_server 10.0.0.70 58563 {
        weight          1
        TCP_CHECK {
            connect_timeout 3   
            connect_port    58563
        }
    }

    ... more real_servers ...

}

Wenn ich also lb_type auf nat setze, kann ich mich vom LB selbst mit dem VIP/Port verbinden und alles geht durch, aber nicht von einem externen Host (Client). Wenn ich lb_type auf DR setze, kann weder der LB, der sich mit sich selbst verbindet, noch ein externer Client eine Verbindung herstellen.

sys.net.ipv4.ip_forward ist auf 1 gesetzt und es ist derzeit nur ein LB konfiguriert.

Antwort1

Ich weiß nicht, ob Sie darauf schon eine Antwort bekommen haben, da es schon so alt ist, aber DR (Direct Routing) ist ganz anders als NAT. NAT lässt den Load Balancer (LB) wie einen Router agieren, indem er das Paket an den realen Server weiterleitet, und der reale Server gibt es wieder an den LB zurück, um es an den Client zurückzusenden.

Bei DR ist der LB nur ein Pseudo-Mittelsmann. Wenn ein Paket auf dem VIP des LB eintrifft, entscheidet dieser, an welchen RS (realen Server) es gesendet wird, undschreibt umden Paketheader durch Ändern der MAC-Adresse. Anschließend leitet er das Paket an den Switch zurück, und der Switch liefert es mit der passenden MAC-Adresse an den RS.

Sie müssen dann Ihren RS dazu bringen, ein für seine Schnittstelle bestimmtes Paket anzunehmen. Normalerweise tun Sie das, indem Sie den VIP zu einem Loopback-Adapter hinzufügen und ihm die Netzmaske 255.255.255.255 geben. Ihr Service-Daemon muss auch so konfiguriert werden, dass er auf diesem VIP lauscht (in Apache fügen Sie einfach eine zusätzliche Zeile Listen xxxx:80 hinzu).

Um das Ganze abzurunden, müssen Sie sich mit dem ARP-Problem auseinandersetzen. Normalerweise führt das Hinzufügen

net.ipv4.conf.eth0.arp_announce = 2
net.ipv4.conf.eth0.arp_ignore = 1

zu Ihrer sysctl.conf wird sich darum kümmern

verwandte Informationen