Menu Close

Red Hat Training

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

Virtual Server Administration

Red Hat Enterprise Linux 5

Linux Virtual Server (LVS) for Red Hat Enterprise Linux

Ausgabe 5

Logo

Zusammenfassung

Building a Linux Virtual Server (LVS) system offers highly-available and scalable solution for production services using specialized routing and load-balancing techniques configured through the PIRANHA. This book discusses the configuration of high-performance systems and services with Red Hat Enterprise Linux and LVS for Red Hat Enterprise Linux 5.

Introduction

This document provides information about installing, configuring, and managing Red Hat Virtual Linux Server (LVS) components. LVS provides load balancing through specialized routing techniques that dispatch traffic to a pool of servers. This document does not include information about installing, configuring, and managing Red Hat Cluster software. Information about that is in a separate document.
The audience of this document should have advanced working knowledge of Red Hat Enterprise Linux and understand the concepts of clusters, storage, and server computing.
This document is organized as follows:
For more information about Red Hat Enterprise Linux 5, refer to the following resources:
  • Red Hat Enterprise Linux Installation Guide — Provides information regarding installation of Red Hat Enterprise Linux 5.
  • Red Hat Enterprise Linux Deployment Guide — Provides information regarding the deployment, configuration and administration of Red Hat Enterprise Linux 5.
For more information about Red Hat Cluster Suite for Red Hat Enterprise Linux 5, refer to the following resources:
  • Red Hat Cluster Suite Overview — Provides a high level overview of the Red Hat Cluster Suite.
  • Configuring and Managing a Red Hat Cluster — Provides information about installing, configuring and managing Red Hat Cluster components.
  • Logical Volume Manager Administration — Provides a description of the Logical Volume Manager (LVM), including information on running LVM in a clustered environment.
  • Global File System: Configuration and Administration — Provides information about installing, configuring, and maintaining Red Hat GFS (Red Hat Global File System).
  • Global File System 2: Configuration and Administration — Provides information about installing, configuring, and maintaining Red Hat GFS2 (Red Hat Global File System 2).
  • Using Device-Mapper Multipath — Provides information about using the Device-Mapper Multipath feature of Red Hat Enterprise Linux 5.
  • Using GNBD with Global File System — Provides an overview on using Global Network Block Device (GNBD) with Red Hat GFS.
  • Red Hat Cluster Suite Release Notes — Provides information about the current release of Red Hat Cluster Suite.
Red Hat Cluster Suite documentation and other Red Hat documents are available in HTML, PDF, and RPM versions on the Red Hat Enterprise Linux Documentation CD and online at http://www.redhat.com/docs/.

1. Feedback

If you spot a typo, or if you have thought of a way to make this manual better, we would love to hear from you. Please submit a report in Bugzilla (http://bugzilla.redhat.com/bugzilla/) against the component Documentation-cluster.
Be sure to mention the manual's identifier:
Virtual_Server_Administration(EN)-5 (2010-02-08T16:55)
By mentioning this manual's identifier, we know exactly which version of the guide you have.
If you have a suggestion for improving the documentation, try to be as specific as possible. If you have found an error, please include the section number and some of the surrounding text so we can find it easily.

Kapitel 1. Überblick über Linux Virtual Server

Linux Virtual Server (LVS) ist ein Set integrierter Software-Komponenten für das gleichmäßige Verteilen von IP-Load innerhalb einer Gruppe realer Server. LVS läuft auf einem Paar gleich konfigurierter Computer: Ein Computer, der einen aktiven LVS-Router darstellt und ein Computer, der als ein Backup-LVS-Router agiert. Der aktive LVS-Router erfüllt zwei Rollen:
  • Gleichmäßige Verteilung der Auslastung unter den realen Servern.
  • Überprüfung der Integrität der Dienste auf jedem realen Server.
Der Backup-LVS-Router überwacht den aktiven LVS-Router und übernimmt dessen Aufgaben im Falle eines Ausfalls.
Dieses Kapitel liefert einen Überblick über die LVS-Komponenten und -funktionen und besteht aus den folgenden Abschnitten:

1.1. A Basic LVS Configuration

Abbildung 1.1, »A Basic LVS Configuration« shows a simple LVS configuration consisting of two layers. On the first layer are two LVS routers — one active and one backup. Each of the LVS routers has two network interfaces, one interface on the Internet and one on the private network, enabling them to regulate traffic between the two networks. For this example the active router is using Network Address Translation or NAT to direct traffic from the Internet to a variable number of real servers on the second layer, which in turn provide the necessary services. Therefore, the real servers in this example are connected to a dedicated private network segment and pass all public traffic back and forth through the active LVS router. To the outside world, the servers appears as one entity.
A Basic LVS Configuration

Abbildung 1.1. A Basic LVS Configuration

Service requests arriving at the LVS routers are addressed to a virtual IP address, or VIP. This is a publicly-routable address the administrator of the site associates with a fully-qualified domain name, such as www.example.com, and is assigned to one or more virtual servers. A virtual server is a service configured to listen on a specific virtual IP. Refer to Abschnitt 4.6, »VIRTUAL SERVERS« for more information on configuring a virtual server using the Piranha Configuration Tool. A VIP address migrates from one LVS router to the other during a failover, thus maintaining a presence at that IP address (also known as floating IP addresses).
VIP-Adressen können eine Alias-Bezeichnung mit demselben Gerät erhalten, welches den LVS-Router mit dem öffentlichen Netzwerk verbindet. Wenn zum Beispiel eth0 mit dem Internet verbunden ist, dann können mehrere virtuelle Server eine Alias-Bezeichnung eth0:1 erhalten. Alternativ kann jeder virtuelle Server mit einem separaten Gerät pro Dienst verknüpft werden. Beispielsweise kann HTTP-Datenverkehr auf eth0:1 und FTP-Datenverkehr auf eth0:2 verwaltet werden.
Only one LVS router is active at a time. The role of the active router is to redirect service requests from virtual IP addresses to the real servers. The redirection is based on one of eight supported load-balancing algorithms described further in Abschnitt 1.3, »LVS Scheduling-Überblick«.
Auch überwacht der aktive Router dynamisch die Gesamtverfassung der speziellen Dienste auf den realen Servern durch einfache send/expect-Skripte. Als Hilfe bei der Analyse des Zustands eines Dienstes, der dynamische Daten wie HTTPS oder SSL benötigt, können Sie auch externe ausführbare Dateien aufrufen. Falls ein Dienst auf einem realen Server nicht ordnungsgemäß funktioniert, hört der aktive Router auf, Jobs an diesen Server zu senden, bis dieser wieder auf normalem Betriebslevel ist.
Der Backup-Router übernimmt die Rolle eines Systems in Bereitschaft. Die LVS-Router tauschen periodisch Heartbeat-Meldungen durch die primäre externe öffentliche Schnittstelle, und im Falle einer Ausfallsicherung, durch die private Schnittstelle aus. Erhält der Backup-Knoten keine Heartbeat-Meldung innerhalb eines erwarteten Intervalls, leitet er eine Ausfallsicherung ein und übernimmt die Rolle des aktiven Routers. Während der Ausfallsicherung übernimmt der Backup-Router die VIP-Adressen, die vom ausgefallenen Router bereitgestellt wurden, unter Verwendung einer Technik, die als ARP-Spoofing bekannt ist — hier zeigt der Backup-LVS-Router an, dass er das Ziel für IP-Pakete, die an den ausgefallenen Knoten gerichtet sind, darstellt. Falls der ausgefallene Knoten wieder aktiv wird, nimmt der Backup-Knoten seine Backup-Rolle wieder auf.
The simple, two-layered configuration used in Abbildung 1.1, »A Basic LVS Configuration« is best for serving data which does not change very frequently — such as static webpages — because the individual real servers do not automatically sync data between each node.

1.1.1. Datenreplikation und Datenaustausch zwischen realen Servern

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:
  • Synchronisation der Daten innerhalb des Pools der realen Server.
  • Hinzufügen einer dritten Ebene zur Topologie für den Zugriff auf gemeinsam genutzte Daten.
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.

1.1.1.1. Konfiguration von realen Servern zur Synchronisation von Daten

Administratoren steht eine Reihe von Möglichkeiten zur Auswahl, um Daten innerhalb des Pools von realen Servern zu synchronisieren. So können beispielsweise Shell-Skripte eingesetzt werden, so dass bei einer Aktualisierung einer Seite durch einen Web-Engineer, diese gleichzeitig an alle Server versendet wird. Auch kann der Systemadministrator Programme wie rsync verwenden, um Daten, die sich geändert haben, auf allen Knoten zu einem festgelegten Zeitintervall zu replizieren.
Diese Art der Datensynchronisation funktioniert allerdings nicht optimal, wenn die Konfiguration mit Benutzern überlastet ist, die anhaltend Dateien hochladen oder Datenbanktransaktionen ausführen. Für eine Konfiguration mit hoher Auslastung ist eine Three-Tiered-Topologie die ideale Lösung.

1.2. A Three-Tier LVS Configuration

Abbildung 1.2, »A Three-Tier LVS Configuration« shows a typical three-tier LVS topology. In this example, the active LVS router routes the requests from the Internet to the pool of real servers. Each of the real servers then accesses a shared data source over the network.
A Three-Tier LVS Configuration

Abbildung 1.2. A Three-Tier LVS Configuration

Diese Konfiguration eignet sich ideal für gut ausgelastete FTP-Server, bei denen Daten, auf die zugegriffen werden kann, auf einem Hochverfügbarkeits-Server gespeichert werden und auf die von jedem realen Server via einem exportierten NFS-Verzeichnis oder einer Samba-Freigabe zugegriffen wird. Diese Topologie wird außerdem für Websites empfohlen, die auf eine zentrale, Hochverfügbarkeits-Datenbank für Transaktionen zugreifen. Zusätzlich können Administratoren unter Verwendung einer aktiv-aktiv-Konfiguration in Zusammenhang mit Red Hat Cluster Manager ein Hochverfügbarkeits-Cluster so konfigurieren, dass es diese beiden Rollen gleichzeitig ausübt.
Die dritte Tier im oben aufgeführten Beispiel muss Red Hat Cluster Manager nicht nutzen. Wird jedoch keine Hochverfügbarkeitslösung verwendet, stellt dies einen "Single Point of Failure" dar.

1.3. LVS Scheduling-Überblick

Einer der Vorteile bei der Verwendung von LVS ist die Fähigkeit, flexible Lastverteilung auf IP-Level im Pool der realen Server durchzuführen. Diese Flexibilität ist auf die Vielzahl der Scheduling-Algorithmen zurückzuführen, aus denen ein Administrator bei der Konfiguration von LVS auswählen kann. LVS-Lastverteilung ist weniger flexiblen Methoden, wie Round-Robin DNS überlegen, bei der die hierarchische Art von DNS und das Caching (Zwischenspeichern) von Client-Maschinen zu ungleichmäßiger Auslastung führen kann. Zusätzlich besitzt das Filtern auf einer niedrigen Stufe, das vom LVS-Router eingesetzt wird, Vorteile gegenüber einer Weiterleitung von Anfragen auf Applikationslevel, da Lastverteilung auf der Stufe eines Netzwerkpakets minimale Rechenleistung verursacht und eine bessere Skalierbarkeit bietet.
Using scheduling, the active router can take into account the real servers' activity and, optionally, an administrator-assigned weight factor when routing service requests. Using assigned weights gives arbitrary priorities to individual machines. Using this form of scheduling, it is possible to create a group of real servers using a variety of hardware and software combinations and the active router can evenly load each real server.
Der Scheduling-Mechanismus für LVS wird von einer Sammlung von Kernel-Patches, genannt IP Virtual Server- oder IPVS-Module, zur Verfügung gestellt. Diese Module aktivieren Layer 4 (L4) Transport-Layer-Switching, welches für eine gute Zusammenarbeit mit mehreren Servern im Rahmen einer einzelnen IP-Adresse konzipiert ist.
Um Pakete effektiv zu den realen Servern zu routen und deren Verlauf nachzuverfolgen, erstellt IPVS eine IPVS-Tabelle im Kernel. Diese Tabelle wird vom aktiven LVS-Router verwendet, um Anfragen von einer virtuellen Server-Adresse umzuleiten, die an einen realen Server im Pool gerichtet sind, oder von diesem zurückkommen. Die IPVS-Tabelle wird laufend durch das Dienstprogramm ipvsadm aktualisiert — je nach Verfügbarkeit werden Cluster-Mitglieder hinzugefügt oder entfernt.

1.3.1. Scheduling-Algorithmen

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«.
Round-Robin Scheduling
Verteilt jede Anfrage nacheinander in einem Pool von realen Servern. Bei der Verwendung dieses Algorithmus werden alle realen Server als gleichwertig behandelt, ohne Rücksicht auf deren Kapazität oder Auslastung. Dieses Scheduling-Modell ist so ähnlich wie Round-Robin-DNS, ist jedoch tiefgehender, da es netzwerkbasiert und nicht hostbasiert ist. LVS Round-Robin-Scheduling leidet außerdem nicht unter den ungleichmäßigen Auslastungen, die von zwischengespeicherten DNS-Anfragen verursacht werden.
Weighted Round-Robin Scheduling
Distributes each request sequentially around the pool of real servers but gives more jobs to servers with greater capacity. Capacity is indicated by a user-assigned weight factor, which is then adjusted upward or downward by dynamic load information. Refer to Abschnitt 1.3.2, »Server-Gewichtung und Scheduling« for more on weighting real servers.
Gewichtetes Round-Robin-Scheduling ist die bevorzugte Wahl falls signifikante Unterschiede bei der Kapazität von realen Servern in einem Server-Pool vorliegen. Wenn die Last durch Anfragen jedoch dramatisch variiert, kann ein stark gewichteter Server ggf. mehr Anfragen beantworten, als ihm zugeteilt sind.
Least-Connection
Verteilt mehr Anfragen an reale Server mit weniger aktiven Verbindungen. Da aktive Verbindungen mit den realen Servern mit Hilfe der IPVS-Tabelle nachverfolgt werden, ist Least-Connection eine Form von dynamischem Scheduling-Algorithmus und ist die bessere Wahl, falls ein hohes Maß an Abweichung in der Anfragelast vorliegt. Es ist am besten für einen Pool von realen Server geeignet, in dem jeder Server-Knoten in etwa dieselbe Kapazität besitzt. Falls die realen Server unterschiedliche Kapazitäten besitzen, ist das gewichtete Least-Connection-Scheduling die bessere Wahl.
Weighted Least-Connections (default)
Distributes more requests to servers with fewer active connections relative to their capacities. Capacity is indicated by a user-assigned weight, which is then adjusted upward or downward by dynamic load information. The addition of weighting makes this algorithm ideal when the real server pool contains hardware of varying capacity. Refer to Abschnitt 1.3.2, »Server-Gewichtung und Scheduling« for more on weighting real servers.
Locality-Based Least-Connection Scheduling
Verteilt mehrere Anfragen an Server mit weniger aktiven Verbindungen in Relation zu ihren Ziel-IPs. Dieser Algorithmus ist für den Einsatz in einem Proxy-Cache-Server-Cluster gedacht. Er routet die Pakete für eine IP-Adresse solange an den Server für diese Adresse, bis dieser Server seine Kapazitätsgrenze überschreitet und einen Server mit dessen halber Last vorliegen hat. In diesem Fall weist er die IP-Adresse einem realen Server mit der geringsten Auslastung zu.
Locality-Based Least-Connection Scheduling with Replication Scheduling
Verteilt mehr Anfragen an Server mit weniger aktiven Verbindungen in Relation zu ihren Ziel-IPs. Dieser Algorithmus ist auch für den Einsatz in einem Proxy-Cache-Server-Cluster gedacht. Es unterscheidet sich vom Locality-Based Least-Connection Scheduling durch das Zuordnen der Ziel-IP-Adresse zu einer Teilmenge von realer Server-Knoten. Anfragen werden anschließend zum Server in dieser Teilmenge mit der niedrigsten Anzahl an Verbindungen geroutet. Falls alle Knoten für die Ziel-IP über der Kapazität liegen, wird ein neuer Server für diese Ziel-IP-Adresse repliziert, indem der reale Server mit den wenigsten Verbindungen aus dem gesamten Pool der realen Server zur Teilmenge der realen Server für diese Ziel-IP hinzugefügt wird. Der Knoten mit der höchsten Last wird dann aus der Teilmenge der realen Server entfernt, um eine Überreplikation zu verhindern.
Destination Hash Scheduling
Verteilt Anfragen an den Pool realer Server, indem die Ziel-IP in einer statischen Hash-Tabelle abgefragt wird. Dieser Algorithmus ist für die Verwendung in einem Proxy-Cache Server-Cluster konzipiert.
Source Hash Scheduling
Verteilt Anfragen an den Pool realer Server, indem die Quell-IP in einer statischen Hash-Tabelle gesucht wird. Dieser Algorithmus ist für LVS-Router mit mehreren Firewalls konzipiert.

1.3.2. Server-Gewichtung und Scheduling

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.

1.4. Routing-Methoden

Red Hat Enterprise Linux verwendet Network Address Translation oder NAT-Routing für LVS, was dem Administrator eine hohe Flexibilität beim Einsetzen von verfügbarer Hardware und bei der Integration des LVS in ein vorhandenes Netzwerk einräumt.

1.4.1. NAT-Routing

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

Abbildung 1.3. LVS Implemented with NAT Routing

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.

1.4.2. Direktes Routing

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.
LVS Implemented with Direct Routing

Abbildung 1.4. LVS Implemented with Direct Routing

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.

1.4.2.1. Direktes Routing und die ARP-Einschränkung

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.
Um dieses Problem zu lösen, sollten Sie sicherstellen, dass eingehende Anfragen immer an den LVS-Router, anstatt an einen der realen Server gesendet werden. Dies erreichen Sie entweder mit Hilfe von arptables_jf oder des Paketfilter-Tools iptables aus den folgenden Gründen:
  • arptables_jf hindert ARP an der Verknüpfung von VIPs mit realen Servern.
  • Die iptables-Methode umgeht das ARP-Problem komplett, indem VIPs auf realen Servern von vornherein nicht konfiguriert werden.
For more information on using arptables or iptables in a direct routing LVS environment, refer to Abschnitt 3.2.1, »Direktes Routing und arptables_jf« or Abschnitt 3.2.2, »Direktes Routing und iptables«.

1.5. Persistenz und Firewall-Markierungen

In bestimmten Situationen kann es wünschenswert sein, dass sich ein Client immer wieder mit demselben realen Server erneut verbindet, anstatt dass ein LVS-Algorithmus diese Anfrage an den am besten verfügbaren Server zur Lastverteilung schickt. Beispiele für eine solche Situation umfassen Web-Formulare, die sich über mehrere Bildschirme erstrecken, Cookies, SSL- und FTP-Verbindungen. In diesen Fällen funktioniert ein Client ggf. nicht ordnungsgemäß, bis die Transaktionen von demselben Server behandelt werden, um den Kontext beizubehalten. LVS bietet zwei verschiedene Features, um dies zu handhaben: Persistenz und Firewall Markierungen.

1.5.1. Persistenz

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.

1.5.2. Firewall-Markierungen

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.

1.6. LVS — ein Block-Diagramm

LVS routers use a collection of programs to monitor cluster members and cluster services. Abbildung 1.5, »LVS Components« illustrates how these various programs on both the active and backup LVS routers work together to manage the cluster.
LVS Components

Abbildung 1.5. LVS Components

Der pulse-Daemon läuft sowohl auf den aktiven, als auch auf den passiven LVS-Routern. Auf dem Backup-LVS-Router sendet pulse einen heartbeat an die öffentliche Schnittstelle des aktiven Routers, um sicherzustellen, dass der aktive LVS-Router ordnungsgemäß funktioniert. Auf dem aktiven LVS-Router startet pulse den lvs-Daemon und reagiert auf heartbeat-Anfragen des Backup-LVS-Routers.
Sobald er gestartet wird, ruft der lvs-Daemon das ipvsadm-Dienstprogramm auf, um die IPVS (IP Virtual Server) Routing-Tabelle im Kernel zu konfigurieren und zu pflegen, und startet einen nanny-Prozess für jeden konfigurierten virtuellen Server auf jedem realen Server. Jeder nanny-Prozess überprüft den Status eines konfigurierten Dienstes auf einem realen Server und informiert den lvs-Daemon, falls der Dienst auf diesem realen Server nicht korrekt funktioniert. Falls eine Fehlfunktion entdeckt wird, weist der lvs-Daemon ipvsadm an, diesen realen Server aus der IPVS-Routing-Tabelle zu entfernen.
Falls der Backup-LVS-Router keine Antwort vom aktiven LVS-Router erhält, leitet er eine Ausfallsicherung ein, indem er send_arp aufruft, alle virtuellen IP-Adressen den NIC Hardware-Adressen (MAC Adressen) des Backup-LVS-Router neu zuzuweisen. Weiterhin sendet er einen Befehl an den aktiven LVS-Router, sowohl durch die öffentliche, als auch die private Netzwerkschnittstelle, den lvs-Daemon auf dem aktiven LVS-Router zu beenden, und startet den lvs-Daemon auf dem Backup-LVS-Router, um Anfragen für die konfigurierten virtuellen Server zu akzeptieren.

1.6.1. LVS Components

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

1.6.1.1. pulse

This is the controlling process which starts all other daemons related to LVS routers. At boot time, the daemon is started by the /etc/rc.d/init.d/pulse script. It then reads the configuration file /etc/sysconfig/ha/lvs.cf. On the active router, pulse starts the LVS daemon. On the backup router, pulse determines the health of the active router by executing a simple heartbeat at a user-configurable interval. If the active router fails to respond after a user-configurable interval, it initiates failover. During failover, pulse on the backup router instructs the pulse daemon on the active router to shut down all LVS services, starts the send_arp program to reassign the floating IP addresses to the backup router's MAC address, and starts the lvs daemon.

1.6.1.2. lvs

Der lvs-Daemon läuft auf dem aktiven LVS-Router, sobald er von pulse aufgerufen wird. Er liest die Konfigurationsdatei /etc/sysconfig/ha/lvs.cf, ruft das Dienstprogramm ipvsadm auf, um die IPVS-Routing-Tabelle zu erstellen und zu pflegen und weist jedem konfigurierten LVS-Dienst einen nanny-Prozess zu. Falls nanny meldet, dass ein realer Server nicht mehr erreichbar ist, weist lvs das Dienstprogramm ipvsadm an, den realen Server aus der IPVS-Routing-Tabelle zu entfernen.

1.6.1.3. ipvsadm

Dieser Dienst aktualisiert die IPVS-Routing-Tabelle im Kernel. Der lvs-Daemon richtet LVS ein und verwaltet dieses, indem er ipvsadm aufruft, um Einträge in der IPVS-Routing-Tabelle hinzuzufügen, zu verändern oder zu löschen.

1.6.1.4. nanny

Der nanny-Überwachungs-Daemon läuft auf dem aktiven LVS-Router. Mit Hilfe dieses Daemons ermittelt der aktive Router den Zustand jedes realen Servers und überwacht optional dessen Arbeitsbelastung. Ein separater Prozess läuft für jeden Dienst, der auf jedem realen Server definiert ist.

1.6.1.5. /etc/sysconfig/ha/lvs.cf

Dies ist die LVS-Konfigurationsdatei. Alle Daemons erhalten ihre Konfigurationsinformationen direkt oder indirekt aus dieser Datei.

1.6.1.6. Piranha Configuration Tool

Dies ist das webbasierte Tool für die Überwachung, die Konfiguration und die Administration von LVS. Es ist das Standard-Tool zur Pflege der LVS-Konfigurationsdatei /etc/sysconfig/ha/lvs.cf.

1.6.1.7. send_arp

Dieses Programm sendet während der Ausfallsicherung ARP-Broadcasts beim Übertragen von IP-Adressänderungen von einem Knoten auf einen anderen.
Kapitel 2, Erste LVS-Konfiguration reviews important post-installation configuration steps you should take before configuring Red Hat Enterprise Linux to be an LVS router.

Kapitel 2. Erste LVS-Konfiguration

Nach der Installation von Red Hat Enterprise Linux müssen Sie einige grundlegende Schritte durchführen, um sowohl die LVS-Router, als auch die realen Server einzurichten. Dieses Kapitel deckt die ersten Schritte hierfür im Detail ab.

Anmerkung

Der LVS-Router-Knoten, der zum aktiven Knoten wird, sobald LVS gestartet wird, wird auch als der Primäre Knoten bezeichnet. Verwenden Sie zur Konfiguration von LVS das Piranha Configuration Tool auf dem primären Knoten.

2.1. Konfiguration von Diensten auf den LVS-Routern

Das Installationsprogramm von Red Hat Enterprise Linux installiert alle Komponenten, die zur Einrichtung von LVS benötigt werden. Die entsprechenden Dienste müssen jedoch vor der Konfiguration von LVS aktiviert werden. Richten Sie die entsprechenden Dienste für beide LVS-Router so ein, dass sie zum Zeitpunkt des Bootens gestartet werden. Es stehen drei Haupt-Tools zur Einrichtung von Diensten unter Red Hat Enterprise Linux zur Verfügung, so dass diese zum Zeitpunkt des Bootens aktiviert werden: Das Kommandozeilenprogramm chkconfig, das auf Ncurses basierende Programm ntsysv und das grafische Services Configuration Tool. Alle drei Tools erfordern Root-Zugriff.

Anmerkung

Um Root-Zugriff zu erlangen, öffnen Sie einen Shell-Prompt und verwenden den Befehl su -, gefolgt vom Root-Passwort. Zum Beispiel:
$ su - root password
Auf den LVS-Routern müssen drei Dienste zum Zeitpunkt des Bootens auf "aktiviert" gesetzt werden:
  • Der Dienst piranha-gui (nur primärer Knoten)
  • Der pulse-Dienst
  • Der sshd-Dienst
Falls Sie Mehrport-Dienste zu einem Cluster zusammenfassen oder Firewall-Markierungen verwenden, müssen Sie außerdem den iptables-Dienst aktivieren.
Am besten werden diese Dienste so eingerichtet, dass sie sowohl in Runlevel 3, als auch in Runlevel 5 aktiviert werden. Geben Sie den folgenden Befehl für jeden Dienst ein, um dies mit chkconfig zu erledigen:
/sbin/chkconfig --level 35 daemon on
Ersetzen Sie im oben aufgeführten Befehl daemon mit dem Namen des Dienstes, den Sie aktivieren. Um eine Liste von Diensten auf dem System zu bekommen, und darüberhinaus zu sehen, für welche Runlevel diese aktiviert sind, führen Sie den folgenden Befehl aus:
/sbin/chkconfig --list

Warnung

Turning any of the above services on using chkconfig does not actually start the daemon. To do this use the /sbin/service command. See Abschnitt 2.3, »Starten des Piranha Configuration Tool Dienstes« for an example of how to use the /sbin/service command.
For more information on runlevels and configuring services with ntsysv and the Services Configuration Tool, refer to the chapter titled "Controlling Access to Services" in the Red Hat Enterprise Linux System Administration Guide.

2.2. Einrichten eines Passworts für das Piranha Configuration Tool

Bevor das Piranha Configuration Tool erstmalig auf dem primären LVS-Router verwendet werden kann, müssen Sie den Zugriff auf dasselbe mit einem Passwort einschränken. Loggen Sie sich hierfür als Root ein und führen Sie den folgenden Befehl aus:
/usr/sbin/piranha-passwd
Erstellen Sie nach der Eingabe dieses Befehls das administrative Passwort, wenn Sie dazu aufgefordert werden.

Warnung

Damit ein Passwort sicherer ist, sollte es keine echten Substantive, häufig verwendete Akronyme oder Wörter aus einem Wörterbuch einer beliebigen Sprache enthalten. Hinterlassen Sie das Passwort nicht unverschlüsselt irgendwo auf dem System.
Falls sich das Passwort während einer aktiven Sitzung des Piranha Configuration Tool ändert, wird der Administrator aufgefordert, das neue Passwort einzugeben.

2.3. Starten des Piranha Configuration Tool Dienstes

Nachdem Sie das Passwort für das Piranha Configuration Tool gesetzt haben, starten Sie den piranha-gui-Dienst, der sich unter /etc/rc.d/init.d/piranha-gui befindet (neu). Führen Sie hierfür den folgenden Befehl als Root aus:
/sbin/service piranha-gui start
or
/sbin/service piranha-gui restart
Issuing this command starts a private session of the Apache HTTP Server by calling the symbolic link /usr/sbin/piranha_gui -> /usr/sbin/httpd. For security reasons, the piranha-gui version of httpd runs as the piranha user in a separate process. The fact that piranha-gui leverages the httpd service means that:
  1. Der Apache HTTP Server muss auf dem System installiert sein.
  2. Das Anhalten oder Neustarten des Apache HTTP Server durch den Befehl service hält den piranha-gui-Dienst an.

Warnung

Falls der Befehl /sbin/service httpd stop oder /sbin/service httpd restart auf einem LVS-Router ausgeführt wird, müssen Sie den piranha-gui-Dienst durch die Eingabe des folgenden Befehls starten:
/sbin/service piranha-gui start
The piranha-gui service is all that is necessary to begin configuring LVS. However, if you are configuring LVS remotely, the sshd service is also required. You do not need to start the pulse service until configuration using the Piranha Configuration Tool is complete. See Abschnitt 4.8, »Starten von LVS« for information on starting the pulse service.

2.3.1. Konfiguration des Web-Server-Ports für das Piranha Configuration Tool

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.

2.4. Zugangsbeschränkung zum Piranha Configuration Tool

Das Piranha Configuration Tool fordert Sie zur Eingabe eines gültigen Benutzernamens und eines Passworts auf. Da jedoch jegliche an das Piranha Configuration Tool gesendete Daten in reiner Textform vorliegen, wird empfohlen, dass Sie den Zugriff nur auf vertrauenswürdige Netzwerke oder die lokale Maschine beschränken.
The easiest way to restrict access is to use the Apache HTTP Server's built in access control mechanisms by editing /etc/sysconfig/ha/web/secure/.htaccess. After altering the file you do not have to restart the piranha-gui service because the server checks the .htaccess file each time it accesses the directory.
Standardmäßig gestattet die Zugriffskontrolle für dieses Verzeichnis jedem Benutzer die Anzeige des Inhalts des Verzeichnisses. So sieht der standardmäßige Zugriff aus:
Order deny,allow
Allow from all
Um den Zugriff auf das Piranha Configuration Tool auf 'localhost' zu beschränken, ändern Sie die Datei .htaccess so, dass der Zugriff nur noch vom Loopback-Gerät (127.0.0.1) aus erlaubt ist. Werfen Sie einen Blick auf das Kapitel mit dem Titel Netzwerkskripte im Red Hat Enterprise Linux Reference Guide für weitere Informationen zum Loopback-Gerät.
Order deny,allow
Deny from all
Allow from 127.0.0.1
Sie können auch spezielle Hosts oder Subnetze autorisieren, wie in diesem Beispiel gezeigt:
Order deny,allow
Deny from all
Allow from 192.168.1.100
Allow from 172.16.57
In diesem Beispiel können nur Web-Browser von den Maschinen mit der IP-Adresse 192.168.1.100 und von Maschinen aus dem 172.16.57/24 Netzwerk auf das Piranha Configuration Tool zugreifen.

Warnung

Das Bearbeiten der .htaccess-Datei des Piranha Configuration Tool schränkt den Zugriff auf die Konfigurationsseiten im Verzeichnis /etc/sysconfig/ha/web/secure/ ein, jedoch nicht für die Login- und Hilfeseiten in /etc/sysconfig/ha/web/. Um den Zugriff auf dieses Verzeichnis einzuschränken, müssen Sie eine .htaccess-Datei im Verzeichnis /etc/sysconfig/ha/web/ erstellen, und zwar mit zu /etc/sysconfig/ha/web/secure/.htaccess identischen Zeilen order, allow, und deny.

2.5. Aktivierung der Paketweiterleitung

Damit der LVS-Router Netzwerkpakete ordnungsgemäß an den realen Server weiterleiten kann, muss auf jedem LVS-Router IP-Weiterleitung im Kernel aktiviert sein. Loggen Sie sich als Root ein und ändern Sie die Zeile net.ipv4.ip_forward = 0 in /etc/sysctl.conf wie folgt:
net.ipv4.ip_forward = 1
Die Änderungen werden bei einem Neustart des Systems wirksam.
Um zu prüfen, ob IP-Weiterleitung aktiviert ist, geben Sie den folgenden Befehl als Root ein:
/sbin/sysctl net.ipv4.ip_forward
Falls der oben aufgeführte Befehl eine 1 zurückgibt, dann ist die IP-Weiterleitung aktiviert. Falls der Rückgabewert 0 lautet, dann können Sie die IP-Weiterleitung manuell mit dem folgenden Befehl aktivieren:
/sbin/sysctl -w net.ipv4.ip_forward=1

2.6. Konfiguration von Diensten auf den realen Servern

Falls die realen Server Red Hat Enterprise Linux-Systeme sind, richten Sie die entsprechenden Server-Daemons so ein, dass sie zum Zeitpunkt des Bootens aktiviert werden. Diese Daemons können httpd für Web-Dienste oder xinetd für FTP- oder Telnet-Dienste umfassen.
Es kann ggf. auch nützlich sein, von remote aus auf die realen Server zuzugreifen, so dass der sshd-Daemon auch installiert sein und laufen sollte.

Kapitel 3. Einrichten von LVS

LVS besteht aus zwei grundlegenden Gruppen: den LVS-Routern und den realen Servern. Um einen "Single Point of Failure" auszuschließen, sollte jede Gruppe mindestens zwei Mitgliedersysteme enthalten.
Die LVS-Router-Gruppe sollte aus zwei identischen oder sehr ähnlichen Systemen bestehen, auf denen Red Hat Enterprise Linux läuft. Einer agiert als der aktive LVS-Router, während der andere für den unmittelbaren Einsatz bereitsteht, so dass beide so weit wie möglich dieselben Fähigkeiten besitzen müssen.
Vor der Auswahl und der Konfiguration der Hardware für die Gruppe der realen Server müssen Sie ermitteln, welcher der drei Typen der LVS-Topologien verwendet werden soll.

3.1. Das NAT LVS-Netzwerk

Die NAT-Topologie bietet einen großen Spielraum bei der Verwendung von existierender Hardware, ist jedoch bei der Handhabung von großer Auslastung in seiner Fähigkeit auf Grund der Tatsache eingeschränkt, dass alle Pakete, die in den Pool ein-, bzw. austreten, den LVS-Router passieren müssen.
Netzwerk-Layout
Die Topologie für LVS unter Verwendung von NAT-Routing ist aus der Sicht eines Netzwerk-Layouts die einfachste, da nur ein Zugriffspunkt zum öffentlichen Netzwerk benötigt wird. Die realen Server geben alle Anfragen zurück an den LVS-Router, so dass sie sich in ihrem eigenen privaten Netzwerk befinden.
Hardware
Die NAT-Topologie ist die flexibelste hinsichtlich der Hardware, weil die realen Server keine Linux-Maschinen sein müssen, um ordnungsgemäß zu funktionieren. In einer NAT-Topologie benötigt jeder reale Server nur eine NIC, da er lediglich dem LVS-Router antwortet. Die LVS-Router dagegen benötigen jeweils zwei NICs, um den Datenverkehr zwischen den beiden Netzwerken zu routen. Da diese Topologie zu einem Engpass beim LVS-Router führt, können auf jedem LVS-Router Gigabit Ethernet-NICs eingesetzt werden, um die Bandbreite, die die LVS-Router handhaben können, zu erweitern. Falls ein Gigabit-Ethernet auf den LVS-Routern eingesetzt wird, muss jedes Switch, das die realen Server mit den LVS-Routern verbindet, mindestens zwei Gigabit-Ethernet-Ports besitzen, um die Auslastung effektiv zu bewältigen.
Software
Da die NAT-Topologie die Verwendung von iptables für einige Konfigurationen erfordert, kann einiges an Software-Konfiguration über Piranha Configuration Tool hinaus anfallen. Speziell FTP-Dienste und die Verwendung von Firewall-Markierungen erfordern zusätzliche manuelle Konfiguration der LVS-Router, um Anfragen ordnungsgemäß zu routen.

3.1.1. Konfiguration von Netzwerkschnittstellen für LVS mit NAT

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.

Wichtig

The sample Ethernet interface configuration settings in this section are for the real IP addresses of an LVS router and not the floating IP addresses. To configure the public and private floating IP addresses the administrator should use the Piranha Configuration Tool, as shown in Abschnitt 4.4, »GLOBAL SETTINGS« and Abschnitt 4.6.1, »Der Unterabschnitt VIRTUAL SERVER«.
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.

Wichtig

Stellen Sie sicher, dass jede Schnittstelle auf dem Backup-Knoten dasselbe Netzwerk wie die Schnittstelle auf dem primären Knoten bedient. Wenn eth0 beispielsweise mit dem öffentlichen Netzwerk auf dem primären Knoten verbunden ist, muss es ebenfalls mit dem öffentlichen Netzwerk auf dem Backup-Knoten verbunden sein.

3.1.2. Routing auf den realen Servern

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.

Anmerkung

Once the network interfaces are up on the real servers, the machines will be unable to ping or connect in other ways to the public network. This is normal. You will, however, be able to ping the real IP for the LVS router's private interface, in this case 10.11.12.8.
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

Warnung

Falls ein realer Server mehr als eine Netzwerkschnittstelle mit einer Zeile GATEWAY= konfiguriert hat, erhält die erste, die aktiv ist, die Gateway-Adresse. Wenn daher sowohl eth0 und eth1 konfiguriert sind und eth1 für LVS verwendet wird, kann es sein, dass die realen Server Anfragen ggf. nicht korrekt routen.
Irrelevante Netzwerkschnittstellen sollten am besten deaktiviert werden, indem ihre Netzwerkskripte im Verzeichnis /etc/sysconfig/network-scripts/ auf ONBOOT=no gesetzt werden oder indem sichergestellt wird, dass das Gateway bei der Schnittstelle korrekt eingerichtet wurde, die als erstes aktiviert wird.

3.1.3. Aktivierung von NAT-Routing auf den LVS-Routern

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.

Warnung

Do not configure the floating IP for eth0:1 or eth1:1 by manually editing network scripts or using a network configuration tool. Instead, use the Piranha Configuration Tool as shown in Abschnitt 4.4, »GLOBAL SETTINGS« and Abschnitt 4.6.1, »Der Unterabschnitt VIRTUAL SERVER«.
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.

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.

3.2.2. Direktes Routing und iptables

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:
  1. Führen Sie auf jedem realen Server den folgenden Befehl für jede VIP, jeden Port und jede Kombination von Protokollen (TCP oder UDP), die für die realen Server bedient werden sollen, aus:
    iptables -t nat -A PREROUTING -p <tcp|udp> -d <vip> --dport <port> -j REDIRECT
    Dieser Befehl veranlasst die realen Server, Pakete zu verarbeiten, die für die VIP und den spezifizierten Port bestimmt sind.
  2. Speichern Sie die Konfiguration auf jedem realen Server:
    # service iptables save
    # chkconfig --level 2345 iptables on
    Die oben aufgeführten Befehle veranlassen das System, die iptables-Konfiguration beim Booten neu zu laden — bevor das Netzwerk gestartet wird.

3.3. Zusammensetzen der Konfiguration

Nach der Festlegung, welche der oben aufgeführten Routing-Methoden verwendet werden soll, sollte die Hardware miteinander im Netzwerk verbunden werden.

Wichtig

Die Adapter-Geräte auf den LVS-Routern müssen so konfiguriert werden, dass sie auf dieselben Netzwerke zugreifen. Falls eth0 zum Beispiel mit dem öffentlichen Netzwerk und eth1 mit dem privaten Netzwerk verbunden ist, dann müssen dieselben Geräte auf dem Backup-LVS mit denselben Netzwerken verbunden sein.
Auch wird das in der ersten Schnittstelle aufgelistete Gateway, das zum Zeitpunkt des Bootens aktiviert wird, zur Routing-Tabelle hinzugefügt und nachfolgende Gateways, die in anderen Schnittstellen aufgeführt sind, werden ignoriert. Dies muss besonders bei der Konfiguration neuer Server bedacht werden.
Nachdem Sie die Hardware physikalisch miteinander verbunden haben, konfigurieren Sie die Netzwerkschnittstellen auf dem primären und den Backup-LVS-Routern. Hierzu können Sie eine grafische Applikation wie system-config-network verwenden, oder die Netzwerkskripte manuell bearbeiten. Werfen Sie einen Blick auf das Kapitel Netzwerkkonfiguration im Red Hat Enterprise Linux Deployment-Handbuch für weitere Informationen über das Hinzufügen von Geräten mit Hilfe von system-config-network. Was den Rest des Kapitels angeht, werden Änderungen an Netzwerkschnittstellen entweder manuell oder durch das Piranha Configuration Tool durchgeführt.

3.3.1. Allgemeine Tipps bezüglich LVS-Vernetzung

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.
Aktivieren von realen Netzwerkschnittstellen
Um eine reale Netzwerkschnittstelle zu aktivieren, führen Sie den folgenden Befehl als Root aus und ersetzen dabei N mit der entsprechenden Nummer der Schnittstelle (eth0 und eth1).
/sbin/ifup ethN

Warnung

Do not use the ifup scripts to bring up any floating IP addresses you may configure using Piranha Configuration Tool (eth0:1 or eth1:1). Use the service command to start pulse instead (see Abschnitt 4.8, »Starten von LVS« for details).
Deaktivieren von Schnittstellen des realen Netzwerks
Um eine reale Netzwerkschnittstelle zu deaktivieren, führen Sie den folgenden Befehl als Root aus und ersetzen dabei N mit der entsprechenden Nummer der Schnittstelle (eth0 und eth1).
/sbin/ifdown ethN
Überprüfen des Status von Netzwerkschnittstellen
Falls Sie zu jedem beliebigen Zeitpunkt überprüfen müssen, welche Netzwerkschnittstellen aktiviert sind, geben Sie Folgendes ein:
/sbin/ifconfig
Um die Routing-Tabelle für eine Maschine anzusehen, führen Sie den folgenden Befehl aus:
/sbin/route

3.4. Multiport-Dienste und LVS

LVS routers under any topology require extra configuration when creating multi-port LVS services. Multi-port services can be created artificially by using firewall marks to bundle together different, but related protocols, such as HTTP (port 80) and HTTPS (port 443), or when LVS is used with true multi-port protocols, such as FTP. In either case, the LVS router uses firewall marks to recognize that packets destined for different ports, but bearing the same firewall mark, should be handled identically. Also, when combined with persistence, firewall marks ensure connections from the client machine are routed to the same host, as long as the connections occur within the length of time specified by the persistence parameter. For more on assigning persistence to a virtual server, see Abschnitt 4.6.1, »Der Unterabschnitt VIRTUAL SERVER«.
Leider kann der Mechanismus, der für die Lastverteilung auf den realen Servern verwendet wird — IPVS — zwar die Firewall-Markierungen erkennen, die einem Paket zugeordnet sind, kann jedoch nicht selbst Firewall-Markierungen zuweisen. Der Job der Zuweisung von Firewall-Markierungen muss vom Netzwerk-Paketfilter iptables außerhalb des Piranha Configuration Tool durchgeführt werden.

3.4.1. Zuweisen von Firewall-Markierungen

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.

Warnung

The commands above will take effect immediately, but do not persist through a reboot of the system. To ensure network packet filter settings are restored upon reboot, refer to Abschnitt 3.6, »Speichern der Einstellungen des Netzwerkpaketfilters«

3.5. Konfiguration von FTP

Das File Transport Protocol (FTP) ist ein altes und komplexes Multiport-Protokoll, welches eine Reihe von Herausforderungen in einer LVS-Umgebung mit sich bringt. Um die Art dieser Herausforderungen zu verstehen, müssen Sie zunächst ein paar zentrale Dinge über die Funktionsweise von FTP verstehen.

3.5.1. Funktionsweise von FTP

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:
Aktive Verbindungen
Beim Aufbau einer aktiven Verbindung öffnet der Server eine Datenverbindung mit dem Client von Port 20 bis zu einem Port in einem hohen Bereich auf der Client-Maschine. Alle Daten vom Server werden dann über diese Verbindung weitergeleitet.
Passive Verbindungen
Beim Aufbau einer passiven Verbindung fragt der Client beim FTP-Server bezüglich des Aufbaus eines Ports für eine passive Verbindung an, der sich auf jedem Port größer als 10,000 befinden kann. Der Server wird dann an diesen großzahligen Port für diese spezielle Sitzung gebunden und leitet die Portnummer zurück an den Client. Der Client öffnet dann den neu gebundenen Port für die Datenverbindung. Jede Datenanfrage, die der Client durchführt, resultiert in einer separaten Datenverbindung. Die meisten modernen FTP-Clients versuchen bei der Abfrage von Daten von Servern eine passive Verbindung aufzubauen.

Anmerkung

Der Client ermittelt den Verbindungstyp, nicht der Server. Dies bedeutet, dass der LVS-Router so konfiguriert werden muss, dass er sowohl aktive, als auch passive Verbindungen unterstützt, um FTP effektiv zu clustern.
Die Verbindung FTP-Client/Server kann potentiell eine große Anzahl an Ports öffnen, die dem Piranha Configuration Tool und IPVS nicht bekannt sind.

3.5.2. Auswirkungen auf das LVS-Routing

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.

3.5.3. Erstellen von Netzwerk-Paketfilterregeln

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.

3.5.3.1. Regeln für aktive Verbindungen

Die Regeln für aktive Verbindungen teilen dem Kernel mit, Verbindungen zu akzeptieren und weiterzuleiten, die auf der internen floating IP-Adresse auf Port 20 ankommen — dem FTP-Datenport.
Der folgende iptables-Befehl ermöglicht dem LVS-Router, ausgehende Verbindungen von realen Servern, über die das IPVS nichts weiß, zu akzeptieren:
/sbin/iptables -t nat -A POSTROUTING -p tcp -s n.n.n.0/24 --sport 20 -j MASQUERADE
In the iptables command, n.n.n should be replaced with the first three values for the floating IP for the NAT interface's internal network interface defined in the GLOBAL SETTINGS panel of Piranha Configuration Tool.

3.5.3.2. Regeln für passive Verbindungen

Die Regeln für passive Verbindungen weisen die entsprechende Firewall-Markierung für Verbindungen zu, die aus dem Internet an die floating IP für den Dienst auf einer großen Bandbreite an Ports eingehen — 10,000 to 20,000.

Warnung

Falls Sie die Port-Bandbreite für passive Verbindungen einschränken, müssen Sie auch den VSFTP-Server so konfigurieren, dass er eine passende Port-Bandbreite verwendet. Dies erreicht man, indem folgende Zeilen zu /etc/vsftpd.conf hinzugefügt werden:
pasv_min_port=10000
pasv_max_port=20000
Sie müssen auch die Adresse kontrollieren, die der Server dem Client für passive FTP-Verbindungen anzeigt. Fügen Sie in einem NAT-gerouteten LVS-System die folgende Zeile zu /etc/vsftpd.conf hinzu, um die IP-Adresse des realen Servers mit der des VIP außer Kraft zu setzen, welche diejenige ist, die ein Client bei einer Verbindung sieht. Zum Beispiel:
pasv_address=n.n.n.n
Ersetzen Sie n.n.n.n mit der VIP-Adresse des LVS-Systems.
Konsultieren Sie zur Konfiguration weiterer FTP-Server die entsprechende Dokumentation.
Diese Bandbreite sollte für die meisten Situationen ausreichen. Sie können die Zahl jedoch auch so erhöhen, dass alle verfügbaren nicht-sicheren Ports enthalten sind, indem Sie 10000:20000 im unten aufgeführten Befehl in 1024:65535 ändern.
Die folgenden iptables-Befehle haben den reinen Effekt, dass jeglichem Datenverkehr, der an die floating IP auf dem entsprechenden Port gerichtet ist, eine Firewall-Markierung von 21 zugewiesen wird, was im Gegenzug von IPVS erkannt und entsprechend weitergeleitet wird:
/sbin/iptables -t mangle -A PREROUTING -p tcp -d n.n.n.n/32 --dport 21 -j MARK --set-mark 21
/sbin/iptables -t mangle -A PREROUTING -p tcp -d n.n.n.n/32 --dport 10000:20000 -j MARK --set-mark 21
In den iptables-Befehlen sollte n.n.n.n durch die floating IP für den virtuellen FTP-Server ersetzt werden, wie im Unterabschnitt VIRTUAL SERVER des Piranha Configuration Tool definiert.

Warnung

The commands above take effect immediately, but do not persist through a reboot of the system. To ensure network packet filter settings are restored after a reboot, see Abschnitt 3.6, »Speichern der Einstellungen des Netzwerkpaketfilters«
Finally, you need to be sure that the appropriate service is set to activate on the proper runlevels. For more on this, refer to Abschnitt 2.1, »Konfiguration von Diensten auf den LVS-Routern«.

3.6. Speichern der Einstellungen des Netzwerkpaketfilters

Speichern Sie die Einstellungen nach der Konfiguration der entsprechenden Netzwerkpaketfilter für Ihre Situation, damit diese bei einem Neustart wieder hergestellt werden. Geben Sie den folgenden Befehl für iptables ein:
/sbin/service iptables save
Dies speichert die Einstellungen in /etc/sysconfig/iptables, so dass sie zum Zeitpunkt des Bootens wieder abgerufen werden können.
Once this file is written, you are able to use the /sbin/service command to start, stop, and check the status (using the status switch) of iptables. The /sbin/service will automatically load the appropriate module for you. For an example of how to use the /sbin/service command, see Abschnitt 2.3, »Starten des Piranha Configuration Tool Dienstes«.
Finally, you need to be sure the appropriate service is set to activate on the proper runlevels. For more on this, see Abschnitt 2.1, »Konfiguration von Diensten auf den LVS-Routern«.
Im nächsten Kapitel wird erklärt, wie das Piranha Configuration Tool verwendet wird, um den LVS-Router zu konfigurieren und beschreibt die notwendigen Schritte, um LVS zu aktivieren.

Kapitel 4. Konfiguration der LVS-Router mit dem Piranha Configuration Tool

Das Piranha Configuration Tool liefert einen strukturierten Ansatz zur Erstellung der nötigen Konfigurationsdatei für LVS — /etc/sysconfig/ha/lvs.cf. Dieses Kapitel beschreibt die grundlegenden Funktionen des Piranha Configuration Tool und der Aktivierung von LVS nach Abschluss der Konfiguration.

Wichtig

Die Konfigurationsdatei für LVS befolgt strenge Formatierungsregeln. Das Verwenden des Piranha Configuration Tool ist der beste Weg, syntaktische Fehler in lvs.cf und damit Software-Ausfälle zu vermeiden.

4.1. Benötigte Software

Der Dienst piranha-gui muss auf dem primären LVS-Router laufen, um das Piranha Configuration Tool benutzen zu können. Um LVS konfigurieren zu können, brauchen Sie mindestens einen Text-Browser, wie links. Falls Sie von einer anderen Maschine aus auf den LVS-Router zugreifen, brauchen Sie außerdem eine ssh-Verbindung mit dem primären LVS-Router als Root-Benutzer.
Während der Konfiguration des primären LVS-Routers ist es eine gute Idee, parallel eine ssh-Verbindung in einem Terminal-Fenster offen zu haben. Diese Verbindung liefert eine sichere Möglichkeit, pulse und andere Dienste neu zu starten, Netzwerk-Paketfilter zu konfigurieren und /var/log/messages auf der Suche nach Fehlern zu überwachen.
Die nächsten vier Abschnitte führen Sie durch jede der Konfigurationsseiten des Piranha Configuration Tool und geben Anweisungen, wie es zur Einrichtung von LVS verwendet werden kann.

4.2. Einloggen in das Piranha Configuration Tool

When configuring LVS, you should always begin by configuring the primary router with the Piranha Configuration Tool. To do this,verify that the piranha-gui service is running and an administrative password has been set, as described in Abschnitt 2.2, »Einrichten eines Passworts für das Piranha Configuration Tool«.
If you are accessing the machine locally, you can open http://localhost:3636 in a Web browser to access the Piranha Configuration Tool. Otherwise, type in the hostname or real IP address for the server followed by :3636. Once the browser connects, you will see the screen shown in Abbildung 4.1, »The Welcome Panel«.
The Welcome Panel

Abbildung 4.1. The Welcome Panel

Klicken Sie auf die Schaltfläche Login und geben Sie piranha als Username und das administrative Passwort, dass Sie im Feld Password erstellt haben, ein.
Das Piranha Configuration Tool besteht aus vier Haupt-Bildschirmen oder Panels. Zusätzlich enthält das Panel VIRTUAL SERVERS vier Unterabschnitte. Das Panel CONTROL/MONITORING ist das erste Panel nach der Login-Seite.

4.3. CONTROL/MONITORING

Das Panel CONTROL/MONITORING liefert einen eingeschränkten Laufzeit-Status von LVS. Es zeigt den Status des pulse-Daemon, der LVS-Routing-Tabelle und den von LVS erzeugten nanny-Prozessen an.

Anmerkung

The fields for CURRENT LVS ROUTING TABLE and CURRENT LVS PROCESSES remain blank until you actually start LVS, as shown in Abschnitt 4.8, »Starten von LVS«.
The CONTROL/MONITORING Panel

Abbildung 4.2. The CONTROL/MONITORING Panel

Auto update
Die Statusanzeige dieser Seite kann zu einem vom Benutzer konfigurierten Intervall automatisch aktualisiert werden. Klicken Sie auf Auto update und setzen Sie die gewünschte Aktualisierungsfrequenz im Textfeld Update frequency in seconds (der Standardwert ist 10 Sekunden).
Es wird nicht empfohlen, die automatische Aktualisierung auf ein Zeitintervall von weniger als 10 Sekunden zu setzen. Andernfalls kann es problematisch werden, das Zeitintervall für die Auto update neu zu konfigurieren, da die Seite zu schnell neu lädt. Falls Sie dieses Problem haben, klicken Sie einfach auf ein anderes Panel und dann zurück auf CONTROL/MONITORING.
Das Auto update-Feature funktioniert nicht mit allen Browsern, wie beispielsweise Mozilla.
Update information now
Sie können die Statusinformationen manuell aktualisieren, indem Sie auf diese Schaltfläche klicken.
CHANGE PASSWORD
Ein Klick auf diese Schaltfläche führt Sie zu einer Hilfeseite mit Informationen, wie Sie das administrative Passwort für das Piranha Configuration Tool ändern können.

4.4. GLOBAL SETTINGS

The GLOBAL SETTINGS panel is where the you define the networking details for the primary LVS router's public and private network interfaces.
The GLOBAL SETTINGS Panel

Abbildung 4.3. The GLOBAL SETTINGS Panel

The top half of this panel sets up the primary LVS router's public and private network interfaces. These are the interfaces already configured in Abschnitt 3.1.1, »Konfiguration von Netzwerkschnittstellen für LVS mit NAT«.
Primary server public IP
Geben Sie in diesem Feld die öffentlich routbare reale IP-Adresse für den primären LVS-Knoten ein.
Primary server private IP
Enter the real IP address for an alternative network interface on the primary LVS node. This address is used solely as an alternative heartbeat channel for the backup router and does not have to correlate to the real private IP address assigned in Abschnitt 3.1.1, »Konfiguration von Netzwerkschnittstellen für LVS mit NAT«. You may leave this field blank, but doing so will mean there is no alternate heartbeat channel for the backup LVS router to use and therefore will create a single point of failure.

Anmerkung

Die private IP wird nicht für Konfigurationen, die Direktes Routing verwenden, benötigt, da alle realen Server, wie auch die LVS-Directors dieselbe virtuelle IP-Adresse teilen und dieselbe IP-Route-Konfiguration besitzen sollten.

Anmerkung

The primary LVS router's private IP can be configured on any interface that accepts TCP/IP, whether it be an Ethernet adapter or a serial port.
Use network type
Klicken Sie auf die Schaltfläche NAT, um NAT-Routing auszuwählen.
Klicken Sie auf die Schaltfläche Direct Routing, um direktes Routing auszuwählen.
The next three fields deal specifically with the NAT router's virtual network interface connecting the private network with the real servers. These fields do not apply to the direct routing network type.
NAT Router IP
Geben Sie die private floating IP in dieses Textfeld ein. Diese floating IP sollte als Gateway für die realen Server verwendet werden.
NAT Router netmask
If the NAT router's floating IP needs a particular netmask, select it from drop-down list.
NAT Router device
Verwenden Sie dieses Textfeld, um den Gerätenamen der Netzwerkschnittstelle für die floating IP-Adresse zu definieren, wie beispielsweise eth1:1.

Anmerkung

Sie sollten einen Alias für die NAT floating IP-Adresse mit der Ethernet-Schnittstelle, die mit dem privaten Netzwerk verbunden ist, kreieren. In diesem Beispiel befindet sich das private Netzwerk auf der eth1-Schnittstelle, so dass eth1:1 die floating IP-Adresse darstellt.

Warnung

Klicken Sie nach Fertigstellung dieser Seite auf die Schaltfläche ACCEPT um sicherzustellen, dass Sie keine Änderungen verlieren, wenn Sie ein neues Panel auswählen.

4.5. REDUNDANCY

Das Panel REDUNDANCY ermöglicht Ihnen die Konfiguration des Backup-LVS-Router-Knotens und das Einstellen verschiedener Heartbeat-Überwachungsoptionen.

Anmerkung

The first time you visit this screen, it displays an "inactive" Backup status and an ENABLE button. To configure the backup LVS router, click on the ENABLE button so that the screen matches Abbildung 4.4, »The REDUNDANCY Panel«.
The REDUNDANCY Panel

Abbildung 4.4. The REDUNDANCY Panel

Redundant server public IP
Geben Sie die öffentliche reale IP-Adresse für den Backup-LVS-Router-Knoten an.
Redundant server private IP
Enter the backup node's private real IP address in this text field.
Falls Sie das Feld Redundant server private IP nicht sehen können, gehen Sie zurück zum Panel GLOBAL SETTINGS, geben Sie eine Primary server private IP Adresse ein und klicken Sie auf ACCEPT.
Der Rest des Panels ist für die Konfiguration des Heartbeat-Kanals gedacht, welcher von dem Backup-Knoten zur Überwachung des primären Knotens hinsichtlich eines Ausfall verwendet wird.
Heartbeat Interval (seconds)
In diesem Feld werden die Anzahl der Sekunden zwischen den Heartbeats gesetzt — Dies ist das Intervall, in dem der Backup-Knoten den funktionalen Status des primären LVS-Knoten überprüft.
Assume dead after (seconds)
Falls der primäre LVS-Knoten nicht nach dieser Anzahl an Sekunden antwortet, leitet der Backup-LVS-Knoten die Ausfallsicherung ein.
Heartbeat runs on port
In diesem Feld wird der Port eingestellt, auf dem der Heartbeat mit dem primären LVS-Knoten kommuniziert. Der Standardwert beträgt 539, falls dieses Feld leer gelassen wird.

Warnung

Denken Sie nach dem Ändern dieser Seite daran, auf die Schaltfläche ACCEPT zu klicken, um sicherzustellen, dass Sie keine Änderungen verlieren, wenn Sie ein neues Panel auswählen.

4.6. VIRTUAL SERVERS

Das Panel VIRTUAL SERVERS zeigt Informationen zu jedem derzeit definierten virtuellen Server an. Jeder Tabelleneintrag zeigt den Status des virtuellen Servers, dessen Namen, die dem Server zugeteilte virtuelle IP, die Netzmaske der virtuellen IP, die Portnummer, auf der der Dienst kommuniziert, das verwendete Protokoll und die Schnittstelle des virtuellen Geräts.
The VIRTUAL SERVERS Panel

Abbildung 4.5. The VIRTUAL SERVERS Panel

Jeder Server, der im Panel VIRTUAL SERVERS angezeigt wird, kann auf den nachfolgenden Bildschirmen oder Unterabschnitten konfiguriert werden.
Um einen Dienst hinzuzufügen, klicken Sie auf die Schaltfläche ADD. Um einen Dienst zu entfernen, wählen Sie diesen aus, indem Sie auf das Auswahlsymbol neben dem virtuellen Server und dann auf die Schaltfläche DELETE klicken.
Um einen virtuellen Server in der Tabelle zu aktivieren oder zu deaktivieren, klicken Sie auf dessen Auswahlsymbol und anschließend auf die Schaltfläche (DE)ACTIVATE.
Nach Hinzufügen eines virtuellen Servers, können Sie diesen konfigurieren, indem Sie auf das Auswahlsymbol links daneben und anschließend auf die Schaltfläche EDIT klicken, um den Unterabschnitt VIRTUAL SERVER anzuzeigen.

4.6.1. Der Unterabschnitt VIRTUAL SERVER

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.
The VIRTUAL SERVERS Subsection

Abbildung 4.6. The VIRTUAL SERVERS Subsection

Name
Geben Sie einen aussagekräftigen Namen zur Identifikation des virtuellen Servers an. Dieser Name ist nicht der Hostname für die Maschine und sollte daher veranschaulichend und einfach identifizierbar sein. Sie können sogar das Protokoll angeben, das vom virtuellen Server verwendet werden soll, wie zum Beispiel HTTP.
Application port
Geben Sie die Portnummer ein, auf der die Dienst-Applikation horcht. Nachdem dieses Beispiel für HTTP-Dienste gilt, wird Port 80 verwendet.
Protocol
Wählen Sie im Drop-Down-Menü zwischen UDP und TCP. Web-Server kommunizieren typischerweise via TCP-Protokoll, weswegen dies im oben aufgeführten Beispiel ausgewählt ist.
Virtual IP Address
Enter the virtual server's floating IP address in this text field.
Virtual IP Network Mask
Setzen Sie die Netzmaske für diesen virtuellen Server mit Hilfe des Drop-Down-Menüs.
Firewall Mark
Geben Sie keinen ganzzahligen Wert für Firewall-Markierungen in diesem Feld an, bevor Sie nicht Multiport-Protokolle zusammenfassen oder einen virtuellen Multiport-Server für getrennte, jedoch zusammenhängende Protokolle erstellen. In diesem Beispiel besitzt der oben aufgeführte virtuelle Server eine Firewall Mark von 80, da wir Verbindungen zu HTTP auf Port 80 und zu HTTPS auf Port 443 mit Hilfe des Firewall-Markierungswert 80 zusammenfassen. Zusammen mit Persistenz stellt diese Technik sicher, dass Benutzer, die sowohl auf unsichere, als auch sichere Webseiten zugreifen an denselben realen Server weitergeleitet werden und gleichzeitig der Status beibehalten wird.

Warnung

Entering a firewall mark in this field allows IPVS to recognize that packets bearing this firewall mark are treated the same, but you must perform further configuration outside of the Piranha Configuration Tool to actually assign the firewall marks. See Abschnitt 3.4, »Multiport-Dienste und LVS« for instructions on creating multi-port services and Abschnitt 3.5, »Konfiguration von FTP« for creating a highly available FTP virtual server.
Device
Geben Sie den Namen der Netzwerkschnittstelle, mit der Sie die floating IP-Adresse, die im Feld Virtual IP Address definiert ist, verknüpft haben möchten.
Sie sollten einen Alias für die öffentliche floating IP-Adresse mit der Ethernet-Schnittstelle, die mit dem privaten Netzwerk verbunden ist, kreieren. In diesem Beispiel befindet sich das private Netzwerk auf der eth0-Schnittstelle, so dass eth0:1 als der Gerätename eingegeben werden sollte.
Re-entry Time
Geben Sie einen ganzzahligen Wert ein, der die Länge der Zeitspanne in Sekunden definiert, bevor der aktive LVS-Router versucht, einen realen Server nach Ausfall wieder in den Pool zu integrieren.
Service Timeout
Geben Sie einen ganzzahligen Wert ein, der die Länge der Zeitspanne in Sekunden definiert, bevor der reale Server als inaktiv angesehen und aus dem Pool entfernt wird.
Quiesce server
Wenn das Auswahlsymbol Quiesce server aktiviert ist, wird - jedes Mal, wenn ein neuer realer Server-Knoten online geht - die Tabelle mit den wenigsten Verbindungen auf Null zurückgesetzt, so dass der aktive LVS-Router Anfragen so routet, als ob alle realen Server frisch zum Pool hinzugefügt wurden. Diese Optionen verhindert, dass sich ein neuer Server beim Eintreten in einen Pool durch eine hohe Anzahl an Verbindungen verzettelt.
Load monitoring tool
Der LVS-Router kann die Auslastung auf verschiedenen realen Servern entweder mit Hilfe von rup oder ruptime überwachen. Falls Sie rup aus dem Drop-Down-Menü auswählen muss auf jedem realen Server der rstatd-Dienst laufen. Falls Sie ruptime auswählen, muss auf jedem realen Server der rwhod-Dienst laufen.

Warnung

Die Überwachung der Auslastung ist nicht dasselbe, wie die Lastverteilung und kann in schwer vorhersagbares Scheduling-Verhalten resultieren, wenn sie mit gewichteten Scheduling-Algorithmen verknüpft wird. Weiterhin müssen die realen Server Linux-Maschinen sein, wenn Sie die Überwachung der Auslastung verwenden.
Scheduling
Select your preferred scheduling algorithm from the drop-down menu. The default is Weighted least-connection. For more information on scheduling algorithms, see Abschnitt 1.3.1, »Scheduling-Algorithmen«.
Persistence
Falls ein Administrator persistente Verbindungen während einer Client-Transaktion zum virtuellen Server benötigt, geben Sie die Anzahl der Sekunden von Inaktivität ein, die verstreichen dürfen, bevor eine Verbindung in diesem Textfeld zeitlich abläuft.

Wichtig

If you entered a value in the Firewall Mark field above, you should enter a value for persistence as well. Also, be sure that if you use firewall marks and persistence together, that the amount of persistence is the same for each virtual server with the firewall mark. For more on persistence and firewall marks, refer to Abschnitt 1.5, »Persistenz und Firewall-Markierungen«.
Persistence Network Mask
Um die Persistenz für ein bestimmtes Subnetz einzuschränken, wählen Sie die entsprechende Netzwerkmaske aus dem Drop-Down-Menü.

Anmerkung

Vor der Einführung von Firewall-Markierungen, war die durch Subnetze eingeschränkte Persistenz eine umständliche Möglichkeit, Verbindungen zusammenzufassen. Gegenwärtig ist es am besten, Persistenz in Verbindung mit Firewall-Markierungen zu verwenden, um dasselbe Ergebnis zu erzielen.

Warnung

Denken Sie nach dem Ändern dieser Seite daran, auf die Schaltfläche ACCEPT zu klicken, um sicherzustellen, dass Sie keine Änderungen verlieren, wenn Sie ein neues Panel auswählen.

4.6.2. Der Unterabschnitt REAL SERVER

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.
The REAL SERVER Subsection

Abbildung 4.7. The REAL SERVER Subsection

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«.
The REAL SERVER Configuration Panel

Abbildung 4.8. The REAL SERVER Configuration Panel

Dieses Panel besteht aus drei Eingabefeldern:
Name
Ein veranschaulichender Name für den realen Server.

Anmerkung

Dieser Name ist nicht der Hostname für die Maschine und sollte daher veranschaulichend und einfach identifizierbar sein.
Address
The real server's IP address. Since the listening port is already specified for the associated virtual server, do not add a port number.
Weight
An integer value indicating this host's capacity relative to that of other hosts in the pool. The value can be arbitrary, but treat it as a ratio in relation to other real servers in the pool. For more on server weight, see Abschnitt 1.3.2, »Server-Gewichtung und Scheduling«.

Warnung

Denken Sie nach dem Ändern dieser Seite daran, auf die Schaltfläche ACCEPT zu klicken, um sicherzustellen, dass Sie keine Änderungen verlieren, wenn Sie ein neues Panel auswählen.

4.6.3. EDIT MONITORING SCRIPTS Subsection

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.
The EDIT MONITORING SCRIPTS Subsection

Abbildung 4.9. The EDIT MONITORING SCRIPTS Subsection

Sending Program
Zur etwas fortgeschrittenen Dienstverifizierung können Sie dieses Feld zur Angabe des Pfades zu einem Skript zur Überprüfung eines Dienstes verwenden. Diese Funktion ist besonders für Dienste hilfreich, die dynamisch verändernde Daten erfordern, wie beispielsweise HTTPS oder SSL.
Um diese Funktion zu verwenden, müssen Sie ein Skript schreiben, das eine Antwort in Textform zurückgibt, dieses ausführbar machen und den Pfad im Feld Sending Program eingeben.

Anmerkung

To ensure that each server in the real server pool is checked, use the special token %h after the path to the script in the Sending Program field. This token is replaced with each real server's IP address as the script is called by the nanny daemon.
Nachfolgend ist ein Beispiel-Skript aufgeführt, das bei der Zusammenstellung eines externen Skript zur Überprüfung von Diensten als Vorlage verwendet werden kann:
#!/bin/sh

TEST=`dig -t soa example.com @$1 | grep -c dns.example.com

if [ $TEST != "1" ]; then
	echo "OK
else
	echo "FAIL"
fi

Anmerkung

Falls im Feld Sending Program ein externes Programm eingegeben wird, dann wird das Feld Send ignoriert.
Send
Geben Sie einen String für den nanny-Daemon ein, der an jeden realen Server in diesem Feld gesendet werden soll. Standardmäßig wird das Send-Feld für HTTP vervollständigt. Sie können diesen Wert abhängig von Ihren Anforderungen ändern. Wenn Sie dieses Feld leer lassen, versucht der nanny-Daemon, den Port zu öffnen und geht davon aus, dass der Dienst läuft, wenn er erfolgreich ist.
Nur eine Send-Sequenz ist in diesem Feld gestattet und es kann nur druckbare, ASCII-Zeichen, sowie die folgenden Code-Umschaltzeichen enthalten:
  • \n für Zeilenumbruch.
  • \r für Wagenrücklauf.
  • \t für Tabulator.
  • \ für den Escape des nächsten Zeichens, das darauf folgt.
Expect
Geben Sie eine Antwort in Textform ein, die der Server zurückgeben soll, falls er ordnungsgemäß funktioniert. Falls Sie Ihr eigenes Programm zum Versenden geschrieben haben, geben Sie die Antwort ein, die sie ihm im Falle eines Erfolgs zugewiesen haben.

Anmerkung

Um zu ermitteln, was für einen vorgegebenen Dienst versendet werden soll, können Sie eine telnet-Verbindung mit dem Port auf dem realen Server herstellen und so sehen, was dieser zurückgibt. So gibt FTP beispielsweise 220 bei der Verbindung zurück, so dass Sie quit im Feld Send und 220 im Feld Expect eingeben könnten.

Warnung

Denken Sie nach dem Ändern dieser Seite daran, auf die Schaltfläche ACCEPT zu klicken, um sicherzustellen, dass Sie keine Änderungen verlieren, wenn Sie ein neues Panel auswählen.
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.

4.7. Synchronisation von Konfigurationsdateien

Nach der Konfiguration des primären LVS-Routers gibt es mehrere Konfigurationsdateien, die auf den Backup-LVS-Router kopiert werden müssen, bevor Sie LVS starten können.
Diese Dateien umfassen:
  • /etc/sysconfig/ha/lvs.cf — Die Konfigurationsdatei für die LVS-Router.
  • /etc/sysctl — Die Konfigurationsdatei, die neben anderen Dingen die Paketweiterleitung im Kernel aktiviert.
  • /etc/sysconfig/iptables — Falls Sie Firewall-Markierungen verwenden, sollten Sie eine dieser Dateien synchronisieren, abhängig davon, welchen Paketfilter Sie verwenden.

Wichtig

Die Dateien /etc/sysctl.conf und /etc/sysconfig/iptables ändern sich nicht, wenn Sie LVS mit dem Piranha Configuration Tool konfigurieren.

4.7.1. Synchronisation von lvs.cf

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.

Warnung

Sowohl der aktive, als auch der Backup-LVS-Router-Knoten muss identische lvs.cf-Dateien besitzen. LVS-Konfigurationsdateien unter den LVS-Router-Knoten können eine Ausfallsicherung verhindern.
Am besten kann dies mit scp durchgeführt werden.

Wichtig

To use scp the sshd must be running on the backup router, see Abschnitt 2.1, »Konfiguration von Diensten auf den LVS-Routern« for details on how to properly configure the necessary services on the LVS routers.
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.

4.7.2. Synchronisation von sysctl

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.

Wichtig

If you are not sure whether or not packet forwarding is enabled in the kernel, see Abschnitt 2.5, »Aktivierung der Paketweiterleitung« for instructions on how to check and, if necessary, enable this key functionality.

4.7.3. Synchronisation von Regeln zur Netzwerk-Paket-Filterung

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.

4.8. Starten von LVS

Um LVS zu starten, eignen sich zwei simultan geöffnete Root-Terminals oder zwei von Root simultan geöffnete ssh-Sitzungen zum primären LVS-Router am besten.
Überwachen Sie in einem Terminal die Protokollmeldungen des Kernels mit dem Befehl:
tail -f /var/log/messages
Starten Sie anschließend LVS mit dem folgenden Befehl in dem anderen Terminal:
/sbin/service pulse start
Follow the progress of the pulse service's startup in the terminal with the kernel log messages. When you see the following output, the pulse daemon has started properly:
gratuitous lvs arps finished
Drücken Sie Strg+c, um das Beobachten von /var/log/messages zu beenden.
Ab diesem Punkt ist der primäre LVS-Router auch der aktive LVS-Router. Auch wenn an diesem Punkt bereits Anfragen an LVS gestellt werden können, sollten Sie den Backup-LVS-Router starten, bevor Sie LVS in Betrieb nehmen. Führen Sie hierfür einfach den oben beschriebenen Prozess für den Backup-LVS-Router-Knoten erneut durch.
Nach Abschluss des letzten Schritts, ist LVS aktiv und läuft.

Anhang A. Die Verwendung von LVS in einem Red Hat Cluster

Sie können LVS-Router mit einem Red Hat Cluster verwenden, um eine hochverfügbare E-Commerce-Site einzusetzen, die Lastverteilung, Datenintegrität und Verfügbarkeit von Applikationen bietet.
The configuration in Abbildung A.1, »LVS with a Red Hat Cluster« represents an e-commerce site used for online merchandise ordering through a URL. Client requests to the URL pass through the firewall to the active LVS load-balancing router, which then forwards the requests to one of the Web servers. The Red Hat Cluster nodes serve dynamic data to the Web servers, which forward the data to the requesting client.
LVS with a Red Hat Cluster

Abbildung A.1. LVS with a Red Hat Cluster

Serving dynamic Web content with LVS requires a three-tier configuration (as shown in Abbildung A.1, »LVS with a Red Hat Cluster«). This combination of LVS and Red Hat Cluster allows for the configuration of a high-integrity, no-single-point-of-failure e-commerce site. The Red Hat Cluster can run a high-availability instance of a database or a set of databases that are network-accessible to the Web servers.
Eine Three-Tier-Konfiguration wird benötigt, um dynamischen Inhalt zur Verfügung zu stellen. Auch wenn eine Two-Tier-LVS-Konfiguration für die Bereitstellung von statischem Web-Inhalt (bestehend aus einer geringen Menge von sich selten verändernden Daten) durch Web-Server geeignet ist, ist sie nicht dafür geeignet, wenn die Web-Server dynamischen Inhalt bereitstellen. Dynamischer Inhalt könnte Warenbestand, Bestellungen oder Kundendatenbanken beinhalten, welche auf allen Web-Servern einheitlich sein müssen, um zu gewährleisten, dass Kunden Zugriff auf aktuelle und präzise Informationen hat.
Jede Tier liefert die folgenden Funktionen:
  • Erste Tier — LVS-Router, die Lastverteilung durchführen, um Web-Anfragen zu verteilen.
  • Zweite Tier — Eine Reihe von Web-Servern, die die Anfragen bearbeiten.
  • Dritte Tier — Ein Red Hat Cluster, das Daten für die Web-Server liefert.
In an LVS configuration like the one in Abbildung A.1, »LVS with a Red Hat Cluster«, client systems issue requests on the World Wide Web. For security reasons, these requests enter a Web site through a firewall, which can be a Linux system serving in that capacity or a dedicated firewall device. For redundancy, you can configure firewall devices in a failover configuration. Behind the firewall are LVS load-balancing routers, which can be configured in an active-standby mode. The active load-balancing router forwards the requests to the set of Web servers.
Each Web server can independently process an HTTP request from a client and send the response back to the client. LVS enables you to expand a Web site's capacity by adding Web servers behind the LVS routers; the LVS routers perform load balancing across a wider set of Web servers. In addition, if a Web server fails, it can be removed; LVS continues to perform load balancing across a smaller set of Web servers.

Anhang B. Revision History

Versionsgeschichte
Version 5-8.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
Version 5-82012-07-18Anthony Towns
Rebuild for Publican 3.0
Version 2.0-0Mon Feb 08 2010Paul Kennedy
Resolves: 492000
Changes -d to -s in arptables "OUT" directive in "Direct Routing and arptables_jf" section.
Version 1.0-0Tue Jan 20 2009Paul Kennedy
Consolidation of point releases

Stichwortverzeichnis

Symbole

/etc/sysconfig/ha/lvs.cf file, /etc/sysconfig/ha/lvs.cf

D

direct routing
and arptables_jf, Direktes Routing und arptables_jf

F

feedback, Feedback
FTP, Konfiguration von FTP
(Siehe auch LVS)

I

introduction, Introduction
other Red Hat Enterprise Linux documents, Introduction
iptables , Konfiguration von Diensten auf den LVS-Routern
ipvsadm program, ipvsadm

J

job scheduling, LVS, LVS Scheduling-Überblick

L

least connections (Siehe job scheduling, LVS)
LVS
/etc/sysconfig/ha/lvs.cf file, /etc/sysconfig/ha/lvs.cf
components of, LVS Components
daemon, lvs
date replication, real servers, Datenreplikation und Datenaustausch zwischen realen Servern
direct routing
and arptables_jf, Direktes Routing und arptables_jf
requirements, hardware, Direktes Routing, LVS via direktem Routing
requirements, network, Direktes Routing, LVS via direktem Routing
requirements, software, Direktes Routing, LVS via direktem Routing
initial configuration, Erste LVS-Konfiguration
ipvsadm program, ipvsadm
job scheduling, LVS Scheduling-Überblick
lvs daemon, lvs
LVS routers
configuring services, Erste LVS-Konfiguration
necessary services, Konfiguration von Diensten auf den LVS-Routern
primary node, Erste LVS-Konfiguration
multi-port services, Multiport-Dienste und LVS
FTP, Konfiguration von FTP
nanny daemon, nanny
NAT routing
enabling, Aktivierung von NAT-Routing auf den LVS-Routern
requirements, hardware, Das NAT LVS-Netzwerk
requirements, network, Das NAT LVS-Netzwerk
requirements, software, Das NAT LVS-Netzwerk
overview of, Überblick über Linux Virtual Server
packet forwarding, Aktivierung der Paketweiterleitung
Piranha Configuration Tool , Piranha Configuration Tool
pulse daemon, pulse
real servers, Überblick über Linux Virtual Server
routing methods
NAT, Routing-Methoden
routing prerequisites, Konfiguration von Netzwerkschnittstellen für LVS mit NAT
scheduling, job, LVS Scheduling-Überblick
send_arp program, send_arp
shared data, Datenreplikation und Datenaustausch zwischen realen Servern
starting LVS, Starten von LVS
synchronizing configuration files, Synchronisation von Konfigurationsdateien
three-tier
Red Hat Cluster Manager, A Three-Tier LVS Configuration
using LVS with Red Hat Cluster, Die Verwendung von LVS in einem Red Hat Cluster
lvs daemon, lvs

M

multi-port services, Multiport-Dienste und LVS
(Siehe auch LVS)

N

nanny daemon, nanny
NAT
enabling, Aktivierung von NAT-Routing auf den LVS-Routern
routing methods, LVS, Routing-Methoden
network address translation (Siehe NAT)

R

real servers
configuring services, Konfiguration von Diensten auf den realen Servern
Red Hat Cluster
and LVS, Die Verwendung von LVS in einem Red Hat Cluster
using LVS with, Die Verwendung von LVS in einem Red Hat Cluster
round robin (Siehe job scheduling, LVS)
routing
prerequisites for LVS, Konfiguration von Netzwerkschnittstellen für LVS mit NAT

S

scheduling, job (LVS), LVS Scheduling-Überblick
security
Piranha Configuration Tool , Zugangsbeschränkung zum Piranha Configuration Tool
send_arp program, send_arp
sshd service, Konfiguration von Diensten auf den LVS-Routern
synchronizing configuration files, Synchronisation von Konfigurationsdateien

W

weighted least connections (Siehe job scheduling, LVS)
weighted round robin (Siehe job scheduling, LVS)

Rechtlicher Hinweis

Copyright © 2009 Red Hat, Inc.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.