Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

3.2. Load Balancer Add-On mit direktem Routing

Wie in Abschnitt 1.4.2, »Direktes Routing« erwähnt, ermöglicht das direkte Routing den realen Servern, Pakete zu verarbeiten und direkt an den anfragenden Benutzer zu leiten, statt ausgehende Pakete durch den LVS-Router leiten zu müssen. Direktes Routing erfordert, dass die realen Server physisch mit einem Netzwerksegment mit dem LVS-Router verbunden sind und ausgehende Pakete verarbeitet und weitergeleitet werden können.
Netzwerkaufbau
In einer Load Balancer Add-On Konfiguration mit direktem Routing muss der LVS-Router eingehende Anfragen empfangen und diese an die richtigen realen Server zur Verarbeitung weiterleiten. Die realen Server müssen ihre Antwort dann direkt an den Client senden. Falls sich der Client beispielsweise im Internet befindet und das Paket durch den LVS-Router an einen realen Server sendet, dann muss der reale Server dazu in der Lage sein, über das Internet direkt an den Client zu senden. Sie erreichen dies, indem Sie ein Gateway für den realen Server konfigurieren, das die Pakete an das Internet weiterleitet. Jeder reale Server im Server-Pool kann über ein eigenes Gateway verfügen (und jedes Gateway über eine eigene Verbindung zum Internet) für maximalen Durchsatz und optimale Skalierbarkeit. In typischen Load Balancer Add-On Konfigurationen können die realen Server jedoch über ein einziges Gateway und somit eine Netzwerkverbindung kommunizieren.

Wichtig

Es wird nicht empfohlen, den LVS-Router als Gateway für die realen Server zu verwenden, da dies die Konfiguration des LVS-Routers unnötig verkompliziert und diesem darüber hinaus weitere Netzwerklast aufbürdet, wodurch wie beim NAT-Routing wieder ein Engpass entsteht.
Hardware
Die Hardware-Anforderungen eines Load Balancer Add-On Systems mit direktem Routing ähneln denen anderer Load Balancer Add-On Topologien. Während auf dem LVS-Router Red Hat Enterprise Linux laufen muss, um die eingehenden Anfragen zu verarbeiten und die Lastverteilung für die realen Server durchzuführen, muss es sich bei den realen Servern nicht um Linux-Rechner handeln, um ordnungsgemäß zu funktionieren. Die LVS-Router benötigen jeweils eine oder zwei NICs (abhängig davon, ob es einen Backup-Router gibt). Sie können zwei NICs verwenden, um die Konfiguration zu vereinfachen und den Datenverkehr abzugrenzen – eingehende Anfragen werden von einer NIC gehandhabt und geroutete Pakete zu den realen Servern auf der anderen.
Da die realen Server den LVS-Router umgehen und ausgehende Pakete direkt an einen Client senden, ist ein Gateway zum Internet erforderlich. Für ein Höchstmaß an Leistung und Verfügbarkeit kann jeder reale Server mit einem eigenen Gateway verbunden werden, der über eine eigene Verbindung zu dem Netzwerk verfügt, auf dem sich der Client befindet (z. B. das Internet oder ein Intranet).
Software
Es gibt einige notwendige Konfigurationsschritte außerhalb des Piranha-Konfigurationstools, insbesondere für Administratoren, die beim Einsatz des Load Balancer Add-Ons mit direktem Routing auf ARP-Probleme stoßen. Siehe Abschnitt 3.2.1, »Direktes Routing und arptables_jf« oder Abschnitt 3.2.2, »Direktes Routing und iptables« für weitere Informationen.

3.2.1. Direktes Routing und arptables_jf

Um direktes Routing mithilfe von arptables_jf zu konfigurieren, muss auf jedem realen Server eine virtuelle IP-Adresse konfiguriert sein, damit diese Pakete direkt routen können. ARP-Anfragen für die VIP werden von den realen Servern völlig ignoriert und jegliche andere ARP-Pakete, die gegebenenfalls die VIPs enthalten, werden geändert, um die IP des realen Servers zu enthalten anstelle der VIPs.
Mithilfe von arptables_jf können Applikationen mit jeder einzelnen VIP oder jedem einzelnen Port verbinden, die vom realen Server bereitgestellt werden. Beispielsweise ermöglicht arptables_jf, dass mehrere laufende Instanzen von Apache HTTP Server explizit mit anderen VIPs auf dem System verknüpft werden. Es gibt zudem deutliche Leistungsvorteile bei der Verwendung von arptables_jf im Vergleich zur iptables-Option.
Allerdings ist es bei Verwendung von arptables_jf nicht möglich, mithilfe von standardmäßigen Red Hat Enterprise Linux Systemkonfigurationstools die VIPs zum Start beim Bootzeitpunkt zu konfigurieren.
Führen Sie die folgenden Schritte aus, um jeden realen Server zu konfigurieren, um ARP-Anfragen für jede virtuelle IP-Adresse zu ignorieren:
  1. Erstellen Sie die ARP-Tabelleneinträge für jede virtuelle IP-Adresse auf jedem realen Server (die real_ip ist die IP, die der Router zur Kommunikation mit dem realen Server verwendet, oft ist diese IP eth0 zugewiesen): 
    arptables -A IN -d <virtual_ip> -j DROP
arptables -A OUT -s <virtual_ip> -j mangle --mangle-ip-s <real_ip>
    Dies führt dazu, dass die realen Server alle ARP-Anfragen für die virtuellen IP-Adressen ignorieren, und ändert jegliche ausgehende ARP-Antworten, die andernfalls die virtuelle IP enthalten, auf die reale IP des Servers. Der einzige Knoten, der auf ARP-Anfragen für die VIPs reagieren sollte, ist der derzeit aktive LVS-Knoten.
  2. Sobald dies auf jedem realen Server fertiggestellt wurde, speichern Sie die ARP-Tabelleneinträge, indem Sie die folgenden Befehle auf jedem realen Server ausführen:
    service arptables_jf save
    chkconfig --level 2345 arptables_jf on
    Der chkconfig-Befehl führt dazu, dass das System die arptables-Konfiguration beim Systemstart – noch vor dem Start des Netzwerks – neu lädt.
  3. Konfigurieren Sie die virtuelle IP-Adresse auf allen realen Servern mithilfe von ifconfig, um ein IP-Alias zu erstellen. Zum Beispiel: 
    # ifconfig eth0:1 192.168.76.24 netmask 255.255.252.0 broadcast 192.168.79.255 up
    Sie können auch das iproute2-Dienstprogramm ip verwenden, zum Beispiel: 
    # ip addr add 192.168.76.24 dev eth0
    Wie bereits erwähnt, können die virtuellen IP-Adressen nicht mithilfe der Red Hat Systemkonfigurationstools zum Starten beim Systemstart konfiguriert werden. Sie können dieses Problem jedoch umgehen, indem Sie diese Befehle in die Datei /etc/rc.d/rc.local einfügen.
  4. Konfigurieren Sie Piranha für das direkte Routing. Siehe Kapitel 4, Konfigurieren des Load Balancer Add-Ons mit dem Piranha-Konfigurationstool für weitere Informationen.