Surveillance à tolérance de panne — comment l'assurer avec des clusters de serveurs ?
Surveillance à tolérance de panne — comment l'assurer avec des clusters de serveurs ?
Les réseaux informatiques sont depuis longtemps des composants critiques des processus métier. La panne d'un tel système interrompt l'activité de toute l'organisation. Surveiller et diagnostiquer les performances du réseau est l'une des tâches principales pour maintenir une entreprise en état de marche. C'est un processus continu, destiné à détecter à temps les défauts et les erreurs, et à y répondre vite et de façon adaptée. Se pose alors la question de la haute disponibilité du service de surveillance lui-même, et de son fonctionnement sans interruption.
10-Strike Network Monitor Pro met en œuvre plusieurs mécanismes qui assurent la tolérance de panne du système de surveillance. Ils permettent de garder l'infrastructure réseau sous un contrôle fiable. Voici ces méthodes, jusqu'au cluster de basculement des serveurs de surveillance.
Garde du service de surveillance
Le chien de garde du serveur de surveillance est le service 10-Strike Network Monitor Watchdog. Il est installé sur chaque hôte qui reçoit le paquet d'installation du programme principal ou celui du serveur de surveillance. Il surveille le service 10-Strike Network Monitor Pro Service et le SGBD Firebird Server. Si ces services s'arrêtent ou plantent, la garde les redémarre automatiquement. Après cinq tentatives infructueuses, elle envoie un e-mail à l'adresse indiquée. Même si vous arrêtez régulièrement le service de surveillance pour maintenir la base, une garde active le relance au bout de quelques secondes. Dans ce cas, arrêtez d'abord le service de garde, puis le serveur de surveillance.
Le chien de garde ne surveille pas seulement l'état du service (démarré ou non), mais aussi l'activité du processus de surveillance et ses paramètres. Si le processus ne montre plus de signe d'activité (écriture d'un marqueur dans la base), la garde redémarre le service. Elle fait de même si un certain nombre de contrôles cessent d'être exécutés, ce qui peut signaler une accumulation d'erreurs internes.
Le chien de garde évite ainsi un arrêt de la surveillance dû à des erreurs logicielles du serveur de surveillance.
Serveur de base de secours
Dans le système de surveillance distribuée, la base centrale est sur un serveur physique, et les serveurs de surveillance sont en général sur d'autres machines. Les services se connectent à la base en TCP : ils en lisent les paramètres et y enregistrent les statistiques et les résultats. Si le serveur de base tombe en panne, ou si la liaison est perdue, les informations opérationnelles que le serveur de surveillance y écrit peuvent être perdues.
Pour y remédier, utilisez un serveur de secours avec une base installée, vers lequel tout le système de fichiers (ou une partie des fichiers) est répliqué. Les paramètres du service de surveillance contiennent l'adresse de ce serveur de base de secours. Le serveur de surveillance et la console graphique peuvent basculer automatiquement si le serveur principal devient indisponible. L'adresse se définit dans les paramètres de connexion à la base. Vous devez configurer vous-même la réplication (par exemple la mise en miroir du système de fichiers) pour que la copie de secours reste à jour.
Protection contre la perte d'informations si la liaison avec la base centrale est coupée
Il existe une autre réponse à la perte de liaison entre le serveur de surveillance distant et la base centrale. Si aucun serveur de base de secours n'est indiqué, le service bascule vers la base locale, configurée et installée automatiquement par le paquet (c:\ProgramData\10-Strike\Network Monitor Pro\LocalDB\NETMONITOR.FDB). Il y écrit les statistiques de surveillance des hôtes jusqu'au rétablissement de la communication avec la base principale. À la reconnexion, toutes les données accumulées pendant l'interruption sont transférées automatiquement vers la base principale. Le processus est entièrement automatique et ne demande aucune action. Aucun réglage supplémentaire n'est nécessaire.
Dans ces situations, le journal du service est écrit dans le journal du programme (c:\ProgramData\10-Strike\Network Monitor Pro\Logs\NetMonitorPro.log). Si la liaison avec la base reste coupée longtemps, vous pouvez vérifier que les données ont bien été transférées vers la base centrale.
Réserve du serveur de surveillance — fonctionnement avec un serveur secondaire
La réserve peut concerner non seulement le serveur de base central, mais aussi le serveur de surveillance lui-même. Si l'hôte qui exécute le service de surveillance tombe en panne, la surveillance s'arrête complètement. Pour éviter cela, installez un serveur de surveillance de secours sur un second hôte physique et donnez-lui le même identifiant. On obtient ainsi deux services actifs, connectés à la même base et portant le même identifiant dans le fichier de configuration c:\ProgramData\10-Strike\Network Monitor Pro\NetMonitorPro.ini. Le service qui démarre le premier devient actif et exécute tous les contrôles. Celui qui démarre en second devient le service de secours. Il lit la même liste de contrôles, mais ne les exécute pas. Il surveille en permanence l'activité du premier service, d'après des indicateurs de la base. Si le premier service n'est plus actif, le service de secours prend le relais et exécute les contrôles sans interruption.
Lorsque le premier serveur reprend un fonctionnement normal, le premier service passe en rôle de secours et surveille l'activité du second. Et ainsi de suite.
Cette solution peut servir à constituer un cluster de basculement de serveurs.