3515
Commentaire:
|
← Version 20 à la date du 2019-01-17 19:02:23 ⇥
4655
|
Texte supprimé. | Texte ajouté. |
Ligne 1: | Ligne 1: |
#acl +All:read | |
Ligne 3: | Ligne 4: |
Au Crans, comme on aime la HA, depuis février 2017, on a 2 routeurs redondants, un master (odlyd) et un backup (sable) | Au Crans, comme on aime la HA, depuis février 2017, on a 2 routeurs redondants, un master (gulp) et un backup (odlyd) |
Ligne 10: | Ligne 11: |
Voici ce qu'on veut faire, avoir 2 routeurs en parrallèle. Pour cela, on utilise une vip comme le schéma ci-dessous. | Voici ce qu'on veut faire, avoir 2 routeurs en parallèle. Pour cela, on utilise une vip (pour "Virtual IP address") comme le schéma ci-dessous. ([[http://backreference.org/2013/04/03/firewall-ha-with-conntrackd-and-keepalived/|Credit]]) ||<tablewidth="100%" tablestyle="text-align:center"style="border:none;"> {{attachment:firewallha.png||height="500"}} || |
Ligne 17: | Ligne 20: |
Chaque machine dispose d'ip en dur (ex : odlyd.crans.org; 138.231.136.4) et en plus l'ip "passerelle" sur chaque vlan. | Chaque machine dispose d'ip en dur (ex : gulp.crans.org; 138.231.136.3) et en plus l'ip "passerelle" sur chaque vlan. |
Ligne 29: | Ligne 32: |
Les ip de sortie de la zone crans sont donc en .254 à présent, et gérées par keepalived. |
|
Ligne 33: | Ligne 38: |
Quand un routeur est activé, il faut donc lui assigner les ip. Mais pour communiquer nos routes avec la dsi; les routeurs doivent se parler (voir ospf). Le programme utilisé pour cela est quagga. Quand un routeur devient actif, il faut le démarer, et l'eteindre quand il ne l'est plus, sous peine de déclencher un shitstorm de routes sur zrt. | Quand un routeur est activé, il faut donc lui assigner les ip. Mais pour communiquer nos routes avec la dsi; les routeurs doivent se parler (voir ospf). Le programme utilisé pour cela est quagga. Quand un routeur devient actif, il faut le démarrer, et l’éteindre quand il ne l'est plus, sous peine de déclencher un shitstorm de routes sur zrt. |
Ligne 45: | Ligne 50: |
En temps normal, seul odlyd est actif et route. On peut vouloir activer le routage sur sable, soit en cas de défaillance, soit manuellement. Pour cela, keepalived fait appel à un programme externe qu'on a écrit. Il est à noter que cette conf n'est présente que sur odlyd, qui commande l'activation/desactivation. Si jamais odlyd ne répond plus, sable prendra automatiquement la main. | === Sur gulp === En temps normal, seul gulp est actif et route. On peut vouloir activer le routage sur odlyd, soit en cas de défaillance, soit manuellement. Pour cela, keepalived fait appel à un programme externe qu'on a écrit. Il est à noter que cette conf n'est présente que sur gulp, qui commande l'activation/désactivation. Si jamais gulp ne répond plus, odlyd prendra automatiquement la main. |
Ligne 61: | Ligne 68: |
Si on veut manuellement désactiver le routage sur odlyd, il suffit de supprimer le fichier MASTER. | Si on veut manuellement désactiver le routage sur gulp, il suffit de supprimer le fichier MASTER. |
Ligne 63: | Ligne 70: |
== Utilisation pratique == | Le fichier checkstatus est également utilisé par monit, et en fault il signale que le routage est désactivé sur gulp. |
Ligne 65: | Ligne 72: |
Pour activer ou désactiver le routage sur odlyd (à la demande), il existe ces 2 commandes (qui créent et suppriment MASTER) : | === Sur odlyd === |
Ligne 67: | Ligne 74: |
{{{ .-(7:00:17)-(~)-------------------------------------------------------(detraz@odlyd)- `--[1]-> disable-routage [sudo] password for detraz on odlyd: Routage désactivé sur odlyd, activé sur le routeur backup |
Lorsque odlyd s'active, il crée le fichier /etc/keepalived/BACKUP_ACTIVE. Un second script utilisé cette fois uniquement par monit, vérifie la non présence de ce script. Si il est présent, le routage failover est donc activé, et le signale à travers monit. |
Ligne 73: | Ligne 76: |
.-(7:00:56)-(~)--------------------------------------------------------(detraz@odlyd)- `---> enable-routage Routage activé sur odlyd, désactivé sur le routeur backup }}} |
### == Utilisation pratique == ### Pour activer ou désactiver le routage sur gulp (à la demande), il existe ces 2 commandes (qui créent et suppriment MASTER) : ### {{{ ### .-(7:00:17)-(~)-------------------------------------------------------(detraz@odlyd)- ### `--[1]-> disable-routage ### [sudo] password for detraz on odlyd: ### Routage désactivé sur odlyd, activé sur le routeur backup ### .-(7:00:56)-(~)--------------------------------------------------------(detraz@odlyd)- ### `---> enable-routage ### Routage activé sur odlyd, désactivé sur le routeur backup ### }}} == Comportement observé, bugs connus == Lors de l'activation/désactivation, le lag dure 5 secondes. Si il dure plus ; s'inquiéter. /!\ Éviter de redémarrer inutilement keepalived sur odlyd, cela engendre un lag de 5sec également, ce qui est pénible. (enfin surtout pour les gamers) |
Routage failover
Au Crans, comme on aime la HA, depuis février 2017, on a 2 routeurs redondants, un master (gulp) et un backup (odlyd)
Tout est normalement géré par bcfg2.
Comment ça marche ?
C'est simple comme dirait jammy. Voici ce qu'on veut faire, avoir 2 routeurs en parallèle. Pour cela, on utilise une vip (pour "Virtual IP address") comme le schéma ci-dessous. (Credit)
|
Les vip
Premièrement il y a une instance keepalived qui assigne les ip du routeur.
Chaque machine dispose d'ip en dur (ex : gulp.crans.org; 138.231.136.3) et en plus l'ip "passerelle" sur chaque vlan. De plus, coté zrt (vlan avec la dsi), l'ip est également gérée par keepalived. En voici la liste :
138.231.132.47/24 brd 138.231.132.255 dev ens scope global # vlan zrt, ip sortie 138.231.136.254/21 brd 138.231.143.255 dev crans scope global # vlan adh 10.231.136.254/24 brd 10.231.136.255 dev crans.2 scope global # vlan adm 138.231.148.254/21 brd 10.231.148.255 dev crans.3 scope global # vlan wifi 10.2.9.254/24 brd 10.2.9.255 dev crans.21 scope global # vlan appart 10.53.0.254/16 brd 10.53.254.255 dev crans.22 scope global # vlan federez
Les ip de sortie de la zone crans sont donc en .254 à présent, et gérées par keepalived.
En gros, coté interne, il y a 5 vip, et coté externe (zrt), une seule.
Quagga
Quand un routeur est activé, il faut donc lui assigner les ip. Mais pour communiquer nos routes avec la dsi; les routeurs doivent se parler (voir ospf). Le programme utilisé pour cela est quagga. Quand un routeur devient actif, il faut le démarrer, et l’éteindre quand il ne l'est plus, sous peine de déclencher un shitstorm de routes sur zrt.
Voici la ligne dans la conf keepalived (/etc/keepalived/keepalived.conf) qui commande cela :
notify_master "/usr/sbin/service quagga start" notify_backup "/usr/sbin/service quagga stop" notify_fault "/usr/sbin/service quagga stop"
Activation/désactivation des routeurs
Sur gulp
En temps normal, seul gulp est actif et route. On peut vouloir activer le routage sur odlyd, soit en cas de défaillance, soit manuellement. Pour cela, keepalived fait appel à un programme externe qu'on a écrit. Il est à noter que cette conf n'est présente que sur gulp, qui commande l'activation/désactivation. Si jamais gulp ne répond plus, odlyd prendra automatiquement la main.
track_script { check_routeur } vrrp_script check_routeur { script "/etc/keepalived/checkstatus.sh" interval 5 # check every 5 seconds fall 2 # require 2 failures for KO rise 2 # require 2 successes for OK }
Ce script (très simple et à compléter éventuellement) fait 2 choses, il vérifie la présence d'un fichier vide MASTER dans /etc/keepalived, et le bon fonctionnement de quagga. Si ce n'est pas le cas, il renvoie un code de sortie non nul, et le failover s'active.
Si on veut manuellement désactiver le routage sur gulp, il suffit de supprimer le fichier MASTER.
Le fichier checkstatus est également utilisé par monit, et en fault il signale que le routage est désactivé sur gulp.
Sur odlyd
Lorsque odlyd s'active, il crée le fichier /etc/keepalived/BACKUP_ACTIVE. Un second script utilisé cette fois uniquement par monit, vérifie la non présence de ce script. Si il est présent, le routage failover est donc activé, et le signale à travers monit.
Comportement observé, bugs connus
Lors de l'activation/désactivation, le lag dure 5 secondes. Si il dure plus ; s'inquiéter.
Éviter de redémarrer inutilement keepalived sur odlyd, cela engendre un lag de 5sec également, ce qui est pénible. (enfin surtout pour les gamers)