Abbildung 1.22, »LVS Implemented with NAT Routing«, illustrates LVS using NAT routing to move requests between the Internet and a private network.

In dem Beispiel existieren zwei NICs im aktiven LVS-Router. Die NIC für das Internet besitzt eine reale IP-Adresse auf eth0 und eine floating IP-Adresse, mit einem Alias nach eth0:1. Die NIC für die private Netzwerkschnittstelle besitzt eine reale IP-Adresse auf eth1 und eine floating IP-Adresse, mit einem Alias nach eth1:1. Bei einer Ausfallsicherung werden die virtuelle Schnittstelle, die sich zum Internet hin richtet und die nach privat ausgerichtete virtuelle Schnittstelle gleichzeitig vom Backup-LVS-Router übernommen. Alle realen Server im privaten Netzwerk verwenden die floating IP für den NAT-Router als ihre standardmäßige Route, um mit dem aktiven LVS-Router zu kommunizieren, so dass ihre Fähigkeiten, auf Anfragen aus dem Internet zu reagieren, nicht beeinträchtigt werden.

In the example, the LVS router's public LVS floating IP address and private NAT floating IP address are aliased to two physical NICs. While it is possible to associate each floating IP address to its physical device on the LVS router nodes, having more than two NICs is not a requirement.

Bei der Verwendung dieser Topologie erhält der aktive LVS-Router die Anfragen und routet sie an den entsprechenden Server weiter. Der reale Server verarbeitet anschließend die Anfrage und gibt die Pakete an den LVS-Router zurück. Der LVS-Router verwendet Network Address Translation, um die Adresse des realen Servers in den Paketen durch die öffentliche VIP-Adresse der LVS-Router zu ersetzen. Dieser Prozess wird als IP-Masquerading bezeichnet, da die tatsächlichen IP-Adressen der realen Server vor den anfragenden Clients versteckt wird.

Mit Hilfe von NAT-Routing können reale Server beliebige Rechner sein, auf denen eine Vielzahl an Betriebssystemen laufen. Der Hauptnachteil von NAT-Routing ist, dass der LVS-Router in größeren Einsatzszenarien zu einer Art Engpass werden kann, da er ausgehende und eingehende Anfragen verarbeiten muss.

Direktes Routing bietet den Vorteil einer höheren Leistung im Vergleich zu NAT-Routing. Direktes Routing ermöglicht den realen Servern, Pakete direkt zu verarbeiten und an einen anfragenden Benutzer zu routen, anstatt ausgehende Pakete durch den LVS-Router zu leiten. Direktes Routing vermindert die Wahrscheinlichkeit von Problemen bei der Netzwerkleistung, indem es den Job des LVS-Routers nur auf das Verarbeiten von eingehenden Paketen beschränkt.

In einer typischen Direktes-Routing-LVS-Konfiguration empfängt ein eingehender Server Anfragen durch eine virtuelle IP (VIP) und verwenden einen Plan-Algorithmus, um die Anfragen an reale Server zu routen. Jeder reale Server verarbeitet Anfragen und senden Antworten direkt an Clients und umgeht dabei die LVS-Routers. Direktes Routing ermöglicht Skalierbarkeit, so dass reale Server hinzugefügt werden können, ohne dass der LVS-Router zusätzlich belastet wird, ausgehende Pakete vom realen Server zum Client zu routen, was bei hoher Netzwerkauslastung zu einem Engpass führen kann.

Auch wenn es viele Vorteile zur Verwendung von direktem Routing in LVS gibt, existieren auch einige Einschränkungen. Das häufigste Problem mit direktem Routing und LVS tritt bei Address Resolution Protocol (ARP) auf.

In typical situations, a client on the Internet sends a request to an IP address. Network routers typically send requests to their destination by relating IP addresses to a machine's MAC address with ARP. ARP requests are broadcast to all connected machines on a network, and the machine with the correct IP/MAC address combination receives the packet. The IP/MAC associations are stored in an ARP cache, which is cleared periodically (usually every 15 minutes) and refilled with IP/MAC associations.

Das Problem mit ARP-Anfragen in einer Direkt-Routing-LVS-Konfiguration ist, dass aufgrund der Tatsache, dass eine Client-Anfrage an eine IP-Adresse mit einer MAC-Adresse verknüpft sein muss, damit diese Anfrage behandelt werden kann, die virtuelle IP-Adresse des LVS-Router ebenfalls mit einer MAC verknüpft sein muss. Da aber sowohl der LVS-Router, als auch die realen Server dieselbe VIP besitzen, wird die ARP-Anfrage an alle mit dem VIP verknüpften Knoten verbreitet. Dies kann zu einigen Problemen führen, z.B. dass die VIP direkt mit einem der realen Server verknüpft wird und Anfragen direkt weiterleitet und dabei den LVS-Router komplett umgeht, was den Zweck der LVS-Konfiguration außer Kraft setzt. Das Verwenden eines LVS-Routers mit einer leistungsfähigen CPU, der schnell auf Client-Anfragen eingehen kann, beseitigt dieses Problem nicht notwendigerweise. Falls der LVS-Router unter hoher Auslastung steht, kann er ggf. langsamer auf die ARP-Anfrage reagieren, als ein unterbeschäftigter realer Server, der schneller reagiert und dem die VIP im ARP-Cache des anfragenden Clients zugewiesen wird.

Um dieses Problem zu lösen, sollten die eingehenden Anfragen nur den VIP mit dem LVS-Router verknüpfen, welcher die Anfragen ordnungsgemäß verarbeiten und sie an den Pool der realen Server senden wird. Dies kann mit Hilfe des Tools arptables zur Paketfilterung durchgeführt werden.

Sofern aktiviert, agiert die Persistenz wie ein Timer. Wenn sich ein Client mit einem Dienst verbindet, merkt sich LVS die letzte Verbindung für eine angegebene Zeitspanne. Falls sich dieselbe Client-IP-Adresse erneut innerhalb dieser Spanne verbindet, wird es an denselben Server weitergeleitet, mit dem sie sich zuvor bereits verbunden hatte — dabei werden die Mechanismen zum Lastverteilung übergangen. Falls eine Verbindung außerhalb des Zeitfenster zustandekommt, wird sie anhand der Scheduling-Regeln, die gerade in Kraft sind, behandelt.

Persistenz erlaubt Ihnen auch die Angabe einer Subnet-Maske, die für den Test der Client-IP-Adresse angewendet werden kann, als ein Tool zur Kontrolle, welche Adressen ein höheres Level an Persistenz besitzen, so dass Verbindungen mit diesem Subnet gruppiert werden.

Das Gruppieren von Verbindungen, die für verschiedene Ports bestimmt sind, kann für Protokolle von Bedeutung sein, die mehr als einen Port für die Kommunikation verwenden, wie beispielsweise FTP. Allerdings stellt Persistenz nicht die effektivste Art und Weise dar, Probleme mit der Gruppierung von Verbindungen, die für verschiedene Ports bestimmt sind, zu behandeln. Für diese Situationen werden am besten Firewall-Markierungen vewendet.

Firewall-Markierungen sind eine leichte und effektive Art und Weise, um Ports zu gruppieren, die für ein Protokoll oder eine Gruppe von verwandten Protokollen verwendet werden. Wenn LVS beispielsweise im Rahmen einer E-Commerce-Site eingesetzt wird, können Firewall-Markierungen dazu verwendet werden, HTTP-Verbindungen auf Port 80, sowie sichere HTTPS-Verbindungen auf Port 443 zu bündeln. Indem dieselbe Firewall-Markierung für jedes Protokoll zum virtuellen Servern zugewiesen wird, können Informationen über den Zustand der Transaktion erhalten bleiben, da der LVS-Router alle Anfragen an denselben realen Server weiterleitet, nachdem eine Verbindung geöffnet wurde.

Aufgrund seiner Effizienz und der einfachen Handhabung sollten Administratoren wann immer möglich Firewall-Markierungen zugunsten von Persistenz für Gruppierungsverbindungen verwenden. Allerdings sollten Sie immer noch Persistenz in Verbindung mit Firewall-Markierungen zu den virtuellen Servern hinzufügen um sicherzustellen, dass Clients wieder mit demselben Server für eine angemessene Zeitspanne verbunden werden.

You can access the Cluster Configuration Tool (Abbildung 1.27, »Cluster Configuration Tool«) through the Cluster Configuration tab in the Cluster Administration GUI.

Das Cluster Configuration Tool repräsentiert Cluster-Konfigurations-Komponenten in der Konfigurationsdatei (/etc/cluster/cluster.conf) mit einer hierarchischen grafischen Anzeige im linken Panel. Ein dreieckiges Symbol links neben dem Namen einer Komponente zeigt an, dass der Komponente eine oder mehrere untergeordnete Komponenten zugewiesen sind. Ein Klick auf das dreieckige Symbol klappt dem Teilbereich eines Verzeichnisbaums unterhalb einer Komponente auf und zu. Die im GUI angezeigten Komponenten können wie folgt zusammengefasst werden:

You can access the Cluster Status Tool (Abbildung 1.28, »Cluster Status Tool«) through the Cluster Management tab in Cluster Administration GUI.

Die im Cluster Status Tool dargestellten Knoten und Dienste werden in der Cluster-Konfigurationsdatei (/etc/cluster/cluster.conf) bestimmt. Sie können das Cluster Status Tool verwenden, um einen Hochverfügbarkeitsdienst zu aktivieren, zu deaktivieren, neuzustarten oder zu verschieben.

The VIRTUAL SERVER subsection panel shown in Abbildung 1.34, »The VIRTUAL SERVERS Subsection« allows you to configure an individual virtual server. Links to subsections related specifically to this virtual server are located along the top of the page. But before configuring any of the subsections related to this virtual server, complete this page and click on the ACCEPT button.

Ein Klick auf die Verknüpfung des Unterabschnitts REAL SERVER im oberen Bereich des Panels zeigt den Unterabschnitt EDIT REAL SERVER an. Es zeigt den Status des physikalischen Server-Hosts für einen bestimmten virtuellen Dienst.

Click the ADD button to add a new server. To delete an existing server, select the radio button beside it and click the DELETE button. Click the EDIT button to load the EDIT REAL SERVER panel, as seen in Abbildung 1.36, »The REAL SERVER Configuration Panel«.

Dieses Panel besteht aus drei Eingabefeldern:

Klicken Sie auf die Verknüpfung MONITORING SCRIPTS am oberen Ende der Seite. Der Unterabschnitt EDIT MONITORING SCRIPTS erlaubt dem Administrator die Angabe einer Send/Expect String-Sequenz um zu verifizieren, dass der Dienst für den virtuellen Server auf jedem realen Server funktionsfähig ist. Es ist außerdem der Ort, an dem der Administrator angepasste Skripte angeben kann, um Dienste zu überprüfen, die dynamisch verändernde Daten erfordern.