Correction/amélioration "Optimisation CARP au (re)boot d'un BACKUP" - à continuer

This commit is contained in:
jdubois 2023-04-27 12:04:21 +02:00
parent 930dbae0ab
commit 8d54de6980

View file

@ -228,13 +228,13 @@ Et c'est terminé !
### Optimisation CARP au (re)boot d'un BACKUP
Lorsque que l'on a un firewall en BACKUP, il est important de pouvoir le redémarrer sans que cela n'impacte le MASTER. Pour cela, il faut bien comprendre le comportement de CARP au démarrage : pendant un certain temps, il va toujours rester en BACKUP pour voir si il ne reçoit pas d'annonce d'un MASTER. Ce comportement est aussi présent lors de la (re)configuration même si le CARP était MASTER initialement. S'il n'a rien reçu, il passe en MASTER. Ce temps est d'attente correspond à la valeur du paramètre _advbase_ (par défaut à 1 seconde).
Lorsque que l'on a un firewall en BACKUP, il est important de pouvoir le redémarrer sans que cela n'impacte le MASTER. Pour cela, il faut bien comprendre le comportement de CARP au démarrage : pendant un certain temps, il va toujours rester en BACKUP pour voir s'il ne reçoit pas d'annonce d'un MASTER. Ce comportement est aussi présent lors de sa (re)configuration même si le CARP était MASTER initialement. S'il n'a rien reçu, il passe en MASTER. Ce temps est d'attente correspond à 3 fois la valeur du paramètre _advbase_ (par défaut à 1 seconde).
Conséquences de cela :
* Si on reconfigure une interface CARP MASTER, elle va passer en BACKUP pendant _advbase_ secondes ! Il est donc judicieux avant d'intervenir sur une machine qui est CARP MASTER, de vérifier et si besoin ajuster le paramètre _advbase_ à une valeur très faible.
* Si on reconfigure une interface CARP MASTER, elle va passer en BACKUP pendant _3*advbase_ secondes ! Il est donc judicieux après être intervenu sur une machine qui est CARP MASTER de forcer le retour à l'état master avec `ifconfig carp0 state master`.
* Si on redémarre une machine avec des CARP BACKUP, il est probable que son réseau ne soit pas opérationnel immédiatement (synchronisation _Spanning Tree_ qui prend 50 secondes par défaut sur un switch CISCO par exemple). L'interface va donc se déclarer en MASTER après son temps d'attente, et lorsque le réseau sera activera il y aura donc un conflit entre les deux MASTER. Il faut donc bien ajuster _advbase_ pour qu'il soit bien supérieur au temps d'arrivée du réseau. Une manière de faire est d'avoir une configuration en dur avec _advbase_ à 60 secondes par exemple, ce qui permet d'avoir des reboots transparents, puis on reconfigure manuellement _advbase_ à 10 secondes par exemple quand tout est redémarré.
* Si on redémarre une machine avec des CARP BACKUP, il est probable que son réseau ne soit pas opérationnel immédiatement (synchronisation _Spanning Tree_ qui prend 30 secondes par défaut sur un switch Cisco par exemple). L'interface va donc se déclarer en MASTER après son temps d'attente, et lorsque le réseau sera activé il y aura donc un conflit entre les deux MASTER. Il faut donc bien ajuster _advbase_ pour qu'il soit bien supérieur au temps d'arrivée du réseau. Une manière de faire est d'avoir une configuration en dur avec _advbase_ à 60 secondes par exemple, ce qui permet d'avoir des reboots transparents, puis on reconfigure manuellement _advbase_ à 10 secondes par exemple quand tout est redémarré.
> *Note :* Lors d'un reboot planifié on peut également décider de commenter l'ensemble des lignes présentes dans le(s) fichier(s) `/etc/hostname.carpX` : une fois la machine de nouveau disponible, il suffira de décommenter la configuration et recréer les interfaces via `sh /etc/netstart carp0 carp1`