Technologieaustausch

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Die Hochverfügbarkeitsarchitektur im LVS-Cluster dient nur der Hochverfügbarkeit des Schedulers.

Implementieren Sie die Haupt- und Backup-Planer basierend auf vrrp

Hochverfügbare HA-Architektur

Hauptplaner und Backup-Planer (es können mehrere Backup-Planer vorhanden sein)

Wenn der Scheduler normal arbeitet, ist das Gerät vollständig redundant (Standby). Es beteiligt sich nicht am Betrieb des Clusters. Erst wenn der Hauptplaner ausfällt, übernimmt der Backup die Arbeit des Hauptplaners. Nachdem der Hauptplaner seine Funktion wiederhergestellt hat, fungiert der Master weiterhin als Eingang zum Cluster , und das Backup befindet sich weiterhin in einem redundanten Zustand (abhängig von der Priorität).

Keepalive basiert auf dem VRRP-Protokoll zur Implementierung der LVS-Hochverfügbarkeitslösung.

1. Multicast-Adresse:

224.0.0.18 kommuniziert basierend auf der Multicast-Adresse. Die primären und sekundären Geräte senden Nachrichten, um festzustellen, ob die andere Partei aktiv ist.

2. Bestimmen Sie die Positionen der Primär- und Sekundärpositionen basierend auf der Priorität.

3. Failover: Wenn die primäre Maschine hängt, arbeitet die Backup-Maschine weiter. Wenn die Master-Maschine wiederhergestellt wird, wartet die Backup-Maschine weiter.

4. Das Umschalten zwischen primär und sekundär ist das Umschalten der VIP-Adresse.

Keepalive erscheint speziell für LVS, ist jedoch nicht exklusiv für LVS.

Kernmodul: Das Kernmodul von Keepalive, verantwortlich für den Start und die Wartung des Hauptprozesses sowie das Laden globaler Konfigurationsdateien

VRRP-Modul: Das Modul, das das VRRP-Protokoll implementiert, das das Hauptfunktionsmodul ist

Prüfmodul: Verantwortlich für die Gesundheitsprüfung und kann auch den Status des realen Servers im Hintergrund überprüfen.

Basierend auf dem DR-Modus-Experiment im vorherigen Kapitel fügen wir einige Konfigurationen hinzu. Dieses Mal werden zwei Scheduler verwendet, ein primärer und ein Backup.

Installieren Sie zunächst Keepalive auf dem Scheduler

yum -y install keepalived

Nachdem die Installation abgeschlossen ist

Lassen Sie uns die Datei keepalived.conf ändern

[root@test1 ~]# vim /etc/keepalived/keepalived.conf
   notification_email_from [email protected]
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_01
   vrrp_skip_check_adv_addr
   vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
   vrrp_iptables
}
 
vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 120
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.124.100
    }
}
 
virtual_server 192.168.124.100 80 {
    delay_loop 6
    lb_algo rr
    lb_kind DR
    persistence_timeout 50
    protocol TCP
 
    real_server 192.168.124.40 80 {
        weight 1
            TCP_CHECK {
            connect_port 80
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
 
    real_server 192.168.124.50 80 {
                                                                     9,1           36%

Kopieren Sie die Konfigurationsdatei im ersten Scheduler in den zweiten Scheduler

scp root@192.168.233.10:/etc/keepallved/keepallved.conf
/etc/keepallved

Ändern Sie dann die Konfiguration

Priorität der Primär- und Sekundärstufe

Fügen Sie eine iptables-Option hinzu

Auf diese Weise wird der Zugriff auf Keepalive-Regeln in der ipetables-Regeltabelle nicht gestoppt.

[root@localhost ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.124.100:80 rr persistent 50
  -> 192.168.124.40:80            Route   1      0          0
  -> 192.168.124.50:80            Route   1      0          0

Hör zu

Dann alles neu starten

Schauen Sie sich die Kundenergebnisse an

Lassen Sie uns zuerst den Hauptplaner herunterfahren

stsemctl stop keepalived.servers

Der Backup-Scheduler übernimmt die Arbeit des Masters und arbeitet weiter.

Dies ist die VIP-Adresse, die in den vorbereiteten Scheduler hochgeladen wurde. Der Client greift darauf zu.

Kann immer noch zugreifen

---

Zusammenfassen

Keepalived besteht hauptsächlich aus drei Modulen: Core (Kernmodul, verantwortlich für den Start des Hauptprozesses, die Wartung sowie das Laden und Analysieren globaler Konfigurationsdateien), Check (Gesundheitsprüfungsmodul) und VRRP (Implementierung des VRRP-Protokolls).

Das Funktionsprinzip von Keepalived basiert auf dem VRRP-Protokoll. Mehrere Server, die die gleichen Funktionen bereitstellen, werden zu einer Servergruppe zusammengefasst, die über einen Master und mehrere Backups verfügt. Auf dem Master gibt es einen VIP, der Dienste für die Außenwelt bereitstellt (die Standardroute für andere Computer im LAN, in dem sich der Server befindet, ist dieser VIP). Der Master sendet Multicast, wenn er das VRRP-Paket nicht empfangen kann wird denken, dass der Master ausgefallen ist, und dann entsprechend der Priorität des VRRP-Levels ein Backup auswählen, um der neue Master zu werden.

Bei der Konfiguration von LVS + Keepalived müssen Sie normalerweise zugehörige Software (z. B. ipvsadm, keepalived) auf den Master- und Backup-Knoten installieren und die Datei keepalived.conf konfigurieren. In der Konfigurationsdatei des Masterknotens müssen Sie beispielsweise den Status (State) als Master, Netzwerkschnittstelle (Interface), virtuelle Routen-ID (virtual_router_id), Priorität (priority), Ankündigungsintervall (advert_int) und Authentifizierungsinformationen angeben (Authentifizierung) Und virtuelle IP-Adresse (virtual_ipaddress) usw.; die Konfiguration des Backup-Knotens ist ähnlich, aber der Status ist Backup und die Priorität ist normalerweise niedriger als die des Masters.

Starten Sie nach Abschluss der Konfiguration den Keepalived-Dienst neu, um einen Lastausgleich mit hoher Verfügbarkeit zu erreichen. Wenn der Master-Knoten ausfällt, wechselt VIP automatisch zum Backup-Knoten, um den normalen Zugriff auf den Dienst sicherzustellen. Nach der Wiederherstellung des Master-Knotens fungiert dieser wieder als Hauptlastknoten. Darüber hinaus kann auch der reale Server (rs) entsprechend konfiguriert werden. Wenn beispielsweise das DR-Modell für die Kommunikation verwendet wird, muss lo als VIP auf der Netzwerkkarte von rs konfiguriert werden.

Auf diese Weise kann die Kombination aus LVS und Keepalived die folgenden Ziele erreichen: Der Client greift über VIP auf den Dienst zu und die Anforderung wird gemäß den Konfigurationsregeln verteilt. Wenn der Lastausgleichsknoten des Masters ausfällt, kann er automatisch zum Backup wechseln Knoten, um sicherzustellen, dass der Dienst normal ist; wenn ein bestimmter Knoten ausfällt, kann der Knoten automatisch entfernt und nach der Wiederherstellung wieder dem Cluster hinzugefügt werden.

In tatsächlichen Anwendungen müssen relevante Dinge beachtet werden, z. B. muss die von virtual_ipaddress in der Keepalived-Konfigurationsdatei konfigurierte IP-Adresse im selben Netzwerksegment liegen, desto größer ist die Wahrscheinlichkeit, dass der Knoten zum Master wird Knoten; je kleiner der advert_int-Wert, desto höher ist die Wahrscheinlichkeit, dass der Knoten VRRP-Nachrichten sendet. Gleichzeitig müssen auch Faktoren wie Netzwerkumgebung und Serverleistung berücksichtigt werden, um die Stabilität und den effizienten Betrieb des gesamten Systems sicherzustellen.