Virtual Server Administration

Da es keine integrierte Komponente in LVS gibt, um dieselben Daten unter realen Servern gemeinsam zu nutzen, stehen dem Administrator zwei Grundoptionen zur Verfügung:

Die erste Option wird vorzugsweise für Server verwendet, bei denen einer großen Anzahl von Benutzern das Hochladen oder Verändern von Daten auf realen Servern verweigert wird. Falls die Konfiguration einer großen Anzahl von Benutzern gestattet, Daten zu verändern, wie beispielsweise einer E-Commerce-Website, ist das Hinzufügen einer dritten Schicht besser.

The structure that the IPVS table takes depends on the scheduling algorithm that the administrator chooses for any given virtual server. To allow for maximum flexibility in the types of services you can cluster and how these services are scheduled, Red Hat Enterprise Linux provides the following scheduling algorithms listed below. For instructions on how to assign scheduling algorithms refer to Abschnitt 4.6.1, »Der Unterabschnitt VIRTUAL SERVER«.

Der Administrator von LVS kann jedem Knoten in einem Pool von realen Servern eine Gewichtung zuweisen. Diese Gewichtung besteht aus einem ganzzahligen Wert, der bei jedem beliebigen gewichtungsfähigen Scheduling-Algorithmus (wie beispielsweise gewichtete Least-Connections) mit einbezogen wird und den LVS-Router dabei unterstützt, Hardware mit unterschiedlichen Fähigkeiten gleichmäßiger auszulasten.

Gewichtungen funktionieren im Verhältnis relativ zueinander. Besitzt ein realer Server beispielsweise eine Gewichtung von 1 und ein anderer Server eine Gewichtung von 5, dann erhält der Server mit der Gewichtung von 5 genau 5 Verbindungen für jede einzelne Verbindung, die der andere Server bekommt. Der Standardwert für eine Gewichtung eines realen Servers ist 1.

Auch wenn das Hinzufügen von Gewichtungen zu unterschiedlichen Hardware-Konfigurationen in einem Pool von realen Servern bei der effektiveren Verteilung der Last des Clusters behilflich sein kann, können temporäre ungleichmäßige Verteilungen bei der Integration eines realen Servers in den Pool der realen Server auftreten, wenn der virtuelle Server für die Verwendung von gewichteten Least-Connections eingeplant ist. Stellen Sie sich beispielsweise vor, es existierten drei Server in einem Pool von realen Servern. Server A und B sind mit 1 gewichtet, und der dritte, Server C ist mit 2 gewichtet. Falls Server C aus irgendwelchen Gründen ausfällt, wird die anfallende zusätzliche Last gleichmäßig zwischen Server A und B verteilt. Sobald Server C jedoch wieder erreichbar ist, ermittelt der LVS-Router, dass er keine Verbindungen besitzt und weist dem Server solange alle eingehenden Anfragen zu, bis er mit Server A und B wieder auf einer Stufe ist.

Um dieses Phänomen zu verhindern, können Administratoren den virtuellen Server zu einem Quiesce-Server machen — jedes Mal, wenn ein neuer realer Server-Knoten aktiv wird, wird die Least-Connections-Tabelle wieder auf Null zurückgesetzt und der LVS-Router routet Anfragen so, als ob jeder der realen Server neu zum Cluster hinzugefügt wurde.

Abbildung 1.3, »LVS Implemented with NAT Routing«, illustrates LVS utilizing 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 zu eth0:1. Die NIC für die private Netzwerkschnittstelle besitzt eine reale IP-Adresse auf eth1 und eine Floating-IP-Adresse, mit einem Alias zu eth1:1. Bei einer Ausfallsicherung werden die virtuelle Schnittstelle in Richtung Internet, und die ins private Netz 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 this 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 own 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.

Der Aufbau einer LVS-Installation, die direktes Routing verwendet, bietet den Vorteil einer höheren Leistung im Vergleich zu anderen LVS-Netzwerk-Topologien. Direktes Routing ermöglicht den realen Servern, Pakete direkt zu verarbeiten und direkt 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-Router. 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.

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 zur Lastverteilung übergangen. Falls eine Verbindung außerhalb des Zeitfensters zustandekommt, wird sie anhand der Scheduling-Regeln, die gerade in Kraft sind, behandelt.

Persistenz erlaubt dem Administrator 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 den virtuellen Servern dieselbe Firewall-Markierung für jedes Protokoll 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 von LVS wann immer möglich Firewall-Markierungen zugunsten von Persistenz für Gruppierungsverbindungen verwenden. Allerdings sollten Administratoren 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.

Abschnitt 1.6.1.1, »pulse« shows a detailed list of each software component in an LVS router.

Das Piranha Configuration Tool läuft standardmäßig auf Port 3636. Um diese Portnummer zu ändern, ändern Sie die Zeile Listen 3636 im zweiten Abschnitt der piranha-gui Web-Server Konfigurationsdatei /etc/sysconfig/ha/conf/httpd.conf.

Um das Piranha Configuration Tool zu nutzen, benötigen Sie mindestens einen text-basierten Web-Browser. Falls Sie einen Web-Browser auf dem primären LVS-Router starten, öffnen Sie die URL http://localhost:3636. Sie erreichen das Piranha Configuration Tool von überall via Web-Browser, indem Sie localhost mit dem Hostnamen oder der IP-Adresse des primären LVS-Routers ersetzen.

Wenn sich Ihr Browser mit dem Piranha Configuration Tool verbindet, müssen Sie sich für den Zugriff auf die Konfigurationsdienste einloggen. Geben Sie piranha im Feld Username und das mit piranha-passwd erstellte Passwort im Feld Password ein.

Sobald das Piranha Configuration Tool läuft, sollten Sie ggf. in Erwägung ziehen, den Zugriff auf dieses Tool via Netzwerk einzuschränken. Der nächste Abschnitt beschäftigt sich mit einigen Varianten zur Umsetzung dieser Aufgabe.

To set up LVS with NAT, you must first configure the network interfaces for the public network and the private network on the LVS routers. In this example, the LVS routers' public interfaces (eth0) will be on the 192.168.26/24 network (I know, I know, this is not a routable IP, but let us pretend there is a firewall in front of the LVS router for good measure) and the private interfaces which link to the real servers (eth1) will be on the 10.11.12/24 network.

So on the active or primary LVS router node, the public interface's network script, /etc/sysconfig/network-scripts/ifcfg-eth0, could look something like this:

DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.26.9
NETMASK=255.255.255.0
GATEWAY=192.168.26.254

Das Skript /etc/sysconfig/network-scripts/ifcfg-eth1 für die private NAT-Schnittstelle auf dem LVS-Router könnte ungefähr so aussehen:

DEVICE=eth1
BOOTPROTO=static
ONBOOT=yes
IPADDR=10.11.12.9
NETMASK=255.255.255.0

In this example, the VIP for the LVS router's public interface will be 192.168.26.10 and the VIP for the NAT or private interface will be 10.11.12.10. So, it is essential that the real servers route requests back to the VIP for the NAT interface.

After configuring the primary LVS router node's network interfaces, configure the backup LVS router's real network interfaces — taking care that none of the IP address conflict with any other IP addresses on the network.

Das Wichtigste, das bei der Konfiguration der Netzwerkschnittstellen der realen Server in einer NAT-Topologie beachtet werden muss, ist das Einstellen eines Gateways für die NAT Floating-IP-Adressen des LVS-Routers. In diesem Beispiel lautet die Adresse 10.11.12.10.

So the real server's /etc/sysconfig/network-scripts/ifcfg-eth0 file could look similar to this:

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=static
IPADDR=10.11.12.1
NETMASK=255.255.255.0
GATEWAY=10.11.12.10

In a simple NAT LVS configuration where each clustered service uses only one port, like HTTP on port 80, the administrator needs only to enable packet forwarding on the LVS routers for the requests to be properly routed between the outside world and the real servers. See Abschnitt 2.5, »Aktivierung der Paketweiterleitung« for instructions on turning on packet forwarding. However, more configuration is necessary when the clustered services require more than one port to go to the same real server during a user session. For information on creating multi-port services using firewall marks, see Abschnitt 3.4, »Multiport-Dienste und LVS«.

Once forwarding is enabled on the LVS routers and the real servers are set up and have the clustered services running, use the Piranha Configuration Tool to configure LVS as shown in Kapitel 4, Konfiguration der LVS-Router mit dem Piranha Configuration Tool.

When finished, start the pulse service as shown in Abschnitt 4.8, »Starten von LVS«. Once pulse is up and running, the active LVS router will begin routing requests to the pool of real servers.

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:

Sie können das ARP-Problem ggf. auch umgehen, indem Sie die direkte Routing-Methode durch das Erstellen von iptables Firewall-Regeln verwenden. Um direktes Routing unter Verwendung von iptables zu konfigurieren, müssen Sie Regeln hinzufügen, die einen transparenten Proxy erstellen, so dass ein realer Server Pakete, die an die VIP-Adresse geschickt werden, bedient, auch wenn die VIP-Adresse nicht auf dem System existiert.

Die iptables-Methode ist einfacher zu konfigurieren, als die arptables_jf-Methode. Diese Methode umgeht außerdem das LVS-ARP-Problem komplett, da die virtuelle(n) IP-Adresse(n) nur auf dem aktiven LVS-Director existieren.

Allerdings treten bei der Verwendung der iptables-Methode Leistungsprobleme im Vergleich zu arptables_jf auf, da Overhead bei der Weiterleitung / beim Masquerading von jedem Paket auftritt.

Auch können Sie Ports nicht noch einmal verwenden, wenn Sie die iptables-Methode benutzen. Es ist beispielsweise nicht möglich, zwei separate Apache HTTP Server-Dienste auf Port 80 laufen zu lassen, da sich beide mit INADDR_ANY anstelle der virtuellen IP-Adresse binden müssen.

Um direkt Routing unter Verwendung der iptables-Methode zu konfigurieren, führen Sie die folgenden Schritte durch:

Konfigurieren Sie die realen IP-Adressen sowohl für die öffentlichen, als auch die privaten Netzwerke auf den LVS-Routern, bevor Sie versuchen, LVS mit dem Piranha Configuration Tool zu konfigurieren. Die Abschnitte zu jeder Topologie liefern jeweils Beispiel-Netzwerkadressen, es werden jedoch die tatsächlichen Adressen benötigt. Nachfolgend sind ein paar nützliche Befehle aufgeführt, um Netzwerkschnittstellen zu aktivieren oder ihren Status zu überprüfen.

Um einem Paket, das für einen bestimmten Port gedacht ist, Firewall-Markierungen zuzuweisen, muss der Administrator iptables verwenden.

This section illustrates how to bundle HTTP and HTTPS as an example; however, FTP is another commonly clustered multi-port protocol. If an LVS is used for FTP services, refer to Abschnitt 3.5, »Konfiguration von FTP« for configuration details.

Als Grundregel bei der Verwendung von Firewall-Markierungen kann festgehalten werden, dass für jedes Protokoll, das eine Firewall-Markierung in Piranha Configuration Tool verwendet, eine entsprechende iptables-Regel existieren muss, um den Netzwerkpaketen Markierungen zuzuweisen.

Stellen Sie vor der Erstellung von Netzwerk-Paketfilterregeln sicher, dass nicht bereits Regeln existieren. Öffnen Sie hierfür einen Shell-Prompt, loggen Sie sich als Root ein und geben Sie ein:

/sbin/service iptables status

Falls iptables nicht läuft, erscheint der Prompt umgehend wieder.

Falls iptables aktiv ist, werden eine Reihe an Regeln angezeigt.

/sbin/service iptables stop

Falls die bereits existierenden Regeln wichtig sind, überprüfen Sie den Inhalt von /etc/sysconfig/iptables und kopieren Sie sämtliche Regeln, die es wert sind, zu speichern, an einen sicheren Ort, bevor Sie fortfahren.

Nachfolgend sind Regeln aufgeführt, die dieselbe Firewall-Markierung, 80, eingehendem Datenverkehr, der für die floating IP,n.n.n.n, auf den Ports 80 und 443, zuweisen

/sbin/modprobe ip_tables

/sbin/iptables -t mangle -A PREROUTING -p tcp -d n.n.n.n/32 --dport 80 -j MARK --set-mark 80

/sbin/iptables -t mangle-A PREROUTING -p tcp -d n.n.n.n/32 --dport 443 -j MARK --set-mark 80

For instructions on assigning the VIP to the public network interface, see Abschnitt 4.6.1, »Der Unterabschnitt VIRTUAL SERVER«. Also note that you must log in as root and load the module for iptables before issuing rules for the first time.

In den oben aufgeführten iptables-Befehlen sollte n.n.n.n durch die floating IP für Ihre virtuellen HTTP- und HTTPS-Server ersetzt werden. Diese Befehle haben den reinen Effekt, dass jeglichem Datenverkehr, der an die VIP auf dem entsprechenden Port gerichtet ist, eine Firewall-Markierung von 80 zugewiesen wird, was im Gegenzug von IPVS erkannt und entsprechend weitergeleitet wird.

Bei den meisten anderen Server-Client-Beziehungen öffnet die Client-Maschine eine Verbindung mit dem Server auf einem bestimmten Port und der Server antwortet dem Client anschließend auf diesem Port. Wenn sich ein FTP-Client mit einem FTP-Server verbindet, wird eine Verbindung auf dem FTP-Kontrollport 21 geöffnet. Der Client teilt dem FTP-Server dann mit, ob eine aktive oder passive Verbindung hergestellt werden soll. Die vom Client gewählte Verbindung bestimmt die Antwort des Servers und auf welchen Ports Transaktionen stattfinden.

Die beiden Arten von Datenverbindungen lauten:

IPVS-Paketweiterleitung gestattet lediglich Verbindungen in das Cluster und aus dem Cluster heraus, basierend auf der Erkennung ihrer Portnummer oder Firewall-Markierungen. Falls ein Client außerhalb des Clusters versucht, einen Port zu öffnen, den die aktuelle Konfiguration von IPVS nicht umfasst, wird die Verbindung abgebrochen. Falls der reale Server gleichermaßen versucht, eine Verbindung auf einem Port, den IPVS nicht kennt zurück zum Internet herzustellen, wird die Verbindung abgebrochen. Dies bedeutet, dass alle Verbindungen von FTP-Clients aus dem Internet dieselbe Firewall-Markierung zugewiesen haben müssen und alle Verbindungen vom FTP-Server ordnungsgemäß zum Internet unter Verwendung von Netzwerk-Paketfilterregeln weitergeleitet werden müssen.

Before assigning any iptables rules for FTP service, review the information in Abschnitt 3.4.1, »Zuweisen von Firewall-Markierungen« concerning multi-port services and techniques for checking the existing network packet filtering rules.

Below are rules which assign the same firewall mark, 21, to FTP traffic. For these rules to work properly, you must also use the VIRTUAL SERVER subsection of Piranha Configuration Tool to configure a virtual server for port 21 with a value of 21 in the Firewall Mark field. See Abschnitt 4.6.1, »Der Unterabschnitt VIRTUAL SERVER« for details.

The VIRTUAL SERVER subsection panel shown in Abbildung 4.6, »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 4.8, »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.

Once you have configured virtual servers using the Piranha Configuration Tool, you must copy specific configuration files to the backup LVS router. See Abschnitt 4.7, »Synchronisation von Konfigurationsdateien« for details.

Jedes Mal, wenn die LVS-Konfigurationsdatei /etc/sysconfig/ha/lvs.cf erstellt oder aktualisiert wird, müssen Sie sie auf den Backup-LVS-Router-Knoten kopieren.

Am besten kann dies mit scp durchgeführt werden.

Führen Sie den folgenden Befehl als Root-Benutzer auf dem primären LVS-Router aus, um die lvs.cf-Dateien zwischen den Router-Knoten zu synchronisieren:

scp /etc/sysconfig/ha/lvs.cf n.n.n.n:/etc/sysconfig/ha/lvs.cf

Ersetzen Sie in diesem Befehl n.n.n.n mit der realen IP-Adresse des Backup-LVS-Routers.

Die sysctl-Datei wird in den meisten Situationen nur einmal modifiziert. Diese Datei wird zum Zeitpunkt des Bootens gelesen und weist den Kernel an, Paketweiterleitung zu aktivieren.

Falls Sie iptables verwenden, müssen Sie die entsprechende Konfigurationsdatei auf dem Backup-LVS-Router synchronisieren.

Falls Sie irgendeine Netzwerk-Paketfilter-Regel verändern, geben Sie den folgenden Befehl als Root auf dem primären LVS-Router ein:

scp /etc/sysconfig/iptables n.n.n.n:/etc/sysconfig/

Ersetzen Sie in diesem Befehl n.n.n.n mit der realen IP-Adresse des Backup-LVS-Routers.

Öffnen Sie als nächstes entweder eine ssh-Sitzung zum Backup-Router oder loggen Sie sich als Root auf der Maschine ein und geben folgenden Befehl ein:

/sbin/service iptables restart

Once you have copied these files over to the backup router and started the appropriate services (see Abschnitt 2.1, »Konfiguration von Diensten auf den LVS-Routern« for more on this topic) you are ready to start LVS.