Tiefgreifendes Verständnis des Linux-Lastausgleichs LVS

1. LVS-Lastausgleich

Load Balancing Cluster ist die Abkürzung für Load Balance Cluster, was ins Chinesische als Lastenausgleichscluster übersetzt wird. Zu den häufig verwendeten Open-Source-Programmen zum Lastausgleich zählen Nginx, LVS und Haproxy, und zu den kommerziellen Geräten zum Lastausgleich in der Hardware zählen F5, Netscale usw.

2. Grundlegende Einführung in den Lastausgleich LVS

Die Architektur und das Prinzip des LB-Clusters sind sehr einfach. Wenn eine Benutzeranforderung eingeht, wird sie direkt an den Director-Server verteilt, und dieser verteilt die Benutzeranforderung dann gemäß dem festgelegten Planungsalgorithmus intelligent und gleichmäßig an den realen Back-End-Server. Um zu vermeiden, dass Benutzer auf verschiedenen Rechnern unterschiedliche Daten anfordern, ist ein gemeinsam genutzter Speicher erforderlich, um sicherzustellen, dass alle Benutzer dieselben Daten anfordern.

Dies ist ein Open-Source-Projekt, das von Dr. Zhang Wensong initiiert wurde. Die offizielle Website lautet: http://www.linuxvirtualserver.org. LVS ist jetzt Teil des Linux-Kernel-Standards. Das technische Ziel, das durch die Verwendung von LVS erreicht werden kann, besteht darin, durch die von LVS und dem Linux-Betriebssystem erreichte Lastausgleichstechnologie einen leistungsstarken und hochverfügbaren Linux-Dienstcluster zu implementieren, der eine gute Zuverlässigkeit, Skalierbarkeit und Bedienbarkeit aufweist. Dadurch wird optimale Leistung zu geringen Kosten erreicht.

Der LVS-Cluster verwendet IP-Lastausgleichstechnologie und Technologie zur Verteilung von Inhaltsanforderungen. Der Scheduler hat eine gute Durchsatzrate und verteilt Anfragen zur Ausführung gleichmäßig an verschiedene Server. Der Scheduler schirmt Serverausfälle automatisch ab und bildet so aus einer Gruppe von Servern einen leistungsstarken, hochverfügbaren virtuellen Server. Die Struktur des gesamten Serverclusters ist für den Client transparent und es ist nicht erforderlich, die Client- und Serverprogramme zu ändern.

3. LVS-Architektur

Das Prinzip des Lastenausgleichs ist sehr einfach. Wenn ein Client eine Anfrage initiiert, wird diese direkt an den Director-Server (Scheduler) gesendet. Zu diesem Zeitpunkt wird die Anfrage gemäß dem festgelegten Planungsalgorithmus intelligent und gemäß den Vorschriften des Algorithmus an den tatsächlichen Hintergrundserver verteilt. Um den Druck gleichmäßig zu verteilen. Wir wissen jedoch, dass HTTP-Verbindungen zustandslos sind. Stellen wir uns folgendes Szenario vor: Ich melde mich bei Taobao an, um etwas zu kaufen. Wenn mir ein bestimmtes Produkt gefällt, lege ich es in den Einkaufswagen, aktualisiere dann aber die Seite. Zu diesem Zeitpunkt wählt der Scheduler aufgrund des Lastenausgleichs einen neuen Server aus, der mir Dienste bereitstellt, und der gesamte Inhalt meines Einkaufswagens ist weg. Dies führt zu einer sehr schlechten Benutzererfahrung. Um sicherzustellen, dass die vom Benutzer angeforderten Daten identisch sind, ist daher eine Speicherfreigabe erforderlich. Daher ist der LVS-Lastausgleich in eine dreischichtige Architektur unterteilt (die die Hauptkomponente des LVS-Lastausgleichs darstellt):

Wie in der Abbildung gezeigt:

Detaillierte Einführung in jede Ebene von LVS:

3.1 Load Balancer-Schicht

Es befindet sich am vorderen Ende des gesamten Clustersystems und besteht aus einem oder mehreren Lastplanern (Director-Servern). Das LVS-Modul ist auf dem Director-Server installiert und die Hauptfunktion des Directors ähnelt der eines Routers. Es enthält Routing-Tabellen, die die LVS-Funktion vervollständigen, und verteilt Benutzeranforderungen über diese Routing-Tabellen an die Anwendungsserver (Real Server) auf der Server-Array-Ebene. Gleichzeitig muss das Real Server-Dienstüberwachungsmodul Ldirectord auf dem Director-Server installiert sein. Dieses Modul wird verwendet, um den Integritätsstatus jedes Real Server-Dienstes zu erkennen. Wenn der Real Server nicht verfügbar ist, entfernen Sie ihn aus der LVS-Routingtabelle und fügen Sie ihn erneut hinzu, wenn er wiederhergestellt ist.

3.2 Server-Array-Schicht

Es besteht aus einer Gruppe von Maschinen, auf denen tatsächlich Anwendungsdienste ausgeführt werden. Real Server können Webserver, Mall-Server, FTP-Server, DNS-Server usw. sein. Jeder Real Server ist über ein Hochgeschwindigkeits-LAN oder WAN verbunden, das an verschiedenen Orten verteilt ist. In tatsächlichen Anwendungen kann Director Server gleichzeitig auch als Real Server dienen.

3.3 Gemeinsam genutzte Speicherebene

Es handelt sich um einen Speicherbereich, der gemeinsamen Speicherplatz und Inhaltskonsistenz für alle Real Server bereitstellt. Physisch besteht er im Allgemeinen aus Disk-Array-Geräten. Um Inhaltskonsistenz bereitzustellen, können Daten im Allgemeinen über das NFS-Netzwerkdateisystem gemeinsam genutzt werden. Die Leistung von NFS ist jedoch in stark ausgelasteten Geschäftssystemen nicht sehr gut. Derzeit kann ein Cluster-Dateisystem wie das GFS-Dateisystem von Red Hat verwendet werden. Zur Koordination muss ein Unternehmen über ein Backend-Konto verfügen. Andernfalls zahlt der Kunde das Geld an A und B übernimmt den Empfang des Kunden, da kein identisches Konto besteht. B sagte, dass der Kunde nicht bezahlt habe, es handele sich also nicht um ein Problem der Kundenerfahrung.

4. Implementierungsprinzip von LVS

(1) Wenn der Benutzerlastausgleichsplaner (Director Server) eine Anforderung initiiert, sendet der Planer die Anforderung an den Kernelspeicher

(2) Die PREROUTING-Kette empfängt zuerst die Benutzeranforderung, stellt fest, dass die Ziel-IP tatsächlich die lokale IP ist, und sendet das Datenpaket an die INPUT-Kette

(3) IPVS arbeitet an der INPUT-Kette. Wenn eine Benutzeranforderung bei INPUT eintrifft, vergleicht IPVS die Benutzeranforderung mit dem von ihm definierten Clusterdienst. Wenn der Benutzer den Clusterdienst anfordert, ändert IPVS zwangsweise die Ziel-IP-Adresse und den Port im Datenpaket und sendet das neue Datenpaket an die POSTROUTING-Kette.

(4) Nach dem Empfang des Datenpakets stellt die POSTROUTING-Kette fest, dass die Ziel-IP-Adresse genau ihr eigener Backend-Server ist. Anschließend wird das Datenpaket schließlich durch Routing-Auswahl an den Backend-Server gesendet.

5. Funktionsprinzip von LVS

LVS hat vier Arbeitsmodi: NAT, DR, TUN und FULL-NAT. Zum Vergleich: Aufgrund des Funktionsprinzips hat NAT die einfachste Konfiguration, übt jedoch zu viel Druck auf den Scheduler aus, was zu seiner geringsten Effizienz führt. Die Funktionsprinzipien von DR und TUN sind ähnlich, aber bei DR müssen sich alle Hosts in derselben physischen Umgebung befinden, während bei TUN alle Hosts auf verschiedene Standorte verteilt sein können, mit einem Server in New York und einem anderen in Shenzhen. Am häufigsten wird FULL-NAT verwendet.

6. LVS-bezogene Begriffe

(1) DS: Director Server bezieht sich auf den Front-End-Load-Balancer-Knoten.

(2) RS: Real Server, der wirklich funktionierende Server im Backend.

(3) VIP: Leitet Benutzeranfragen direkt an die Außenwelt weiter und ist die IP-Adresse des Ziels der Benutzeranfrage.

(4) DIP: Director Server IP ist die IP-Adresse, die hauptsächlich für die Kommunikation mit internen Servern verwendet wird.

(5) RIP: Real Server IP: die IP-Adresse des Backend-Servers.

(6) CIP: Client IP: die IP-Adresse des Zugriffsclients.

7. NAT-Modus - Network Address Translation

Dies wird durch die Verwendung der Netzwerkadressübersetzung erreicht. Wenn der Scheduler (LB) zunächst das Anforderungsdatenpaket des Clients empfängt (die Ziel-IP der Anforderung ist VIP), entscheidet er basierend auf dem Planungsalgorithmus, an welchen realen Backend-Server (RS) die Anforderung gesendet werden soll. Anschließend ändert der Dispatcher die Ziel-IP-Adresse und den Port des vom Client gesendeten Anforderungsdatenpakets in die IP-Adresse (RIP) des realen Backend-Servers, sodass der reale Server (RS) das Anforderungsdatenpaket des Clients empfangen kann. Nachdem der reale Server auf die Anfrage geantwortet hat, überprüft er die Standardroute (im NAT-Modus müssen wir die Standardroute von RS zum LB-Server festlegen) und sendet das Antwortdatenpaket an LB. Nachdem LB das Antwortpaket empfangen hat, ändert es die Quelladresse des Pakets in die virtuelle Adresse (VIP) und sendet es an den Client zurück.

VS/NAT ist die einfachste Methode. Alle RealServer müssen ihre Gateways nur auf den Director richten. Der Client kann ein beliebiges Betriebssystem sein, allerdings ist dadurch die Anzahl der RealServer, die von einem Director gesteuert werden können, relativ begrenzt. Im VS/NAT-Modus kann Director auch als RealServer dienen. Die VS/NAT-Architektur ist in der Abbildung dargestellt.

8. Funktionsprinzip des NAT-Modus

(1) Wenn die Benutzeranforderung den Director-Server erreicht, geht das angeforderte Datenpaket zunächst an die PREROUTING-Kette im Kernelbereich. Zu diesem Zeitpunkt ist die Quell-IP der Nachricht CIP und die Ziel-IP VIP.

(2) PREROUTING prüft und stellt fest, dass die Ziel-IP des Datenpakets die lokale Maschine ist, und sendet das Datenpaket an die INPUT-Kette.

(3) IPVS vergleicht den vom Datenpaket angeforderten Dienst, um festzustellen, ob es sich um einen Clusterdienst handelt. Wenn dies der Fall ist, ändert es die Ziel-IP-Adresse des Datenpakets in die IP des Backend-Servers und sendet das Datenpaket dann an die POSTROUTING-Kette. Zu diesem Zeitpunkt ist die Quell-IP der Nachricht CIP und die Ziel-IP RIP.

(4) Die POSTROUTING-Kette wählt eine Route aus und sendet das Datenpaket an den Real-Server.

(5) Der Real-Server vergleicht und stellt fest, dass es sich bei dem Ziel um seine eigene IP-Adresse handelt. Er beginnt mit der Erstellung einer Antwortnachricht und sendet diese an den Director-Server zurück. Zu diesem Zeitpunkt ist die Quell-IP der Nachricht RIP und die Ziel-IP CIP.

(6) Bevor der Director-Server dem Client antwortet, ändert er die Quell-IP-Adresse in seine eigene VIP-Adresse und antwortet dann dem Client. Zu diesem Zeitpunkt ist die Quell-IP der Nachricht VIP und die Ziel-IP CIP.

9. DR-Modus - Direkt-Routing-Modus

Der DR-Modus dient der Nutzung der Direktrouting-Technologie zur Implementierung virtueller Server. Die Verbindungsplanung und -verwaltung sind dieselben wie bei VS/NAT und VS/TUN, aber die Nachrichtenweiterleitungsmethode ist anders. VS/DR schreibt die MAC-Adresse der Anforderungsnachricht neu und sendet die Anforderung an den Real Server. Der Real Server gibt die Antwort direkt an den Client zurück, wodurch der IP-Tunnel-Overhead in VS/TUN entfällt. Diese Methode bietet die höchste Leistung und ist die beste der drei Lastplanungsmechanismen, erfordert jedoch, dass sowohl der Director-Server als auch der Real-Server über eine Netzwerkkarte verfügen, die mit demselben physischen Netzwerksegment verbunden ist.

Director und RealServer müssen physisch über eine Netzwerkkarte und ein unterbrechungsfreies LAN verbunden sein. Die an den RealServer gebundene VIP wird auf den entsprechenden Nicht-ARP-Netzwerkgeräten (wie lo oder tunl) konfiguriert. Die VIP-Adresse des Directors ist von außen sichtbar, während die VIP des RealServers von außen unsichtbar ist. Die Adresse des RealServers kann entweder eine interne oder eine reale Adresse sein.

Der DR-Modus schreibt die Ziel-MAC-Adresse der Anforderungsnachricht neu und sendet die Anforderung an den realen Server. Das Verarbeitungsergebnis der Antwort des realen Servers wird direkt an den Clientbenutzer zurückgegeben. Wie der TUN-Modus kann der DR-Modus die Skalierbarkeit des Clustersystems erheblich verbessern. Darüber hinaus weist der DR-Modus nicht den Overhead von IP-Tunneln auf und die realen Server im Cluster müssen das IP-Tunnelprotokoll nicht unterstützen. Allerdings ist für den Scheduler LB und den realen Server RS ​​eine Netzwerkkarte erforderlich, die mit demselben physischen Netzwerksegment verbunden ist und sich in derselben LAN-Umgebung befindet.

9.1. Diagramm des Funktionsprinzips des DR-Modus

(1) Zunächst fordert der Benutzer mittels CIP ein VIP an.

(2) Wie aus der obigen Abbildung ersichtlich ist, muss sowohl auf dem Director-Server als auch auf dem Real-Server derselbe VIP konfiguriert werden. Wenn also die Benutzeranforderung den Front-End-Router unseres Cluster-Netzwerks erreicht, ist die Quelladresse des Anforderungsdatenpakets CIP und die Zieladresse VIP. Zu diesem Zeitpunkt sendet der Router auch eine Sendung, um zu fragen, wer der VIP ist. Da alle Knoten in unserem Cluster mit VIP konfiguriert sind, sendet der Router die Benutzeranforderung an denjenigen, der zuerst auf den Router antwortet. In diesem Fall ist unser Cluster-System bedeutungslos. Wir können auf dem Gateway-Router statisches Routing konfigurieren, um anzugeben, dass der VIP der Director-Server ist, oder einen Mechanismus verwenden, um zu verhindern, dass der Real-Server ARP-Adressauflösungsanforderungen vom Netzwerk akzeptiert. Auf diese Weise werden die Anforderungspakete des Benutzers durch den Director-Server geleitet.

(3) Wenn die Benutzeranforderung den Director-Server erreicht, geht das angeforderte Datenpaket zunächst zur PREROUTING-Kette im Kernelbereich. Zu diesem Zeitpunkt ist die Quell-IP des Pakets CIP und die Ziel-IP VIP.

(4) PREROUTING prüft und findet, dass die Ziel-IP des Datenpakets die lokale Maschine ist, und sendet das Datenpaket daher an die INPUT-Kette.

(5) IPVS vergleicht den vom Datenpaket angeforderten Dienst, um festzustellen, ob es sich um einen Clusterdienst handelt. Wenn dies der Fall ist, wird die Quell-MAC-Adresse in der Anforderungsnachricht in die MAC-Adresse von DIP geändert und die Ziel-MAC-Adresse in die MAC-Adresse von RIP geändert. Das Datenpaket wird dann an die POSTROUTING-Kette gesendet. Zu diesem Zeitpunkt werden die Quell-IP und die Ziel-IP nicht geändert. Nur die Quell-MAC-Adresse wird in die MAC-Adresse von DIP geändert und die Ziel-MAC-Adresse wird in die MAC-Adresse von RIP geändert.

(6) Da sich DS und RS im selben Netzwerk befinden, wird das Datenpaket über Schicht 2 übertragen. Die POSTROUTING-Kette überprüft, ob die Ziel-MAC-Adresse die MAC-Adresse von RIP ist, dann wird das Datenpaket an den Real-Server gesendet.

(7) RS stellt fest, dass die MAC-Adresse der Anforderungsnachricht seine eigene MAC-Adresse ist und empfängt die Nachricht. Nach Abschluss der Verarbeitung wird die entsprechende Nachricht über die Lo-Schnittstelle an die eth0-Netzwerkkarte übertragen und anschließend gesendet. Zu diesem Zeitpunkt ist die Quell-IP-Adresse VIP und die Ziel-IP CIP.

(8) Die Antwortnachricht wird schließlich an den Client übermittelt.

Es gibt drei Möglichkeiten, DR zu konfigurieren:

• Die erste Methode: Auf dem Router ist klar angegeben, dass die Adresse, die dem VIP entspricht, die MAC auf dem Director sein muss. Sobald sie gebunden ist, muss sie bei zukünftigen Kommunikationen mit dem VIP nicht erneut angefordert werden. Diese Bindung ist statisch, läuft also nicht ab und initiiert keine erneute Anforderung. Es gibt jedoch eine Voraussetzung. Unser Routing-Gerät muss über Betriebsberechtigungen verfügen, um die MAC-Adresse zu binden. Was ist, wenn der Router vom Betreiber betrieben wird und wir ihn nicht bedienen können? Die erste Methode ist einfach, aber nicht unbedingt durchführbar.
• Der zweite Typ: Auf einigen Hosts (wie Red Hat) wurde ein Programm namens Arptables eingeführt, das iptables etwas ähnelt. Es basiert definitiv auf ARP oder MAC für die Zugriffskontrolle. Offensichtlich müssen wir nur auf jedem Real Server Arptables-Regeln definieren. Wenn die Zieladresse der ARP-Broadcast-Anforderung des Benutzers die lokale VIP ist, wird keine Antwort gegeben oder die Antwortnachricht darf nicht gesendet werden. Offensichtlich kann (Gateway) sie nicht empfangen, d. h. die Antwortnachricht vom Director kann das Gateway erreichen. Das ist auch in Ordnung. Die zweite Methode, die wir verwenden können, basiert auf Arptables.
• Der dritte Typ: In relativ neuen Versionen sind zwei neue Kernelparameter (kernelparameter) hinzugekommen. Der erste ist arp_ignore, der die Antwortebene beim Empfang von ARP-Anfragen definiert; der zweite ist arp_announce, der die Ankündigungsebene beim Bekanntgeben der eigenen Adresse nach außen definiert. [Tipp: Offensichtlich unterstützen unsere aktuellen Systeme diese Parameter im Allgemeinen im Kernel. Wir verwenden Parameter, um sie einfacher anzupassen. Es ist weder auf zusätzliche Bedingungen wie Arptables angewiesen, noch auf externe Routing-Konfigurationseinstellungen. Stattdessen verwenden wir normalerweise die dritte Konfigurationsmethode

arp_ignore: definiert die Antwortebene beim Empfang von ARP-Anfragen

0: Sofern lokal eine entsprechende Adresse eingestellt ist, wird eine Antwort gegeben. (Standard)

1: Antworten Sie nur auf ARP-Anfragen, deren Ziel-IP-Adresse eine lokale Netzwerkadresse ist.

2: Antworten Sie nur auf ARP-Anfragen, deren Ziel-IP-Adresse eine lokale Netzwerkadresse ist und deren Quell-IP und Ziel-IP im selben Subnetz liegen.

3: Reagieren Sie nicht auf die ARP-Anfrage der Netzwerkschnittstelle, sondern nur auf die festgelegte eindeutige Verbindungsadresse.

4-7: Reserviert und nicht verwendet.

8: Beantworten Sie nicht alle ARP-Anfragen.

arp_announce: definiert den Bekanntgabegrad der Adresse nach außen:

0: Geben Sie jede Adresse auf jeder lokalen Schnittstelle nach außen bekannt.

1: View gibt nur Adressen bekannt, deren Netzwerk mit dem Zielnetzwerk übereinstimmt.

2: Geben Sie nur an Netzwerke weiter, die mit den Adressen auf der lokalen Schnittstelle übereinstimmen.

9.2. Eigenschaften des DR-Modus

• Stellen Sie sicher, dass der Front-End-Router alle Nachrichten mit der Zieladresse als VIP an den Director-Server und nicht an RS sendet.
• Der VIP von Director und RS ist derselbe VIP.
• RS kann eine private Adresse oder eine öffentliche Netzwerkadresse verwenden. Wenn eine öffentliche Netzwerkadresse verwendet wird, kann auf RIP direkt über das Internet zugegriffen werden.
• RS und Director Server müssen sich im selben physischen Netzwerk befinden.
• Alle Anforderungsnachrichten gehen über den Director-Server, Antwortnachrichten dürfen jedoch nicht über den Director-Server gehen.
• Weder Adressübersetzung noch Portübersetzung werden unterstützt.
• RS kann das gängigste Betriebssystem sein.
• Das RS-Gateway darf niemals auf DIP verweisen (weil wir nicht zulassen, dass es durch Director geht)
• Konfigurieren Sie die VIP-IP-Adresse auf der Lo-Schnittstelle von RS
• Der DR-Modus wird auf dem Markt am häufigsten verwendet.
• Nachteil: RS und DS müssen sich im selben Computerraum befinden.

10. Tunnelmodus

10.1. Funktionsprinzip des Tunnelmodus

(1) Wenn die Benutzeranforderung den Director-Server erreicht, erhält das angeforderte Datenpaket zunächst die PREROUTING-Kette im Kernelbereich. Zu diesem Zeitpunkt ist die Quell-IP des Pakets CIP und die Ziel-IP VIP.

(2) PREROUTING prüft und stellt fest, dass die Ziel-IP des Datenpakets die lokale Maschine ist, und sendet das Datenpaket an die INPUT-Kette.

(3) IPVS vergleicht den vom Datenpaket angeforderten Dienst, um zu sehen, ob es sich um einen Cluster-Dienst handelt. Wenn ja, kapselt es eine weitere Schicht von IP-Paketen in den Header der Anforderungsnachricht ein, mit der Quell-IP als DIP und der Ziel-IP als RIP. Dann wird es an die POSTROUTING-Kette gesendet, wo die Quell-IP DIP und die Ziel-IP RIP ist.

(4) Die POSTROUTING-Kette sendet das Datenpaket basierend auf der zuletzt gekapselten IP-Nachricht an den RS (da in der äußeren Schicht ein zusätzlicher IP-Header gekapselt ist, kann davon ausgegangen werden, dass er zu diesem Zeitpunkt durch einen Tunnel übertragen wird). Zu diesem Zeitpunkt ist die Quell-IP DIP und die Ziel-IP RIP.

(5) Nach dem Empfang der Nachricht stellt RS fest, dass es sich um seine eigene IP-Adresse handelt, und empfängt die Nachricht. Nach dem Entfernen der äußersten IP stellt es fest, dass sich darin eine weitere Schicht von IP-Headern befindet und das Ziel seine eigene lo-Schnittstellen-VIP ist. Dann beginnt RS mit der Verarbeitung der Anforderung. Nach Abschluss der Verarbeitung sendet es sie über die lo-Schnittstelle an die eth0-Netzwerkkarte und gibt sie dann weiter. Zu diesem Zeitpunkt ist die Quell-IP VIP und die Ziel-IP CIP.

(6) Die Antwortnachricht wird schließlich an den Client übermittelt.

10.2. Funktionen des Tunnelmodus

• RIP, VIP und DIP sind allesamt öffentliche Netzwerkadressen.
• Das RS-Gateway wird und kann nicht auf DIP zeigen.
• Alle Anforderungsnachrichten gehen über den Director-Server, Antwortnachrichten dürfen jedoch nicht über den Director-Server gehen.
• Port-Mapping wird nicht unterstützt.
• Das RS-System muss Tunneling unterstützen.

11. LVS-Planungsalgorithmus

Feste Planungsalgorithmen: rr, wrr, dh, sh

Dynamische Planungsalgorithmen: wlc, lc, lblc, lblcr

Fester Planungsalgorithmus: Der Planer beurteilt nicht, ob der Backend-Server beschäftigt ist oder nicht, und versendet die Anfrage wie gewohnt.

Dynamischer Planungsalgorithmus: Der Planer ermittelt die Auslastung des Backend-Servers und verteilt dann Anfragen dynamisch basierend auf dem Planungsalgorithmus.

11.1.rr: Rundenturnier

Dieser Algorithmus ist der einfachste, da er Anfragen im Round-Robin-Verfahren an verschiedene Server verteilt. Das größte Merkmal dieses Algorithmus ist seine Einfachheit. Der Polling-Algorithmus geht davon aus, dass alle Server die gleiche Fähigkeit haben, Anfragen zu verarbeiten. Der Scheduler verteilt alle Anfragen gleichmäßig an jeden realen Server, unabhängig von der Backend-RS-Konfiguration und der Verarbeitungskapazität, und verteilt sie sehr gleichmäßig. Der Nachteil dieser Planung besteht darin, dass der Scheduler die Anfragen der Reihe nach sendet, unabhängig davon, wie ausgelastet der Backend-Server ist. Wenn die Anforderungen auf Server A schnell abgeschlossen werden, die Anforderungen auf Server B jedoch weiterhin bestehen, ist Server B die ganze Zeit über sehr ausgelastet, während Server A sehr untätig ist, wodurch kein Gleichgewicht erreicht wird.

11.2. wrr: gewichtetes Round Robin

Dieser Algorithmus verfügt im Vergleich zum rr-Algorithmus über ein zusätzliches Gewichtskonzept. Sie können ein Gewicht für RS festlegen. Je höher das Gewicht, desto mehr Anfragen werden verteilt. Der Gewichtsbereich liegt zwischen 0 und 100. Es handelt sich hauptsächlich um eine Optimierung und Ergänzung des rr-Algorithmus. LVS berücksichtigt die Leistung jedes Servers und fügt jedem Server eine Gewichtung hinzu. Wenn die Gewichtung von Server A 1 und die von Server B 2 beträgt, sind die für Server B geplanten Anfragen doppelt so hoch wie die von Server A. Je höher das Gewicht eines Servers ist, desto mehr Anfragen verarbeitet er.

11.3. dh: Ziel-Hash-Planungsalgorithmus (Ziel-Hash)

Einfach ausgedrückt werden Anfragen desselben Typs demselben Backend-Server zugewiesen. Beispielsweise werden Anfragen mit der Endung .jgp, .jpg usw. an denselben Knoten weitergeleitet. Dieser Algorithmus dient nicht dem echten Lastausgleich, sondern der klassifizierten Verwaltung von Ressourcen. Dieser Planungsalgorithmus wird hauptsächlich in Systemen verwendet, die Cache-Knoten verwenden, um die Cache-Trefferquote zu verbessern.

11.4. sh: Quell-Hash-Planungsalgorithmus

Das heißt, Anfragen von derselben IP-Adresse werden an denselben Server im Backend gesendet, sofern der Backend-Server ordnungsgemäß funktioniert und nicht überlastet ist. Dies kann das Problem der Sitzungsfreigabe lösen, es gibt hier jedoch ein Problem: Viele Unternehmen, Gemeinden und Schulen teilen sich eine einzige IP-Adresse, was zu einer ungleichmäßigen Verteilung der Anfragen führt.

11.5, lc: kleinste Verbindung

Dieser Algorithmus entscheidet anhand der Anzahl der Verbindungen des Backend-RS, an wen die Anfrage verteilt wird. Wenn beispielsweise die Anzahl der Verbindungen von RS1 geringer ist als die von RS2, wird die Anfrage zuerst an RS1 gesendet. Das Problem hierbei ist, dass Sitzungspersistenz, also Sitzungsfreigabe, nicht erreicht werden kann.

11.6. wlc: gewichtete kleinste Verbindung

Dies beinhaltet ein zusätzliches Konzept der Gewichtung im Vergleich zur Mindestanzahl von Verbindungen, d. h. es wird ein Gewichtungswert auf Grundlage der Mindestanzahl von Verbindungen hinzugefügt. Wenn die Anzahl der Verbindungen ähnlich ist, gilt: Je größer der Gewichtungswert, desto höher ist die Priorität der zugewiesenen Anfrage.

11.7. LBLC: Lokalitätsbasierter Least-Connection-Scheduling-Algorithmus

Anfragen von der gleichen Zieladresse werden, sofern der Server noch nicht vollständig ausgelastet ist, dem gleichen RS zugewiesen, andernfalls dem RS mit der geringsten Anzahl an Verbindungen und dieser wird bei der nächsten Zuweisung zuerst berücksichtigt.

Oben finden Sie ausführliche Inhalte für ein tieferes Verständnis des Lastausgleichs unter Linux (LVS). Weitere Informationen zum Lastausgleich unter Linux (LVS) finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!