Grappe et HA
Fidwyn se met en grappe en actif-actif jusqu'à 24 nœuds. Chaque nœud dessert le trafic derrière une unique IP virtuelle ; l'état se réplique en dessous ; un nœud perdu s'autorépare, et le basculement entre sites est une action délibérée, contrôlée par l'opérateur, jamais une bascule silencieuse.
- Deux appliances ou plus issues de la même image golden (Démarrer), sur le même réseau à faible latence.
- Une IP virtuelle réservée pour le cluster : les clients atteignent le cluster via la VIP, pas une adresse de nœud.
- Des versions produit identiques sur chaque nœud.
- Le premier nœud (primaire) licencié ; les jetons d'enrôlement transportent l'adresse du primaire vers les nœuds qui rejoignent.
Enrôler la grappe ¶
Construisez la grappe à partir d'un primaire vers l'extérieur. Il n'y a aucune veille froide à promouvoir plus tard ; chaque nœud est actif.
- Initialisez le primaire. Sur le premier nœud, ouvrez System Settings → High Availability et initialisez la grappe, en réservant l'IP virtuelle que les clients utiliseront.
- Générez un jeton d'enrôlement. Le primaire émet un jeton à usage unique avec sa propre adresse encodée à l'intérieur, de sorte que les nœuds qui rejoignent n'ont aucune IP à saisir manuellement.
- Rattachez chaque nœud. Démarrez une autre appliance à partir de l'image golden (Démarrer), ouvrez High Availability → Join et collez le jeton. Le nœud entre dans le maillage, commence à répliquer l'état et se met à desservir le trafic, généralement en moins d'une minute.
- Répétez jusqu'à 24 nœuds. Ajoutez une étiquette Site pour regrouper les nœuds par emplacement en vue d'un basculement planifié.
Répliquer l'état (Postgres, Vault, Redis) ¶
- Postgres diffuse en flux vers des standbys tenant compte des rôles, de sorte que les données d'audit et de configuration validées existent sur plus d'un nœud.
- Vault se réplique en un quorum Raft à plusieurs votants ; conservez un nombre impair de votants pour que le magasin de justificatifs garde une majorité (et reste disponible) lors de la perte d'un nœud.
- Redis réplique la couche de cache et de session.
Un maillage de type VRRP détient l'IP virtuelle derrière laquelle se trouve la passerelle d'API de chaque nœud ; les clients continuent de dialoguer avec la VIP quel que soit le nœud qui répond.
Autoréparation et basculement planifié ¶
Tracez clairement la limite entre les deux :
- Automatique, au sein d'une grappe : un conteneur ou un processus défaillant est redémarré localement en quelques secondes, et le trafic reste sur les nœuds sains derrière la VIP. Aucune action de l'opérateur, aucune perte de données.
- Manuel, entre sites : déplacer le rôle actif vers un autre site est une opération délibérée et planifiée qu'un administrateur effectue (pour une maintenance ou un sinistre déclaré). Fidwyn ne bascule pas silencieusement tout un site de lui-même ; c'est vous qui décidez quand la VIP et le rôle primaire se déplacent, de sorte qu'une coupure de liaison passagère ne déclenche jamais une bascule intersite indésirable.
Lire l'état de santé des nœuds (High Availability) ¶
La console High Availability rapporte, par nœud : la mémoire, le disque, le nombre de connexions, le lien maître, l'IP du maillage, l'état de réplication et le quorum Raft. Surveillez-la après chaque rattachement pour confirmer que le nouveau nœud a atteint l'état replicating/healthy avant de vous y fier ; voir État du système pour la distinction avec les services exploités par Fidwyn.