5.10 Haute disponibilité
Deux boîtiers qui agissent comme un seul, de sorte que la panne de l'un ne se remarque pas côté utilisateurs. C'est bâti sur trois couches indépendantes, et comprendre qu'elles sont indépendantes, c'est l'essentiel de comprendre la haute disponibilité :
| Couche | Ce qu'elle fait | Configurée dans |
|---|---|---|
| CARP | Une adresse virtuelle partagée, détenue par celui des nœuds qui est maître. Les clients parlent à cette adresse et ne savent jamais quelle machine répond. | Network → Virtual IPs |
| pfsync | Recopie l'état des connexions du pare-feu entre les nœuds, pour que les connexions existantes survivent à une bascule au lieu d'être réinitialisées. | Une interface dédiée à la paire |
| Synchronisation de configuration | Pousse la configuration du maître vers le secours, pour que le secours soit une copie et non une deuxième machine à entretenir aussi. | Cette page |
Une paire qui a CARP mais pas la synchronisation d'état bascule en perdant toutes les connexions. Une paire qui a les deux mais pas la synchronisation de configuration bascule sur un secours dont les règles datent de plusieurs mois. Les trois, ou vous n'avez pas fini.
Settings — /m/core/hasync

Sur le maître, cette page dit où se trouve le secours et ce qu'il faut lui envoyer : l'adresse du secours, les identifiants de connexion, et la liste des sections à synchroniser.
La liste des sections est délibérée, ce n'est pas « tout » : certains réglages doivent différer entre les nœuds — les adresses d'interface propres à chaque nœud, son nom d'hôte, sa priorité CARP. Ceux-là restent locaux au nœud et ne sont jamais poussés. Tout le reste que vous cochez est recopié à chaque changement.
Ne configurez la synchronisation que dans un seul sens. Deux nœuds qui se poussent mutuellement, c'est ainsi que deux machines écrasent les changements l'une de l'autre. Le maître synchronise vers le secours ; le secours ne synchronise vers personne.
Status — /ha-status

La paire sur une seule page :
- Le rôle de ce nœud — maître ou secours, du point de vue de CARP.
- La synchronisation de configuration — quand elle a tourné pour la dernière fois, ce qu'elle a envoyé, et si elle a réussi. Une synchronisation qui échoue en silence depuis des semaines est précisément le mode de panne que cette page existe pour éviter.
- CARP — chaque adresse virtuelle et le nœud qui la détient. Une paire en bonne santé montre toutes les adresses détenues par le même nœud ; des adresses réparties entre les nœuds veulent dire que les nœuds ne s'entendent pas.
- Les services sur le secours — ce qui tourne là-bas.
Servez-vous de cette page après chaque changement sur la paire, et de nouveau après chaque test de bascule. Et testez vraiment : une bascule qui n'a jamais été répétée est un projet, pas une capacité.