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.
