Menu Close

Red Hat Training

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

3.2. LVS via direktem Routing

As mentioned in Abschnitt 1.4.2, »Direktes Routing«, direct routing allows real servers to process and route packets directly to a requesting user rather than passing outgoing packets through the LVS router. Direct routing requires that the real servers be physically connected to a network segment with the LVS router and be able to process and direct outgoing packets as well.
Netzwerk-Layout
In einer Einstellung mit direktem Routing, muss der LVS-Router eingehende Anfragen erhalten können und sie an den entsprechenden realen Server zur Weiterverarbeitung routen. Die realen Server müssen dann die Antwort direkt an den Client routen. Wenn sich ein Client somit beispielsweise im Internet befindet, und die Pakete via LVS-Router an den realen Server schickt, muss der reale Server in der Lage sein, den Client direkt via Internet ansprechen zu können. Dies erreicht man, indem man ein Gateway für den realen Server einrichtet, das die Pakete an das Internet weitergibt. Jeder reale Server im Server-Pool kann sein eigenes separates Gateway (und jedes Gateway seine eigene Internetverbindung) besitzen, was einen maximalen Durchsatz und eine maximale Skalierbarkeit ermöglicht. In typischen LVS-Einrichtungen können die realen Server jedoch via einem Gateway kommunizieren (und somit auch nur einer Netzwerkverbindung).

Wichtig

Es wird nicht empfohlen, den LVS-Router als ein Gateway für die realen Server zu verwenden, da dies zum einen die Komplexität der Einrichtung erhöht und zum anderen zu mehr Netzwerkauslastung auf dem LVS-Router führt, was wiederum den Engpass im Netzwerk darstellt, der auch beim NAT-Routing existiert.
Hardware
Die Hardware-Anforderungen eines LVS-Systems, das direktes Routing verwendet, ähneln den Anforderungen anderer LVS-Topologien. Während auf dem LVS-Router Red Hat Enterprise Linux laufen muss, um die eingehenden Anfragen zu verarbeiten und Lastverteilung für die realen Server durchzuführen, müssen die realen Server keine Linux-Maschinen sein, um ordnungsgemäß zu funktionieren. Die LVS-Router brauchen jeweils eine oder zwei NICs (abhängig davon, ob es einen Backup-Router gibt). Zur Erleichterung der Konfiguration und um den Datenverkehr deutlich zu unterscheiden, können Sie zwei NICs verwenden — eingehende Anfragen werden von einer NIC gehandhabt, sowie geroutete Pakete zu realen Servern auf der anderen.
Da die realen Server den LVS-Router übergehen und ausgehende Pakete direkt an einen Client versenden, wird ein Gateway zum Internet benötigt. Für die maximale Leistung und Verfügbarkeit kann jeder reale Server mit seinem eigenen Gateway verbunden sein, welches wiederum seine eigene, dedizierte Verbindung mit dem Trägernetzwerk besitzt, mit dem der Client verbunden ist (wie das Internet oder das Intranet).
Software
There is some configuration outside of Piranha Configuration Tool that needs to be done, especially for administrators facing ARP issues when using LVS via direct routing. Refer to Abschnitt 3.2.1, »Direktes Routing und arptables_jf« or Abschnitt 3.2.2, »Direktes Routing und iptables« for more information.

3.2.1. Direktes Routing und arptables_jf

In order to configure direct routing using arptables_jf, each real server must have their virtual IP address configured, so they can directly route packets. ARP requests for the VIP are ignored entirely by the real servers, and any ARP packets that might otherwise be sent containing the VIPs are mangled to contain the real server's IP instead of the VIPs.
Mit Hilfe der arptables_jf-Methode können sich Applikationen mit jeder einzelnen VIP oder jedem einzelnen Port binden, die der reale Server bedient. So gestattet die arptables_jf-Methode beispielsweise, dass mehrere Instanzen des Apache HTTP Server laufen und dabei explizit mit verschiedenen VIPs auf dem System gebunden sind. Die Verwendung von arptables_jf besitzt auch wesentliche Vorteile hinsichtlich der Leistungsfähigkeit gegenüber der Option iptables.
Allerdings können VIPs bei Verwendung der arptables_jf-Methode mit Hilfe von standardmäßigen Red Hat Enterprise Linux Systemkonfigurationstools nicht so konfiguriert werden, dass sie zum Zeitpunkt des Bootens starten.
Um jeden realen Server so zu konfigurieren, dass ARP-Anfragen für jede der virtuellen IP-Adressen ignoriert werden, führen Sie die folgenden Schritte durch:
  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 "director" zur Kommunikation mit dem realen Server verwendet, oft die IP, die eth0 zugeordnet ist)):
    arptables -A IN -d <virtual_ip> -j DROP
    arptables -A OUT -s <virtual_ip> -j mangle --mangle-ip-s <real_ip>
    
    Dies veranlasst die realen Server, alle ARP-Anfragen für die virtuellen IP-Adressen zu ignorieren und alle ausgehenden ARP-Antworten, die ansonsten evtl. die virtuelle IP enthalten könnten, zu verändern, so dass sie stattdessen die IP des Servers enthalten. Der einzige Knoten, der auf ARP-Anfragen für irgendeine der VIPs antworten sollte, ist der aktuell aktive LVS-Knoten.
  2. Nachdem dies auf jedem realen Server abgeschlossen ist, speichern Sie die ARP-Tabelleneinträge, indem Sie die folgenden Befehle auf jedem realen Server eingeben:
    service arptables_jf save
    chkconfig --level 2345 arptables_jf on
    Der Befehl chkconfig veranlasst das System, die arptables-Konfiguration zum Zeitpunkt des Bootens neu zu laden — vor dem Start des Netzwerks.
  3. Konfigurieren Sie die virtuelle IP-Adresse auf allen realen Servern mit Hilfe von ifconfig zur Erstellung eines IP-Alias. Zum Beispiel:
    # ifconfig eth0:1 192.168.76.24 netmask 255.255.252.0 broadcast 192.168.79.255 up
    Oder unter Verwendung des iproute2-Hilfsprogramms ip, zum Beispiel:
    # ip addr add 192.168.76.24 dev eth0
    Wie bereits zuvor erwähnt, kann die virtuelle IP-Adresse mit Hilfe der Red Hat Systemkonfigurationstools nicht so konfiguriert werden, dass sie zum Zeitpunkt des Bootens startet. Eine Möglichkeit, dieses Problem zu umgehen, ist das Platzieren dieser Befehle in /etc/rc.d/rc.local.
  4. Configure Piranha for Direct Routing. Refer to Kapitel 4, Konfiguration der LVS-Router mit dem Piranha Configuration Tool for more information.