Evidian SafeKit : Logiciel de haute disponibilité simple et économique

Cette solution logicielle indépendante de la plateforme est idéale pour les partenaires revendant des applications critiques qui doivent offrir à leurs clients une option simple et économique de haute disponibilité (HA) et de redondance du système, sans la complexité et les coûts des SANs (Storage Area Networks). Les fonctionnalités fondamentales de SafeKit — l'équilibrage de charge, la réplication de données en temps réel et le basculement automatique — simplifient considérablement l'intégration de la HA dans toute offre de service ou de produit.

Avec une expérience éprouvée et de nombreux déploiements dans plus de 30 pays via notre vaste réseau de partenaires, SafeKit est reconnue comme la solution HA la plus simple et la plus rapide à mettre en œuvre pour les systèmes critiques. Cela inclut des secteurs comme les systèmes de gestion vidéo (VMS), le contrôle d'accès, la gestion technique du bâtiment (BMS), les logiciels SCADA, la logistique automatisée et le contrôle critique du trafic aérien/ferroviaire, assurant une disponibilité maximale à tous les niveaux.

SafeKit offre un kit de ressources complet, gratuit et en libre accès pour soutenir ses partenaires, incluant des essais gratuits, des modules de formation en ligne complets et la possibilité d'obtenir la certification officielle SafeKit sans frais. Ces outils permettent aux partenaires d'acquérir rapidement les compétences techniques nécessaires pour déployer efficacement la solution et fournir un support de classe mondiale, minimisant le temps de déploiement et réduisant la courbe d'apprentissage.

Dans cette solution, seules les données de l’application sont répliquées. En cas de panne, seule l’application est redémarrée, et non le système d’exploitation ou la VM entière.

Dans cette solution, la machine virtuelle complète (VM) est répliquée, incluant l’application et le système d’exploitation (OS). En cas de panne, la VM entière est redémarré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.

Le Serveur 1 (PRIM) exécute l'application. Les clients sont connectés à une adresse IP virtuelle. SafeKit réplique en temps réel les modifications apportées à l'intérieur des fichiers à travers le réseau.

La réplication est synchrone sans perte de données en cas de défaillance, contrairement à la réplication asynchrone.
Il vous suffit de configurer les noms des répertoires à répliquer dans SafeKit. Il n'y a pas de prérequis sur l'organisation des disques. Les répertoires peuvent être situés dans le disque système.

Lorsque le Serveur 1 tombe en panne, le Serveur 2 prend le relais. SafeKit bascule l'adresse IP virtuelle et redémarre l'application automatiquement sur le Serveur 2.
L'application retrouve les fichiers répliqués par SafeKit à jour sur le Serveur 2. L'application continue de fonctionner sur le Serveur 2 en modifiant localement ses fichiers qui ne sont plus répliqués vers le Serveur 1.

Le temps de bascule est égal au temps de détection de panne (30 secondes par défaut) plus le temps de démarrage de l'application.

La reprise (failback) consiste à redémarrer le Serveur 1 après avoir résolu le problème qui a causé sa défaillance.
SafeKit resynchronise automatiquement les fichiers, mettant à jour uniquement les fichiers modifiés sur le Serveur 2 pendant que le Serveur 1 était arrêté.

La reprise a lieu sans perturber l'application, qui peut continuer à s'exécuter sur le Serveur 2.

Après la réintégration, les fichiers sont à nouveau en mode miroir, comme à l'étape 1. Le système est de retour en mode haute disponibilité, avec l'application fonctionnant sur le Serveur 2 et SafeKit répliquant les mises à jour de fichiers vers le Serveur 1.

Si l'administrateur souhaite que l'application s'exécute sur le Serveur 1, il/elle peut exécuter une commande "swap" soit manuellement à un moment opportun, soit automatiquement via la configuration.

Sur la figure précédente, l'application s'exécute sur les 3 serveurs (3 est un exemple, il peut y en avoir 2 ou plus). Les utilisateurs sont connectés à une adresse IP virtuelle.
L'adresse IP virtuelle est configurée localement sur chaque serveur du cluster en ferme.
Le trafic entrant vers l'adresse IP virtuelle est reçu par tous les serveurs et réparti entre eux par un filtre réseau à l'intérieur du noyau de chaque serveur.
SafeKit détecte les pannes matérielles et logicielles, reconfigure les filtres réseau en cas de panne et offre des vérificateurs d'application et des scripts de récupération configurables.

L'algorithme d'équilibrage de charge réseau à l'intérieur du filtre réseau est basé sur l'identité des paquets clients (adresse IP client, port TCP client). En fonction de l'identité du paquet client entrant, un seul filtre dans un serveur accepte le paquet; les autres filtres dans les autres serveurs le rejettent.
Une fois qu'un paquet est accepté par le filtre sur un serveur, seuls le CPU et la mémoire de ce serveur sont utilisés par l'application qui répond à la requête du client. Les messages de sortie sont envoyés directement du serveur d'application au client.
Si un serveur tombe en panne, le protocole de battement de cœur de la ferme reconfigure les filtres dans le cluster d'équilibrage de charge réseau pour rééquilibrer le trafic sur les serveurs disponibles restants.

Avec une application avec état (stateful), il y a une affinité de session. Le même client doit être connecté au même serveur sur plusieurs sessions TCP pour récupérer son contexte sur le serveur. Dans ce cas, la règle d'équilibrage de charge SafeKit est configurée sur l'adresse IP du client. Ainsi, le même client est toujours connecté au même serveur sur plusieurs sessions TCP. Et différents clients sont répartis sur différents serveurs de la ferme.
Avec une application sans état (stateless), il n'y a pas d'affinité de session. Le même client peut être connecté à différents serveurs de la ferme sur plusieurs sessions TCP. Il n'y a aucun contexte stocké localement sur un serveur d'une session à l'autre. Dans ce cas, la règle d'équilibrage de charge SafeKit est configurée sur l'identité de la session client TCP. Cette configuration est celle qui est la meilleure pour répartir les sessions entre les serveurs, mais elle nécessite un service TCP sans affinité de session.

Ce tableau fournit les fichiers d'installation SafeKit pour la version actuelle, organisés par système d'exploitation et type d'installeur.

➡️ Accéder aux Archives v7.5

Acquérez une expertise précieuse en Haute Disponibilité (HA) grâce à notre programme de certification gratuit.

• Obtenez Gratuitement votre Certification SafeKit en Haute Disponibilité

Explorez notre documentation marketing produit pour le logiciel HA SafeKit, qui comprend une fiche technique détaillée, un livre blanc produit et un aperçu technique.

• Fiche Technique du Cluster de Haute Disponibilité SafeKit (PDF)
• Livre Blanc sur la Technologie de Cluster de Haute Disponibilité (PDF)
• Aperçu Technique de la Haute Disponibilité SafeKit (DOCX)

Ce tableau présente les solutions de Haute Disponibilité (HA) SafeKit, classées par catégorie d'application et environnement d'exploitation (Bases de données, Serveurs Web, VM, Cloud). Identifiez le module .safe pré-configuré spécifique (par exemple, mirror.safe, farm.safe, et autres) nécessaire pour la réplication en temps réel, l'équilibrage de charge et le basculement automatique des applications critiques sur Windows ou Linux. Simplifiez la configuration de votre cluster HA grâce à des liens directs vers les guides d'installation rapide, chacun incluant un lien de téléchargement pour le module .safe correspondant.

Un module .safe SafeKit est essentiellement un modèle de Haute Disponibilité (HA) pré-configuré qui définit la manière dont une application spécifique sera mise en cluster et protégée par le logiciel SafeKit. En pratique, il contient un fichier de configuration (userconfig.xml) et des scripts de redémarrage.