Vrrp - Historie editací

Locutus: /* Check Script */

2017-08-15T05:56:31Z

Check Script

Locutus: /* HW */

2017-08-15T05:54:23Z

Locutus: /* Praktické zkušenosti s Keepalived */

2017-08-11T07:00:44Z

Praktické zkušenosti s Keepalived

Locutus: /* Praktické zkušenosti s Keepalived */

2017-08-11T06:59:48Z

Praktické zkušenosti s Keepalived

Locutus: /* Mail notifikace */

2017-08-11T06:47:24Z

Mail notifikace

Locutus v 11. 8. 2017, 06:37

2017-08-11T06:37:45Z

Locutus: /* Check Script */

2017-08-11T06:36:56Z

Check Script

Locutus: /* Check Script */

2017-08-11T06:31:48Z

Check Script

Locutus: /* Check Script */

2017-08-11T06:19:37Z

Check Script

Locutus v 11. 8. 2017, 05:54

2017-08-11T05:54:39Z

@@ Řádek 167: / Řádek 167: @@
 Další možností jak řídit kdy a za jakých okolností přejde routr mezi stavy je konstrukce "Check Script" kde můžeme definovat vlastní příkaz nebo script a na základě jeho návratového kódu se Keepalived zachová přepnutím do daného stavu.
-Řekněme, že chceme například sledovat jestli má routr přístup do Internetu pomocí pingu na IP 8.8.8.8, k tomuto nemusím spát žádný script, stačí mi použít pouze příkaz fping 8.8.8.8, ten vrátí návratovou hodnotu 0, pokud je IP dostupná a 1 pokud dostupná není. Check script se chová tak, že pokud je návratová hodnota příkazu/scriptu 0, je vše v pořádku, pokud není 0 (tedy jiné záporné nebo kladné číslo) znamená to chybu.
+Řekněme, že chceme například sledovat jestli má routr přístup do Internetu pomocí pingu na IP 8.8.8.8, k tomuto nemusím psát žádný script, stačí mi použít pouze příkaz fping 8.8.8.8, ten vrátí návratovou hodnotu 0, pokud je IP dostupná a 1 pokud dostupná není. Check script se chová tak, že pokud je návratová hodnota příkazu/scriptu 0, je vše v pořádku, pokud není 0 (tedy jiné záporné nebo kladné číslo) znamená to chybu.
 Do keepalived.conf přidáme tyto řádky (do vrrp_instance):

@@ Řádek 2: / Řádek 2: @@
 == 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.
+Pro naši modelovou situaci použijeme jako routry dva PCengines APU s předinstalovaný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

@@ Řádek 246: / Řádek 246: @@
 *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.
-*keepalived provádí logování do syslogu (pokud není v logovacím systému definováno jinak), zprávy od daemona lze celkem bezpečně dostat takto: cat /var/log/syslog | grep vrrp případně je ještě možnost nechat spustit daemona tak, že logu je do lokální konzole (pouze pro debug): keepalived --log-console
+*keepalived provádí logování do syslogu (pokud není v logovacím systému definováno jinak), zprávy od daemona lze celkem bezpečně dostat takto: "cat /var/log/syslog | grep vrrp" případně je ještě možnost nechat spustit daemona tak, že logu je do lokální konzole (pouze pro debug): keepalived --log-console
 *Pokud je pro vrrp komunikaci použit samostatný interface a samotný provoz jde přes jiný interface, případ kdy jsou routry propojeny na přímo kabelem a ne přes switch, je nutné mít v konfiguraci ještě položky "dont_track_primary" jinak by docházelo k tomu, že při spadnutí linku na sledovaném interface by záložní routr přešel do stavu FAULT místo aby si převzal roli master. Jde o typický příklad kdy jsou routry propojeny napřímo kabelem a jednomu z nich selže např. zdroj, routr tedy vůbec nenaběhne a nenahodí link. Tato fíčura neřeší výpadek switche do kterého jsou routry zapojeny, ale vzhledem k tomu, že switch bude s největší pravděpodobností single-poit-of-failure je to vlastně jedno.

← Starší verze		Verze z 11. 8. 2017, 06:59
Řádek 246:		Řádek 246:
	*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)		*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.		*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.
		+	*keepalived provádí logování do syslogu (pokud není v logovacím systému definováno jinak), zprávy od daemona lze celkem bezpečně dostat takto: cat /var/log/syslog \| grep vrrp případně je ještě možnost nechat spustit daemona tak, že logu je do lokální konzole (pouze pro debug): keepalived --log-console
		+	*Pokud je pro vrrp komunikaci použit samostatný interface a samotný provoz jde přes jiný interface, případ kdy jsou routry propojeny na přímo kabelem a ne přes switch, je nutné mít v konfiguraci ještě položky "dont_track_primary" jinak by docházelo k tomu, že při spadnutí linku na sledovaném interface by záložní routr přešel do stavu FAULT místo aby si převzal roli master. Jde o typický příklad kdy jsou routry propojeny napřímo kabelem a jednomu z nich selže např. zdroj, routr tedy vůbec nenaběhne a nenahodí link. Tato fíčura neřeší výpadek switche do kterého jsou routry zapojeny, ale vzhledem k tomu, že switch bude s největší pravděpodobností single-poit-of-failure je to vlastně jedno.

← Starší verze		Verze z 11. 8. 2017, 06:47
Řádek 193:		Řádek 193:

	==Mail notifikace==		==Mail notifikace==
		+	Keepalived umí posílat maily v případě změny stavu, lze k tomu buď využít globální konfiguraci notification_email {}, která ale není podle mého dostatečně ohebná, použijeme tedy konstrukce notify_master, notify_backup, notify_fault. Úplně stejně se dá použít konstrukce notify, která na to ale není primárně určena.
		+
		+	Definice tedy může být takováto, v keepalived.conf:
		+
		+	<syntaxhighlight lang="bash">
		+	notify_master "/root/keepalivedEmailAlert.sh MASTER"
		+	notify_backup "/root/keepalivedEmailAlert.sh BACKUP"
		+	notify_fault "/root/keepalivedEmailAlert.sh FAULT"
		+	</syntaxhighlight>
		+
		+	Samotný script:
		+	<syntaxhighlight lang="bash">
		+	#!/bin/bash
		+
		+	HW="hrubinova routr1"
		+	IP=10.107.237.1
		+	LOG="/var/log/keepalivedEmailAlert.log"
		+
		+	#email definice#
		+	ODESILATEL=kocourkov@hkfree.org
		+	PRIJEMCE=kocourkov@hkfree.org
		+	MAILAPP="/usr/bin/sendemail"
		+	HOSTNAME=$HW
		+	SMTP="smtp.hkfree.org:25"
		+	MSG="$HOSTNAME Keepalived Alert"
		+	#end email definice#
		+
		+	DATUM=`/bin/date '+%Y.%m.%d_%H.%M.%S'`
		+
		+	case $1 in
		+	"MASTER")
		+	echo $DATUM $HW became MASTER \| tee -a $LOGFILE \| $MAILAPP -u "$MSG transition to MASTER" -t $PRIJEMCE -f $ODESILATEL -s $SMTP -a /var/log/syslog
		+	;;
		+	"BACKUP")
		+	echo $DATUM $HW became BACKUP \| tee -a $LOGFILE \| $MAILAPP -u "$MSG transition to BACKUP" -t $PRIJEMCE -f $ODESILATEL -s $SMTP -a /var/log/syslog
		+	;;
		+	"FAULT")
		+	echo $DATUM $HW in FAULT state \| tee -a $LOGFILE \| $MAILAPP -u "$MSG FAULT state" -t $PRIJEMCE -f $ODESILATEL -s $SMTP -a /var/log/syslog
		+	;;
		+	*)
		+	echo $DATUM $HW is in unknown state \| tee -a $LOGFILE \| $MAILAPP -u "$MSG" -t $PRIJEMCE -f $ODESILATEL -s $SMTP -a /var/log/syslog
		+	;;
		+	esac
		+
		+	exit 0
		+
		+	</syntaxhighlight>
		+	K emailu přikládám i syslog, což je primární logovací cíl pro keepalived.

	==Praktické zkušenosti s Keepalived==		==Praktické zkušenosti s Keepalived==

@@ Řádek 191: / Řádek 191: @@
 *fall ''<int>'' definuje kolikrát musí check po bezprostředně po sobě následujících pokusech selhat, aby byl prohlášen za KO
 *rise ''<int>'' definuje kolikrát musí check po bezprostředně po sobě následujících pokusech selhat, aby byl prohlášen za OK
 ==Praktické zkušenosti s Keepalived==

@@ Řádek 178: / Řádek 178: @@
 vrrp_script chk_myscript {
    script       "/usr/bin/fping 8.8.8.8"
-   weight 50    # weight of this check script
+   weight 60    # weight of this check script
    interval 2   # check every 2 seconds
    fall 2       # require 2 failures for KO
@@ Řádek 187: / Řádek 187: @@
 *Track script {''<vrrp_script name>''} definuje seznam vrrp_scriptů, které se mají spouštět
 *script ''<script/příkaz>'' definuje jaký externí script nebo příkaz se má spouštět (a vyhodnocovat jeho návratová hodnota)
-*weight ''<int>'' je váha check scriptu - pokud se check vyhodnotí jako OK tato hodnota se přičte k prioritě routru, pokud check selže hodnota se odečtě od priority routru, lze tak definovat více checků, kde teprve při selhání více z nich dojde k přepnutí
+*weight ''<int>'' je váha check scriptu - pokud se check vyhodnotí jako OK tato hodnota se přičte k prioritě master routru, pokud check selže hodnota se přičte k prioritě backup routru, lze tak definovat více checků, kde teprve při selhání více z nich dojde k přepnutí
 *interval ''<int>'' definuje jak často [s] se bude chcek provádět
 *fall ''<int>'' definuje kolikrát musí check po bezprostředně po sobě následujících pokusech selhat, aby byl prohlášen za KO

← Starší verze		Verze z 11. 8. 2017, 06:19
Řádek 164:		Řádek 164:

	==Check Script==		==Check Script==
		+	Další možností jak řídit kdy a za jakých okolností přejde routr mezi stavy je konstrukce "Check Script" kde můžeme definovat vlastní příkaz nebo script a na základě jeho návratového kódu se Keepalived zachová přepnutím do daného stavu.
		+
		+	Řekněme, že chceme například sledovat jestli má routr přístup do Internetu pomocí pingu na IP 8.8.8.8, k tomuto nemusím spát žádný script, stačí mi použít pouze příkaz fping 8.8.8.8, ten vrátí návratovou hodnotu 0, pokud je IP dostupná a 1 pokud dostupná není. Check script se chová tak, že pokud je návratová hodnota příkazu/scriptu 0, je vše v pořádku, pokud není 0 (tedy jiné záporné nebo kladné číslo) znamená to chybu.
		+
		+	Do keepalived.conf přidáme tyto řádky (do vrrp_instance):
		+	<syntaxhighlight lang="bash">
		+	track_script {
		+	chk_myscript
		+	}
		+	</syntaxhighlight>
		+
		+	<syntaxhighlight lang="bash">
		+	vrrp_script chk_myscript {
		+	script "/usr/bin/fping 8.8.8.8"
		+	weight 50 # weight of this check script
		+	interval 2 # check every 2 seconds
		+	fall 2 # require 2 failures for KO
		+	rise 2 # require 2 successes for OK
		+	}
		+	</syntaxhighlight>
		+
		+	Track script {''<vrrp_script name>''} definuje seznam vrrp_scriptů, které se mají spouštět
		+	script ''<script/příkaz>'' definuje jaký externí script nebo příkaz se má spouštět (a vyhodnocovat jeho návratová hodnota)
		+	weight ''<int>'' je váha check scriptu - pokud se check vyhodnotí jako OK tato hodnota se přičte k prioritě routru, pokud check selže hodnota se odečtě od priority routru, lze tak definovat více

	==Praktické zkušenosti s Keepalived==		==Praktické zkušenosti s Keepalived==

@@ Řádek 162: / Řádek 162: @@
 esac
 </syntaxhighlight>
 ==Praktické zkušenosti s Keepalived==