Dieser Artikel fasst die Implementierungsmethoden von 6 Lastausgleichstechnologien zusammen (Zusammenfassung).

Lastenausgleich ist ein häufig verwendetes Mittel bei der Bereitstellung von Serverclustern. Wenn die Leistung einer Maschine den Wachstumsanforderungen des Unternehmens nicht gerecht wird, werden Lastenausgleich und Clustering eingesetzt, um die Wachstumsanforderungen der Kunden zu erfüllen, anstatt nach einer Maschine mit besserer Leistung zu suchen.

Die Implementierung der Lastausgleichstechnologie gliedert sich im Wesentlichen in die folgenden Kategorien:

• HTTP-Umleitungsnutzlast
• DNS-Domänennamenauflösungslast
• Reverse-Proxy-Last
• IP-Last (NAT-Last und IP-Tunnel-Last)
• Direktes Routing (LVS-DR)
• IP-Tunnel (LVS-TUN)

Lastverteilung kann nicht so verstanden werden, dass allen tatsächlichen Servern die gleiche Arbeitslast zugewiesen wird, da die Tragfähigkeit mehrerer Server unterschiedlich ist. Dies kann sich in Unterschieden in der Hardwarekonfiguration und Netzwerkbandbreite widerspiegeln oder daran liegen, dass ein Server mehrere Funktionen hat. Was wir als „Balance“ bezeichnen, bedeutet, dass wir hoffen, dass alle Server nicht überlastet werden und maximal funktionieren können.

http-Umleitung

Wenn ein HTTP-Proxy (z. B. ein Browser) eine URL von einem Webserver anfordert, kann der Webserver über das Location-Tag im HTTP-Antwortheader eine neue URL zurückgeben.

Dies bedeutet, dass der HTTP-Proxy diese neue URL weiterhin anfordern muss, um den automatischen Sprung abzuschließen.

Leistungsnachteile:

1. Durchsatzratenbegrenzung

Der Durchsatz der primären Standortserver wird gleichmäßig auf die übertragenen Server verteilt.

Nehmen wir nun an, dass die RR-Planungsstrategie (Round Robin) verwendet wird und der maximale Durchsatz des Subservers 1000 Anforderungen/s beträgt. Dann muss der Durchsatz des Hauptservers 3000 Anforderungen/s erreichen, um die drei Subserver voll auszulasten. Wenn es 100 Subserver gibt, können Sie sich vorstellen, wie hoch der Durchsatz des Hauptservers sein wird.

Wenn dagegen der maximale Durchsatz des Hauptdienstes 6000 Anforderungen/s beträgt, dann beträgt der auf die Unterserver verteilte durchschnittliche Durchsatz 2000 Anforderungen/s und der aktuelle maximale Durchsatz der Unterserver beträgt 1000 Anforderungen/s. Daher muss die Anzahl der Unterserver auf 6 erhöht werden, um die Anforderung zu erfüllen.

2. Unterschiedliche Weiterleitungszugriffstiefen

Einige leiten eine statische Seite um, andere eine komplexe dynamische Seite, sodass der tatsächliche Unterschied in der Serverlast nicht vorhersehbar ist und der Hauptsiteserver nichts davon weiß. Daher ist es keine gute Idee, die Umleitungsmethode zum Lastenausgleich auf der gesamten Site zu verwenden.

Wir müssen den Aufwand für die Übertragung der Anforderung und den Aufwand für die Verarbeitung der tatsächlichen Anforderung abwägen. Je kleiner der erstere im Verhältnis zum letzteren ist, desto größer ist die Bedeutung der Umleitung, beispielsweise des Herunterladens.

Sie können viele Mirror-Download-Sites ausprobieren und werden feststellen, dass die meisten Downloads den Standort zur Umleitung verwenden.

DNS-Lastausgleich

DNS ist für die Bereitstellung von Domänennamenauflösungsdiensten verantwortlich. Wenn Sie auf eine Site zugreifen, müssen Sie zunächst die IP-Adresse abrufen, auf die der Domänenname über den DNS-Server des Domänennamens der Site verweist. Während dieses Vorgangs führt der DNS-Server die Zuordnung des Domänennamens zur IP-Adresse durch.

In ähnlicher Weise kann eine solche Zuordnung auch eins-zu-viele sein. Zu diesem Zeitpunkt fungiert der DNS-Server als Lastenausgleichsplaner. Dies ähnelt der Konvertierungsstrategie für die HTTP-Umleitung und verteilt Benutzeranforderungen auf mehrere Server, aber der Implementierungsmechanismus ist völlig anders.

Verwenden Sie den Befehl dig, um die DNS-Einstellungen von "baidu" anzuzeigen.

Es ist ersichtlich, dass Baidu drei A-Einträge hat

Im Vergleich zur http-Umleitung wird beim DNS-basierten Lastenausgleich die sogenannte Hauptseite vollständig eingespart, bzw. der DNS-Server diente bereits als Hauptseite.

Der Unterschied besteht jedoch darin, dass Sie sich als Scheduler fast keine Gedanken über die Leistung des DNS-Servers selbst machen müssen.

Da DNS-Einträge vom Browser des Benutzers oder den DNS-Servern des Internet-Zugangsanbieters auf allen Ebenen zwischengespeichert werden können, wird die Auflösung erst dann erneut vom DNS-Server des Domänennamens angefordert, wenn der Cache abläuft.

Es wird außerdem gesagt, dass DNS nicht die Durchsatzbeschränkung von HTTP hat und die Anzahl der tatsächlichen Server theoretisch unbegrenzt erhöht werden kann.

Merkmal:

1. Basierend auf der Benutzer-IP kann eine intelligente Analyse durchgeführt werden. Der DNS-Server kann alle verfügbaren A-Einträge nach dem Server durchsuchen, der dem Benutzer am nächsten ist.

2. Dynamisches DNS: Aktualisieren Sie den DNS-Server rechtzeitig, wenn sich die IP-Adresse ändert. Natürlich ist aufgrund des Caching eine gewisse Verzögerung unvermeidlich.

unzureichend:

1. Kein Benutzer kann direkt sehen, zu welchem ​​tatsächlichen Server der DNS aufgelöst wird, was für das Debugging des Serverbetriebs- und Wartungspersonals mit Unannehmlichkeiten verbunden ist.

2. Grenzen der Strategie. Beispielsweise können Sie den Kontext von HTTP-Anfragen nicht in die Planungsstrategie einführen. Im zuvor eingeführten Lastausgleichssystem basierend auf HTTP-Umleitung arbeitet der Scheduler auf HTTP-Ebene. Er kann die HTTP-Anfrage vollständig verstehen und die Planungsstrategie entsprechend der Anwendungslogik der Site entwerfen, z. B. sinnvolles Filtern und Übertragen entsprechend unterschiedlicher angeforderter URLs.

3. Wenn Sie die Planungsstrategie basierend auf den Echtzeit-Lastunterschieden der tatsächlichen Server anpassen möchten, muss der DNS-Server bei jedem Auflösungsvorgang den Integritätsstatus jedes Servers analysieren. Für DNS-Server ist diese Art der benutzerdefinierten Entwicklung sehr anspruchsvoll, ganz zu schweigen davon, dass die meisten Websites nur DNS-Dienste von Drittanbietern verwenden.

4. DNS-Eintrag-Cache. Die Caches verschiedener Programme auf DNS-Servern auf allen Knotenebenen werden Ihnen schwindelig machen.

5. Basierend auf den oben genannten Punkten kann der DNS-Server die Arbeitslastverteilung nicht sehr gut durchführen. Ob Sie sich letztendlich für DNS-basierte Lastverteilung entscheiden, hängt ganz von Ihren Anforderungen ab.

Reverse-Proxy-Lastausgleich

Dies ist sicherlich etwas, mit dem jeder schon einmal in Berührung gekommen ist, da nahezu alle gängigen Webserver die auf Reverse-Proxys basierende Lastverteilung unterstützen. Seine Hauptaufgabe besteht darin, HTTP-Anfragen weiterzuleiten.

Im Vergleich zur bisherigen HTTP-Umleitung und DNS-Auflösung übernimmt der Reverse-Proxy-Dispatcher die Rolle eines Vermittlers zwischen dem Benutzer und dem eigentlichen Server:

1. Jede HTTP-Anfrage an den eigentlichen Server muss durch den Scheduler gehen

2. Der Scheduler muss auf die HTTP-Antwort vom tatsächlichen Server warten und diese an den Benutzer zurückmelden (die ersten beiden Methoden erfordern keine Planungsrückmeldung, der tatsächliche Server sendet sie direkt an den Benutzer).

Merkmal:

1. Umfangreiche Planungsstrategien. So können zum Beispiel für unterschiedliche tatsächliche Server unterschiedliche Gewichtungen festgelegt werden, um den Effekt zu erzielen, dass die Leistungsstärkeren mehr Arbeit haben.

2. Der Reverse-Proxy-Server stellt hohe Anforderungen an die gleichzeitige Verarbeitungskapazität, da er auf HTTP-Ebene arbeitet.

3. Der Weiterleitungsvorgang des Reverse-Proxy-Servers selbst erfordert einen gewissen Overhead, z. B. das Erstellen von Threads, das Herstellen einer TCP-Verbindung mit dem Back-End-Server, das Empfangen der vom Back-End-Server zurückgegebenen Verarbeitungsergebnisse, das Analysieren von HTTP-Header-Informationen und das häufige Wechseln zwischen Benutzerbereich und Kernelbereich.

Obwohl dieser Zeitanteil nicht lang ist, wird der Weiterleitungsaufwand besonders deutlich, wenn der Back-End-Server die Anforderung in sehr kurzer Zeit verarbeitet. Wenn Sie beispielsweise statische Dateien anfordern, ist es besser, die zuvor vorgestellte DNS-basierte Methode zum Lastenausgleich zu verwenden.

4. Der Reverse-Proxy-Server kann den Backend-Server überwachen, z. B. Systemlast, Antwortzeit, Verfügbarkeit, Anzahl der TCP-Verbindungen, Datenverkehr usw. und die Lastausgleichsstrategie basierend auf diesen Daten anpassen.

5. Der Reflective Proxy-Server ermöglicht die Weiterleitung aller Benutzeranfragen innerhalb eines Sitzungszyklus an einen bestimmten Backend-Server (Sticky Session). Dies hat folgende Vorteile: Erstens bleibt der lokale Zugriff auf die Sitzung erhalten und zweitens wird die Verschwendung dynamischer Cache-Ressourcen auf dem Backend-Server vermieden.

IP-Lastausgleich (LVS-NAT)

Da der Reverse-Proxy-Server auf der HTTP-Ebene arbeitet, ist seine Skalierbarkeit durch seinen eigenen Overhead stark eingeschränkt und damit auch seine Leistungsgrenze erreicht. Ist ein Lastenausgleich unterhalb der HTTP-Ebene möglich?

NAT-Server: Er arbeitet auf der Transportebene. Er kann die gesendeten IP-Datenpakete ändern und die Zieladresse der Datenpakete in die tatsächliche Serveradresse ändern.

Ab dem Linux-Kernel 2.4 verwaltet das integrierte Neftilter-Modul einige Paketfiltertabellen im Kernel. Diese Tabellen enthalten Regeln zur Steuerung der Paketfilterung.

Glücklicherweise bietet Linux iptables zum Einfügen, Ändern und Löschen von Filtertabellen. Noch spannender ist, dass der Linux 2.6.x-Kernel über ein integriertes IPVS-Modul verfügt, das ähnlich wie das Netfilter-Modul funktioniert, sich jedoch stärker auf die Erzielung eines IP-Lastausgleichs konzentriert.

Um herauszufinden, ob Ihr Serverkernel das IPVS-Modul installiert hat, können Sie

Ausgabe bedeutet, dass IPVS installiert wurde. Das Verwaltungstool von IPVS ist ipvsadm, das eine befehlszeilenbasierte Konfigurationsschnittstelle bereitstellt, über die schnell ein Lastausgleichssystem implementiert werden kann.

Dies ist der berühmte LVS (Linux Virtual Server).

1. Öffnen Sie die Paketweiterleitungsoption des Schedulers

echo 1 > /proc/sys/net/ipv4/ip_forward

2. Überprüfen Sie, ob der eigentliche Server den NAT-Server als Standard-Gateway verwendet hat. Wenn nicht, fügen Sie hinzu

Route hinzufügen Standard gw xx.xx.xx.xx

3. Verwenden Sie die ipvsadm-Konfiguration

ipvsadm -A -t 111.11.11.11:80 -s rr

Fügen Sie einen virtuellen Server hinzu. Auf -t folgen die externe Netzwerk-IP und der Port des Servers. -s rr bezieht sich auf die RR-Planungsstrategie mit einfachem Polling (dies ist eine statische Planungsstrategie. Darüber hinaus bietet LVS auch eine Reihe dynamischer Planungsstrategien, wie z. B. Least Connection (LC), Least Connection with Weight (WLC), Shortest Expected Delay (SED) usw.).

ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.210:8000 -m 
ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.211:8000 -m

Fügen Sie zwei tatsächliche Server hinzu (keine externe IP erforderlich), auf -r folgt die interne IP und der Port des tatsächlichen Servers, -m bedeutet die Verwendung von NAT zum Weiterleiten von Datenpaketen

Führen Sie ipvsadm -L -n aus, um den Status des aktuellen Servers anzuzeigen. Das ist es.

Experimente haben den Einsatz eines NAT-basierten Lastausgleichssystems gezeigt. Ein als Dispatcher agierender NAT-Server kann den Durchsatz auf ein neues Niveau steigern, fast das Doppelte eines Reverse-Proxy-Servers, was größtenteils auf den geringeren Overhead bei der Anforderungsweiterleitung im Kernel zurückzuführen ist.

Wenn der angeforderte Inhalt jedoch zu groß ist, unterscheidet sich der Gesamtdurchsatz des Lastenausgleichs nicht wesentlich, unabhängig davon, ob er auf einem Reverse-Proxy oder NAT basiert. Dies zeigt, dass es sich bei Inhalten mit hohem Overhead lohnt, die Verwendung eines einfachen Reverse-Proxys zum Aufbau eines Lastenausgleichssystems in Betracht zu ziehen.

Selbst ein so leistungsfähiges System weist immer noch einen Engpass auf: die Netzwerkbandbreite des NAT-Servers, einschließlich des internen und des externen Netzwerks.

Wenn Sie Geld haben, können Sie natürlich einen Gigabit-Switch oder einen 10-Gigabit-Switch oder sogar ein Hardwaregerät zum Lastenausgleich kaufen, aber was können Sie tun, wenn Sie ein Verlierer sind?

Eine einfache und effektive Möglichkeit besteht darin, NAT-basierte Cluster mit dem vorherigen DNS zu mischen, z. B. einen Cluster mit 5 100 Mbit/s-Exportbreitband, und dann DNS zu verwenden, um Benutzeranforderungen gleichmäßig an diese Cluster weiterzuleiten. Gleichzeitig können Sie auch die intelligente DNS-Auflösung verwenden, um regionalen Zugriff zu erreichen.

Für die meisten Unternehmen reicht eine solche Konfiguration zwar aus, für große Websites, die Dienste wie Downloads oder Videos anbieten, ist der NAT-Server jedoch immer noch nicht gut genug.

Direktes Routing (LVS-DR)

NAT arbeitet auf der Transportschicht (Schicht 4) des Netzwerkschichtenmodells, während direktes Routing auf der Datenverbindungsschicht (Schicht 2) arbeitet, die leistungsfähiger zu sein scheint.

Es leitet das Datenpaket an den tatsächlichen Server weiter, indem es die Ziel-MAC-Adresse des Datenpakets ändert (ohne die Ziel-IP zu ändern). Der Unterschied besteht darin, dass das Antwortdatenpaket des tatsächlichen Servers direkt an den Client gesendet wird, ohne den Scheduler zu durchlaufen.

1. Netzwerkeinstellungen

Hier gehen wir von einem Lastenausgleichsplaner und zwei tatsächlichen Servern aus und kaufen drei externe IP-Adressen, eine für jede Maschine. Die Standardgateways der drei Maschinen müssen gleich sein und schließlich muss der gleiche IP-Alias ​​festgelegt werden. Hier gehen wir davon aus, dass der Alias ​​10.10.120.193 ist.

Auf diese Weise wird auf den Dispatcher über den IP-Alias ​​10.10.120.193 zugegriffen und Sie können den Domänennamen der Site auf diesen IP-Alias ​​verweisen.

2. Fügen Sie den IP-Alias ​​zur Loopback-Schnittstelle hinzu lo

Damit wird verhindert, dass der eigentliche Server nach anderen Servern mit diesem IP-Alias ​​sucht. Führen Sie auf dem eigentlichen Server Folgendes aus:

Darüber hinaus müssen Sie verhindern, dass der eigentliche Server auf ARP-Broadcasts für IP-Aliase aus dem Netzwerk antwortet. Dazu müssen Sie außerdem Folgendes ausführen:

• echo "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore
• echo "2" > /proc/sys/net/ipv4/conf/lo/arp_announce
• echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore
• echo "1" > /proc/sys/net/ipv4/conf/all/arp_announce

Nachdem die Konfiguration abgeschlossen ist, können Sie ipvsadm verwenden, um den LVS-DR-Cluster zu konfigurieren.

• ipvsadm -A -t 10.10.120.193:80 -s rr
• ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.210:8000 -g
• ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.211:8000 -g

-g bedeutet die Weiterleitung von Paketen mittels direktem Routing

Der größte Vorteil von LVS-DR gegenüber LVS-NAT besteht darin, dass LVS-DR nicht durch die Bandbreite des Schedulers begrenzt ist. Angenommen, die drei Server haben beispielsweise eine auf 10 Mbit/s begrenzte Exportbandbreite des WAN-Switches, dann gibt es keine Geschwindigkeitsbegrenzung für den LAN-Switch, der den Scheduler und die beiden eigentlichen Server verbindet.

Nun, durch die Verwendung von LVS-DR kann theoretisch eine maximale Exportbandbreite von 20 Mbit/s erreicht werden, da das tatsächliche Serverantwortdatenpaket direkt an das Benutzerende gesendet werden kann, ohne den Scheduler zu durchlaufen. Es hat also nichts mit der Exportbandbreite des Schedulers zu tun, sondern nur mit seiner eigenen.

Beim Einsatz von LVS-NAT steht dem Cluster nur eine maximale Bandbreite von 10 Mbit/s zur Verfügung. Daher sollte bei Diensten, bei denen die Anzahl der Antwortpakete die Anzahl der Anforderungspakete bei weitem übersteigt, der Overhead des Schedulers für die Übertragung von Anforderungen reduziert werden, wodurch die allgemeine Skalierbarkeit verbessert und letztendlich die WAN-Ausgangsbandbreite stärker genutzt wird.

Im Allgemeinen eignet sich LVS-DR zum Aufbau eines skalierbaren Lastausgleichssystems. Es bietet eine hervorragende Leistung, unabhängig davon, ob es sich um einen Webserver, einen Dateiserver oder einen Videoserver handelt. Voraussetzung ist, dass Sie für den eigentlichen Server eine Reihe gültiger IP-Adressen erwerben.

IP-Tunnel (LVS-TUN)

Anforderungsweiterleitungsmechanismus basierend auf IP-Tunnel: Das vom Scheduler empfangene IP-Datenpaket wird in ein neues IP-Datenpaket gekapselt und an den tatsächlichen Server weitergeleitet. Anschließend kann das Antwortdatenpaket des tatsächlichen Servers das Benutzerende direkt erreichen.

Derzeit wird dies von den meisten Linux-Versionen unterstützt und kann mit LVS implementiert werden, genannt LVS-TUN. Anders als bei LVS-DR dürfen sich der eigentliche Server und der Scheduler nicht im selben WANt-Segment befinden. Der Scheduler leitet Anfragen über IP-Tunneling-Technologie an den eigentlichen Server weiter, daher muss der eigentliche Server auch eine gültige IP-Adresse haben.

Im Allgemeinen sind sowohl LVS-DR als auch LVS-TUN für Webserver mit asymmetrischen Antworten und Anfragen geeignet. Welche Sie zwischen ihnen wählen, hängt von Ihren Netzwerkbereitstellungsanforderungen ab. Da LVS-TUN je nach Bedarf tatsächliche Server in verschiedenen Regionen bereitstellen und Anfragen basierend auf dem Näheprinzip übertragen kann, sollten Sie sich bei ähnlichen Anforderungen für LVS-TUN entscheiden.

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.