Vrrp
VRRP neboli Virtual Router Redundancy Protocol slouží k vytvoření jednoho nebo více routrů, které se navzájem zálohují a plně přebírají funkci pokud primární routr z jakéhokoli důvodu přestane fungovat, či pro loadbalancing serverů, což také není předmětem tohoto návodu. Záložních (backup) routrů může být 1 až n. Způsob zapojení routrů do HA není předmětem tohoto návodu, jde pouze o ukázku konfigurace a funkčnosti takovéhoto řešení vysoké dostupnosti routrů. Princip jako funguje VRRP, HSRP apod. také není předmětem tohoto návodu, jak VRRP funguje: [1]
Obsah
HW
Pro naši modelovou situaci použijeme jako routry dva PCengines APU s přeinstalovaným základním systémem, switch a klientské zařízení na kterém budeme testovat funkčnost VRRP, v našem případě půjde o PC s Linuxem.
VRRP na Debianu
Konfigurace, použité verze aplikací a serverů platí pro, v době psaní návodu aktuální, stable release debianu a to verzi 8.5
- Nejdříve si nastavíme na obou routrech statické IP adresy, v našem případě jsem zvolil pro interface eth1 adresy 192.168.100.10 a 11 za předpokladu, že IP routru v síti (tedy z pohledu routrů virtuální adresa) má být 192.168.100.2
- Protože virtuální adresa nebude fyzicky nastavena na jednom nebo více routrech (pouze na aktivním), musíme systému říct, aby na tuto adresu odpovídal. Do /etc/sysctl.conf přidáme tento řádek:
net.ipv4.ip_nonlocal_bind=1
- Pro načtení změn v /etc/sysctl.conf provedeme příkaz:
sysctl -p
man sysctl -p: Load in sysctl settings from the file specified or /etc/sysctl.conf if none given. Specifying - as filename means reading data from standard input.
- Nainstalujeme keepalived
apt-get install keepalived
- Editujeme /etc/keepalived/keepalived.conf pro routr 1:
vrrp_instance VI_1 {
state MASTER !MASTER ma nejvyssi prioritu
interface eth1 !interface na kterem bude keepalived komunikovat, tedy ten interface ve stejne siti/vlan jako zalozni routr(y)
virtual_router_id 1 !identifikator virtualniho routru
priority 150 !priorita daneho routru, fakticky je to jedina hodnota, ktera se meni, plati, ze vim vyssi cislo, tim vyssi priorita
advert_int 1 !hodnota v sekundach jak casto se bude routr dotazovat ostatnich routru jestli jsou nazivu
authentication {
auth_type PASS !typ autentifikace, PASS je plaintext heslo
auth_pass TajneHeslo !heslo v plaintext
}
virtual_ipaddress {
192.168.100.2/24 dev eth1
!virtualni adresa a zarizeni, kteremu se ma priradit, pokud ma routr vic adres,
!vic interfacu, postupujeme analogicky IP dev INTERFACE, napr.
!192.168.101.1 dev vlan10
!192.168.102.1 dev vlan20
!apod.
}
}
- Pro routr 2 je konfigurák /etc/keepalived/keepalived.conf identický, pouze se změní hodnota priority na nějaké nižší číslo, třeba 100
- Spustím daemona keepalived:
service keepalived start
- Daemon by měl do logu vypsat něco jako:
Sep 6 14:35:03 host2 Keepalived[959]: Starting Keepalived v1.2.13 (05/28,2014)
Sep 6 14:35:03 host2 Keepalived[960]: Starting Healthcheck child process, pid=962
Sep 6 14:35:03 host2 Keepalived_healthcheckers[962]: Initializing ipvs 2.6
Sep 6 14:35:03 host2 Keepalived[960]: Starting VRRP child process, pid=963
Sep 6 14:35:03 host2 Keepalived_vrrp[963]: Registering Kernel netlink reflector
Sep 6 14:35:03 host2 Keepalived_vrrp[963]: Registering Kernel netlink command channel
Sep 6 14:35:03 host2 Keepalived_healthcheckers[962]: Registering Kernel netlink reflector
Sep 6 14:35:03 host2 Keepalived_vrrp[963]: Registering gratuitous ARP shared channel
Sep 6 14:35:03 host2 Keepalived_healthcheckers[962]: Registering Kernel netlink command channel
Sep 6 14:35:03 host2 Keepalived_healthcheckers[962]: Opening file '/etc/keepalived/keepalived.conf'.
Sep 6 14:35:03 host2 Keepalived_healthcheckers[962]: Configuration is using : 5295 Bytes
Sep 6 14:35:03 host2 Keepalived_vrrp[963]: Opening file '/etc/keepalived/keepalived.conf'.
Sep 6 14:35:03 host2 Keepalived_vrrp[963]: Configuration is using : 60752 Bytes
Sep 6 14:35:03 host2 Keepalived_vrrp[963]: Using LinkWatch kernel netlink reflector...
Sep 6 14:35:03 host2 Keepalived_healthcheckers[962]: Using LinkWatch kernel netlink reflector...
Sep 6 14:35:04 host2 Keepalived_vrrp[963]: VRRP_Instance(VI_1) Transition to MASTER STATE
Sep 6 14:35:05 host2 Keepalived_vrrp[963]: VRRP_Instance(VI_1) Entering MASTER STATE
Testování funkčnosti
V tuto chvíli máme připravené dva routry se zcela totožnou konfigurací (až na statické IP a prioritu)
- Situace 1:
- běží mi pouze záložní routr2,
- zapnu routr1, po naběhnutí systému si VRRP protokol zjistí, že v síti existuje další routr, ale s nižší prioritou,
- pošle tedy routru s nižší prioritou, že si přebírá roli mastera,
- routr2 si smaže virtuální IP,
- routr1 si nastaví virtuální IP a stane se tím MASTER routrem
V logu proces vypadá nějak takto (všimněte si časových značek):
routr2:
Sep 6 15:35:54 host2 Keepalived_vrrp[963]: VRRP_Instance(VI_1) Received higher prio advert
Sep 6 15:35:54 host2 Keepalived_vrrp[963]: VRRP_Instance(VI_1) Entering BACKUP STATE
routr1 (těsně po startu systému):
Sep 6 15:35:52 host1 Keepalived[440]: Starting Keepalived v1.2.13 (05/28,2014)
Sep 6 15:35:52 host1 Keepalived[472]: Starting Healthcheck child process, pid=475
Sep 6 15:35:52 host1 Keepalived[472]: Starting VRRP child process, pid=476
Sep 6 15:35:52 host1 Keepalived_healthcheckers[475]: Initializing ipvs 2.6
Sep 6 15:35:52 host1 Keepalived_vrrp[476]: Registering Kernel netlink reflector
Sep 6 15:35:52 host1 Keepalived_vrrp[476]: Registering Kernel netlink command channel
Sep 6 15:35:52 host1 Keepalived_vrrp[476]: Registering gratuitous ARP shared channel
Sep 6 15:35:52 host1 Keepalived_vrrp[476]: Opening file '/etc/keepalived/keepalived.conf'.
Sep 6 15:35:52 host1 Keepalived_vrrp[476]: Configuration is using : 60752 Bytes
Sep 6 15:35:52 host1 Keepalived_vrrp[476]: Using LinkWatch kernel netlink reflector...
Sep 6 15:35:52 host1 Keepalived_healthcheckers[475]: Registering Kernel netlink reflector
Sep 6 15:35:52 host1 Keepalived_healthcheckers[475]: Registering Kernel netlink command channel
Sep 6 15:35:52 host1 Keepalived_healthcheckers[475]: Opening file '/etc/keepalived/keepalived.conf'.
Sep 6 15:35:52 host1 Keepalived_healthcheckers[475]: Configuration is using : 5295 Bytes
Sep 6 15:35:52 host1 Keepalived_healthcheckers[475]: Using LinkWatch kernel netlink reflector...
Sep 6 15:35:53 host1 Keepalived_vrrp[476]: Kernel is reporting: interface eth1 DOWN
Sep 6 15:35:53 host1 Keepalived_vrrp[476]: VRRP_Instance(VI_1) Now in FAULT state
Sep 6 15:35:55 host1 Keepalived_vrrp[476]: VRRP_Instance(VI_1) prio is higher than received advert
Sep 6 15:35:55 host1 Keepalived_vrrp[476]: VRRP_Instance(VI_1) Transition to MASTER STATE
Sep 6 15:35:55 host1 Keepalived_vrrp[476]: VRRP_Instance(VI_1) Received lower prio advert, forcing new election
Sep 6 15:35:56 host1 Keepalived_vrrp[476]: VRRP_Instance(VI_1) Entering MASTER STATE
Z pohledu klienta se neděje vůbec nic, přechod je tak rychlý, že klient přesun IP z jednoho stroje na druhý ani nezaznamená. Testováno pomocí ping 192.168.100.2 -i 0.1 > nevypadne ani jeden packet.
- Situace 2:
- běží mi oba routry, routr1 je master,
- routr1 restartuji,
- routr2 po chvilce přebere roli mastera
routr2 (těsně po restartu routru1): Sep 6 15:35:12 host2 Keepalived_vrrp[963]: VRRP_Instance(VI_1) Transition to MASTER STATE Sep 6 15:35:13 host2 Keepalived_vrrp[963]: VRRP_Instance(VI_1) Entering MASTER STATE
z pohledu klienta jde asi o 2s výpadek brány.
- Situace 3:
- Na primárním routru chci dělat update, konkrétně upgrade kernelu, k takové změně musím systém restartovat
- na primárním routru si v konfiguraci snížím prioritu pod prioritu záložního routru (např. na 90) a restartuji keepalived
- záložní routr by si měl bezpečně a řízeně převezmout roli martera
- primární routr pak mohu bezpečně restartovat
VRRP a OSPF
Na záložním routru není nutné, ba ani žádoucí, aby běžel routovací daemon v době kdy tento stroj nemá aktivně plnit roli routru. Routovací daemony nebo i jakékoli jiné služby můžeme podle potřeby vypnout či zapnout podle aktuálního stavu ve kterém se routr nachází.
Toto lze docílit pomocí konstrukce v keepalived.conf: notify <script_to_run.sh> Script definovaný u položky "notify" se spustí vždy pokud dojde ke změně stavu, ať MASTER>BACKUP nebo BACKUP>MASTER nebo MASRTER>FAULT a scriptu jako parametr předá stav do kterého přešel, pokud chci tímto řídit spouštění a zastavování routovacích daemonů, script může vypadat nějak takto:
#!/bin/bash
TYPE=$1
NAME=$2
STATE=$3
case $STATE in
"MASTER")
service zebra start
service ospfd start
service ospf6d start
exit 0
;;
"BACKUP")
service zebra stop
service ospfd stop
service ospf6d stop
exit 0
;;
"FAULT")
service zebra stop
service ospfd stop
service ospf6d stop
exit 0
;;
*)
echo "unknown state"
exit 1
;;
esac
Check Script
Praktické zkušenosti s Keepalived
- Pokud chci nechat načíst novou konfiguraci, mělo by se to dělat odesláním signálu "HUP" hlavnímu procesu keepalived, nikoli kompletním restartem služby: kill -HUP $(cat /var/run/keepalived.pid)
- pozor na misconfig u keepalived.conf! některé nesrovnalosti v konfiguraci mohou odstavit primární routr a backup routr poslat do FAULT stavu, zle tak jednoduše dospět do stavu, že ani jeden z routrů nebude mít nastaveny VIP.