SafeKit Smart Console : votre cluster de haute disponibilité à portée de main

La console web SafeKit fournit une interface intuitive pour orchestrer la haute disponibilité de vos applications critiques. En quelques étapes seulement, vous pouvez configurer un cluster miroir SafeKit afin d’assurer la continuité de service :

• Basculement applicatif (onglet Macros) : définissez les services applicatifs à redémarrer automatiquement en cas de défaillance.
• Réseau(x) de heartbeat : chemins de communication dédiés utilisés par les nœuds du cluster pour surveiller en continu leur état de santé et synchroniser les décisions de basculement.
• Gestion des IP virtuelles : configurez l’IP virtuelle (VIP) pour permettre une reconnexion transparente des clients après un basculement.
• Réplication en temps réel : sélectionnez les répertoires critiques à répliquer de manière synchrone, au niveau octet.
• Checkers : surveillent l’état de santé de l’application et déclenchent une reprise automatique en cas de détection d’un processus défaillant.

Le cluster SafeKit intègre un checker dédié de split-brain permettant de résoudre les situations d’isolement réseau sans recourir à une machine témoin tierce ni à un réseau de heartbeat supplémentaire. Pour en savoir plus, consultez heartbeat, basculement et quorum dans un cluster.

La console d’administration SafeKit offre une vue unifiée de votre infrastructure de haute disponibilité. Elle permet aux administrateurs de surveiller l’état opérationnel du cluster et de suivre la synchronisation des données en temps réel.

Pour un cluster miroir à deux nœuds, la console affiche clairement le rôle de chaque serveur :

• PRIM (Primaire) : le nœud actif qui exécute l’application et gère l’IP virtuelle. Il écrit sur le stockage local et réplique les données en temps réel vers le nœud secondaire.
• SECOND (Secondaire) : le nœud en attente qui reçoit les mises à jour synchrones au niveau octet. Il est prêt à prendre instantanément le relais en cas de défaillance du primaire.
• État ALONE : alerte visuelle indiquant que le cluster fonctionne sur un seul nœud (par exemple lors d’une maintenance ou après un incident), signalant une perte temporaire de redondance.
• Progression de la resynchronisation : lorsqu’un nœud redémarre après une panne, son état passe en orange durant la réintégration des données en arrière-plan, sans interruption de service lors du retour à la normale.

Au-delà des simples indicateurs d’état, l’interface propose une orchestration du basculement en un clic (menu ...), permettant de réassigner manuellement le rôle primaire lors d’opérations planifiées, tout en garantissant une disponibilité continue pour les utilisateurs.

Le cluster ferme SafeKit est conçu pour assurer la haute disponibilité et la montée en charge des services. La configuration vise à répartir le trafic entrant simultanément sur l’ensemble des nœuds :

• Services équilibrés en charge (onglet Macros) : définissez les services applicatifs (par exemple Apache, IIS, Nginx) devant rester actifs sur tous les nœuds.
• Réseau(x) de heartbeat : chemins de communication utilisés pour détecter la sortie d’un nœud de la ferme et déclencher une redistribution immédiate de la charge.
• IP virtuelle (VIP de ferme) : contrairement à un cluster miroir, la VIP de la ferme est partagée entre les nœuds à l’aide d’un algorithme de filtrage au niveau du noyau afin de répartir le trafic réseau.
• Règles d’équilibrage de charge : définissez la politique de répartition du trafic en fonction de l’adresse IP source ou du port source.
• Checkers : surveillent l’état de santé des applications et déclenchent un redémarrage automatique en cas de détection d’une défaillance de processus.

La supervision d’un cluster ferme offre une visibilité directe sur la nature Active-Active de l’infrastructure, dans laquelle tous les nœuds contribuent aux performances de l’application (deux nœuds dans cet exemple; extensible à d'autres nœuds) :

• État UP (50 % sur 2 nœuds) : dans une ferme saine, les deux nœuds sont à l’état « UP » (50 %), ce qui signifie qu’ils reçoivent et traitent activement les requêtes clients via l’IP virtuelle partagée.
• Rééquilibrage automatique : en cas de défaillance d’un nœud, la console affiche visuellement que le nœud restant prend 100 % du trafic. Il n’y a pas de délai de « basculement », puisque le nœud survivant est déjà actif (hormis un temps de détection de quelques secondes).
• Réintégration d’un nœud : lorsqu’un nœud réparé redémarre, il passe de l’état « STOP » à « UP » et recommence automatiquement à recevoir sa part de charge, sans intervention de l’administrateur.
• Aucune synchronisation de données : dans un cluster ferme, il n’existe pas d’état de resynchronisation « orange », car les nœuds sont conçus pour être sans état (stateless) ou pour s’appuyer sur une base de données partagée, laquelle peut être protégée séparément par un cluster miroir.

Au-delà des simples icônes d’état, l’interface propose une gestion des nœuds en un clic (menu ...), permettant d’arrêter ou de démarrer manuellement un nœud pour une maintenance planifiée, tandis que l’IP virtuelle partagée redistribue automatiquement le trafic sans interruption pour les utilisateurs.