1.8. 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.
Abbildung 1.19, »Components of a Running LVS Cluster« provides an overview of the LVS components and their interrelationship.
Abbildung 1.19. Components of a Running LVS Cluster
Der
pulse-Daemon läuft sowohl auf den aktiven als auch den passiven LVS-Routern. Auf dem Backup-LVS-Router sendet pulse einen heartbeat an die öffentliche Schnittstelle des aktiven Router, 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 unterrichtet den lvs-Daemon darüber, ob 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.
Für einen außenstehenden Benutzer, der auf einen gehosteten Dienst zugreift (wie einer Website oder Datenbankapplikation), erscheint LVS als ein Server. Tatsächlich greift der Benutzer jedoch auf reale Server hinter den LVS-Routern zu.
Da es keine integrierte Komponente in LVS gibt, um Daten unter realen Servern zu verteilen, stehen Ihnen zwei Grundoptionen zur Verfügung:
- Synchronisation der Daten unter den realen Servern.
- Hinzufügen einer dritten Ebene zur Topologie für den Zugriff auf gemeinsam genutzte Daten.
Die erste Option wird vorzugsweise für Server verwendet, die einer großen Anzahl von Benutzern das Hochladen oder Verändern von Daten auf realen Servern untersagt. Falls die realen Server einer großen Anzahl von Benutzern gestatten, Daten zu verändern, wie beispielsweise einer E-Commerce-Website, ist das Hinzufügen einer dritten Schicht besser.
Es gibt viele Möglichkeiten, Daten zwischen realen Servern zu synchronisieren. Sie können zum Beispiel Shell-Skripte verwenden, um aktualisierte Web-Seiten gleichzeitig an reale Server zu schicken. Auch können Sie Programme wie
rsync verwenden, um aktualisierte Daten im Rahmen eines bestimmten Intervalls auf allen Knoten zu replizieren. Allerdings funktionieren Skripte in Umgebungen, in denen Benutzer häufig Dateien hochladen oder Datenbank-Transaktionen durchführen, nicht optimal. Aus diesem Grund ist eine three-tiered topology besser geeignet zur Synchronisation von Daten für reale Server, auf die eine große Menge Daten hochgeladen wird oder mit Datenbank-Transaktionen oder ähnlichem Datenverkehr.
1.8.1. Two-Tier LVS Topology
Abbildung 1.20, »Two-Tier LVS Topology« shows a simple LVS configuration consisting of two tiers: LVS routers and real servers. The LVS-router tier consists of one active LVS router and one backup LVS router. The real-server tier consists of real servers connected to the private network. Each LVS router has two network interfaces: one connected to a public network (Internet) and one connected to a private network. A network interface connected to each network allows the LVS routers to regulate traffic between clients on the public network and the real servers on the private network. In Abbildung 1.20, »Two-Tier LVS Topology«, the active LVS router uses Network Address Translation (NAT) to direct traffic from the public network to real servers on the private network, which in turn provide services as requested. The real servers pass all public traffic through the active LVS router. From the perspective of clients on the public network, the LVS router appears as one entity.
Abbildung 1.20. Two-Tier LVS Topology
Dienstanfragen, die bei einem LVS-Router ankommen, werden an eine virtuelle IP Adresse oder VIP adressiert. Dies ist eine öffentlich routbare Adresse, die der Administrator einer Site mit einem vollständigen Namen einer Domain (FQDN) verknüpft, wie z.B. www.example.com und die einem oder mehreren virtuellen Servern zugewiesen wird.[1]. Beachten Sie bitte, dass eine VIP-Adresse während einer Ausfallsicherung von einem LVS-Router auf den anderen migriert und auf diese Weise eine Präsenz auch weiterhin unter dieser IP-Adresse gewährleistet ist. Dies ist auch als Floating IP-Adressen bekannt.
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.
Nur jeweils ein LVS-Router ist aktiv. Die Aufgabe des aktiven LVS-Routers ist es, Dienstanfragen von virtuellen IP-Adressen an die realen Server umzuleiten. Die Umleitung basiert auf einem von acht Algorithmen für den Lastverteilung:
- Round-Robin-Scheduling — Verteilt jede Anfrage nacheinander in einen 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.
- Gewichtetes Round-Robin-Scheduling — Verteilt jede Anfrage nacheinander in einem Pool von realen Servern, teilt jedoch Servern mit einer höheren Kapazität mehr Jobs zu. Die Kapazität wird durch einen durch einen Benutzer zugewiesenen Gewichtungsfaktor angezeigt, der dann durch eine dynamische Auslastungsinformation entweder nach oben oder unten korrigiert wird. Dies ist die bevorzugte Wahl falls signifikante Unterschiede 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. Dies ist ein dynamischer Scheduling-Algorithmus-Typ und stellt eine bessere Wahl dar, falls eine 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.
- Gewichtete Least-Connections (Standard) — Verteilt mehrere Anfragen an Server mit weniger aktiven Verbindungen in Relation zu ihrer Kapazität. Die Kapazität wird durch eine benutzerdefinierte Gewichtung angezeigt, welche dann wiederum je nach dynamischer Lastinformation nach oben oder unten korrigiert wird. Der Zusatz der Gewichtung macht diesen Algorithmus zu einer idealen Alternative, wenn der Pool der realen Server aus Hardware mit unterschiedlichen Kapazitäten besteht.
- 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 mit 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, repliziert er einen neuen Server für diese Ziel-IP-Adresse, indem er den realen Server mit den wenigsten Verbindungen aus dem gesamten Pool der realen Server zur Teilmenge der realen Server für diese Ziel-IP hinzufügt. Der Knoten mit der höchsten Last wird dann aus der Teilmenge der realen Server entfernt, um eine Überreplikation zu verhindern.
- Source-Hash-Scheduling — Verteilt Anfragen an den Pool realer Server, in dem er die Quell-IP in einer statischen Hash-Tabelle sucht. Dieser Algorithmus ist für LVS-Router mit mehreren Firewalls gedacht.
Auch überwacht der aktive LVS-Router dynamisch die Gesamtverfassung der speziellen Dienste auf den realen Servern durch einfache send/expect-Skripte. Als Hilfe bei der Analyse der Verfassung 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 LVS-Router auf, Jobs an diesen Server zu senden, bis dieser wieder auf normalem Betriebslevel ist.
Der Backup-LVS-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-LVS-Router keine Heartbeat-Meldung innerhalb eines erwarteten Intervalls, leitet er eine Ausfallsicherung ein und übernimmt die Rolle des aktiven LVS-Routers. Während der Ausfallsicherung übernimmt der Backup-LVS-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-Adressen darstellt, die an den ausgefallenen Knoten gerichtet sind. Falls der ausgefallene Knoten wieder aktiv wird, nimmt der Backup-LVS-Router seine Backup-Rolle wieder auf.
The simple, two-tier configuration in Abbildung 1.20, »Two-Tier LVS Topology« is suited best for clusters serving data that does not change very frequently — such as static web pages — because the individual real servers do not automatically synchronize data among themselves.
[1]
Ein virtueller Server ist ein Dienst, der so konfiguriert ist, dass er auf einer speziellen virtuellen IP horcht.
