Architecture

The SKOOR Engine uses a PostgreSQL database to store its configuration data as well as its historical values and historical data. It supports the use of a primary/standby configuration to continuously replicate the database contents. PostgreSQL's own replication methods are used, which means that an exact copy of the database on the primary server is kept on the standby server and that all database updates on the primary server are immediately replicated to the standby server. Le serveur principal met en mémoire tampon les instructions SQL dans un journal binaire, le serveur de secours demande ces instructions au serveur.

Cela garantit des temps d'arrêt courts en cas de défaillance matérielle. Cependant, cela ne protège PAS contre les erreurs humaines telles que les instructions de suppression erronées, qui seront immédiatement synchronisées avec le serveur de secours. La réplication ne remplace pas les sauvegardes régulières.

La figure suivante montre un exemple de configuration de réplication standard.

En mode par défaut, le serveur principal supporte toute la charge, toutes les requêtes des utilisateurs sont traitées par le serveur web Apache sur le serveur principal, les données de mesure sont transmises par les collecteurs au serveur principal actuel et stockées dans la base de données. Les services eranger-server, eranger-collector et eranger-report ne fonctionnent PAS sur le serveur de secours.

Principales caractéristiques de la configuration de réplication

• La réplication peut être mise en œuvre même avec des SKOOR Collectors externes.

• Si une réplication a déjà été effectuée, une grande partie des fichiers de la base de données sera probablement déjà synchronisée. Le script ne transférera PAS les anciennes tables qui sont déjà synchronisées. Cela permet d'économiser de la bande passante réseau si une réinitialisation doit être effectuée.

• Il n'y a pas de basculement automatique du serveur principal vers le serveur de secours. Le script a été conçu pour laisser cette décision à l'appréciation d'un utilisateur. Cependant, il prend en charge un mode non interactif qui permet de lancer un basculement à l'aide d'un script (option -f).

• Possibilité de surveiller le serveur principal à partir du serveur de secours (indépendamment de SKOOR) en envoyant un e-mail dès qu'il détecte que l'SKOOR Engine ne fonctionne plus sur le serveur principal actuel.

• Possibilité d'exécuter des scripts ou des commandes personnalisés avant et/ou après le basculement des fonctions du server (de secours vers principal et vice versa).

Exigences

Pour configurer la réplication de la base de données, un deuxième SKOOR Server est nécessaire, avec les mêmes spécifications de performance que le premier. Bien que ce serveur de secours soit en mode veille la plupart du temps, il doit être capable de supporter la charge complète lorsque sa fonction passe de secours à principale.

Les conditions préalables suivantes doivent être remplies :

• La même version de SKOOR est installée sur le serveur principal et le serveur de secours.

• (Facultatif) Les collecteurs externes sont correctement configurés et fonctionnent.

  • Le paramètre server<N>_address doit être défini sur la même adresse IP que le serveur principal.

  • Les collecteurs utilisant le protocole HTTP ne peuvent pas être commutés automatiquement.

• Le fichier /opt/eranger/bin/eranger-server-replication.pl est identique sur le serveur principal, le serveur de secours et tous les collecteurs. Cela signifie que tous les hôtes concernés doivent avoir la même version de SKOOR installée.

• Le fichier /etc/opt/eranger/eranger-replication.cfg est correctement configuré et identique sur le serveur principal, le serveur de secours et tous les collecteurs.

• Connectivité réseau

  • Port TCP 22 (ssh) du serveur principal vers le serveur de secours, et inversement, ainsi que du serveur principal et du serveur de secours vers tous les collecteurs externes.

  • Port TCP 50001 (transmission des données du SKOOR Collector) de tous les collecteurs externes vers le serveur principal et le serveur de secours.