lvs-Cluster, NAT-Modus und DR-Modus, keepalive

Der vollständige Name lautet Linux Virtual Server. Dabei handelt es sich um eine Software, die den Lastausgleich auf Linux-Kernel-Ebene implementiert.

Hauptfunktion: Bilden Sie mehrere Back-End-Server zu einem hochverfügbaren und leistungsstarken Servercluster und verteilen Sie Clientanforderungen über Lastausgleichsalgorithmen an Back-End-Server, um eine hohe Verfügbarkeit und einen Lastausgleich zu erreichen.

Alibabas SLB-Server-Loab-Balance wird mit lvs+keepalive implementiert.

Geclustert und verteilt

So erweitern Sie das System:

Vertikale Skalierung: Skalierung nach oben, um leistungsfähigere Computer zu bauen.Engpässe: Einschränkungen der eigenen Ausstattung des Computers; Leistungsengpässe der Hardware selbst

Horizontale Erweiterung: Nach außen erweitern und Ausrüstung hinzufügen.Führen Sie mehrere Dienste parallel aus und verlassen Sie sich auf das Netzwerk, um interne Kommunikationsprobleme zu lösen, Cluster-Cluster

Cluster: Ein einzelnes System, das durch die Kombination mehrerer Computer zur Lösung eines bestimmten Problems entsteht

Arten von Clustern: drei Arten

PFUND: Load-Balancing-Cluster, bestehend aus mehreren Hosts, jeder Host trägt nur einen Teil der Zugriffsanforderungen

HA : hohe Verfügbarkeit: Beim Entwurf des Systems werden bestimmte Maßnahmen ergriffen, um sicherzustellen, dass bei Ausfall einer Komponente oder eines Teils des Systems das gesamte System weiterhin normal laufen kann.Zur Aufrechterhaltung der Systemverfügbarkeit, Zuverlässigkeit und Fehlertoleranz

Hochleistungsrechnen：Hochleistungs-Computing-Hochleistungscluster mit höheren Anforderungen an Reaktionszeit und Rechenleistung

Systemzuverlässigkeitsindex

MEIN FREUND: Mittlere Zeit zwischen Ausfällen. Mittlere Zeit zwischen Ausfällen

MTTR: Durchschnittliche Wiederherstellungszeit. Reparatur bedeutet Zeit bis zur Wiederherstellung

A = MTBF/(MTBF + MTTR)

Der A-Index sollte zwischen 0 und 1 liegen. Der A-Index ist ein Maß für die Systemverfügbarkeit. 0 bedeutet, dass das System weniger verfügbar ist, 1 bedeutet, dass das System höher verfügbar ist.

Der A-Indikator sollte unendlich nahe bei 1 liegen (98 %–99 % qualifiziert; 90 %–95 % unqualifiziert).

Alle Angaben in Stunden (8760 Stunden in einem Jahr, 365 Tage)

Ausfallzeiten und geplante Zeit sind nicht enthalten

Die ungeplante Zeit, also die Ausfallzeit, ist die Gesamtzeit vom Auftreten des Fehlers bis zur Fehlerbehebung. Die ungeplante Zeit ist ein Indikator, auf den wir achten müssen.

Anwendbare LVS-Szenarien:

Kleine Cluster müssen kein LVS verwenden, sondern Nginx, und große Cluster müssen LVS verwenden

Terminologie im LVS-Cluster

VS: Der logische Name des Vittual-Server-LVS-Dienstes. Dies ist die IP-Adresse und der Port, die wir verwenden, wenn wir von außen auf den LVS-Cluster zugreifen.

DS: Der Hauptserver im Director-Server-LVS-Cluster, also der Scheduler (also der Nginx-Proxy-Server), ist der Kern des Clusters. Der Scheduler wird verwendet, um Client-Anfragen anzunehmen und an das Back-End weiterzuleiten Server.

RS: Der reale Server im realen Server-LVS-Cluster, der Back-End-Server, wird verwendet, um von DS weitergeleitete Anforderungen anzunehmen und auf die Ergebnisse zu antworten.

CIP: Client-IP Die Adresse des Clients, also die Adresse des Clients, der die Anfrage initiiert hat

VIP: Virtuelle IP-IP-Adresse, die vom LVS-Cluster verwendet wird, virtuelle IP-Adresse, die externen Clusterzugriff ermöglicht

DIP: Director-IP ist die Adresse des Schedulers im Cluster, die für die Kommunikation mit RS verwendet wird

RIP: echte IP Die IP-Adresse des Back-End-Servers im Cluster

So funktioniert lvs

NAT-Modus: Der Modus wird dem Client vom Scheduler (Adressübersetzung) geantwortet.

DR-Modus (Direct-Routing-Modus): Der reale Server antwortet direkt auf den Client

TUN-Modus: Tunnelmodus

Häufig verwendete Modi: NAT-Modus und DR-Modus

NAT-Modus

Im NAT-Modus ändert LVS die Ziel-IP-Adresse und den Ziel-Port in der Anforderungsnachricht vom Client in die IP-Adresse und den Port innerhalb von LVS und leitet die Anforderung dann an den Back-End-Server weiter.

Wenn das Antwortergebnis an den Client zurückgegeben wird, wird die Antwortnachricht von lvs verarbeitet und die Ziel-IP und der Ziel-Port werden in die IP-Adresse und den Port des Clients geändert.

Prinzip: Wenn der Load Balancer zunächst das Anforderungspaket des Kunden empfängt, bestimmt er anhand des Planungsalgorithmus, an welchen realen Backend-Server (RS) die Anforderung gesendet werden soll.
Der Load Balancer ändert dann die Ziel-IP-Adresse und den Ziel-Port des vom Client gesendeten Anforderungspakets in die IP-Adresse (RIP) des realen Back-End-Servers.
Nachdem der reale Server auf die Anfrage geantwortet hat, überprüft er die Standardroute und sendet das Antwortdatenpaket an den Load Balancer
Ändern Sie die Quelladresse des Pakets in eine virtuelle Adresse (VIP) und senden Sie es an den Client zurück.

Vorteile: Server im Cluster können jedes Betriebssystem verwenden, das TCP/IP unterstützt, sofern der Load Balancer über eine legale IP-Adresse verfügt.

Nachteile: Begrenzte Skalierbarkeit, wenn Serverknoten zu stark wachsen, da alle Anfragen und Antworten den Load Balancer durchlaufen müssen.
Daher wird der Load Balancer zum Flaschenhals des gesamten Systems.

Gekennzeichnet durch Adressübersetzung

Adressübersetzung: internes Netzwerk - externes Netzwerk, die Quell-IP-Adresse wird SNAT konvertiert

Externes Netzwerk-internes Netzwerk konvertiert die Ziel-IP-Adresse DNAT

lvs-Tools

ipvsadmTools zum Konfigurieren und Verwalten von LVS-Clustern

-A fügt VIP des virtuellen Servers hinzu

-D virtuelle Serveradresse löschen

-s gibt den Planungsalgorithmus für den Lastausgleich an

-a fügt einen echten Server hinzu

-d echten Server löschen

-t gibt die VIP-Adresse und den Port an

-r gibt die Adresse und den Port des RIP an

-m NAT-Modus verwenden

-g DR-Modus verwenden

-i Tunnelmodus verwenden

-w legt das Gewicht fest

-p 60 hält die Verbindung für 60 Sekunden. Legt die Verbindungshaltezeit fest

-l Listenansicht

-n Digitalanzeige

Algorithmus

Umfrage rr

Gewichtete Umfrage wrr

Mindestverbindung lc

gewichteter kleinster Link WLC

Experiment

Datenfluss

nginx 1 RS1 192.168.233.20

nginx2 RS2 192.168.233.30

test1-Scheduler ens33 192.168.233.10 ens36 12.0.0.1

test2-Client 12.0.0.10

Schritt

1. Scheduler-Konfiguration (test1 192.168.233.10)

yum -y installiere ipvsadm* -y

Konfigurieren Sie ens33

systemctl restart network

Konfigurieren Sie ens36

cd /etc/sysconfig/netzwerkskripte/

cp ifcfg-ens33 ifcfg-ens36

vim ifcfg-ens36

systemctl restart network

2. RS-Konfiguration (nginx1 und nginx2)

Konfigurieren Sie nginx1 192.168.233.20 und ändern Sie das Gateway

systemctl restart network

Konfigurieren Sie Nginx2 192.168.233.30 und ändern Sie das Gateway

systemctl restart network

vim /usr/local/nginx/html/index.html

Ändern Sie den Inhalt der besuchten Seite

Überprüfen Sie, ob der Zugriff verbunden ist

3. Adressübersetzung (test1 192.168.233.10)

iptables -t nat -vnL Überprüfen Sie, ob die NAT-Tabelle eine Richtlinie hat

iptables -t nat -A POSTROUTING -s 192.168.233.0/24 -o ens36 -j SNAT --to 12.0.0.1

Die Geräteadresse von 192.168.233.0/24 wird in 12.0.0.1 umgewandelt

ipvsadm -C löscht die ursprüngliche Richtlinie

ipvsadm -A -t 12.0.0.1:80 -s rr Geben Sie die VIP-Adresse und den Port an

Fügen Sie zuerst den VIP, die IP und den Port des virtuellen Servers hinzu und fügen Sie dann den realen Server hinzu

ipvsadm -a -t 12.0.0.1:80 -r 192.168.233.20:80 -m

-a echten Server hinzufügen

-t gibt die VIP-Adresse an

-r gibt die Adresse und den Port des realen Servers an

-m gibt den Modus als NAT-Modus an

ipvsadm -ln anzeigen

ipvsadm-save speichern

ipvsadm -D -t 192.168.233.10:80 Richtlinie löschen

ipvsadm -d -r 192.168.233.20: -t 12.0.0.1:80 Knotenserver löschen

5. Aktivieren Sie die Routing- und Weiterleitungsfunktion

vim /etc/sysctl.conf

net.ipv4.ip_forward=1

4. Client (test2 12.0.0.10)

Ändern Sie die IP-Adresse und das Gateway von test2

Experimentelle Ergebnisse

gewichtete Umfrage

DR-Modus

Konzept

Es handelt sich um den direkten Routing-Modus

NAT-Modus: Der Scheduler ist der wichtigste im gesamten LVS-Cluster. Im NAT-Modus ist er für den Empfang von Anforderungen, die Weiterleitung des Datenverkehrs gemäß dem Lastausgleichsalgorithmus und das Senden von Antworten an den Client verantwortlich.

DR-Modus: Der Scheduler ist weiterhin für den Empfang von Anforderungen verantwortlich und leitet den Datenverkehr gemäß dem Lastausgleichsalgorithmus auch an RS weiter. Die Antwort wird von RS direkt an den Client gesendet.

Direktes Routing: Es handelt sich um einen Layer-2-Weiterleitungsmodus. Layer 2 leitet Datenrahmen weiter und leitet sie basierend auf der Quell-MAC-Adresse und der Ziel-MAC-Adresse weiter, ohne die Quell-IP und Ziel-IP des Datenpakets zu ändern. Weiterleiten basierend auf der MAC-Adresse des Datenpakets.

Im DR-Modus verwaltet LVS auch eine virtuelle IP-Adresse und alle Anforderungen werden an diese VIP gesendet. Da die Weiterleitung der Ebene 2 verwendet wird, wird ein RS entsprechend dem Lastausgleichsalgorithmus und dem VIP-Server ausgewählt, wenn die Anforderung des Clients den Scheduler erreicht Der Ziel-Mac wird zur MAC-Adresse von RS. Nachdem RS die Anfrage verarbeitet hat, kann er die Antwort entsprechend der Quell-Mac-Adresse des Clients in der Nachricht direkt senden, ohne den Scheduler zu durchlaufen.

Prinzip: Wenn der Load Balancer zunächst das Anforderungspaket des Kunden empfängt, bestimmt er anhand des Planungsalgorithmus, an welchen realen Backend-Server (RS) die Anforderung gesendet werden soll.
Der Load Balancer ändert dann die Ziel-MAC-Adresse des vom Client gesendeten Anforderungspakets in die MAC-Adresse (R-MAC) des realen Backend-Servers.
Nachdem der reale Server auf die Anfrage geantwortet hat, überprüft er die Standardroute und sendet das Antwortpaket direkt an den Client, ohne den Load Balancer zu durchlaufen.

Vorteile: Der Load Balancer ist nur für die Verteilung von Anforderungspaketen an Back-End-Knotenserver verantwortlich, während RS Antwortpakete direkt an Benutzer sendet.
Dadurch wird der große Datenfluss durch den Load Balancer reduziert. Der Load Balancer stellt nicht länger den Engpass des Systems dar und kann eine große Menge an Anfragen verarbeiten.

Nachteile: Sowohl der Load Balancer als auch der reale Server RS müssen über eine Netzwerkkarte verfügen, die mit demselben physischen Netzwerksegment verbunden ist, und sie müssen sich in derselben LAN-Umgebung befinden.

Datenflussdiagramm

Frage:

1. VIP-Adresskonflikt

Grund: Der Scheduler ist mit VIP konfiguriert und der RS ist auch mit einer VIP-Adresse konfiguriert. Ein VIP-Adresskonflikt führt zu einer ARP-Kommunikationsstörung, da sich der Scheduler und der RS beide im selben Netzwerksegment befinden. Da es im gesamten LAN ausgestrahlt wird, empfangen es alle Geräte.

So blockieren Sie die Loopback-Antwort von lo, sodass nur die physische IP-Adresse dieser Maschine antwortet.

Lösung: Ändern Sie die Kernel-Parameter:arp_ignore=1

Nur die physische IP-Adresse des Systems antwortet auf ARP-Anfragen, und die Lo-Loopback-Schnittstelle antwortet nicht auf ARP-Anfragen.

2. Wenn die Nachricht zurückgegeben wird, ist die VIP-Adresse noch vorhanden. Wie kann der Client die Antwort erhalten?

Lösung:arp_announce=2

Das System verwendet nicht die Quelladresse des IP-Pakets, um auf die ARP-Anfrage zu antworten, sondern sendet direkt die IP-Adresse der physischen Schnittstelle.

Implementierung des DR-Modus

nginx1 RS (echte IP) 192.168.233.20

nginx2 RS 192.168.233.30

VIP-Nummer: 192.168.233.100

Planer 192.168.233.10

Kunde 192.168.233.40

Schritt

1. Scheduler-Konfiguration (test1 192.168.233.10)

yum -y installiere ipvsadm* -y

Fügen Sie die virtuelle Netzwerkkarte ens33:0 hinzu

Ändern Sie die Antwortparameter des Schedulers

vim /etc/sysctl.conf

net.ipv4.ip_forward=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0
net.ipv4.conf.ens33.send_redirects=0

sysctl -p

Richtlinie hinzufügen

cd /opt

ipvsadm -A -t 192.168.233.100:80 -s rr

ipvsadm -a -t 192.168.233.100:80 -r 192.168.233.20:80 -g

ipvsadm -a -t 192.168.233.100:80 -r 192.168.233.30:80 -g

ipvsadm-speichern >/etc/sysconfig/ipvsadm

systemctl restart ipvsadm

ipvsadm -ln

2. RS-Konfiguration (nginx1 und nginx2) [muss beide Male geändert werden]

Ändern Sie den Anzeigeinhalt statischer Seiten

vim /usr/local/nginx/html/index.html

systemctl startet nginx neu

Loopback-Adresse hinzufügen

cd /etc/sysconfig/netzwerkskripte/

cp ifcfg-lo ifcfg-lo:0

vim ifcfg-lo:0

lo:0-Schnittstelle als vip hinzufügen

Route hinzufügen -Host 192.168.233.100 dev lo:0

Stellen Sie die IP-Adresse auf 192.168.233.100 ein und fügen Sie sie als VIP von lvs zur Loopback-Schnittstelle hinzu. Sie wird über den Routing-Modus an RS weitergeleitet, wodurch der VIP den tatsächlichen Server identifizieren kann.

Ändern Sie die Kernel-Antwort des RS-Real-Servers

vim /etc/sysctl.conf

net.ipv4.conf.lo.arp_ignore=1
net.ipv4.conf.lo.arp_announce=2
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

Experimentelle Ergebnisse

Ändern Sie den VIP-Abfragealgorithmus

Ändern Sie die Gewichtung bei der Richtlinienabfrage

Zusammenfassen

Der Unterschied zwischen lvs und nginx für den Lastausgleich

LVS ist eine vierschichtige Weiterleitung, die IP + Port im Kernelmodus verwendet und nur als vierschichtiger Proxy verwendet werden kann.

Nginx-Vierschicht-Proxy oder Siebenschicht-Proxy

Zusammenfassendes Experiment

lvs (DR-Modus)+nginx+tomcat

LVS implementiert eine vierschichtige Weiterleitung + Nginx implementiert eine siebenschichtige Weiterleitung (dynamisch). Durch den Zugriff auf die VIP-Adresse von LVS kann eine dynamische und statische Trennung erreicht werden.

Datenflussdiagramm

Experimentelle Schritte

Basierend auf den obigen Experimenten im DR-Modus wird eine dynamische und statische Trennung erreicht.

1. Katerteil

1. Erstellen Sie dynamische Seiten in Tomcat1 bzw. Tomcat2

<%@ Seitensprache="java" import="java.util.*" Seitenkodierung="UTF-8"%>
<html>
<head>
<title>JSP-Test1-Seite</title>
</head>
<body>
<% out.println("Dynamische Seite 1, http://www.test1.com");%>
</body>
</html>

2. Fügen Sie Sites zu Tomcat1 bzw. Tomcat2 hinzu

CD-Konf

vim server.xml

Löschen Sie zuerst die ursprüngliche Site

Überprüfen Sie, ob der Port gestartet ist

Besuchen Sie 192.168.233.40:8080/index.jsp

2. Nginx-Teil

Konfigurieren Sie nginx2 und nginx3

cd /usr/local/nginx/conf/

cp nginx.conf nginx.conf.bak.2024.07.08

vim nginx.conf

Upstream-Tomcat {
Server 192.168.233.40:8080 Gewicht=1;
Server 192.168.233.50:8080 Gewicht=1;
}

Standort ~ .*.jsp$ {
Proxy-Passwort http://Tomcat;
Proxy_Set_Header HOST $Host;
Proxy_Set_Header X-Real-IP $Remote_Addr;
proxy_set_header X-Weitergeleitet-Für $proxy_add_x_forwarded_for;
}

Dann startet systemctl nginx neu

Konfigurieren Sie den Nginx1-Proxy

Seien Sie ein vierstufiger Agent

cd /usr/local/nginx/conf

vim nginx.conf

Dann startet systemctl nginx neu

Experimentelle Ergebnisse

Besuchen Sie die statische Seite 192.168.100:81

Besuchen Sie die dynamische Seite 192.168.233.100:82/index.jsp

Drei Arbeitsmodi von lvs

NAT DR TUN

Vorteile: Adressübersetzung, einfache Konfiguration, beste WAN-Leistung, kann Datenpaketweiterleitung über größere Entfernungen erreichen

Nachteile Leistungsengpass Unterstützt keine netzwerksegmentübergreifenden dedizierten Kanäle, erfordert die Eröffnung eines VPN (kostet Geld)

RS-Anforderungen: Es müssen keine Einschränkungen für ARP-Antworten auf nicht-physischen Schnittstellen vorhanden sein.

Menge RS 10-20 Einheiten 100 Einheiten 100 Einheiten

Interview Fragen:

1. Beschreiben Sie kurz die drei Modi und Unterschiede von lvs

Tabelle oben

2. So lösen Sie das Split Brain in Keepalive