So beheben Sie die Zustandsprüfung des Netzwerk-Load-Balancers auf der sekundären Netzwerkschnittstelle

Haben Sie einen Netzwerk-Load-Balancer für Ihre sekundären Netzwerkschnittstellen konfiguriert? Haben Sie Probleme, die Gesundheitsprüfungen zum Laufen zu bringen, selbst nachdem Sie die abhörenden IPs und Ports sowie die Firewall-Regeln überprüft haben?

Die Antworten auf Ihre Gesundheitstests werden höchstwahrscheinlich über die primäre Schnittstelle zurückgegeben, wodurch die Pakete verloren gehen und/oder verworfen werden. Nutzen Sie diesen Blog, um das Problem zu überprüfen und zu beheben.

Wie Passthrough Network Load Balancers funktionieren

Ein Passthrough Network Load Balancer leitet Verbindungen von Clients direkt und ohne Unterbrechung an die gesunden Backends weiter. Um den Datenverkehr mit Lastausgleich zu akzeptieren, konfiguriert Google Cloud jede Backend-VM mit der IP-Adresse des Load Balancers über eine lokale Route:

laurensknoll@squid-proxy-c837:~$ ip route get 10.0.1.2
local 10.0.1.2 dev lo table local src 10.0.1.2 uid 1001 
    cache <local> 

Das Problem aufspüren

Erkennen Sie eingehende Load Balancer Health Checks mit tcpdump:

laurensknoll@squid-proxy-c837:~$ sudo tcpdump host 10.0.1.2 -i any
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
13:21:33.030400 ens5  In  IP 235-0-211-130.1e100.net.59030 > 10.0.1.2.3128: Flags [S], seq 1186327794, win 65535, options [mss 1420,sackOK,TS val 3126546969 ecr 0,nop,wscale 8], length 0
13:21:33.030441 ens4  Out IP 10.0.1.2.3128 > 235-0-211-130.1e100.net.59030: Flags [S.], seq 3824338898, ack 1186327795, win 64768, options [mss 1420,sackOK,TS val 2826694419 ecr 3126546969,nop,wscale 7], length 0
13:21:33.283290 ens4  Out IP 10.0.1.2.3128 > 235-0-211-130.1e100.net.56104: Flags [S.], seq 63151303, ack 507892428, win 64768, options [mss 1420,sackOK,TS val 2826694672 ecr 3126536969,nop,wscale 7], length 0
13:21:33.355735 ens5  In  IP 245-0-211-130.1e100.net.40674 > 10.0.1.2.3128: Flags [S], seq 2840299953, win 65535, options [mss 1420,sackOK,TS val 3570372660 ecr 0,nop,wscale 8], length 0
13:21:33.355790 ens4  Out IP 10.0.1.2.3128 > 245-0-211-130.1e100.net.40674: Flags [S.], seq 3518750145, ack 2840299954, win 64768, options [mss 1420,sackOK,TS val 930125414 ecr 3570372660,nop,wscale 7], length 0
13:21:33.539284 ens4  Out IP 10.0.1.2.3128 > 245-0-211-130.1e100.net.34284: Flags [S.], seq 1263115617, ack 440200841, win 64768, options [mss 1420,sackOK,TS val 930125598 ecr 3570362659,nop,wscale 7], length 0
13:21:33.860639 ens5  In  IP 247-0-211-130.1e100.net.54780 > 10.0.1.2.3128: Flags [S], seq 2976663686, win 65535, options [mss 1420,sackOK,TS val 3399067719 ecr 0,nop,wscale 8], length 0
13:21:33.860680 ens4  Out IP 10.0.1.2.3128 > 247-0-211-130.1e100.net.54780: Flags [S.], seq 2634616183, ack 2976663687, win 64768, options [mss 1420,sackOK,TS val 921309107 ecr 3399067719,nop,wscale 7], length 0
...

Die Ausgabe tcpdump zeigt eingehende Gesundheitsprüfungen (130.211.0.0/22) auf der sekundären Schnittstelle: ens5 In. Die Antworten werden jedoch über die primäre Schnittstelle gesendet: . Da die Gesundheitsprüfung keine Verbindung zu dieser Schnittstelle herstellen konnte, wird das Paket nicht ordnungsgemäß zurückgesendet, was den Zustand Unhealthy verursacht:

Sie sehen keinen Rückverkehr? Wahrscheinlich lässt der Reverse Path Filter die Pakete fallen. Prüfen Sie, ob sich der netstat -s | grep IPReversePathFilter-Zähler erhöht.

Lenken des lastverteilten Datenverkehrs

Eine benutzerdefinierte Routentabelle und Routing-Richtlinie wird so konfiguriert, dass der Datenverkehr mit Lastausgleich über die sekundäre Netzwerkschnittstelle weitergeleitet wird:

• Routentabelle mit sekundärer Schnittstelle als Standardgateway hinzufügen

Geben Sie die Gateway-Adresse der sekundären Schnittstelle an:

laurensknoll@squid-proxy-c837:~$ ip route | grep 'dev ens5'
..
10.0.1.1 dev ens5 scope link 
10.0.1.1 dev ens5 proto dhcp scope link src 10.0.1.4 metric 100 
..

Erstellen Sie die Routentabelle nlb, die die sekundäre Schnittstelle als Standardgateway verwendet:

laurensknoll@squid-proxy-c837:~$ echo "10 nlb" | sudo tee -a /etc/iproute2/rt_tables
laurensknoll@squid-proxy-c837:~$ sudo ip route add default via 10.0.1.1 dev ens5 table nlb

• Konfigurieren Sie die Routing-Richtlinie für lastverteilten Verkehr

Weisen Sie den Kernel an, Pakete mit der Load Balancer-Quelladresse an die nlb Routentabelle weiterzuleiten:

laurensknoll@squid-proxy-c837:~$ sudo ip rule add from 10.0.1.2 table nlb

• Validierung der Weiterleitung des Health Check-Verkehrs

Überprüfen Sie, ob der Kernel den lastverteilten Datenverkehr zum sekundären Schnittstellen-Gateway leitet:

laurensknoll@squid-proxy-c837:~$ ip route get from 10.0.1.2 to 130.211.0.0
130.211.0.0 from 10.0.1.2 via 10.0.1.1 dev ens5 table nlb uid 1001 
    cache

Bild von Reto Scheiwiller aus Pixabay