Red Hat Cluster Suite: Konfiguration und Management eines Cluster | ||
---|---|---|
Zurück | Kapitel 9. Linux Virtual Server Überblick | Nach vorne |
Einer der Vorteile der Verwendung eines LVS Clusters ist dessen Fähigkeit einen flexiblen IP-Level Lastausgleich auf der Gruppe der realen Server durchzuführen. Diese Flexibilität wird einer Reihe von Scheduling-Algorithmen verdankt, aus denen ein Administrator bei der Konfiguration des Clusters auswählen kann. LVS Lastausgleich ist weniger flexiblen Methoden überlegen, wie dem Round-Robin DNS, wo die hierarchische Natur des DNS und das Caching von Client-Maschinen zu Unausgeglichenheiten führen kann. Auch hat das Low-Level Filtern, welches vom LVS Router eingesetzt wird, Vorteile gegenüber der Weiterleitung von Anforderungen auf der Applikationsebene, da das Ausgleichen von Lasten auf der Ebene von Netzwerk-Paketen einen kleineren Overhead verursacht und eine größere Skalierbarkeit bietet.
Unter Verwendung von Scheduling, kann der aktive Router die Aktivität der einzelnen realen Server und, optional, ein vom Administrator zugewiesenes Gewicht (engl.: weight) bei der Weiterleitung der Service-Anforderungen berücksichtigen. Deswegen ist es möglich, eine Gruppe von realen Servern zu erzeugen, welche eine Vielzahl von Hardware und Software-Kombinationen verwendet und der aktive Router kann jeden realen Server gleichmäßig beladen.
Der Scheduling-Mechanismus für einen LVS Cluster ist durch eine Kollektion von Kernel-Patches bereitgestellt, welche IP Virtual Server oder IPVS Module genannt werden. Diese Module erlauben Layer 4 (L4) Transport-Layer-Switching, das auf Grund seines Designs gut mit mehreren Servern und einer einzelnen IP Adresse arbeitet.
Um den Pfad von Paketen zu ermitteln und diese effizient zu den realen Servern weiterzuleiten, erzeugt IPVS eine IPVS Tabelle im Kernel. Diese Tabelle wird vom aktiven LVS Router verwendet, um Anforderungen an einen virtuellen Server (oder dessen Adresse) zur Gruppe der realen Server weiterzuleiten und von dieser wieder entgegen zu nehmen. Die IPVS Tabelle wird ständig von einem Utility aktualisiert, ipvsadm genannt — durch Hinzufügen und Entfernen von Cluster Systemen, je nach deren Verfügbarkeit.
Das Format der IPVS Tabelle hängt vom jeweiligen Scheduling-Algorithmus ab, den der Administrator für einen gegebenen virtuellen Server wählt. Um für beides, die Typen von Services im Cluster und die Art des Scheduling der Services, eine maximale Flexibilität zu gewähren, bietet Red Hat Enterprise Linuxdie unten angegebenen Scheduling-Algorithmen. Für Anleitungen zur Zuweisung von Scheduling-Algorithmen, siehe Abschnitt 12.6.1.
Verteilt Anforderungen in sequentieller Reihenfolge unter der Gruppe von realen Servern. Unter Verwendung dieses Algorithmus, werden alle realen Server als gleich betrachtet, unabhängig von deren Kapazität und Arbeitslast. Dieses Scheduling-Model ist dem Round-Robin DNS ähnlich, ist aber körniger, da es Netzwerk-basiert und nicht Host-basiert ist. LVS Round-Robin Scheduling ist auch den Unausgeglichenheiten nicht ausgesetzt, welche von im Cache zwischengespeicherten DNS Anfragen verursacht werden.
Verteilt jede Anforderung in sequentieller Reihenfolge über die Gruppe von realen Servern, gibt jedoch mehr Jobs zu Servern mit einer höheren Kapazität. Kapazität wird durch ein vom Benutzer zugewiesenes Gewicht (weight) festgelegt, welches dann durch dynamische Lastinformation abgestimmt wird. Siehe Abschnitt 9.3.2 für mehr Information zum Gewichten von realen Servern.
Weighted Round-Robin Scheduling ist die bessere Wahl, sollten große Unterschiede in den Kapazitäten der einzelnen realen Server bestehen. Wenn die angeforderten Arbeitslasten allerdings sehr verschieden sind, können schwer gewichtete Server unter Umständen mehr als nur ihren Teil der Last bearbeiten müssen.
Gibt mehr Anforderungen zu realen Servern mit weniger aktiven Verbindungen. Da dieser durch die IPVS Tabelle über die aktiven Verbindungen der realen Server auf dem laufenden bleibt, ist Least-Connection eine Art dynamischer Scheduling-Algorithmus, was diesen eine besser Wahl für in hohem Grade variierende Arbeitslasten macht. Er ist am besten geeignet für ein Gruppen von realen Servern, die ungefähr die gleiche Kapazität haben. Sollte die realen Server in the Gruppe unterschiedliche Kapazitäten haben, ist Weighted Least-Connection Scheduling die bessere Alternative.
Verteilt mehr Anforderungen zu Servern mit weniger aktiven Verbindungen, unter Berücksichtigung deren Kapazitäten. Kapazität wird durch ein vom Benutzer zugewiesenes Gewicht (weight) festgelegt, welches dann durch dynamische Lastinformation abgestimmt wird. Die Hinzunahme der Gewichtung macht diesen Algorithmus ideal, wenn die Gruppe von realen Servern Hardware unterschiedlicher Kapazität enthält. Siehe Abschnitt 9.3.2 für mehr Information zum Gewichten von realen Servern.
Gibt mehr Anforderungen an Server mit weniger aktiven Verbindungen, relativ zu deren Ziel-IPs. Dieser Algorithmus wurde für die Verwendung in einem Proxy-Cache Server Cluster entwickelt. Er leitet die Pakete für eine bestimmte IP Adresse zu dem Server mit dieser IP Adresse, es sei denn, dieser Server hat seine Kapazität überschritten und hat einen Server in seiner Halblast, in welchem Fall er die IP Adresse dem realen Server mit der kleinsten Arbeitslast zuteilt.
Gibt mehr Anforderungen zu Servern mit weniger aktiven Verbindungen, relativ zu deren Ziel-IPs. Auch dieser Algorithmus wurde für Proxy-Cache Server Cluster entwickelt. Er unterscheidet sich von Locality-Based Least-Connection Scheduling durch ein Mapping der Ziel-IP zu einer Untergruppe der realen Server. Die Anforderung wird dann zum Server in dieser Untergruppe mit den wenigsten aktiven Verbindungen gegeben. Sollten alle Server für die Ziel-IP ihre Kapazitäten überschritten haben, wird ein neuer Server für diese IP Adresse repliziert, indem der reale Server mit den wenigsten aktiven Verbindungen zu der Untergruppe von realen Servern für die Ziel-IP hinzugefügt wird. Der Server mit der höchsten Arbeitsbelastung in dieser Untergruppe wird dann aus dieser entfernt, um eine Überreplikation zu vermeiden.
Verteilt Anforderungen zu der Gruppe von realen Servern, indem dieser deren Ziel-IP in einer statischen Hash-Table nachliest. Dieser Algorithmus wurde für die Verwendung in einem Proxy-Cache Server Cluster entwickelt.
Verteilt Anforderungen zu der Gruppe von realen Servern, indem dieser deren Ziel-IP in einer statischen Hash-Table nachliest. Dieser Algorithmus wurde für LVS Router mit mehreren Firewalls entwickelt.
Der Administrator eines LVS Clusters kann jedem Server eine Gewichtung zuweisen. Diese Gewichtung ist ein ganzzahliger Wert, welcher in jeden gewichtungsbewußten (weight-aware) Scheduling-Algorithmus (wie Weighted Least-Connections) eingerechnet wird und dem LVS Router hilft Hardware mit ungleichen Kapazitäten mehr gleichmäßig zu beladen.
Gewichtungen arbeiten in einem Verhältnis relativ zueinander. Wenn ein realer Server, zum Beispiel, eine Gewichtung von 1 hat, und ein anderer eine Gewichtung von 5, dann wird der Server mit der Gewichtung von 5 auch 5 Verbindungen erhalten, für jede Verbindung die der Server mit der Gewichtung 1 erhält. Der Default für die Gewichtung realer Server ist 1.
Obwohl das Hinzufügen von Gewichtungen zu variierenden Hardware-Konfigurationen in einer Gruppe von realen Servern helfen kann die Last im Cluster mehr effizient zu verteilen, kann dies zu temporären Unausgeglichenheiten führen, wenn ein realer Server zu der Gruppe der realen Server hinzugefügt wird und der virtuelle Server Weighted Least-Connections Scheduling verwendet. Um dies zu illustrieren, nehmen wir an wir haben drei Server in der Gruppe. Server A und B haben eine Gewichtung von 1 und der dritte, Server C, hat eine Gewichtung von 2. Sollte Server C aus irgendwelchen Gründen für einige Zeit ausfallen, werden Server A und B dessen Last übernehmen. Wenn Server C wieder Online geht, wird der LVS Router sehen, dass dieser keine Verbindungen hat und diesen demnach mit Anforderungen solange überfluten, bis dieser die gleiche Belastung wie A und B zusammen hat.
Um diesem vorzubeugen, kann der Administrator den virtuellen Server einen quiesce Server machen — jedes mal, wenn ein neuer Server Online geht, wird die Least-Connections Tabelle zurückgesetzt, sodass der LVS Router Anforderungen so verteilt, als ob alle realen Server gerade zum Cluster hinzugefügt wurden.
Zurück | Zum Anfang | Nach vorne |
Eine Drei-Tier LVS Konfiguration | Nach oben | Routing Methoden |