SafeKit : logiciel tout-en-un de haute disponibilité « SANless » et de clustering d'applications

SafeKit offre les fonctionnalités suivantes pour Windows et Linux dans un produit logiciel unique :

• Répartition de charge (Load balancing)
• Réplication de fichiers synchrone en temps réel
• Basculement automatique des applications (Failover)
• Retour automatique après une panne de serveur (Failback)

Non. SafeKit est simple à déployer — aucune expertise avancée n'est requise.

Non. SafeKit s'exécute sur vos serveurs existants, vos machines virtuelles ou dans le cloud — aucun disque partagé ni stockage SAN n'est nécessaire.

Non. SafeKit fonctionne avec les éditions standard de Windows et Linux et ne nécessite pas de licences de base de données "Enterprise".

SafeKit résout les problèmes suivants :

• Les pannes matérielles (20 % des problèmes), y compris la défaillance complète d'une salle informatique
• Les pannes logicielles (40 % des problèmes), y compris le redémarrage des processus critiques
• Les erreurs humaines (40 % des problèmes) grâce à sa facilité d'utilisation

Vous pouvez mettre en œuvre la réplication en temps réel et le basculement pour :

• Tous types d'applications, de répertoires de fichiers et de services
• Les bases de données
• Les machines virtuelles complètes Hyper-V ou KVM
• Docker, Podman et les applications cloud

SafeKit élimine les besoins suivants :

• Répartiteurs de charge réseau ou serveurs proxy dédiés
• Disques partagés ou stockage SAN répliqué
• Éditions "Enterprise" des systèmes d'exploitation et des bases de données
• Compétences spécialisées en maintenance de clusters

Non. La réplication de données est simplement l'action de copier des données du serveur A vers le serveur B. Bien qu'elle soit critique, la réplication seule ne fournit pas la disponibilité. Sans les autres composants d'une architecture HA, la réplication n'est qu'une « copie passive » qui nécessite une intervention manuelle longue pour devenir utile :

• Si le serveur A tombe en panne, le logiciel de réplication de données ne dirigera pas automatiquement vos utilisateurs vers le serveur B.
• Il ne détectera pas que l'application s'est arrêtée.
• Il ne redémarrera pas les services.

De nombreux fournisseurs vous obligent à « assembler » plusieurs produits différents pour obtenir la réplication basée sur l'hôte, le basculement et la répartition de charge. Cette architecture fragmentée est une stratégie dangereuse pour les systèmes critiques :

• Intégration fragile : Lorsque vous utilisez un produit A pour la réplication et un produit B pour le clustering, vous créez un « château de cartes ». Chaque mise à jour de l'OS ou correctif de sécurité risque de briser le lien de communication fragile entre ces moteurs distincts.
• Charge cognitive élevée et erreur humaine : La gestion de multiples interfaces augmente le risque d'erreurs. Lors d'une panne système critique, passer d'une interface graphique à une autre ou utiliser des syntaxes CLI différentes pour diagnostiquer un problème génère de la confusion et prolonge l'interruption de service.
• Rejet de responsabilité entre fournisseurs : Si un basculement échoue, le fournisseur de la réplication peut blâmer l'outil de clustering, vous laissant sans solution claire. Une solution tout-en-un offre un point de responsabilité unique.
• Maintenance complexe : Les systèmes fragmentés nécessitent des compétences spécialisées pour chaque composant, ce qui rend la solution plus difficile à maintenir et nettement plus coûteuse sur le long terme.

Pour automatiser la reprise et éliminer les interruptions de service, un produit tout-en-un doit gérer simultanément plusieurs éléments techniques mobiles :

• Réplication basée sur l'hôte : réplication synchrone en temps réel des données applicatives critiques entre serveurs, sans dépendre d'un stockage partagé (SAN). Cela garantit une perte de données nulle (RPO=0) et élimine les dépendances matérielles coûteuses.
• Adresse IP virtuelle (VIP) : elle fournit un point d'entrée unique pour les utilisateurs. En cas de panne, le logiciel déplace la VIP du nœud défaillant vers le nœud sain, évitant ainsi aux utilisateurs de modifier leur configuration.
• Détecteurs d'erreurs matérielles et logicielles : le système doit tester en permanence (« heartbeat ») le serveur physique et les processus logiciels spécifiques pour identifier immédiatement un blocage ou un plantage.
• Scripts de redémarrage personnalisables : chaque application démarre différemment. Un outil tout-en-un permet d'utiliser des scripts personnalisés pour s'assurer que les services complexes démarrent dans le bon ordre.
• Basculement automatique : l'intelligence nécessaire pour orchestrer l'ensemble du transfert d'un serveur à un autre sans intervention humaine.

Si votre gestionnaire de basculement et votre réplication de données sont deux produits différents, ils peuvent ne pas être « en phase ».

Le danger : Si un basculement se produit alors que la réplication n'a pas fini d'envoyer les derniers bits de données, le serveur B démarrera l'application avec des données obsolètes ou corrompues.

Une solution HA « SANless » tout-en-un garantit que le mécanisme de basculement a connaissance de l'état de la réplication. Elle n'autorisera le démarrage de l'application sur le nœud de secours que si les données sont garanties à jour, évitant ainsi les conflits entre nœuds actifs et la perte de données.

Souvent ignoré dans les guides techniques et mal exécuté par les solutions HA traditionnelles, le retour automatique (failback) reste l'exigence la plus critique pour une véritable résilience. Un véritable produit tout-en-un gère le « retour à la normale » aussi élégamment que la panne. Lorsque le serveur défaillant revient en ligne, ses données sont en retard. Le logiciel HA doit alors :

1. Resynchroniser les données en arrière-plan, du nœud actif vers le nœud rétabli.
2. Maintenir la disponibilité : cette resynchronisation doit s'effectuer sans interrompre l'application en cours d'exécution sur le nœud actif.
3. Restaurer la redondance : une fois les données à nouveau répliquées (miroir), le cluster revient automatiquement à un état protégé, prêt pour un prochain événement.

La méthode technique utilisée pour la réplication basée sur l'hôte impacte considérablement la complexité de configuration de votre application existante.

• Le défi de la réplication au niveau bloc : La plupart des solutions « SANless » répliquent au niveau du disque ou du bloc. Ce n'est pas transparent pour l'application. Cela vous oblige à reconfigurer entièrement l'application pour déplacer ses données sur un volume spécifique de « disque répliqué » nouvellement créé. Cela implique souvent des migrations complexes et des modifications potentielles de la logique applicative.
• L'avantage SafeKit au niveau fichier : SafeKit effectue une réplication basée sur l'hôte au niveau fichier, ce qui est totalement transparent pour l'application. Vous n'avez pas besoin de déplacer les données vers un disque spécial ; il vous suffit de configurer SafeKit pour répliquer les dossiers applicatifs existants. Ces dossiers peuvent même rester sur le disque système, vous permettant de protéger une application exactement là où elle est déjà installée.

Temps de resynchronisation après une panne (étape 3)

• Réseau 1 Gb/s ≈ 3 heures pour 1 téraoctet.
• Réseau 10 Gb/s ≈ 1 heure pour 1 téraoctet ou moins selon les performances d’écriture disque.

Alternative

• Pour un volume de données important, utiliser un stockage partagé externe.
• Plus coûteux, plus complexe.

• Performance du temps de resynchronisation après une panne (étape 3).
• Temps nécessaire pour vérifier chaque fichier entre les deux nœuds.

Alternative

• Regrouper les nombreux fichiers à répliquer dans un disque dur virtuel / une machine virtuelle.
• Seuls les fichiers représentant le disque dur virtuel / la machine virtuelle seront répliqués et resynchronisés dans ce cas.

• Chaque VM fonctionne dans un module miroir indépendant.
• Maximum de 32 modules miroir exécutés sur le même cluster.

Alternative

• Utiliser un stockage partagé externe et une autre solution de clustering de VM.
• Plus coûteux, plus complexe.

• Basculement automatique de l’adresse IP virtuelle avec 2 nœuds dans le même sous-réseau.
• Bonne bande passante pour la resynchronisation (étape 3) et bonne latence pour la réplication synchrone (typiquement un aller-retour inférieur à 2 ms).

Alternative

• Utiliser un load balancer pour l’adresse IP virtuelle si les 2 nœuds sont dans 2 sous-réseaux (pris en charge par SafeKit, notamment dans le cloud).
• Utiliser des solutions de sauvegarde avec réplication asynchrone pour un réseau à forte latence.

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

• Basculement d'application (Onglet Macros) : Définissez les services applicatifs spécifiques à redémarrer automatiquement en cas de défaillance.
• Réseau(x) de heartbeat : Chemin(s) de communication dédié(s) utilisé(s) par les nœuds du cluster pour surveiller mutuellement leur état de santé et synchroniser les décisions de basculement.
• Gestion de l'IP virtuelle : Configurez l'adresse IP virtuelle (VIP) pour une reconnexion transparente des clients après un basculement.
• Réplication en temps réel : Sélectionnez les répertoires critiques pour une réplication synchrone au niveau octet basée sur l'hôte.
• Checkers (Vérificateurs) : Surveillez l'état de santé de l'application et déclenchez une récupération automatique si une défaillance de processus est détectée.

Le cluster SafeKit inclut un vérificateur de split-brain dédié pour résoudre les problèmes d'isolement réseau sans nécessiter de troisième machine témoin (witness) ou de réseau de heartbeat supplémentaire. En savoir plus sur les coupures de courant et l'isolement réseau 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 à 2 nœuds, la console affiche clairement les rôles de chaque serveur :

• PRIM (Primaire) : Le nœud actif qui exécute actuellement l'application et gère l'IP virtuelle. Il effectue les écritures sur le stockage local et la réplication en temps réel vers le nœud secondaire.
• SECOND (Secondaire) : Le nœud passif (standby) qui reçoit les mises à jour synchrones au niveau octet. Il est prêt à prendre le relais instantanément en cas de défaillance du Primaire.
• État ALONE : Vous alerte visuellement lorsque le cluster fonctionne sur un seul nœud (par exemple, pendant une maintenance ou après une panne), indiquant que la redondance est temporairement perdue.
• Progression de la resynchronisation : Lorsqu'un nœud défaillant redémarre, son état passe à l'orange pendant la réintégration des données en arrière-plan, garantissant l'absence d'interruption de service pendant la phase de « retour à la normale ».

Au-delà des simples icônes d'état, l'interface permet une orchestration du basculement en un clic, vous permettant d'inverser manuellement les rôles (Primaire/Secondaire) pour une maintenance planifiée sans interrompre l'activité des utilisateurs.

Le cluster farm SafeKit est conçu pour la haute disponibilité et l'évolutivité des services. La configuration se concentre sur la répartition du trafic entrant sur les deux nœuds simultanément :

• Services avec équilibrage de charge (onglet Macros) : Définissez les services applicatifs spécifiques (ex : Apache, IIS, Nginx) qui doivent rester actifs sur tous les nœuds.
• Réseau(x) de heartbeat : Chemin(s) de communication utilisé(s) pour détecter si un nœud a quitté la ferme, déclenchant une redistribution immédiate de la charge.
• IP virtuelle (Farm VIP) : Contrairement à un cluster miroir, l'IP virtuelle Farm est partagée entre les nœuds à l'aide d'un algorithme de filtrage noyau pour 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.
• Checkers (Vérificateurs) : Surveillez l'état de santé de l'application et déclenchez un redémarrage automatique si une défaillance de processus est détectée.

La surveillance d'un cluster farm offre une visibilité sur la nature Active-Active de l'infrastructure, où tous les nœuds contribuent aux performances de l'application (exemple ici avec 2 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 : Si un nœud tombe en panne, la console montre visuellement que le nœud restant prend 100% du trafic. Il n'y a pas de délai de basculement, car le nœud survivant est déjà actif (hormis un temps de détection de quelques secondes).
• Insertion de nœud : Lorsqu'un nœud réparé est redémarré, il passe de l'état « STOP » à « UP » et commence automatiquement à recevoir sa part de la charge sans intervention de l'administrateur.
• Pas de synchro de données : Notez que dans un cluster farm, il n'y a pas d'état de resynchronisation « Orange », car les nœuds sont censés être sans état (stateless) ou partager une base de données backend (qui peut être protégée séparément dans un cluster miroir).

Au-delà des icônes d'état, l'interface permet une gestion des nœuds en un clic, vous permettant d'arrêter ou de démarrer manuellement un nœud pour une maintenance planifiée pendant que l'IP virtuelle partagée redistribue automatiquement le trafic sans interrompre l'activité des utilisateurs.