Hochverfügbarkeit und Lastverteilung mit keepalived und ipvsadm unter Debian GNU/Linux – Teil 4

Der vierte Teil der Artikelreihe: Hochverfügbarkeit und Lastverteilung mit keepalived und ipvsadm unter Debian GNU/Linux

Konfiguration des Nodes (Teil3/3)

Wenn keepalived entsprechend der eigenen Anforderungen konfiguriert wurde, muss der Dienst noch mit „/etc/init.d/keepalived start“ gestartet werden.

Sourcecode des vorher erwähnten Bash-Skriptes:

#!/bin/bash

REAL_SERVER=$1
REAL_PORT=$2
WEB=`lynx -dump http://$1:$2/ldcheck.php | grep running | awk {‚print $1‘}`

if [ „$WEB“ == „running“ ]
then
RETURN=0
else
RETURN=1
fi

exit $RETURN

 

Überprüfen der Konfiguration

Erstmal schauen wir uns das Netzwerk an:

root@lb01:~# ip address list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:1e:c9:bb:09:4a brd ff:ff:ff:ff:ff:ff
inet 198.19.254.54/24 brd 198.19.254.255 scope global eth0
inet 198.19.253.1/32 scope global eth0
inet 198.19.254.1/32 scope global eth0
inet6 2a00:e10:1000:7:124::a1/128 scope global
valid_lft forever preferred_lft forever
inet6 2a00:e10:1000:7:124::b1/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::21e:c9ff:febb:94a/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 00:1e:c9:bb:09:4b brd ff:ff:ff:ff:ff:ff

Wie sehen das der Netzwerkschnittstelle eth0 alle IP-Adressen (sowohl IPv4 als auch IPv6) zugeordnet sind.

Nun lassen wir uns die aktiven Zielhost und Verbindungen anzeigen:

root@lb01:~# /sbin/ipvsadm -L
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  198.19.253.1:www wrr persistent 50
-> 198.19.253.7:www Route   1      0          0
-> 198.19.253.8:www Route   1      0          0
TCP  198.19.254.1:https wrr persistent 50
-> 198.19.254.7:https Route   1      0          0
-> 198.19.254.8:https Route   1      0          0
TCP  [2a00:e10:1000:7:124::a1]:www wrr persistent 50
-> [2a00:e10:1000:7:124::a7]:www Route   1      0          0
-> [2a00:e10:1000:7:124::a8]:www Route   1      0          0
TCP  [2a00:e10:1000:7:124::b1]:https wrr persistent 50
-> [2a00:e10:1000:7:124::b7]:https Route   1      0          0
-> [2a00:e10:1000:7:124::b8]:https Route   1      0          0

Der Load Balancer hat erkannt, dass unter der IP-Adresse 198.19.253.7 der konfigurierte Service erreichbar ist. Dies erkennt man dadurch, dass bei Weight eine „1“ steht. Bei „0“ konnte keine Verbindung aufgebaut werden.

Einige Informationen zu VRRP und keepalived

VRRP ist ein Standardprotokoll für die Hochverfügbarkeit von Routern. Siehe dazu http://de.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol.

In keepalived ist dieses Protokoll implementiert. Es wird auf die Verwendung einer virtuellen MAC-Adresse verzichtet, wie es dei Dell und anderen Herstellern der Fall ist. Stattdessen kommt GARP zum Einsatz.

keepalived sendet kontinuierlich konfigurierte VRRP Pakete ins LAN. Jeweils der Host mit der höchten Priorität gewinnt die Entscheidungsauswahl und setzt die virtuelle IP-Adresse. Empfängt ein Host keine VRRP Pakete mehr mit höherer Priorität, setzt er selbst die virtuelle IP-Adresse. Ist der bisherige Master ausgefallen und kommt irgendwann repariert zurück, dann wird die IP-Adresse standardmäßig auf den alten Master zurückgeschaltet. [Z. 1]

Zitatquelle:
1. http://wiki.suretodie.de/wiki:keepalived