Simplicité du quorum dans un cluster SafeKit
Avec le logiciel de haute disponibilité SafeKit, la gestion du quorum dans un cluster Windows ou Linux ne nécessite pas de troisième serveur de quorum, ni de disque de quorum spécial, ni de reset hardware à distance. Un simple split brain checker est suffisant pour le quorum SafeKit et pour éviter la double exécution d'une application.
Le split brain checker, sur détection d’isolation réseau entre les serveurs, sélectionne un unique serveur pour devenir primaire. L’autre serveur devient non à jour et se bloque dans l’état WAIT, jusqu’à ce qu’il reçoive à nouveau les heartbeats de l’autre serveur, auquel cas il resynchronise automatiquement les données répliquées à partir de l'autre serveur.
L’élection du serveur primaire via le split brain checker de SafeKit repose sur le ping d’un composant externe, appelé witness (témoin). Le witness est typiquement un routeur qui ne tombe pas en panne. En cas d'isolation réseau, seul le serveur ayant accès au witness sera primaire ALONE, l'autre partira en WAIT. Le witness n'est pas testé en permanence mais uniquement lorsque le système bascule. Si au moment du basculement, le witness est down, le cluster part dans l'état WAIT-WAIT et un administrateur peut choisir de redémarrer l'un des nœuds en tant que primaire via l'interface web de SafeKit.
Envisageons le cas critique d'un gel OS ou d'une isolation réseau sans split brain checker configuré. Un cluster de haute disponibilité SafeKit supporte une double exécution d'une application critique sans corruption de données. Dans ce cas, le serveur primaire continue d'exécuter l'application dans l'état ALONE. Et le serveur secondaire redémarre l'application et passe aussi dans l'état ALONE. Les répertoires répliqués sont isolés et chaque application en cours d'exécution travaille sur ses propres données dans son propre répertoire.
Lorsque le réseau est reconnecté, un sacrifice est réalisé en arrêtant l'application sur un des deux serveurs. Ce sacrifice arrête donc l'application sur un serveur et provoque la réintégration des données à partir de l'autre serveur primaire. Après cette réintégration, les données sont à nouveau en mode mirroir entre un serveur primaire et un serveur secondaire.
Toutes ces opérations sont automatiques avec SafeKit. La complexité de gestion des heartbeats, du failover et du quorum dans le cluster est intégrée au produit SafeKit et transparent pour les utilisateurs de SafeKit. Ainsi, les personnes déployant SafeKit sans compétence particulière peuvent le faire sur deux serveurs standards locaux ou distants. De plus, la configuration est la même que ce soit un cluster Windows ou Linux.
Important: si vous choisissez une autre solution basée sur un disque partagé ou répliqué, il faut s'assurer qu'après un gel OS, le serveur qui sort du gel ne peut plus accéder au disque partagé ou répliqué sinon deux serveurs accédant au même disque via son système de fichiers amène à une corruption des données.
La solution inclut toutes les fonctionnalités de clustering:
surveillance de la défaillance des serveurs, surveillance de la défaillance réseau, surveillance de la défaillance logicielle, redémarrage automatique de
l'application
avec un temps de reprise rapide, une adresse IP virtuelle basculée en cas de panne pour rerouter automatiquement les clients
Ce n'est pas le cas avec les solutions de réplication pure comme la réplication au niveau base de données
