Installation und einrichtung
Beschreibung:
Hier ist ein Tutorial, um zwei Loadbalancer mit einer Floating-IP erreichbar zu machen. Damit nicht nur die Backendserver-Verbindung hochverfügbar ist, sondern auch die Verbindungs-IP (Floating-IP) mithilfe von zwei Loadbalancern anstelle von einem. Zusätzlich überprüfen die Loadbalancer die OpenVPN-Dienste und HTTPS-Dienste.
Es kann natürlich jeder anderer Dienst in betracht gezogen werden
Hinweis:
Bei einem N2N Tunnel funktioniert der LVS nicht richtig, da dann haproxy nehmen. Aber als reiner LB für die floating IPS reicht es.
Vorrausetzungen:
5 x Public IP Adresses, 2 x LB , 2 x RVS and 1 x Floating ip
2 x Machines as LB01 and LB02, with Linux (eg Debian) and ssh access
2 x Machines as RVS01 and RVS02 for example
Ein internes Netz zwischen den Loadbalancern für die Heartbeat funktion. (Hier wird ein broadcast gesendet, der über Öffentliche Netzte nicht funktioniert)
In unserer Testumgebung haben wir diese IPS
Floating IP : 49.12.154.74
LB01 : 49.12.154.77
LB02 : 49.12.154.78
RVS01 : 49.12.154.75
RVS02 : 49.12.154.76
Installation:
Installiere die Software-Anforderungen durch die folgenden Pakete und Konfigurationen auf LB01 und LB02. Es ist notwendig, dass die Netzwerk-IP und SSH korrekt konfiguriert sind für die nächsten Schritte...
apt update
apt dist-upgrade
apt install curl wget
apt install keepalived
apt install python3 python-is-python3Das Routing muss in der sysctl auch aktiviert sein.
nano /etc/sysctl.confInhalt am Ende anfügen
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1nun anwenden
sysctl -pAnforderungen an die RVS-Server für HA mit Loadbalancer und Floating-IP.
Wir müssen nur eine iptables-Regel hinzufügen, weil die RVS-Server zur Floating-IP umgeleitet werden müssen.
Befehl zur direkten Ausführung. Siehe Punkt 6, um dies automatisch beim Start des Servers durchzuführen.
iptables -t nat -A PREROUTING -d 49.12.154.74 -j REDIRECTKeepalived-Konfiguration, der lustige Teil.
Wir beginnen mit der Erklärung der Konfiguration von Server 1, die Konfiguration von
Server 2 ist fast identisch mit der von Server 1, mit nur wenigen Änderungen.
Wir starten mit Server 1.
Hinweis: Hinweis: In version 3 von Keepalived wurde die Autehntifizierung.
Der Abschnitt .
...
authentication { #Validierungsinformationen einstellen, zwei Knoten müssen konsistent sein
auth_type PASS #Authentifizierungstypen einrichten, hauptsächlich PASS und AH
auth_pass 8nzlTBSoSrpJP0i77TgL! #Das Authentifizierungspasswort einstellen, zwei Knoten müssen unter einem vrrp_instance dasselbe Passwort verwenden
}
....
kann entfernt werden.
Denn dieser wird ignoriert.
Das bedeutet das für die Heartbeat Verbindung kein Öffentliches Netz mehr gewählt werden sollte, sondern nur Private / dedizierte Verbindungen.
Der Abschnitt .
...
authentication { #Validierungsinformationen einstellen, zwei Knoten müssen konsistent sein
auth_type PASS #Authentifizierungstypen einrichten, hauptsächlich PASS und AH
auth_pass 8nzlTBSoSrpJP0i77TgL! #Das Authentifizierungspasswort einstellen, zwei Knoten müssen unter einem vrrp_instance dasselbe Passwort verwenden
}
....
kann entfernt werden.
Denn dieser wird ignoriert.
Das bedeutet das für die Heartbeat Verbindung kein Öffentliches Netz mehr gewählt werden sollte, sondern nur Private / dedizierte Verbindungen.
Hinweis: Keepalived Heartbeat ist Standard Multicast, sollte die Verbindung zwischen den LBs kein Multicast unterstützen
dann den Abschnitt weiter unten Unicast anschauen. Ich würde warscheinlich generell Unicast verwenden um Fehler vorzubeugen.
dann den Abschnitt weiter unten Unicast anschauen. Ich würde warscheinlich generell Unicast verwenden um Fehler vorzubeugen.
Erstellen Sie eine neue Datei /etc/keepalived/keepalived.conf.
Die Datei hat verschiedene Abschnitte:
global_defs{}: Dies enthält Benachrichtigungen und Identifikationen der Loadbalancer.
vrrp_instance VI_1{}: Enthält die Verbindungsauthentifizierung und die Zuweisung der virtuellen IP (Floating IP).
Hier können wir auch Skripte definieren, die bei Statusänderungen von Master zu Backup oder von Backup zu Master ausgeführt werden.
Zum Beispiel, um eine andere Floating-IP von Hetzner über ein sh-Skript zuzuweisen.
virtual_server{}: Hier wird die virtuelle Server-IP mit Port und Protokoll (UDP, TCP) definiert.
In diesem Abschnitt ist der letzte Abschnittstyp eingebettet.
Die real_servers, die in Punkt d aufgelistet sind.
real_server{}: Hier werden die RVS-Server mit Service-Checks definiert.
Die Global Config
#=========Global Config==============#
#Email notification
global_defs {
notification_email {
root@localhost //Accept email address
}
#Mailserver Settings
notification_email_from keepalived@localhost //Mailing address
smtp_server 127.0.0.1 //Send mail server IP
smtp_connect_timeout 30 //Mail connection timeout
#Rounting settings #here master on the seconday lb02 it must called be slave
router_id master #An identity that identifies the keepalived server running (type an string)
}
#======= End Globals ==========#vrrp_instance section with virtual ip
Die Authentication wurfde in Version 3 entfernt. Da das hauptmerkmal darauf gelegt wurde, das die interne verbindung für das Heartbeat sicher ist. Sprich firewall regeln dediziertes VPn etc.
#======= HA for Floating IP ===#
vrrp_instance VI_1 { #VRRP instance definition section
state MASTER #Gibt an, dass der Knoten der Hauptknoten ist (Großbuchstaben) und der Standby-Knoten BACKUP ist
interface ens18 #Netzwerkschnittstelle, über die die Interne kommunikation laufen soll, heartbeat. Muss ein Privates netzwerk sein, da hier einj Broadcast gesendet wird.
virtual_router_id 51 #VRRP Gruppenname, zwei Knoten müssen gleich eingestellt werden, um anzuzeigen, dass jeder Knoten derselben VRRP-Gruppe angehört. Muss eine ganze Zahl sein
priority 100 #Priorität des Hauptknotens (1-254), Standard 100, beachten Sie, dass die Priorität des sekundären Knotens niedriger sein muss als die des Hauptknotens
advert_int 1 #Legt das Zeitintervall zwischen Synchronisationsprüfungen zwischen zwei Knoten fest, die beiden Knoten müssen konsistent sein. Wert in Sekunden
authentication { #Validierungsinformationen einstellen, zwei Knoten müssen konsistent sein
auth_type PASS #Authentifizierungstypen einrichten, hauptsächlich PASS und AH
auth_pass 8nzlTBSoSrpJP0i77TgL! #Das Authentifizierungspasswort einstellen, zwei Knoten müssen unter einem vrrp_instance dasselbe Passwort verwenden
}
virtual_ipaddress { #Virtuelle IP (Floating IPs) angeben, beide Knoten müssen gleich eingestellt sein, es kann mehr als eine geben, eine pro Zeile. Als Parameter dev das Netzwerkgerät, dem die IP zusätzlich zugewiesen wurde
49.12.154.74 dev ens18
}
#Benachrichtigungsbereich, wann welches Skript im angegebenen Zustand ausgeführt wird (z.B. Skript zur Zuweisung von Floating IP per Skript bei Hetzner oder anderen)
#Nur notify wird bei jedem Zustand aufgerufen.
#Aber die folgenden Parameter werden übergeben
#notify /pfad_zum_skript/skript_allezustände.sh
#Im Skript allezustände gibt es 3 Parameter, die überprüft werden können
#Type enthält den Wert "GROUP" oder "INSTANCE"
#TYPE = $1
#Name enthält den Namen der Gruppe oder Instanz
#NAME = $2
#State enthält den Zustand. Diese sind "MASTER" "BACKUP" "FAULT" mit * kann man einen unbekannten Zustand abfangen
#STATE = $3
#Beispiel skript_allezustände.sh weiter unten im nächsten Codekasten.
Da wir ein script für alle zustände haben, wenn wir das hetzner script verwenden möchten dann müssen wir alle scripte unten austauschen,
#ansonsten selbt andere scripte definieren
#Diese rufen die Skripte im gegebenen Zustand auf, daher ist keine Überprüfung im sh-Skript erforderlich
#notify_master /pfad_zum_skript/skript_hauptknoten.sh
# (oder notify_master “ /pfad_zum_skript/skript_hauptknoten.sh)
#notify_backup /pfad_zum_skript/skript_backup.sh
# (oder notify_backup “ /pfad_zum_skript/skript_backup.sh)
#notify_fault /pfad_zum_skript/skript_fehler.sh
# (oder notify_fault “ /pfad_zum_skript/skript_fehler.sh)
}
#=== End Ha for Floating IP =========================#Beispiel skript_allezustände.sh mit Hetzner Floating-IP-Zuweisungsbeispiel. In unserer Textumgebung verwenden wir keine Hetzner Floating-IP, aber als Beispiel für andere, die es nutzen werden. Dies ist ein Beispiel-Skript für lb01, daher wird die Hetzner Server-ID 5605626 verwendet.
das script wertet über Parameter $3 also state aus, was Phase ist, master, backup ,unknown
#!/bin/bash
#lb01 ID : 5605626
#lb02 ID : 5605974
#floatingipv4 id =: 245713
#floatingipv6 id =: 246612
TYPE=$1
NAME=$2
STATE=$3
case $STATE in
"MASTER") curl -X POST -H "Content-Type: application/json" -H "Authorization: Bearer <hetzner-api-key>" -d '{"server": 5605626}' 'https://api.hetzner.cloud/v1/floating_ips/245713/actions/assign'
curl -X POST -H "Content-Type: application/json" -H "Authorization: Bearer <hetzner-api-key>" -d '{"server": 5605626}' 'https://api.hetzner.cloud/v1/floating_ips/246612/actions/assign'
echo "Master"
exit 0
;;
"BACKUP") echo "backup"
exit 0
;;
"FAULT") echo "fault"
exit 0
;;
*) echo "unknown state"
exit 1
;;
esacZurück in der Konfigurationsdatei nach dem Exkurs zum allstateshscript.
Der Virtualserver-Bereich ist in zwei Abschnitte unterteilt. Der Virtualserver selbst und die Realservers. In den Virtualserver-Einstellungen legen wir den Load-Balancer-Modus, die virtuelle IP und den Port fest, auf den der Server hört.
Im Realservers-Abschnitt befinden sich die Checks und die Serveradresse. So haben wir eine Liste von Realservers. Dies sind die Server, die im Failover ausbalanciert werden...
Die Checks können auch benutzerdefinierte Skripte sein. Für OpenVPN verwenden wir ein Python3-Skript von Icinga2, das die Verfügbarkeit von OpenVPN überprüft. Dieses Skript gibt 0 für Erfolg und 1 für Fehlschlag zurück.
Ideal für unseren OpenVPN-Service-Check. Das openvpn_check-Skript ist hier als Anhang: check_vpn.py.
Im check_vpn-Skript müssen Sie den Rückgabecode bei "crit" von 2 auf 1 ändern.
Sie müssen das Skript ausführbar machen: chmod +x check_vpn.py.
#==========Virtual Server - Definition which floating ip and Ports
#========== Virtual Server for OpenVPN UDP 1194============#
virtual_server 49.12.154.74 1194 { #Virtueller IP-Dienst
delay_loop 6 #Intervall für die Überprüfung des tatsächlichen Servers festlegen
lvs_sched fo #LVS-Zeitplanalgorithmus angeben (fo, wechselt bei Gewicht, das höchste gewinnt)
#if Dr Mode dont forget to set iptables nat to the virtual ip on the realservers eg. on 49.12.154.75
#iptables -t nat -A PREROUTING -d 49.12.154.74 -j REDIRECT
#its virtual ip : 49.12.154.74
#LVS direct routing
lvs_method DR #Specify LVS mode, mainly NAT, TUN, DR
protocol UDP #Forwarding protocol is UDP
#Real-Server - here Specify nodes 1-n. Can have an other port, when whished
#================= Reaslserver UDP 1194 VPN02
real_server 49.12.154.75 1194 { #Backend Real Server Configuration for VPN01
weight 10 #Set the weight value of the server node. The highest is preferred connection, if available.
#this is an Standard TCP check, but we will check UDP VPN we need an own check script, that return 0 or 1. 0 = OK, 1 = fail
#TCP_CHECK { #Real Server State Detection Settings section, in seconds
# connect_timeout 3 #Connection timeout
# nb_get_retry 3 #retry count
# delay_before_retry 3 #retry interval
# connect_port 80 #Connection Port
#}
#This done with, misc check
MISC_CHECK {
#misc_path /path/to/check_whatever.sh or py. Hint when parameters given it must be quoted
#misc_path "/root/check_vpn.py -p 1194 --tls-auth /root/ta.key 49.12.154.76" this is when tls key is needed
misc_path "/root/check_vpn.py -p 1194 49.12.154.76"
}
}
#=================== Realserver UDP 1194 LB02 ==============#
real_server 49.12.154.76 1194 { #Backend Real Server Configuration for VPN02
weight 9 #Set the weight value of the server node. The highest is preferred connection, if available.
#this is an Standard TCP check, but we will check UDP VPN we need an own check script, that return 0 or 1. 0 = OK, 1 = fail
#TCP_CHECK { #Real Server State Detection Settings section, in seconds
# connect_timeout 3 #Connection timeout
# nb_get_retry 3 #retry count
# delay_before_retry 3 #retry interval
# connect_port 80 #Connection Port
#}
#This done with, misc check
MISC_CHECK {
#misc_path /path/to/check_whatever.sh or py. Hint when parameters given it must be quoted
#misc_path "/root/check_vpn.py -p 1194 --tls-auth /root/ta.key 49.12.154.76" this is when tls key is needed
misc_path "/root/check_vpn.py -p 1194 49.12.154.76"
}
}
#============= End Realsserver ======================#
}
#=== End Virtual Server UDP 1194===================#Der nächste Virtual Server HTTPS 443, hier ist auch vpn auf 443 das sogenannte split tunneling, wird per webrowser angefragt gehts auf einen webserver, aber wir wollen hier den VPN dienst prüfen
#===Virtual Server TCP VPN 443
virtual_server 49.12.154.74 443 { #Virtual IP Service
delay_loop 6 #Set interval to check actual server
lvs_sched fo #Specify LVS Scheduling Algorithm (fo, switched at weight, the heighest wins)
#f Dr Mode dont forget to set iptables nat to the virtual ip on the realservers eg. on 49.12.154.75
#iptables -t nat -A PREROUTING -d 192.168.35.127 -j REDIRECT
#its virtual ip : 49.12.154.74
lvs_method DR #Specify LVS mode, mainly NAT, TUN, DR
# persistence_timeout 50 #Session Hold Time
protocol TCP #Forwarding protocol is TCP
#Real-Server - here Specify nodes 1-n. Can have an other port, when whished
#================= Reaslserver TCP 443 VPN02
real_server 49.12.154.75 443 { #Backend Real Server Configuration for VPN01
weight 10 #Set the weight value of the server node. The highest is preferred connection, if available.
MISC_CHECK {
#misc_path /path/to/check_whatever.sh or py. Hint when parameters given it must be quoted
#misc_path "/root/check_vpn.py -p 443 -t --tls-auth /root/ta.key 49.12.154.75" this is when tls key is needed
misc_path "/root/check_vpn.py -p 443 -t 49.12.154.75"
}
}
#=================== Realserver TCP 443 LB02 ==============#
real_server 49.12.154.76 443 { #Backend Real Server Configuration for VPN02
weight 9 #Set the weight value of the server node. The highest is preferred connection, if available.
MISC_CHECK {
#misc_path /path/to/check_whatever.sh or py. Hint when parameters given it must be quoted
#misc_path "/root/check_vpn.py -p 443 -t --tls-auth /root/ta.key 49.12.154.76" this is when tls key is needed
misc_path "/root/check_vpn.py -p 443 -t 49.12.154.76"
}
}
#============ End Real Server =================#
}
#================ End Virtual Server TCP 443Möchte man einen TCP check benutzen sähe das ganze so aus, hier enhmen wir https 10443 kann aber auch 443 sein für euer Scenario.
#===Virtual Server TCP 10443
virtual_server 49.12.154.74 10443 { #Virtual IP Service
delay_loop 6 #Set interval to check actual server
lvs_sched fo #Specify LVS Scheduling Algorithm (fo, switched at weight, the heighest wins)
#f Dr Mode dont forget to set iptables nat to the virtual ip on the realservers eg. on 49.12.154.75
#iptables -t nat -A PREROUTING -d 192.168.35.127 -j REDIRECT
#its virtual ip : 49.12.154.74
lvs_method DR #Specify LVS mode, mainly NAT, TUN, DR
# persistence_timeout 50 #Session Hold Time
protocol TCP #Forwarding protocol is TCP
#Real-Server - here Specify nodes 1-n. Can have an other port, when whished
#================= Reaslserver TCP 10443 VPN02
real_server 49.12.154.75 10443 { #Backend Real Server Configuration for VPN01
weight 10 #Set the weight value of the server node. The highest is preferred connection, if available.
TCP_CHECK { #Real Server State Detection Settings section, in seconds
connect_timeout 3 #Connection timeout
nb_get_retry 3 #retry count
delay_before_retry 3 #retry interval
connect_port 10443 #Connection Port
}
}
#=================== Realserver TCP 10443 LB02 ==============#
real_server 49.12.154.76 10443 { #Backend Real Server Configuration for VPN02
weight 9 #Set the weight value of the server node. The highest is preferred connection, if available.
TCP_CHECK { #Real Server State Detection Settings section, in seconds
connect_timeout 3 #Connection timeout
nb_get_retry 3 #retry count
delay_before_retry 3 #retry interval
connect_port 10443 #Connection Port
}
}
#============ End Real Server =================#
}
#================ End Virtual Server TCP 10443
#========== End Virtual Server - Definition which floating ip and Ports ==================#
#========== End config file =================#Somit hätten wir die Scenarien einmal mit benutzerdefinierten check und TCP check abgedeckt.
Jetzt ist die Konfigurationsdatei für lb01 fertig.
Nun Server 2
Wir können diese Konfigurationsdatei kopieren und müssen nur wenige Dinge ändern.
Globaler Abschnitt.
Hier ändern wir die id auf backup
#=========Global Config==============#
....
#Rounting settings #here master on the seconday lb02 it must called be slave
router_id backup #An identity that identifies the keepalived server running (type an string)
}
#======= End Globals ==========#Nun die HA vrrp_instance section
Hier muss der state auf BACKUP geändert werden.
Die Priority von 100 auf 99.
Sollte die Netzwerkkarte eine andere sein, diese natürlich auch anpassen
#======= HA for Floating IP ===#
vrrp_instance VI_1 { #VRRP instance definition section
state BACKUP #Specify that the node is the primary node (uppercase) and the standby node is BACKUP
interface ens18 #Netzwerkschnittstelle, über die die Interne kommunikation laufen soll, heartbeat. Muss ein Privates netzwerk sein, da hier einj Broadcast gesendet wird.
virtual_router_id 51 #VRRP group name, two nodes need to be set the same to indicate that each node belongs to the same VRRP group. Must be an integer
priority 99 #Priority of the primary node (1-254), default 100, note that the secondary node priority needs to be lower than the primary node
advert_int 1 #Set the time interval between synchronization checks between two nodes, the two nodes need to be consistent. Value in seconds
authentication { #Set validation information, two nodes need to be consistent
auth_type PASS #Set up authentication types, mainly PASS and AH
auth_pass 8nzlTBSoSrpJP0i77TgL! #Set the authentication password, two nodes must use the same secret under a vrrp_instance
}
virtual_ipaddress { #Specify virtual IP (floating IPs), two nodes need to be set the same, can have more than one, one per line. as paremeter dev the network device were the ip additionally assigned
49.12.154.74 dev ens18 #it could be an other interface name on lb02
}
....
#=== End Ha for Floating IP =========================#Fertig mit der Konfiguration.
Kopieren Sie die Konfigurationsdateienund starten der Dienste
nach /etc/keepalived und die check_vpn.py nach /root.
Hier sind die kompletten Konfigurationsdateien:
lb01.conf
lb02.conf
check_vpn.py.
Dann auf den Loadbalancern den keepalived service starten
service keepalived restartNun noch auf den Servern die route zur floating ip legen
/usr/sbin/iptables -t nat -A PREROUTING -d 49.12.154.74 -j REDIRECTDieses kann man auch in die interfaces als post-up Befehl integrieren.
Beispiel:
auto enp6s18
iface enp6s18 inet static
address 192.168.178.138
netmask 255.255.255.0
gateway 192.168.178.1
dns-nameservers 8.8.8.8 8.8.4.4
post-up /usr/sbin/iptables -t nat -A PREROUTING -d 49.12.154.74 -j REDIRECTTesten Sie die Konfiguration.
Wenn der Service gestartet ist, können wir den Status damit anzeigen. Geben Sie auf beiden Loadbalancern ein:
Wir können auch sehen, welchen Status die Überprüfungen hatten.
Befehl:
service keepalived statusAusgabe:
Hier sehen wir das der Dienst HTTPS 10443 nicht mehr auf der 76 verfügbar ist und schwenkt zu 75.
Hier ist ein Server ausgefallen, das ist kein Schwenkt des Loadbalancers
service keepalived status
Output from lb01
root@lb01:~# service keepalived status
● keepalived.service - Keepalive Daemon (LVS and VRRP)
Loaded: loaded (/lib/systemd/system/keepalived.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2022-03-16 11:29:36 CET; 21s ago
Main PID: 2900 (keepalived)
Tasks: 3 (limit: 2340)
Memory: 2.0M
CPU: 634ms
CGroup: /system.slice/keepalived.service
├─2900 /usr/sbin/keepalived --dont-fork
├─2902 /usr/sbin/keepalived --dont-fork
└─2903 /usr/sbin/keepalived --dont-fork
Mär 16 11:29:40 lb01 Keepalived_healthcheckers[2902]: TCP_CHECK on service [49.12.154.76]:tcp:10443 failed.
Mär 16 11:29:40 lb01 Keepalived_healthcheckers[2902]: Removing service [49.12.154.76]:tcp:10443 to VS [49.12.154.74]:tcp:10443
Mär 16 11:29:40 lb01 Keepalived_vrrp[2903]: (VI_1) received lower priority (99) advert from 49.12.154.78 - discarding
Mär 16 11:29:40 lb01 Keepalived_vrrp[2903]: (VI_1) Entering MASTER STATE
Mär 16 11:29:41 lb01 Keepalived_healthcheckers[2902]: TCP connection to [49.12.154.75]:tcp:10443 success.
Mär 16 11:29:42 lb01 Keepalived_healthcheckers[2902]: TCP connection to [49.12.154.75]:tcp:443 success.
Mär 16 11:29:42 lb01 Keepalived_healthcheckers[2902]: Misc check for [[49.12.154.76]:udp:1194 VS [49.12.154.74]:udp:1194] by [/root/check_vpn.py] failed with retry disabled (exited with status 1).
Mär 16 11:29:42 lb01 Keepalived_healthcheckers[2902]: Removing service [49.12.154.76]:udp:1194 to VS [49.12.154.74]:udp:1194
Mär 16 11:29:42 lb01 Keepalived_healthcheckers[2902]: TCP_CHECK on service [49.12.154.76]:tcp:443 failed.
Mär 16 11:29:42 lb01 Keepalived_healthcheckers[2902]: Removing service [49.12.154.76]:tcp:443 to VS [49.12.154.74]:tcp:443
In this lines wee see that the RVS tcp check 76 is not available on 10443 and is removed
Mär 16 11:29:40 lb01 Keepalived_healthcheckers[2902]: TCP_CHECK on service [49.12.154.76]:tcp:10443 failed.
Mär 16 11:29:40 lb01 Keepalived_healthcheckers[2902]: Removing service [49.12.154.76]:tcp:10443 to VS [49.12.154.74]:tcp:10443
In this lines we see that RVS 76 misc check openvpn fails and is removed
Mär 16 11:29:42 lb01 Keepalived_healthcheckers[2902]: Misc check for [[49.12.154.76]:udp:1194 VS [49.12.154.74]:udp:1194] by [/root/check_vpn.py] failed with retry disabled (exited with status 1).
Mär 16 11:29:42 lb01 Keepalived_healthcheckers[2902]: Removing service [49.12.154.76]:udp:1194 to VS [49.12.154.74]:udp:1194
In this lines we see that RVS 76 tcp check is not available on 443 and is removed
Mär 16 11:29:42 lb01 Keepalived_healthcheckers[2902]: TCP_CHECK on service [49.12.154.76]:tcp:443 failed.
Mär 16 11:29:42 lb01 Keepalived_healthcheckers[2902]: Removing service [49.12.154.76]:tcp:443 to VS [49.12.154.74]:tcp:443Anzeigen des connection status
ipvsadm -Ln --statsAusgabe:
root@lb01:~# ipvsadm -Ln --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
TCP 49.12.154.74:443 0 0 0 0 0
-> 49.12.154.75:443 0 0 0 0 0
TCP 49.12.154.74:10443 0 0 0 0 0
-> 49.12.154.75:10443 0 0 0 0 0
UDP 49.12.154.74:1194 0 0 0 0 0
-> 49.12.154.75:1194 0 0 0 0 0
root@lb01:~#
#Hier können wir sehen, dass die virtuelle IP 74 nur auf einen Server, nämlich 75, zeigt, weil die Überprüfungen auf 76 fehlgeschlagen sind.
#Das ist klar, denn wir haben das LAN-Kabel von 76 zu Testzwecken herausgezogen.Jetzt stecken wir das Kabel wieder ein.
Im Service-Status sehen wir, dass der Service-Status auf 76 automatisch zurückkehrt.
root@lb01:~# service keepalived status
● keepalived.service - Keepalive Daemon (LVS and VRRP)
Loaded: loaded (/lib/systemd/system/keepalived.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2022-03-16 13:56:27 CET; 17min ago
Main PID: 13902 (keepalived)
Tasks: 3 (limit: 2340)
Memory: 2.0M
CPU: 29.825s
CGroup: /system.slice/keepalived.service
├─13902 /usr/sbin/keepalived --dont-fork
├─13903 /usr/sbin/keepalived --dont-fork
└─13904 /usr/sbin/keepalived --dont-fork
Mär 16 14:06:03 lb01 Keepalived_healthcheckers[13903]: Lost quorum 1-0=1 > 0 for VS [49.12.154.74]:tcp:443
Mär 16 14:06:30 lb01 Keepalived_healthcheckers[13903]: TCP connection to [49.12.154.75]:tcp:443 success.
Mär 16 14:06:30 lb01 Keepalived_healthcheckers[13903]: Adding service [49.12.154.75]:tcp:443 to VS [49.12.154.74]:tcp:443
Mär 16 14:06:30 lb01 Keepalived_healthcheckers[13903]: Gained quorum 1+0=1 <= 10 for VS [49.12.154.74]:tcp:443
Mär 16 14:07:44 lb01 Keepalived_healthcheckers[13903]: TCP connection to [49.12.154.76]:tcp:10443 success.
Mär 16 14:07:44 lb01 Keepalived_healthcheckers[13903]: Adding service [49.12.154.76]:tcp:10443 to VS [49.12.154.74]:tcp:10443
Mär 16 14:07:44 lb01 Keepalived_healthcheckers[13903]: TCP connection to [49.12.154.76]:tcp:443 success.
Mär 16 14:07:44 lb01 Keepalived_healthcheckers[13903]: Adding service [49.12.154.76]:tcp:443 to VS [49.12.154.74]:tcp:443
Mär 16 14:12:51 lb01 Keepalived_healthcheckers[13903]: Misc check for [[49.12.154.76]:udp:1194 VS [49.12.154.74]:udp:1194] by [/root/check_vpn.py] succeeded.
Mär 16 14:12:51 lb01 Keepalived_healthcheckers[13903]: Adding service [49.12.154.76]:udp:1194 to VS [49.12.154.74]:udp:1194Das ganze nochmlas in
ipvsadm -Ln --statsAusgabe:
root@lb01:~# ipvsadm -Ln --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
TCP 49.12.154.74:443 0 0 0 0 0
-> 49.12.154.75:443 0 0 0 0 0
-> 49.12.154.76:443 0 0 0 0 0
TCP 49.12.154.74:10443 20 148 0 8880 0
-> 49.12.154.75:10443 20 148 0 8880 0
-> 49.12.154.76:10443 0 0 0 0 0
UDP 49.12.154.74:1194 0 0 0 0 0
-> 49.12.154.75:1194 0 0 0 0 0
-> 49.12.154.76:1194 0 0 0 0 0Was passiert, wenn lb01 ausfällt? Zu Testzwecken haben wir den Keepalive-Service auf lb01 gestoppt.
root@lb01:~# service keepalived stop
root@lb01:~# service keepalived status
● keepalived.service - Keepalive Daemon (LVS and VRRP)
Loaded: loaded (/lib/systemd/system/keepalived.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Wed 2022-03-16 15:38:51 CET; 32min ago
Process: 16485 ExecStart=/usr/sbin/keepalived --dont-fork $DAEMON_ARGS (code=exited, status=0/SUCCESS)
Main PID: 16485 (code=exited, status=0/SUCCESS)
CPU: 4min 4.232s
Mär 16 15:15:23 lb01 Keepalived_healthcheckers[16486]: TCP connection to [49.12.154.76]:tcp:10443 success.
Mär 16 15:15:23 lb01 Keepalived_healthcheckers[16486]: Adding service [49.12.154.76]:tcp:10443 to VS [49.12.154.74]:tcp:10443
Mär 16 15:38:50 lb01 Keepalived[16485]: Stopping
Mär 16 15:38:50 lb01 Keepalived_vrrp[16487]: (VI_1) sent 0 priority
Mär 16 15:38:50 lb01 systemd[1]: Stopping Keepalive Daemon (LVS and VRRP)...
Mär 16 15:38:51 lb01 Keepalived_vrrp[16487]: Stopped
Mär 16 15:38:51 lb01 Keepalived[16485]: Stopped Keepalived v2.1.5 (07/13,2020)
Mär 16 15:38:51 lb01 systemd[1]: keepalived.service: Succeeded.
Mär 16 15:38:51 lb01 systemd[1]: Stopped Keepalive Daemon (LVS and VRRP).
Mär 16 15:38:51 lb01 systemd[1]: keepalived.service: Consumed 4min 4.232s CPU time.
root@lb01:~#
On lb02
root@lb02:~# service keepalived status
● keepalived.service - Keepalive Daemon (LVS and VRRP)
Loaded: loaded (/lib/systemd/system/keepalived.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2022-03-16 14:32:29 CET; 1h 40min ago
Main PID: 4733 (keepalived)
Tasks: 3 (limit: 2340)
Memory: 7.4M
CPU: 6min 4.240s
CGroup: /system.slice/keepalived.service
├─4733 /usr/sbin/keepalived --dont-fork
├─4734 /usr/sbin/keepalived --dont-fork
└─4735 /usr/sbin/keepalived --dont-fork
Mär 16 15:15:21 lb02 Keepalived_healthcheckers[4734]: Misc check for [[49.12.154.76]:udp:1194 VS [49.12.154.74]:udp:1194] by [/root/check_vpn.py] succeeded.
Mär 16 15:15:21 lb02 Keepalived_healthcheckers[4734]: Adding service [49.12.154.76]:udp:1194 to VS [49.12.154.74]:udp:1194
Mär 16 15:15:23 lb02 Keepalived_healthcheckers[4734]: TCP connection to [49.12.154.76]:tcp:10443 success.
Mär 16 15:15:23 lb02 Keepalived_healthcheckers[4734]: Adding service [49.12.154.76]:tcp:10443 to VS [49.12.154.74]:tcp:10443
Mär 16 15:15:24 lb02 Keepalived_healthcheckers[4734]: Misc check for [[49.12.154.76]:tcp:443 VS [49.12.154.74]:tcp:443] by [/root/check_vpn.py] succeeded.
Mär 16 15:15:24 lb02 Keepalived_healthcheckers[4734]: Adding service [49.12.154.76]:tcp:443 to VS [49.12.154.74]:tcp:443
Mär 16 15:38:50 lb02 Keepalived_vrrp[4735]: (VI_1) Backup received priority 0 advertisement
Mär 16 15:38:51 lb02 Keepalived_vrrp[4735]: (VI_1) Entering MASTER STATE
In the last Line we can see he will become master
Now we start on the lb01 again an the status of lb02
root@lb02:~# service keepalived status
● keepalived.service - Keepalive Daemon (LVS and VRRP)
Loaded: loaded (/lib/systemd/system/keepalived.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2022-03-16 14:32:29 CET; 1h 40min ago
Main PID: 4733 (keepalived)
Tasks: 3 (limit: 2340)
Memory: 7.4M
CPU: 6min 4.240s
CGroup: /system.slice/keepalived.service
├─4733 /usr/sbin/keepalived --dont-fork
├─4734 /usr/sbin/keepalived --dont-fork
└─4735 /usr/sbin/keepalived --dont-fork
Mär 16 15:15:21 lb02 Keepalived_healthcheckers[4734]: Misc check for [[49.12.154.76]:udp:1194 VS [49.12.154.74]:udp:1194] by [/root/check_vpn.py] succeeded.
Mär 16 15:15:21 lb02 Keepalived_healthcheckers[4734]: Adding service [49.12.154.76]:udp:1194 to VS [49.12.154.74]:udp:1194
Mär 16 15:15:23 lb02 Keepalived_healthcheckers[4734]: TCP connection to [49.12.154.76]:tcp:10443 success.
Mär 16 15:15:23 lb02 Keepalived_healthcheckers[4734]: Adding service [49.12.154.76]:tcp:10443 to VS [49.12.154.74]:tcp:10443
Mär 16 15:15:24 lb02 Keepalived_healthcheckers[4734]: Misc check for [[49.12.154.76]:tcp:443 VS [49.12.154.74]:tcp:443] by [/root/check_vpn.py] succeeded.
Mär 16 15:15:24 lb02 Keepalived_healthcheckers[4734]: Adding service [49.12.154.76]:tcp:443 to VS [49.12.154.74]:tcp:443
Mär 16 15:38:50 lb02 Keepalived_vrrp[4735]: (VI_1) Backup received priority 0 advertisement
Mär 16 15:38:51 lb02 Keepalived_vrrp[4735]: (VI_1) Entering MASTER STATE
Mär 16 16:12:21 lb02 Keepalived_vrrp[4735]: (VI_1) Master received advert from 49.12.154.77 with higher priority 100, ours 99
Mär 16 16:12:21 lb02 Keepalived_vrrp[4735]: (VI_1) Entering BACKUP STATE
root@lb02:~#
In the last Line we can see he will become backup state again
on the lb01 service status
root@lb01:~# service keepalived status
● keepalived.service - Keepalive Daemon (LVS and VRRP)
Loaded: loaded (/lib/systemd/system/keepalived.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2022-03-16 16:12:18 CET; 10s ago
Main PID: 23921 (keepalived)
Tasks: 3 (limit: 2340)
Memory: 2.0M
CPU: 586ms
CGroup: /system.slice/keepalived.service
├─23921 /usr/sbin/keepalived --dont-fork
├─23922 /usr/sbin/keepalived --dont-fork
└─23923 /usr/sbin/keepalived --dont-fork
Mär 16 16:12:19 lb01 Keepalived_healthcheckers[23922]: TCP connection to [49.12.154.75]:tcp:10443 success.
Mär 16 16:12:19 lb01 Keepalived_vrrp[23923]: (VI_1) received lower priority (99) advert from 49.12.154.78 - discarding
Mär 16 16:12:20 lb01 Keepalived_vrrp[23923]: (VI_1) received lower priority (99) advert from 49.12.154.78 - discarding
Mär 16 16:12:21 lb01 Keepalived_healthcheckers[23922]: Misc check for [[49.12.154.76]:udp:1194 VS [49.12.154.74]:udp:1194] by [/root/check_vpn.py] succeeded.
Mär 16 16:12:21 lb01 Keepalived_vrrp[23923]: (VI_1) received lower priority (99) advert from 49.12.154.78 - discarding
Mär 16 16:12:21 lb01 Keepalived_vrrp[23923]: (VI_1) Entering MASTER STATE
Mär 16 16:12:22 lb01 Keepalived_healthcheckers[23922]: Misc check for [[49.12.154.75]:udp:1194 VS [49.12.154.74]:udp:1194] by [/root/check_vpn.py] succeeded.
Mär 16 16:12:22 lb01 Keepalived_healthcheckers[23922]: Misc check for [[49.12.154.76]:tcp:443 VS [49.12.154.74]:tcp:443] by [/root/check_vpn.py] succeeded.
Mär 16 16:12:23 lb01 Keepalived_healthcheckers[23922]: Misc check for [[49.12.154.75]:tcp:443 VS [49.12.154.74]:tcp:443] by [/root/check_vpn.py] succeeded.
Mär 16 16:12:25 lb01 Keepalived_healthcheckers[23922]: TCP connection to [49.12.154.76]:tcp:10443 success.
root@lb01:~#
In this Line
....
Mär 16 16:12:21 lb01 Keepalived_vrrp[23923]: (VI_1) Entering MASTER STATE
....
He will become master again.
Mission accomplished, HA keepalived works!Unicast wenn das Heartbeat Netz nicht in einem Netz mit Multicast funktionen ist.
Multicast funktioniert nicht über VPN und nicht im Hetzner internen Netz.
Für Unicast sollte allerdings kein Öffentliches Netz gewählt werden, denn die Autehntifizierung wurde in Version 3 entfernt.
Daher nur Private / Dedizierte Verbindungen für Heartbeate verwenden.
Um Unicast zu benutzen in der VVRP einfach folgendes hinzufügen.
Die eigen IP von Privaten / VPN Netz und die IP Adresse vom Privaten / VPN Netz des anderen.
Es können auch mehrer einträge gültig seoin.
Einmal mit zwei LBs
10.1.0.3 ist die IP von Knoten selbst, hier lb02
10.1.0.2 ist die ip von lb01
...
priority 99
advert_int 1
unicast_src_ip 10.1.0.3
unicast_peer {
10.1.0.2
}
virtual_ipaddress {
...
Einmal mit zwei LBs
10.1.0.3 ist die IP von Knoten selbst, hier lb02
10.1.0.2 ist die ip von lb01
10.1.0.4 ist die ip von lb03
Die ips bei Peer müssen untereinander geschrieben sein.
...
priority 99
advert_int 1
unicast_src_ip 10.1.0.3
unicast_peer {
10.1.0.2
10.1.0.4
}
virtual_ipaddress {
...lvs_method und lb_kind
n der Konfiguration von Linux Virtual Server (LVS) innerhalb von keepalived oder ähnlichen Load Balancing-Lösungen sind lvs_method und lb_kind zwei verschiedene Konfigurationseinstellungen, die verschiedene Aspekte des Load Balancing-Verhaltens steuern.
lvs_method (Load Balancing Method)
- Bedeutung:
lvs_methodbezieht sich auf die Methode, wie der Traffic an die Backend-Server (Real Server) weitergeleitet wird. - Typische Methoden:
- NAT (Network Address Translation): Der eingehende Traffic wird umgeschrieben, sodass er von der IP des Load Balancers auf die IP des Real Servers umgeleitet wird. Die Antwort des Servers wird ebenfalls umgeschrieben, um vom Load Balancer zu stammen.
- DR (Direct Routing): Der eingehende Traffic wird direkt an die Backend-Server weitergeleitet, ohne die Pakete umzuschreiben. Die Server müssen so konfiguriert sein, dass sie den Traffic, der für die virtuelle IP-Adresse bestimmt ist, akzeptieren und verarbeiten.
- TUN (Tunneling): Der Traffic wird in IP-Tunnel eingekapselt und an die Backend-Server gesendet.
lb_kind (Load Balancer Kind)
- Bedeutung:
lb_kinddefiniert, wie der Load Balancer selbst im Netzwerk funktioniert. - Typische Arten:
- NAT: Der Load Balancer führt eine Netzwerkadressübersetzung durch (wie oben beschrieben).
- IP-IP: Der Load Balancer verwendet IP-IP-Tunneling, wobei die ursprünglichen IP-Pakete in neue IP-Pakete eingekapselt werden.
- BRIDGE: Der Load Balancer arbeitet auf der Datenträgerebene (Layer 2) des OSI-Modells, was bedeutet, dass er wie eine Netzwerkbrücke funktioniert.
- Bei LB kind müss allerdings noch in der sysctl folgender Wert auf 1 gestell werden
net.ipv4.ip_nonlocal_bind = 1
Zusammenfassung
- lvs_method steuert, wie der Traffic an die Backend-Server weitergeleitet wird (z.B. NAT, DR, TUN).
- lb_kind definiert, wie der Load Balancer im Netzwerk arbeitet (z.B. NAT, IP-IP, BRIDGE).
Die Auswahl der richtigen Methode und des Typs hängt von Ihrer Netzwerktopologie, Ihren Performance-Anforderungen und anderen spezifischen Bedürfnissen Ihres Netzwerks ab. Jede Methode und jeder Typ hat seine eigenen Vor- und Nachteile in Bezug auf Komplexität, Durchsatz und Flexibilität.