Keepalived implementiert Nginx-Lastausgleich und Beispielcode für hohe Verfügbarkeit

Kapitel 1: Einführung in Keepalived

Der Zweck des VRRP-Protokolls besteht darin, das Single Point Failure-Problem des statischen Routings zu lösen.

Kapitel 2: So funktioniert Keepalived

2.1 Hochverfügbarkeitsfunktion (Failover) als Systemnetzwerkdienst

Das Grundprinzip der Keepalived-Hochverfügbarkeitsfunktion ist:
Installieren Sie die Keepalived-Software auf beiden Hosts und starten Sie den Dienst. Wenn beide Hosts normal arbeiten, erhält der Host mit der Rolle des Masters alle Ressourcen und stellt den Benutzern Dienste zur Verfügung. Der Host mit der Rolle des Backups dient als Hot-Standby für den Master-Host.

Wenn der Host mit der Master-Rolle ausfällt oder eine Fehlfunktion aufweist, übernimmt der Host mit der Backup-Rolle automatisch die gesamte Arbeit des Master-Hosts, einschließlich der Übernahme von VIP-Ressourcen und entsprechenden Ressourcendiensten.

Wenn der Fehler des Hosts mit der Rolle des Masters behoben ist, übernimmt dieser automatisch die Arbeit, die er ursprünglich erledigt hat. Der Host mit der Rolle des Backups gibt auch die Arbeit frei, die er übernommen hat, als der Master-Host ausgefallen ist. Zu diesem Zeitpunkt kehren die beiden Hosts zum Zeitpunkt des Starts zu ihren ursprünglichen Rollen und Arbeitszuständen zurück.

2.2 Was ist VRRP
VRRP, vollständiger Name Virtual Router Redundancy Protocol, chinesischer Name ist Virtual Router Redundancy Protocol
VRRP wurde entwickelt, um das Single-Point-Failure-Problem des statischen Routings zu lösen.
VRRP weist einem VRRP-Router über einen Kampagnenmechanismus Routing-Aufgaben zu.

VRRP implementiert die Funktion eines virtuellen Routers über einen Auswahlmechanismus. Alle Protokollnachrichten werden in Form von IP-Multicast-Paketen gesendet (Standard-Multicast-Adresse 224.0.0.18).
Ein virtueller Router besteht aus einer VRID (Bereich 0-255) und einer Reihe von IP-Adressen, die extern als bekannte MAC-Adresse erscheinen: 00-00-5E-00-01-{VRID}.
Daher werden in einem virtuellen Router unabhängig davon, wer der Master ist, extern dieselbe MAC-Adresse und IP-Adresse (VIP genannt) verwendet.
Client-Hosts müssen ihre Routing-Konfigurationen aufgrund von Änderungen im Master nicht ändern. Für sie ist dieser Switch transparent.

In einer Gruppe virtueller Router sendet immer nur der VRRP-Router, der der Master ist, VRRP-Broadcast-Pakete. Zu diesem Zeitpunkt wird der Backup dem Master nicht den Vortritt lassen.
Wenn der Master nicht verfügbar ist, empfängt der Backup keine Broadcast-Pakete vom Master. Zu diesem Zeitpunkt übernimmt der Router mit der höchsten Priorität unter den mehreren Backups die Rolle des Masters.
Diese Präemption erfolgt sehr schnell (möglicherweise nur 1 Sekunde oder sogar weniger), um die Dienstkontinuität sicherzustellen. Aus Sicherheitsgründen werden VRRP-Datenpakete mithilfe von Verschlüsselungsprotokollen verschlüsselt.

2.3 Was man in einem Vorstellungsgespräch sagen sollte <br /> Antwort:
Keepalived-Hochverfügbarkeitspaare kommunizieren über VRRP, deshalb beginne ich mit VRRP.
1) VRRP (der vollständige Name lautet Virtual Router Reduancy Protocol) wurde entwickelt, um das Problem des Einzelpunktausfalls beim statischen Routing zu lösen.
2) VRRP verwendet ein Kampagnenprotokoll, um einem VRRP-Router Routing-Aufgaben zuzuweisen.
3) VRRP verwendet IP-Multicast (Standard-Multicast-Adresse (224.0.0.18)), um die Kommunikation zwischen Hochverfügbarkeitspaaren zu erreichen.
4) Während des Betriebs sendet der Masterknoten Pakete und der Standbyknoten empfängt sie. Wenn der Standbyknoten die vom Masterknoten gesendeten Pakete nicht empfangen kann, startet er das Übernahmeprogramm, um die Ressourcen des Masterknotens zu übernehmen. Es kann mehrere Standbyknoten geben, die nach Priorität ausgewählt werden, aber im Allgemeinen gibt es ein Paar beim Betrieb und bei der Wartung des Keepalived-Systems.
5) VRRP verwendet Verschlüsselungsprotokolle zum Verschlüsseln von Daten, doch die Verantwortlichen von Keepalived empfehlen derzeit die Verwendung von Klartext zum Konfigurieren von Authentifizierungstypen und Passwörtern.
Nachdem ich VRRP vorgestellt habe, möchte ich nun das Funktionsprinzip des Keepalived-Dienstes vorstellen.
Keepalived-Hochverfügbarkeitspaare kommunizieren über VRRP miteinander. VRRP bestimmt den Master und den Standby durch einen Auswahlmechanismus. Der Master hat eine höhere Priorität als der Standby. Daher erhält er beim Arbeiten zuerst alle Ressourcen. Der Standby-Knoten befindet sich im Wartezustand. Wenn der Master-Knoten auflegt, übernimmt der Standby-Knoten die Ressourcen des Master-Knotens und ersetzt dann den Master-Knoten, um externe Dienste bereitzustellen.
Zwischen den Keepalived-Dienstpaaren sendet nur der Masterserver weiterhin VRRP-Broadcast-Pakete, um dem Backup-Server mitzuteilen, dass er noch aktiv ist. Zu diesem Zeitpunkt wird der Backup-Server den Masterserver nicht verdrängen. Wenn der Masterserver nicht verfügbar ist, d. h. wenn der Backup-Server die vom Masterserver gesendeten Broadcast-Pakete nicht überwachen kann, startet er verwandte Dienste, um Ressourcen zu übernehmen und so die Geschäftskontinuität sicherzustellen. Die Übernahmegeschwindigkeit kann weniger als eine Sekunde betragen.

Kapitel 3: VRRP-Protokoll
VRRP implementiert die Funktion eines virtuellen Routers durch einen Wahlmechanismus. Alle Protokollnachrichten werden über IP-Multicast-Pakete übertragen. Die Standard-Multicast-Adresse lautet 224.0.0.18

VIP-Voraussetzungen:
1. Die virtuelle öffentliche IP muss real und verfügbar sein
2. Virtuelle öffentliche IP kann nicht wiederholt werden
3. Die Multicast-Adresse muss kommunizierbar sein

Kapitel 4: Keepalived-Installation und -Konfiguration

1. Installieren Sie Keepalived

yum installiere keepalived -y

2. Erläuterung der Konfigurationsdatei

global_defs {  
  router_id lb01 #Legen Sie die Routing-ID fest, jeder Host ist anders} 

vrrp_instance VI_1 { #VRRP-Gruppennamen festlegen, derselbe Gruppenname state MASTER #Rollenstatus festlegen, unterteilt in MASTER BACKUP
    Schnittstelle eth0 #An VIP gebundene Netzwerkkarte virtual_router_id 50 #Virtuelle Router-ID, gleich für dieselbe Gruppe Priorität 150 #Gewicht, je höher das Gewicht, desto höher die Priorität advert_int 1 #Intervall zum Senden der Multicast-Authentifizierung { #Authentifizierung festlegen, das Kennwort ist im Klartext auth_type PASS 
      Auth_Passwort 1111 
    }
    virtual_ipaddress { #Virtuelle IP festlegen. Diese virtuelle IP muss vorhanden und gültig sein und darf nicht verwendet werden.
      10.0.0.3
    }
}

3.lb01-Konfiguration

[root@lb01 ~]# cat /etc/keepalived/keepalived.conf 
global_defs {
  Router-ID lb01
}

vrrp_instance VI_1 {
  Zustand MEISTER
    Schnittstelle eth0
    virtuelle_Router_ID 50
    Priorität 150
    Anzeige_int 1
    Authentifizierung
      Authentizitätstyp PASS
      Auth_Passwort 1111
    }
    virtuelle_IP-Adresse {
      10.0.0.3
    }
}

4.lb02-Konfiguration

[root@lb02 ~]# cat /etc/keepalived/keepalived.conf 
global_defs {
  Router-ID lb02
}

vrrp_instance VI_1 {
  Status BACKUP 
    Schnittstelle eth0
    virtuelle_Router_ID 50
    Priorität 100
    Anzeige_int 1
    Authentifizierung
      Authentizitätstyp PASS
      Auth_Passwort 1111
    }
    virtuelle_IP-Adresse {
      10.0.0.3
    }
}

5. Inbetriebnahme

systemctl start keepalived

6. Führen Sie einen Test durch, indem Sie eine beliebige Maschine herunterfahren und beobachten, ob die VIP zum Master zurückkehrt und ob die BACKUP-VIP verschwindet.

Kapitel 5: Split-Brain-Phänomen

1. Installieren Sie das Paketerfassungstool

yum installiere tcpdump -y 

2.lb02 Paketerfassung und -anzeige

tcpdump -nn -i beliebiger Host 224.0.0.18

3. lb02 Öffnen Sie ein neues Terminal und schalten Sie die Firewall ein

systemctl starte firewalld.service

4.lb02 beobachtet das Paketerfassungsphänomen, um festzustellen, ob auf beiden Seiten VIPs vorhanden sind

5. Release-Regeln hinzufügen

Firewall-Befehl --direct --permanent --add-rule IPv4-Filter INPUT 0 --in-interface eth0 --destination 224.0.0.18 --protocol vrrp -j ACCEPT
Firewall-Befehl --direct --permanent --add-rule IPv4-Filter INPUT 0 --in-interface eth1 --destination 224.0.0.18 --protocol vrrp -j AKZEPTIEREN
systemctl neu laden firewalld

6.lb02 Beobachten Sie das Paketerfassungsphänomen, um festzustellen, ob auf beiden Seiten VIPs vorhanden sind

Kapitel 6: Keepalived-Dual-Master-Experiment
1.lb01 Konfigurationsdatei

[root@lb01 ~]# cat /etc/keepalived/keepalived.conf 
global_defs {
  Router-ID lb01
}

vrrp_instance VI_1 {
  Zustand MEISTER
    Schnittstelle eth0
    virtuelle_Router_ID 50
    Priorität 150
    Anzeige_int 1
    Authentifizierung
      Authentizitätstyp PASS
      Auth_Passwort 1111
    }
    virtuelle_IP-Adresse {
      10.0.0.3
    }
}

vrrp_instance VI_2 {
  Status BACKUP 
    Schnittstelle eth0
    virtuelle_Router_ID 51
    Priorität 100
    Anzeige_int 1
    Authentifizierung
      Authentizitätstyp PASS
      Auth_Passwort 2222 
    }
    virtuelle_IP-Adresse {
      10.0.0.4
    }
}

2.lb02 Konfigurationsdatei

[root@lb02 ~]# cat /etc/keepalived/keepalived.conf 
global_defs {
  Router-ID lb02
}

vrrp_instance VI_1 {
  Status BACKUP 
    Schnittstelle eth0
    virtuelle_Router_ID 50
    Priorität 100
    Anzeige_int 1
    Authentifizierung
      Authentizitätstyp PASS
      Auth_Passwort 1111
    }
    virtuelle_IP-Adresse {
      10.0.0.3
    }
}

vrrp_instance VI_2 {
  Zustand MEISTER 
    Schnittstelle eth0
    virtuelle_Router_ID 51
    Priorität 150
    Anzeige_int 1
    Authentifizierung
      Authentizitätstyp PASS
      Auth_Passwort 2222 
    }
    virtuelle_IP-Adresse {
      10.0.0.4
    }
}

3. Starten Sie Keepalived neu und beobachten Sie das Phänomen

systemctl Neustart keepalived

Kapitel 7: Keepalived kombiniert mit Nginx Reverse Proxy Load Balancing
Nginx-Konfiguration für lb-Server:
Beachten! Die Nginx-Konfiguration der beiden lb-Server ist genau gleich

1. Sichern Sie die ursprüngliche Konfiguration

mkdir /sicherung
cd /etc/nginx/conf.d
mv * /Sicherung 

2. Schreiben Sie die Nginx-Konfigurationsdatei

[root@lb01 /etc/nginx/conf.d]# cat proxy.conf 
Upstream-Webpools {
  Server 172.16.1.7;
  Server 172.16.1.8;
}

Server {
  hören Sie 80;
  Servername (www|bbs).mysun.com;
  Standort / {
   Proxy-Passwort http://Webpools;
   Proxy-Parameter einschließen;
  }
}

3. Testen und starten Sie nginx neu

nginx -t
systemctl startet nginx neu 

Keepalived-Konfiguration des lb-Servers:

1.lb01 Keepalived-Konfiguration

[root@lb01 ~]# cat /etc/keepalived/keepalived.conf 
global_defs {
  Router-ID lb01
}

vrrp_instance VI_1 {
  Zustand MEISTER
    Schnittstelle eth0
    virtuelle_Router_ID 50
    Priorität 150
    Anzeige_int 1
    Authentifizierung
      Authentizitätstyp PASS
      Auth_Passwort 1111
    }
    virtuelle_IP-Adresse {
      10.0.0.3
    }
}

2.lb02 Keepalived-Konfiguration

[root@lb02 ~]# cat /etc/keepalived/keepalived.conf 
global_defs {
  Router-ID lb02
}

vrrp_instance VI_1 {
  Status BACKUP 
    Schnittstelle eth0
    virtuelle_Router_ID 50
    Priorität 100
    Anzeige_int 1
    Authentifizierung
      Authentizitätstyp PASS
      Auth_Passwort 1111
    }
    virtuelle_IP-Adresse {
      10.0.0.3
    }
}

Webserver-Konfiguration:

Beachten! Die beiden Webserver haben die gleiche Konfiguration

1. Nginx-Konfiguration

[root@web01 ~]# cat /etc/nginx/conf.d/www.conf 
Server {
 hören Sie 80;
 Servername www.mysun.com;
 Standort / {
   Wurzel /Code;
   inhaltsverzeichnis www.html;
 }
}

2. Testdateien schreiben

echo "$(Hostname)" >/code/index.html 

Kapitel 8: Split-Brain-Präventionsskript

1. Problemphänomen:
1.nginx ist down, aber keep ist noch aktiv
2. Beide Seiten haben VIP

2. Ideen:
Lösen Sie das Problem, dass Nginx hängt:
1. Schreiben Sie ein Skript

• Starten Sie nginx
• Wenn der Start zweimal fehlschlägt, stoppen Sie Ihren Keepalived

2.keepalived ruft dieses Skript regelmäßig auf

3. Umsetzung:

1. So implementieren Sie den Befehl

systemctl starte nginx

2. Überprüfen Sie den Nginx-Prozess

[root@lb01 ~]# ps -ef|grep nginx|grep -v "grep"
root 1210 1 0 11:21 ? 00:00:00 nginx: Masterprozess /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx 1211 1210 0 11:21 ? 00:00:00 nginx: Arbeitsprozess
[root@lb01 ~]# ps -ef|grep nginx|grep -v "grep"|wc -l
2
[root@lb01 ~]# ps -ef|grep nginx|grep -v "grep"|wc -l
0

Skriptinhalt:

[root@lb01 ~]# cat check_web.sh 
!/bin/bash

nginx_status=$(ps -C nginx --no-header|wc -l)

wenn [[ ${nginx_status} == 0 ]]
Dann
  systemctl start nginx &> /dev/null 
  Schlaf 1
  nginx_status=$(ps -C nginx --no-header|wc -l)
  wenn [[ ${nginx_status} == 0 ]]
  Dann
    systemctl stop keepalived 
  fi
fi

Keepalived ruft das Skript auf:

[root@lb01 ~]# cat /etc/keepalived/keepalived.conf 
global_defs {
  Router-ID lb01
}

vrrp_script check_web {
  Skript "/server/scripts/check_web.sh"
  Intervall 5
  Gewicht 50
}

vrrp_instance VI_1 {
  Zustand MEISTER
    Schnittstelle eth0
    virtuelle_Router_ID 50
    Priorität 150
    Anzeige_int 1
    Authentifizierung
      Authentizitätstyp PASS
      Auth_Passwort 1111
    }
    virtuelle_IP-Adresse {
      10.0.0.3
    }

  Titel_Skript {
    check_web
  }

}

4. Das zweite Problem: Split-Brain-Problem <br /> Beide Seiten haben VIPs

Phänomen:
VIP auf beiden Seiten
Nginx ist auf beiden Seiten lebendig

Der Nginx des anderen MASTER ist noch am Leben

curl -I -s -w "%{http_code}\n" -o /dev/null 10.0.0.5

Aber ich habe wieder VIP

ip a |grep "10.0.0.3"|wc -l

Ich werde mich umbringen

systemctl stoppt nginx 
systemctl stop keepalived 

Skriptinhalt:

[root@lb02 /server/scripts]# cat check_vip.sh 

#!/bin/bash

master_status=$(curl -I -s -w "%{http_code}\n" -o /dev/null 10.0.0.5)

mein_vip=$(ip a |grep "10.0.0.3"|wc -l)

wenn [ ${master_status} == 200 -a ${my_vip} == 1 ]
Dann
  systemctl stoppt nginx 
  systemctl stop keepalived 
fi

Keepalived-Konfiguration:

[root@lb02 ~]# cat /etc/keepalived/keepalived.conf 
global_defs {
  Router-ID lb02
}

vrrp_script check_web {
  Skript "/server/scripts/check_web.sh"
  Intervall 5
  Gewicht 50
}

vrrp_script check_vip {
  Skript "/server/scripts/check_vip.sh"
  Intervall 5
  Gewicht 50
}

vrrp_instance VI_1 {
  Status BACKUP 
    Schnittstelle eth0
    virtuelle_Router_ID 50
    Priorität 100
    Anzeige_int 1
    Authentifizierung
      Authentizitätstyp PASS
      Auth_Passwort 1111
    }
    virtuelle_IP-Adresse {
      10.0.0.3
    }
  Titel_Skript {
    check_web
    check_vip
  }
}

Dies ist das Ende dieses Artikels über den Beispielcode zur Implementierung des Nginx-Lastausgleichs und der Hochverfügbarkeit mit Keepalived. Weitere verwandte Inhalte zum Nginx-Lastausgleich und zur Hochverfügbarkeit mit Keepalived finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!