☰

Lastenausgleich für mehrere Internetverbindungen unter Linux mit Fehlerbehandlung

tag-icon • tag-icon linux networking gentoo routing
Lastenausgleich für mehrere Internetverbindungen unter Linux mit Fehlerbehandlung

Ich habe zwei ISP-Verbindungen und brauche einen automatischen Lastausgleich zwischen ihnen. Ich muss auch fehlgeschlagene Verbindungen verarbeiten (nicht eine verwenden, die nicht funktioniert).

Die erste Verbindung ist eine PPTP-Verbindung ( ppp0), die zweite ist normales Ethernet. Das System ist Gentoo Linux.

Momentan habe ich mit eine grundlegende Balance erreicht ip route, aber es sieht so aus, als ob es nicht sehr gut funktioniert. Folgendes habe ich verwendet:

ip rule $ADD from $IP1 table rt_link1
ip rule $ADD fwmark 1 lookup rt_link1
ip rule $ADD from $IP2 table rt_link2
ip rule $ADD fwmark 2 lookup rt_link2
$NET2 dev eth2 src $IP2 table rt_link2
default via GW2 table rt_link2
$NET2 dev eth2 src $IP2
$NET1 dev ppp0 src $IP1 table rt_link1
default via GW1 table rt_link1
$NET1 dev ppp0 src $IP1
default scope global nexthop via $GW1 weight 1 nexthop via $GW2 dev eth2 weight 1

Antwort1

Als ehemaliges Mitglied des Kernteams des LVS-Projekts rate ich dringend davon ab, diese Technologie zum Ausgleichen mehrerer Internetverbindungen zu verwenden. Tatsächlich kann ich Ihnen fast garantieren, dass sie nicht wie erwartet funktionieren wird.

Die Behandlung ausgefallener Providerverbindungen wird heute häufig als Dead Gateway Detection (DGD) und manchmal als Neighbor Unreachability Detection (NUD) bezeichnet. Laut RFC816 und RFC1122 gibt es mehrere Möglichkeiten, DGD durchzuführen, allerdings habe ich nur etwa drei davon in freier Wildbahn gesehen (von einemalter Beitrag von mirzur LVS-Mailingliste):

  • Link-Layer-Informationen, die Host-Fehler zuverlässig erkennen und melden (z. B. ARPANET-Destination-Dead-Meldungen), sollten als negativer Hinweis verwendet werden.
  • Eine ICMP-Umleitungsnachricht von einem bestimmten Gateway sollte als positiver Hinweis zu diesem Gateway verwendet werden.
  • Pakete, die von einer bestimmten Link-Layer-Adresse ankommen, sind ein Beweis dafür, dass das System an dieser Adresse aktiv ist. Um diese Informationen jedoch in Gateway-Informationen umzuwandeln, muss die Link-Layer-Adresse einer IP-Adresse zugeordnet und diese IP-Adresse dann mit den Gateways verglichen werden, auf die der Routen-Cache verweist. Dies ist wahrscheinlich zu ineffizient.

Als ich 2006 die aktive Linux-Kernel-Netzwerkentwicklung aufgab, gab es noch keine endgültige Entscheidung darüber, wie NUD-Statusänderungen implementiert werden sollten. Ein Freund von mir und Kernentwickler von LVS, Julian Anastasov, musste diese Herausforderung bereits 2002 lösen. Also setzte er sich eines Abends hin und schrieb eine funktionierende Version des DGD für statisches Routing, indem er den NUD-Status zur FIB (Forward Information Base) hinzufügte. Seinen Patch finden SieHierund die DokumentationHier,HierUndHier. Dies sollte Ihnen viele Informationen für Ihre weitere Suche bei der Bewältigung dieser nicht trivialen Aufgabe geben. Ich sehe, dass die Patches immer noch weit verbreitet sind und daher mit den neuesten Kerneln auf dem neuesten Stand gehalten werden. Sie können mit einem Skript wie dem folgenden beginnen (geschrieben vonRobert Kurjata):

#!/bin/bash
# This script is done by : Robert Kurjata Sep, 2003.
# feel free to use it in any useful way

# CONFIGURATION
IP=/sbin/ip
PING=/bin/ping

#--------------- LINK PART -----------------
# EXTIFn - interface name
# EXTIPn - outgoing IP
# EXTMn  - netmask length (bits)
# EXTGWn - outgoing gateway
#-------------------------------------------

# LINK 1
EXTIF1=eth2
EXTIP1=
EXTM1=
EXTGW1=

# LINK 2
EXTIF2=eth1
EXTIP2=
EXTM2=
EXTGW2=

#ROUTING PART
# removing old rules and routes

echo "removing old rules"
${IP} rule del prio 50 table main
${IP} rule del prio 201 from ${EXTIP1}/${EXTM1} table 201
${IP} rule del prio 202 from ${EXTIP2}/${EXTM2} table 202
${IP} rule del prio 221 table 221
echo "flushing tables"
${IP} route flush table 201
${IP} route flush table 202
${IP} route flush table 221
echo "removing tables"
${IP} route del table 201
${IP} route del table 202
${IP} route del table 221

# setting new rules
echo "Setting new routing rules"

# main table w/o default gateway here
${IP} rule add prio 50 table main
${IP} route del default table main

# identified routes here
${IP} rule add prio 201 from ${EXTIP1}/${EXTM1} table 201
${IP} rule add prio 202 from ${EXTIP2}/${EXTM2} table 202

${IP} route add default via ${EXTGW1} dev ${EXTIF1} src ${EXTIP1} proto static table 201
${IP} route append prohibit default table 201 metric 1 proto static

${IP} route add default via ${EXTGW2} dev ${EXTIF2} src ${EXTIP2} proto static table 202
${IP} route append prohibit default table 202 metric 1 proto static

# mutipath
${IP} rule add prio 221 table 221

${IP} route add default table 221 proto static \
            nexthop via ${EXTGW1} dev ${EXTIF1} weight 2\
            nexthop via ${EXTGW2} dev ${EXTIF2} weight 3

${IP} route flush cache

while : ; do
  ${PING} -c 1 ${EXTGW1}
  ${PING} -c 1 ${EXTGW2}
  sleep 60
done

Darüber hinaus können Sie die Option zum Ausführen dynamischer Routing-Protokolle prüfen.

Antwort2

Verwenden Sie LVS in Verbindung mit lvs-kiss. Oder etwas Ähnlichem.

LVS ist im Grunde der ìpvsadmBefehl. Der einzige Nachteil dieses Load Balancers ist, dass er keine Überwachung durchführt. Sie benötigen also ein Programm, das dies für Sie übernimmt und den toten Link aus Ihrer Konfiguration entfernt (und ihn wieder hinzufügt, wenn er aktiv ist).

ldirectordaus dem Heartbeat-Stack könnte eine weitere LVS-Ergänzung sein (anstelle von LVS-Kiss).

verwandte Informationen