1.3. Übersicht über das Load Balancer Add-On Scheduling
Einer der Vorteile bei der Verwendung des Load Balancer Add-Ons ist dessen Fähigkeit zur flexiblen, IP-basierten Lastverteilung auf dem Pool der realen Server. Diese Flexibilität verdankt es der Vielzahl an Scheduling-Algorithmen, aus denen ein Administrator bei der Konfiguration des Load Balancer Add-Ons auswählen kann. Die Lastverteilung mithilfe des Load Balancer Add-Ons ist weniger flexiblen Methoden wie z. B. Round-Robin DNS überlegen, bei denen das hierarchische Wesen von DNS und das Caching durch Client-Rechner zu unausgeglichener Last führen kann. Darüber hinaus bietet die Low-Level-Filterung durch den LVSR-Router Vorteile gegenüber der Anfrageweiterleitung auf Applikationsebene, da die Lastverteilung auf Netzwerkpaket-Ebene nur einen geringen Overhead verursacht und eine größere Skalierbarkeit ermöglicht.
Beim Scheduling kann der aktive Router die Aktivität der realen Server sowie optional die vom Administrator zugewiesene Gewichtung für das Routing von Dienstanfragen berücksichtigen. Diese zugewiesene Gewichtung gibt einzelnen Rechnern eine beliebige Priorität. Bei dieser Form des Schedulings ist es möglich, aus einer Vielzahl verschiedener Hardware- und Software-Kombinationen eine Gruppe aus Servern zu bilden, auf denen der aktive Router die Last gleichmäßig verteilen kann.
Der Scheduling-Mechanismus für das Load Balancer Add-On wird von einer Reihe von Kernel-Patches namens IP Virtual Server oder IPVS-Modulen bereitgestellt. Diese Module ermöglichen das Layer 4 (L4) Switching der Transportschicht, was für den Einsatz auf mehreren Servern mit einer einzigen IP-Adresse optimiert ist.
Um Pakete wirkungsvoll weiterzuleiten und nachzuverfolgen, erstellt IPVS eine IPVS-Tabelle im Kernel. Diese Tabelle wird vom aktiven LVS-Router verwendet, um Anfragen von einer virtuellen Serveradresse und Antworten von den realen Servern im Pool weiterzuleiten. Die IPVS-Tabelle wird laufend aktualisiert von einem Dienstprogramm namens ipvsadm, das Cluster-Mitglieder abhängig von deren Verfügbarkeit hinzufügt oder entfernt.
1.3.1. Scheduling-Algorithmen
Die Struktur der IPVS-Tabelle hängt vom Scheduling-Algorithmus ab, den der Administrator für den virtuellen Server festlegt. Red Hat Enterprise Linux bietet die nachfolgend aufgeführten Scheduling-Algorithmen und bietet so ein Höchstmaß an Flexibilität für die Arten von Diensten, die geclustert werden können, sowie für die Art und Weise, wie das Scheduling für diese Dienste erfolgt. Anweisungen zur Zuweisung von Scheduling-Algorithmen finden Sie in Abschnitt 4.6.1, »Der Unterabschnitt VIRTUAL SERVER«.
- Round-Robin-Scheduling
- Verteilt die Anfragen reihum in dem Pool der realen Server. Bei der Verwendung dieses Algorithmus werden alle realen Server als gleichwertig behandelt, ohne Rücksicht auf deren Kapazität oder Auslastung. Dieses Scheduling-Modell ähnelt Round-Robin-DNS, ist jedoch feiner steuerbar, da es auf Netzwerkverbindungen basiert statt auf Hosts. Das Round-Robin-Scheduling des Load Balancer Add-Ons leidet zudem nicht unter dem Ungleichgewicht, das gecachte DNS-Anfragen verursachen.
- Gewichtetes Round-Robin-Scheduling
- Verteilt die Anfragen reihum in dem Pool der realen Server, teilt jedoch Servern mit einer höheren Kapazität mehr Jobs zu. Die Kapazität wird durch einen vom Administrator zugewiesenen Gewichtungsfaktor angezeigt, der dann durch eine dynamische Auslastungsinformation entweder nach oben oder unten korrigiert wird. Siehe Abschnitt 1.3.2, »Server-Gewichtung und Scheduling« für weitere Informationen über die Gewichtung der realen Server.Das gewichtete Round-Robin-Scheduling ist die bevorzugte Methode, falls es deutliche Unterschiede in der Kapazität der realen Server im Pool gibt. Falls die Anfragelast jedoch sehr schwankt, bedient der höher gewichtete Server unter Umständen einen zu großen Teil der Anfragen.
- Least-Connection
- Verteilt mehr Anfragen an reale Server mit weniger aktiven Verbindungen. Da diese Methode anhand der IPVS-Tabelle die Anzahl der aktiven Verbindungen zu den realen Servern nachverfolgt, ist dies ein dynamischer Scheduling-Algorithmus-Typ und stellt eine bessere Wahl dar, falls die Anfragelast sehr schwankt. Dieser Algorithmus ist am besten für einen Pool von realen Server geeignet, in dem jeder Mitgliedsknoten ungefähr dieselbe Kapazität besitzt. Falls die realen Server unterschiedliche Kapazitäten besitzen, ist das gewichtete Least-Connection-Scheduling die bessere Wahl.
- Gewichtetes Least-Connections (Standard)
- Verteilt mehr 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. Siehe Abschnitt 1.3.2, »Server-Gewichtung und Scheduling« für weitere Informationen über die Gewichtung der realen Server.
- Standortbasiertes Least-Connection-Scheduling
- Verteilt mehr 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 konzipiert. Er leitet 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 dem realen Server mit der geringsten Auslastung zu.
- Standortbasiertes Least-Connection-Scheduling mit Replikations-Scheduling
- Verteilt mehr Anfragen an Server mit weniger aktiven Verbindungen in Relation zu ihren Ziel-IPs. Dieser Algorithmus ist ebenfalls für den Einsatz in einem Proxy-Cache-Server-Cluster konzipiert. Er unterscheidet sich vom standortbasierten Least-Connection-Scheduling durch das Zuordnen der Ziel-IP-Adresse zu einer Teilmenge von realen 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.
- Ziel-Hash-Scheduling
- Verteilt Anfragen an den Pool realer Server, indem die Ziel-IP in einer statischen Hash-Tabelle gesucht wird. Dieser Algorithmus ist für einen Proxy-Cache-Server-Cluster konzipiert.
- Quell-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.
