Sur cette page

Configuration

Tout ce qui se regle par noeud : le bloc HA de webserver.json, l’adresse partagee, le point d’entree, et ce qu’il faut verifier sur les composants et sur un Webserver-Front.

Cle du cluster

Generez une cle et utilisez-la sur tous les noeuds. Elle authentifie les noeuds entre eux.


webserver ha genkey

webserver.json

Sur le premier Webserver (celui qui detient vos donnees actuelles) :


{
  "HTTPS": "true",
  "PortAPI": "8050",
  "PortWEB": "9090",
  "AdvertiseAddress": "mugnsoft.example.com",
  "HA": {
    "NodeID": "node1",
    "Bind": "10.0.0.11:7001",
    "Key": "<la cle du cluster>",
    "Bootstrap": "true",
    "Peers": ["10.0.0.12:7001", "10.0.0.13:7001"]
  }
}

Sur le second Webserver : le meme bloc avec ses propres NodeID, Bind et Peers, et sans Bootstrap.

Sur le temoin : ses propres NodeID, Bind et Peers, et "Witness": "true".

Parametre Signification
NodeID Nom unique du noeud. Ne le changez jamais.
Bind hote:port du canal du cluster sur ce noeud
Advertise Ce que les autres noeuds doivent appeler, si different de Bind
Key La cle du cluster, identique sur tous les noeuds
Bootstrap "true" sur le premier noeud uniquement. Ignore une fois le cluster cree.
Peers Canal du cluster des autres noeuds (voir ci-dessous)
Witness "true" sur le temoin
AdvertiseAddress Le nom partage ou l’IP virtuelle communique aux composants (hors du bloc HA)

Peers : les autres noeuds

Chaque noeud liste les autres noeuds, pas lui-meme. Avec trois noeuds, chacun en liste deux :

Noeud Bind Peers
noeud 1 10.0.0.11:7001 10.0.0.12:7001, 10.0.0.13:7001
noeud 2 10.0.0.12:7001 10.0.0.11:7001, 10.0.0.13:7001
temoin 10.0.0.13:7001 10.0.0.11:7001, 10.0.0.12:7001

Peers ne sert qu’au demarrage d’un noeud, pour trouver le cluster. Y ajouter l’adresse du noeud lui-meme est sans effet.

Ordre de demarrage

  1. Demarrez le premier Webserver. Il devient actif avec ses donnees existantes.
  2. Demarrez le second Webserver, puis le temoin. Chacun copie les donnees du noeud actif, puis rejoint le cluster. Ce qu’un noeud detenait avant de rejoindre est conserve sous dbs/backup/pre-join-<date>.

Point d’entree

Faites pointer l’IP virtuelle ou le repartiteur vers les deux Webservers, sur les ports WEB et API, avec ce controle de sante :

Controle Noeud actif En attente
GET /ha/health 200 503

C’est le controle de sante qui ecarte les clients d’un noeud tombe. Une requete qui arrive sur un noeud en attente n’est pas perdue non plus : il la transmet au noeud actif.

Adresse partagee sur chaque Webserver

Definissez le meme AdvertiseAddress dans webserver.json sur les deux Webservers. C’est l’adresse donnee a chaque composant que l’on configure : par la visite guidee, par le generateur de configuration, a l’enregistrement. Elle est lue dans le fichier de chaque noeud ; le cluster ne la copie pas.

Situation Ce qui se passe Ce qu’affiche le panneau du cluster
Pas d’AdvertiseAddress sur le Webserver actif Les composants configures maintenant recoivent l’adresse propre du noeud actif. Ils perdent le Webserver quand un autre noeud prend le relais. A verifier : “Aucune adresse partagee n’est definie”, avec le nom du serveur actif. Chaque Webserver ecrit aussi un avertissement dans son journal au demarrage.
Un noeud en attente a un AdvertiseAddress different, ou aucun Rien pour l’instant. Les composants ajoutes apres sa prise de relais recevraient une autre adresse. A verifier : “Adresse partagee : <noeud> n’est pas configure avec la meme adresse que le serveur actif”, avec le nom du serveur a corriger.

Dans les deux cas : definissez le meme AdvertiseAddress sur le serveur nomme, puis redemarrez-le (un serveur a la fois).

Le temoin ne sert aucun composant et n’a pas besoin d’AdvertiseAddress.

Les composants apres le passage en cluster

Passer d’un Webserver autonome a un cluster n’est pas une migration d’IP : aucun composant n’est a enregistrer de nouveau et aucune commande migrate n’est necessaire. Les fiches des composants, leurs certificats et leurs jetons sont copies sur tous les noeuds, le Webserver qui prend le relais les joint donc aussitot.

Composant Ce qu’il detient sur le Webserver Que faire
Agent Sentinel L’adresse vers laquelle il pousse ses donnees Rien. Quand le Webserver actif demarre avec AdvertiseAddress, il communique l’adresse partagee a chaque agent active. L’agent ne bascule qu’apres avoir verifie qu’il joint cette adresse : il doit donc resoudre le nom et joindre le port API. Un agent trop ancien pour etre prevenu (le journal le dit) est mis a jour, ou enregistre une fois depuis la page Composants.
Sonde (Monitor) Rien en fonctionnement : c’est le Webserver qui l’appelle Rien. Utilisez l’adresse partagee la prochaine fois que vous lancez register.
Integrateur webserverUrl : le lien place dans les notifications Mettez webserverUrl a https://<adresse partagee>:9090 dans integrator.json et redemarrez-le. Sinon les liens continuent d’ouvrir le premier noeud.
Nouveaux composants L’adresse donnee a l’enregistrement Enregistrez-les avec l’adresse partagee (--webserver <adresse partagee>:8050).

Webserver-Front avec un cluster

Un Webserver-Front est alimente exactement comme avec un Webserver autonome : le noeud actif pousse les donnees vers lui, a sens unique. Les noeuds en attente restent silencieux. Quand un autre noeud prend le relais, il commence a pousser et renvoie d’abord tout, de sorte que le Front rattrape ce que le noeud precedent n’avait pas encore envoye.

A savoir :

Point Pourquoi c’est important
Installez le materiel de replication sur les deux Webservers ReplKey et les fichiers pki/ (certificat et cle client, cle de signature, CA) sont declares dans webserver.json et stockes sur disque. Le cluster ne les copie pas. Un noeud qui prend le relais sans eux sert normalement mais ne peut pas pousser vers le Front, qui affiche alors des donnees perimees.
Gardez les horloges synchronisees (NTP) Le Front conserve la copie qui porte l’heure la plus recente. Si l’horloge du noeud qui prend le relais est en retard, le Front ignore ses mises a jour jusqu’a ce qu’elle rattrape.
Les parametres du Front sont partages L’activation de la replication, l’adresse du Front et la cadence sont enregistres dans l’interface et copies sur tous les noeuds. Rien a repeter par noeud.
Testez une bascule une fois Apres l’installation du cluster, arretez le Webserver actif et verifiez que l’indicateur de fraicheur du Front continue d’avancer.

Le panneau du cluster le verifie pour vous : quand un Front est declare et que la cle de replication ou les certificats d’un Webserver sont absents, invalides ou differents de ceux du noeud actif, le panneau affiche A verifier et nomme le serveur, avant toute bascule. Si le Webserver actif lui-meme ne peut pas alimenter le Front, le panneau affiche Front non mis a jour.

Le temoin ne pousse jamais vers le Front et n’a besoin de rien de tout cela.

Frequence des instantanes

Pour garder son journal des modifications court, le cluster enregistre regulierement une copie complete de ses donnees et supprime le journal qui la precede. Sur une grande installation, augmentez le nombre de modifications entre deux copies : dans le panneau du cluster, sous Parametres avances et activite. Le panneau indique a quelle frequence cela correspond au rythme actuel. La valeur s’applique a tous les noeuds, sans redemarrage.

Voir aussi

Traductions

Licence