SafeKit : logiciel tout-en-un de haute disponibilité « SANless » et de clustering d’applications
Qu’est-ce que SafeKit ?
SafeKit est une solution logicielle de haute disponibilité tout-en-un qui garantit une disponibilité applicative de 100 % en combinant la réplication logicielle en temps réel, le basculement automatique (failover) et la répartition de charge (load balancing) dans un seul package.
En synchronisant les données entre des serveurs standards, SafeKit élimine le besoin de stockage partagé coûteux (SAN) ou de compétences informatiques spécialisées, offrant ainsi un moyen simple et économique de protéger les bases de données d’entreprise (comme SQL Server), les systèmes de sécurité critiques (comme le logiciel de gestion vidéo Milestone XProtect) et les logiciels de contrôle industriel SCADA (comme les applications Siemens) sur les environnements Windows et Linux.
🔍 Hub de navigation SafeKit Haute Disponibilité
Explorez SafeKit : fonctionnalités, vidéos techniques, documentation et essai gratuit
| Type de ressource | Description | Lien direct |
|---|---|---|
| Fonctionnalités clés | Pourquoi choisir SafeKit pour une haute disponibilité simple et économique ? | Voir pourquoi choisir SafeKit pour la Haute Disponibilité |
| Cas d’usage | Découvrez comment SafeKit garantit la haute disponibilité des infrastructures critiques | Voir tous les cas d’usage (Logiciels OEM, Serveurs Edge, SCADA, et plus) |
| Modèle de déploiement | HA SANless tout-en-un : Cluster logiciel sans partage (Shared-Nothing) | Voir SafeKit HA SANless tout-en-un |
| Stratégies HA | SafeKit : Infrastructure (VM) vs Haute Disponibilité au niveau applicatif | Voir SafeKit HA & Redondance : Niveau VM vs Niveau Applicatif |
| Spécifications techniques | Limitations techniques pour le clustering SafeKit | Voir les limitations de la Haute Disponibilité SafeKit |
| Preuve de concept | SafeKit : Démos de configuration HA et de basculement | Voir les tutoriels de basculement SafeKit |
| Architecture | Fonctionnement du cluster miroir SafeKit (Réplication et basculement en temps réel) | Voir Cluster miroir SafeKit : réplication et basculement en temps réel |
| Architecture | Fonctionnement du cluster de ferme SafeKit (Répartition de charge réseau et basculement) | Voir Cluster de ferme SafeKit : répartition de charge et basculement |
| Avantages concurrentiels | Comparaison : SafeKit vs Clusters de Haute Disponibilité (HA) traditionnels | Voir la comparaison SafeKit vs Clusters HA traditionnels |
| Ressources techniques | SafeKit Haute Disponibilité : Documentation, téléchargements et essai | Voir l’essai gratuit SafeKit HA & la documentation technique |
| Solutions préconfigurées | Bibliothèque de modules applicatifs SafeKit : solutions HA prêtes à l’emploi | Voir les modules applicatifs de Haute Disponibilité SafeKit |
Pourquoi choisir SafeKit pour une haute disponibilité simple et économique ?
Quelles sont les fonctionnalités de SafeKit ?
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)
Ai-je besoin de compétences particulières pour installer SafeKit ?
Non. SafeKit est simple à déployer — aucune expertise avancée n’est requise.
SafeKit nécessite-t-il du matériel supplémentaire ?
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.
Des licences logicielles supplémentaires sont-elles requises pour SafeKit ?
Non. SafeKit fonctionne avec les éditions standard de Windows et Linux et ne nécessite pas de licences de base de données “Enterprise”.
Quels problèmes SafeKit résout-il ?
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
Quelles applications sont supportées par SafeKit ?
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
Comment SafeKit réduit-il les coûts ?
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
Quels sont les tarifs et le modèle de licence de SafeKit Haute Disponibilité ?
SafeKit propose un modèle de licence par nœud transparent et économique, basé strictement sur le nombre de serveurs, sans tenir compte du nombre de cœurs CPU ou de sockets. Contrairement à de nombreux concurrents en haute disponibilité qui imposent des abonnements récurrents, SafeKit offre des licences perpétuelles pour garantir un coût total de possession (TCO) réduit et une valorisation de vos actifs logiciels à long terme.
- Aucun coût caché : Tous les modules applicatifs de HA pré-configurés sont fournis gratuitement.
- Évaluation sans risque : Téléchargez un essai gratuit de 30 jours pour tester le basculement et la réplication dans votre environnement.
- Devis personnalisés : N’hésitez pas à nous contacter pour un devis adapté à vos besoins spécifiques en haute disponibilité.
Cas d’usage de SafeKit
SafeKit pour les OEM
Offrir une haute disponibilité avec votre application augmente sa valeur commerciale en garantissant un service continu, en réduisant les risques d’interruption et en renforçant la confiance des clients, tout en permettant aux opérations critiques de fonctionner sans interruption sur des infrastructures standards.
Ajoutez SafeKit à votre catalogue comme option de haute disponibilité : une solution exclusivement logicielle et adaptée à votre application, sans coûts cachés tels que le stockage partagé, totalement agnostique vis-à-vis du matériel, et déployable sur des environnements physiques, virtuels ou cloud, avec une administration simple et “plug-and-play”.
SafeKit pour l’Edge
Les sites Edge ne disposent souvent ni de centre de données ni d’expertise en haute disponibilité — pourtant, la continuité d’activité y est critique. SafeKit maintient le fonctionnement des applications Edge dans les usines, les plateformes pétrolières, les navires, la sécurité des bâtiments, le contrôle aérien, les réseaux 5G, la santé, le commerce de détail…
SafeKit transforme deux serveurs Edge standards (de n’importe quelle marque) en un cluster HA plug-and-play — sans stockage partagé ni SAN. Une pile logicielle légère assure la réplication en temps réel et le basculement automatique (pouvant également inclure la répartition de charge), tout en étant facile à installer et à administrer.
SafeKit pour VMS
Le logiciel de gestion vidéo (VMS) est un élément critique pour la sécurité publique ; il enregistre et diffuse des flux vidéo en direct et archivés afin que les agents de sécurité puissent réagir instantanément aux incidents. Toute interruption du VMS met directement en danger les personnes et les biens.
SafeKit prévient la perte de données vidéo et les interruptions de surveillance en maintenant un accès continu aux flux en direct et enregistrés, même en cas de panne matérielle ou logicielle. Il s’intègre parfaitement aux principales plateformes VMS telles que Milestone, Genetec, Hanwha et bien d’autres, pour maintenir la surveillance opérationnelle au moment où elle est le plus nécessaire.
SafeKit pour l’EACS
Les systèmes de contrôle d’accès électronique (EACS) sont essentiels à la sécurité physique ; ils contrôlent et surveillent l’accès aux zones privées et sensibles via des portes, des badges, des lecteurs et des capteurs. Toute interruption du système peut immédiatement exposer les personnes, les bâtiments et les actifs à un risque d’intrusion.
SafeKit maintient la disponibilité des décisions d’accès, des alarmes et des identifiants à tout moment en éliminant les points de défaillance uniques. Il assure un fonctionnement résilient pour les solutions EACS telles que Hirsch Microsesame, Nedap AEOS et Siemens SiPass , garantissant un accès sécurisé même lors d’incidents d’infrastructure.
SafeKit pour le SCADA
Les systèmes SCADA (Supervisory Control and Data Acquisition) sont au cœur des environnements industriels ; ils contrôlent et surveillent les processus critiques via des vannes, des capteurs et des automates. Toute panne du système peut entraîner des arrêts de production coûteux et compromettre la sécurité des installations.
SafeKit minimise les temps d’arrêt de production en garantissant que les systèmes de contrôle SCADA — tels que ceux pilotant les torréfacteurs Probat ou les systèmes de tri de bagages ALSTEF — restent opérationnels malgré les incidents matériels ou logiciels. Cela permet aux opérateurs de conserver une visibilité et un contrôle total sur les processus industriels en tout temps, évitant ainsi des interruptions coûteuses et des risques sécuritaires.
SafeKit pour la GTB (BMS)
Les systèmes de gestion technique du bâtiment (BMS ou GTB) sont au cœur des infrastructures modernes ; ils assurent le contrôle automatisé du CVC (chauffage, ventilation, climatisation), de la distribution électrique, de l’éclairage, de la sécurité incendie et des réseaux d’eau. Toute interruption du système peut impacter directement la sécurité des occupants, leur confort et le fonctionnement global du bâtiment.
SafeKit sécurise l’automatisation du bâtiment en permettant aux services BMS de continuer à fonctionner de manière transparente en cas de défaillance. Il prend en charge des plateformes telles que Siemens Desigo CC, Bosch BIS et d’autres systèmes similaires pour maintenir des opérations de bâtiment sûres, efficaces et ininterrompues.
SafeKit pour l’ATC
Les systèmes de contrôle du trafic aérien (ATC) sont essentiels à la sécurité de l’aviation ; ils permettent de surveiller et de contrôler en temps réel les mouvements des aéronefs au sol et en vol grâce à des applications de surveillance, de guidage et de contrôle.
SafeKit renforce la résilience des systèmes ATC en garantissant aux contrôleurs un accès ininterrompu aux applications critiques du côté piste. Il est utilisé avec des solutions aéroportuaires et ATC telles que ADB SafeGate pour soutenir des opérations de trafic aérien sûres et continues, quelles que soient les conditions.
SafeKit pour l’OCC
Les centres de contrôle opérationnel (OCC) sont au cœur des réseaux de métro modernes ; ils centralisent la supervision des mouvements des trains, de l’alimentation électrique, de la signalisation, de l’information voyageur et de la gestion des incidents. Dans les lignes de métro automatisées et sans conducteur, l’OCC constitue le point de contrôle unique des opérations.
SafeKit sécurise la supervision ininterrompue du métro en garantissant que les applications de l’OCC restent disponibles en cas de défaillance. Il équipe les centres de contrôle des lignes automatisées et sans conducteur du métro de Paris , permettant un service continu et une réponse rapide aux incidents en l’absence de conducteurs à bord.
Pourquoi un produit de haute disponibilité « SANless » tout-en-un est-il essentiel ?
Dans le monde de la continuité d’activité, de nombreuses organisations croient à tort qu’avoir une sauvegarde ou un outil de réplication de données équivaut à avoir de la Haute Disponibilité (HA). En réalité, ce ne sont que les pièces d’un puzzle bien plus vaste. Pour garantir véritablement un temps de disponibilité de 100 %, vous avez besoin d’une solution tout-en-un qui intègre chaque étape du processus de basculement.
Voici pourquoi une approche fragmentée échoue et pourquoi un produit intégré et tout-en-un comme SafeKit — utilisant la réplication logicielle au niveau fichier — est indispensable.
La réplication basée sur l’hôte est-elle suffisante à elle seule pour la haute disponibilité ?
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.
Les risques cachés des solutions fragmentées : pourquoi le cloisonnement de la HA augmente les échecs
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.
Au-delà des données, quels composants spécifiques sont requis pour un véritable basculement « SANless » ?
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.
Pourquoi le mécanisme de basculement doit-il être synchronisé avec la réplication basée sur l’hôte ?
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.
Que se passe-t-il lorsque le serveur en panne est réparé (failback) ?
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 :
- Resynchroniser les données en arrière-plan, du nœud actif vers le nœud rétabli.
- Maintenir la disponibilité : cette resynchronisation doit s’effectuer sans interrompre l’application en cours d’exécution sur le nœud actif.
- 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.
Réplication au niveau bloc vs niveau fichier : pourquoi la transparence est essentielle
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.
Choisir sa stratégie de haute disponibilité : HA VM vs HA applicative
SafeKit propose deux approches principales pour assurer la continuité d’activité : la HA des machines virtuelles (VM HA) et la HA applicative. Bien que ces deux méthodes offrent des mécanismes de basculement automatique, elles diffèrent sensiblement par leur périmètre, leurs mécanismes de réplication des données, leur vitesse de reprise et leur compatibilité plateforme. Cette comparaison met en évidence ces différences afin d’identifier la stratégie la plus adaptée à chaque environnement IT, selon que l’on privilégie un support large de la virtualisation ou une reprise applicative fine et rapide.
Comparaison des fonctionnalités : SafeKit VM HA vs clustering HA applicatif SafeKit
| Critère de comparaison | VM HA avec module SafeKit Hyper-V ou KVM | HA applicative avec modules applicatifs SafeKit |
|---|---|---|
| Schéma de déploiement | ||
| Périmètre du basculement | SafeKit dans 2 hyperviseurs : réplication et basculement de la VM complète. | SafeKit sur 2 machines virtuelles ou physiques : réplication et basculement au niveau applicatif. |
| Données répliquées | Réplication d’un volume plus important de données (application + système d’exploitation). | Réplication uniquement des données applicatives, réduisant le volume de données. |
| Processus et vitesse de reprise (RTO) | Redémarrage de la VM sur l’hyperviseur 2 si l’hyperviseur 1 tombe. Le temps de reprise dépend du redémarrage de l’OS. Vérification de la VM et mécanisme de basculement. | Temps de reprise rapide avec redémarrage de l’application sur OS2 si le serveur 1 tombe. Typiquement autour d’une minute ou moins (RTO faible). Vérification applicative et basculement logiciel. |
| Installation | L’application est installée une seule fois dans une VM. | L’application est installée sur deux nœuds. |
| Configuration | Solution générique pour toute application / OS exécuté dans la VM. • Ne nécessite pas une connaissance technique de l’application installée dans la VM. • Solution idéale si vous ne connaissez pas le fonctionnement interne de l’application. • Il suffit de définir l’emplacement des fichiers de la VM. | Nécessite une compréhension technique de l’application elle-même. • Quels services doivent être redémarrés. • Les répertoires applicatifs à répliquer en temps réel. • La configuration d’une adresse IP virtuelle pour le basculement. |
| Compatibilité plateforme | Compatible avec Windows/Hyper-V et Linux/KVM, mais pas avec VMware. | Indépendant de la plateforme ; fonctionne sur machines physiques ou virtuelles, infrastructures cloud et tout hyperviseur, y compris VMware. |
| Cas d’usage idéal | Idéal pour gérer des environnements complexes avec plusieurs applications réparties sur plusieurs VM via une politique HA unique. | Idéal pour intégrer la haute disponibilité directement au sein d’une solution logicielle, indépendamment du matériel ou de l’hyperviseur. |
Limitations de la haute disponibilité SafeKit
Pourquoi une réplication de quelques téraoctets ?
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.
Pourquoi une réplication < 1 000 000 fichiers ?
- 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.
Pourquoi un basculement ≤ 32 VM répliquées ?
- 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.
Pourquoi un réseau LAN/VLAN entre sites distants ?
- 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.
Tutoriels techniques et démos sur le basculement SafeKit
Vidéo SafeKit : Webinaire (9:43)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Chapitres
- Introduction (0:38)
- Démonstration de SafeKit (1:41)
- Exemples de redondance et de solution de haute disponibilité (2:00)
- SafeKit vendu dans de nombreux pays avec Milestone (0:49)
- Choisir entre 2 solutions : machine virtuelle ou cluster applicatif (2:29)
- Avantages distinctifs (2:06)
SafeKit : Comment mettre en œuvre la HADR (6:42)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Chapitres
- Introduction à SafeKit HADR sur VLAN étendus (1:06)
- Fonctionnement de la réplication synchrone et du double acquittement (1:41)
- Mécanismes de basculement : ARP gratuit (GARP) et IP virtuelle (2:10)
- Conception pour WAN lent : stratégies de haute disponibilité vs sauvegarde (2:45)
En savoir plus sur SafeKit HADR
Vidéo SafeKit : Clustering au Niveau Machine Virtuelle (5:15)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Chapitres
- 2 nœuds Hyper-V et 2 machines virtuelles (0:49)
- Configuration du cluster et de deux modules hyperv.safe (1:59)
- Démarrage et test de la réplication de VM, migration et basculement sur panne (2:26)
Vidéo SafeKit : Clustering au Niveau Application avec SQL (8:47)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Chapitres
- 2 nœuds avec SQL Server (0:32)
- Configuration du cluster et du module mirror.safe (3:58)
- Démarrage et test de la réplication SQL, migration et basculement sur panne (4:17)
Vidéo SafeKit : Intégration OEM Haute Disponibilité (4:22)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Chapitres
- SafeKit pour l’intégration OEM (0:09)
- Exemple de configuration OEM : Milestone XProtect (2:18)
- Explication des scénarios de basculement (1:49)
- Conclusion : Ajoutez la haute disponibilité OEM à votre catalogue (0:15)
Vidéo SafeKit : Clustering Répartition de Charge Réseau (5:03)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Chapitres
- 2 nœuds avec Apache (0:13)
- Configuration du cluster et du module farm.safe (2:20)
- Démarrage et test de la répartition de charge réseau et du basculement sur panne (2:30)
Vidéo SafeKit : Tutoriel Plateforme de Certification Gratuite (6:11)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Chapitres
- La plateforme de formation et de certification (1:41)
- Qu’est-ce qu’un module de formation SafeKit ? (1:57)
- Comment obtenir une certification SafeKit ? (1:40)
- Partager votre certification sur LinkedIn (0:53)
Plateforme de formation et de certification ici
Vidéo SafeKit : Concurrence et architectures de clusters (13:21)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Chapitres
- Introduction (4:10)
- Cluster de machines virtuelles (1:20)
- Cluster miroir (Mirror) (6:04)
- Cluster ferme (Farm) (1:46)
Voir la comparaison SafeKit vs Cluster HA traditionnel
Vidéo SafeKit : Console sur Smartphone (0:54)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Vidéo SafeKit : Notifications par E-mail sur Bascule (1:04)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Comment fonctionne le cluster miroir SafeKit avec Windows/Linux ?
Étape 1. Réplication en temps réel
Le serveur 1 (PRIM) exécute l’application Windows/Linux. Les clients sont connectés à une adresse IP virtuelle. SafeKit réplique en temps réel via le réseau les modifications apportées à l’intérieur des fichiers.
La réplication est synchrone, sans perte de données en cas de panne, contrairement à la réplication asynchrone.
Il vous suffit de configurer les noms des répertoires à répliquer dans SafeKit. Il n’y a aucun prérequis sur l’organisation des disques. Les répertoires peuvent être situés sur le disque système.
Étape 2. Basculement automatique
En cas de panne du serveur 1, le serveur 2 prend le relais (failover). SafeKit bascule l’adresse IP virtuelle et redémarre automatiquement l’application Windows/Linux sur le serveur 2.
L’application retrouve sur le serveur 2 des fichiers à jour répliqués par SafeKit. L’application continue de s’exécuter sur le serveur 2 en modifiant localement ses fichiers, qui ne sont alors plus répliqués vers le serveur 1.
Le temps de basculement est égal au temps de détection de la panne (30 secondes par défaut) plus le temps de démarrage de l’application.
Étape 3. Retour automatique après panne
Le retour après panne (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, en mettant à jour uniquement les fichiers modifiés sur le serveur 2 pendant que le serveur 1 était arrêté.
Le retour après panne se déroule sans perturber l’application Windows/Linux, qui peut continuer à s’exécuter sur le serveur 2.
Étape 4. Retour à la normale
Après la réintégration, les fichiers repassent en mode miroir, comme à l’étape 1. Le système se retrouve en mode haute disponibilité, avec l’application Windows/Linux s’exécutant 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, cela peut être fait manuellement via la console web au moment opportun, ou automatiquement par configuration.
Comment configurer un cluster miroir SafeKit pour Windows/Linux ?
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 garantir la continuité d’activité :
- 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 : canal(aux) de communication dédié(s) utilisé(s) par les nœuds du cluster pour surveiller mutuellement leur état de santé et leur disponibilité en continu, et pour 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 le heartbeat, le basculement et le quorum dans un cluster.
Comment surveiller un cluster miroir SafeKit pour Windows/Linux ?
La console de gestion 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 (Primary) : 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 (Secondary) : le nœud en veille (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 récupère, son état passe à l’orange pendant la réintégration des données en arrière-plan, garantissant l’absence de temps d’arrêt 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 donnant la possibilité de réassigner manuellement le rôle primaire pour une maintenance planifiée tout en assurant une disponibilité continue pour l’activité des utilisateurs.
Comment fonctionne le cluster SafeKit en mode farm avec Windows/Linux ?
Adresse IP virtuelle dans un cluster en mode farm
Sur la figure précédente, l’application Windows/Linux s’exécute sur les 3 serveurs (3 est un exemple, cela peut être 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 mode farm.
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 situé dans le noyau (kernel) de chaque serveur.
SafeKit détecte les pannes matérielles et logicielles, reconfigure les filtres réseau en cas de défaillance, et propose des scripts de vérification (checkers) et de reprise applicative configurables.
Répartition de charge dans un filtre réseau
L’algorithme de répartition de charge réseau au sein du filtre réseau est basé sur l’identité des paquets clients (adresse IP du client, port TCP du client). En fonction de l’identité du paquet client entrant, un seul filtre dans un serveur accepte le paquet ; les autres filtres des autres serveurs le rejettent.
Une fois qu’un paquet est accepté par le filtre d’un serveur, seuls le processeur (CPU) et la mémoire de ce serveur sont utilisés par l’application Windows/Linux qui répond à la demande du client. Les messages de sortie sont envoyés directement depuis le serveur d’application vers le client.
Si un serveur tombe en panne, le protocole de battement de cœur (heartbeat) de la ferme reconfigure les filtres du cluster de répartition de charge réseau afin de rééquilibrer le trafic sur les serveurs disponibles restants.
Applications avec ou sans état (Stateful ou Stateless)
Avec une application Windows/Linux avec état (stateful), il y a une affinité de session. Un même client doit être connecté au même serveur sur plusieurs sessions TCP afin de récupérer son contexte sur ce serveur. Dans ce cas, la règle de répartition de charge SafeKit est configurée sur l’adresse IP du client. Ainsi, un même client est toujours connecté au même serveur sur ses différentes sessions TCP. Les différents clients sont quant à eux répartis sur les différents serveurs de la ferme (farm).
Avec une application Windows/Linux sans état (stateless), il n’y a pas d’affinité de session. Un même client peut être connecté à différents serveurs de la ferme sur plusieurs sessions TCP. Aucun contexte n’est stocké localement sur un serveur d’une session à l’autre. Dans ce cas, la règle de répartition de charge SafeKit est configurée sur l’identifiant de la session TCP du client. Cette configuration est la plus optimale pour répartir les sessions entre les serveurs, mais elle nécessite un service TCP sans affinité de session.
Comment configurer un cluster SafeKit en mode farm pour Windows/Linux ?
Le cluster SafeKit en mode farm est conçu pour la haute disponibilité et la scalabilité des services. La configuration se concentre sur la répartition du trafic entrant simultanément sur les deux nœuds :
- Services avec répartition de charge (onglet Macros) : Définissez les services applicatifs spécifiques (par exemple, Apache, IIS, Nginx) devant rester actifs sur tous les nœuds.
- Réseau(x) de Heartbeat (battement de cœur) : Chemin(s) de communication utilisé(s) pour détecter si un nœud a quitté la ferme, déclenchant ainsi une redistribution immédiate de la charge.
- IP virtuelle (Farm VIP) : Contrairement à un cluster miroir, la VIP Farm est partagée entre les nœuds à l’aide d’un algorithme de filtrage du noyau (kernel) pour répartir le trafic réseau.
- Règles de répartition de charge : Définissez la politique de distribution du trafic en fonction de l’adresse IP source ou du port.
- Checkers (vérificateurs) : Surveillent l’état de santé de l’application et déclenchent un redémarrage automatique si une défaillance de processus est détectée.
Comment superviser un cluster SafeKit en mode farm pour Windows/Linux ?
La supervision d’un cluster en mode farm offre une visibilité sur la nature Actif-Actif de l’infrastructure, où tous les nœuds contribuent aux performances de l’application (l’exemple ici présente 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 des clients via l’IP virtuelle partagée.
- Rééquilibrage automatique : Si un nœud tombe en panne, la console affiche visuellement le nœud restant prenant 100 % du trafic. Il n’y a pas de délai de basculement (failover), 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 » à l’état « UP » et commence automatiquement à recevoir sa part de la charge, sans intervention de l’administrateur.
- Pas de synchronisation de données : Notez que dans un cluster en mode farm, il n’y a pas d’état de resynchronisation « Orange », car les nœuds sont censés être sans état ou partager une base de données interne (qui peut être protégée séparément dans un cluster miroir).
Au-delà des simples icônes d’état, l’interface permet une gestion des nœuds en un clic, vous offrant la possibilité 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 interrompre l’activité des utilisateurs.
Comparaison de SafeKit avec les clusters de Haute Disponibilité (HA) traditionnels
Cette comparaison met en évidence les différences fondamentales entre SafeKit et les solutions traditionnelles de haute disponibilité (HA) telles que les clusters de basculement (Failover Clusters), la HA par virtualisation et SQL Always-On. SafeKit est conçu comme une solution logicielle simple pour la redondance applicative générique, contrairement à la complexité élevée et aux exigences de stockage spécifiques (stockage partagé, SAN) des mécanismes HA traditionnels.
Comparaison de SafeKit avec les clusters traditionnels de haute disponibilité (HA)
| Solutions | Complexité | Commentaires |
|---|---|---|
| Failover Cluster (Microsoft) | Élevée | Stockage spécifique (stockage partagé, SAN) |
| Virtualisation (VMware HA) | Élevée | Stockage spécifique (stockage partagé, SAN, vSAN) |
| SQL Always-On (Microsoft) | Élevée | Seul SQL est redondant, nécessite SQL Enterprise Edition |
| SafeKit | Faible | Le plus simple, générique et 100 % logiciel. Non adapté à la réplication de gros volumes de données. |
En résumé , SafeKit atteint une haute disponibilité à faible complexité grâce à un mécanisme simple de réplication logicielle qui élimine le besoin d’un matériel dédié coûteux comme un SAN (Storage Area Network). Cela en fait une solution très accessible pour mettre en œuvre rapidement la redondance applicative sans modifications complexes de l’infrastructure.
Différences architecturales : SafeKit défini par logiciel vs. Clusters HA Matériels
Choisir la bonne solution de haute disponibilité (HA) est essentiel pour assurer la continuité d’activité et minimiser les interruptions de service. Cette comparaison propose une analyse technique directe de deux approches architecturales majeures : le clustering logiciel sans partage (Shared-Nothing) de SafeKit par opposition aux méthodes HA traditionnelles qui reposent généralement sur du matériel, des disques partagés (comme un SAN) et des configurations complexes. Ces distinctions couvrent la simplicité de déploiement, les méthodes de réplication des données, la vitesse de reprise (RTO/RPO) et la complexité opérationnelle. Le tableau ci-dessous détaille les principales différences selon les sujets clés de la haute disponibilité.
Comparaison de la haute disponibilité : Clustering logiciel SafeKit vs HA traditionnelle / Clustering matériel
| Sujet | SafeKit (Clustering logiciel / Approche principale) | HA traditionnelle / Clustering matériel |
|---|---|---|
| Clustering logiciel vs Clustering matériel | • Un cluster logiciel simple avec le package SafeKit simplement installé sur deux serveurs | • Un clustering matériel complexe nécessitant un stockage externe ou des répartiteurs de charge réseau |
| Cluster Shared Nothing vs Cluster à disques partagés | • SafeKit est un cluster sans partage (Shared-Nothing) : facile à déployer, même sur des sites distants | • Un cluster à disques partagés est complexe à déployer |
| Haute disponibilité applicative vs Haute disponibilité globale de la machine virtuelle | • La HA applicative prend en charge les pannes matérielles et logicielles grâce à des détecteurs d’application. • Temps de reprise rapide en ne redémarrant que l’application (RTO de l’ordre d’une minute ou moins). • La HA applicative nécessite de définir des scripts de redémarrage par application et les répertoires à répliquer (modules d’application SafeKit). | • La HA complète de machine virtuelle prend en charge les pannes matérielles et certaines pannes logicielles (comme une VM figée). • Redémarrage de la VM en cas de panne et temps de reprise dépendant du redémarrage de l’OS. • Aucun script de redémarrage à définir avec la HA complète de machine virtuelle (modules SafeKithyperv.safeoukvm.safe). Les hyperviseurs sont en actif/actif avec simplement plusieurs machines virtuelles. |
| Haute disponibilité vs Tolérance aux pannes (Fault Tolerance) | • Pas de serveur dédié avec SafeKit. Chaqueserveur peut être le serveur de secours (failover) de l’autre. • Panne logicielle avec redémarrage dans un autre environnement d’OS. • Mise à niveau fluide de l’application et de l’OS possible serveur par serveur (les versions N et N+1 peuvent coexister). | • Serveur secondaire dédié à l’exécution de la même application synchronisée au niveau de l’instruction. • Exception logicielle survenant sur les deux serveurs en même temps. • Mise à niveau fluide impossible. • Matériel ou hyperviseurs spécifiques à tolérance aux pannes. |
| Réplication synchrone vs Réplication asynchrone | • SafeKit met en œuvre une réplication synchrone en temps réel sans aucune perte de données en cas de panne. • Préalable indispensable pour la haute disponibilité. | • Avec la réplication asynchrone, il y a perte de données en cas de panne. • Non adapté à la haute disponibilité mais aux solutions de sauvegarde. |
| Réplication de fichiers au niveau octet vs Réplication de disque au niveau bloc | • SafeKit met en œuvre une réplication de fichiers en temps réel au niveau octet et se configure simplement avec les répertoires d’application à répliquer, même sur le disque système. | • La réplication de disque au niveau bloc est complexe à configurer et exige de placer les données de l’application sur un disque dédié. |
| Heartbeat, Failover et Quorum pour éviter d’avoir 2 nœuds maîtres | • Pour éviter d’avoir 2 maîtres (Split-Brain), SafeKit propose un vérificateur de split-brain simple configuré sur un routeur. | • Pour éviter 2 maîtres, les autres clusters nécessitent une configuration complexe avec une troisième machine, un disque de quorum dédié ou une liaison réseau d’interconnexion spécifique. |
| Adresse IP virtuelle : Primaire/Secondaire, répartition de charge réseau, basculement | • Aucun serveur proxy dédié ni aucune configuration réseau spéciale ne sont nécessaires dans un cluster SafeKit pour les adresses IP virtuelles. | • Une configuration réseau spéciale est requise dans les autres clusters pour les adresses IP virtuelles (remarque : SafeKit propose un health check adapté aux répartiteurs de charge). |
En résumé , le choix architectural entre le clustering logiciel (comme SafeKit) et le clustering matériel (architectures traditionnelles à disque partagé/SAN) a un impact significatif sur la complexité du déploiement, les coûts d’exploitation et l’efficacité de la reprise après incident. La principale conclusion de cette comparaison est l’évolution vers une architecture sans disque partagé (« shared-nothing ») et une haute disponibilité au niveau applicatif, qui privilégie une reprise rapide des applications (RTO faible) ainsi qu’une grande flexibilité de déploiement (y compris entre sites distants). Cette approche aboutit souvent à une solution plus simple à mettre en œuvre et plus résiliente que les configurations de cluster fortement dépendantes du matériel et complexes à administrer. Pour assurer une continuité d’activité maximale tout en simplifiant la gestion, il est essentiel d’évaluer une approche fondée sur le logiciel.
Principaux Éléments Différenciateurs du Cluster Miroir SafeKit
Choisir la bonne approche de réplication des données est essentiel pour garantir la continuité d’activité. Cette comparaison met en évidence les principaux différenciateurs du cluster miroir SafeKit avec réplication de fichiers en temps réel par rapport aux alternatives traditionnelles telles que la réplication au niveau base de données, la réplication de disque, les solutions à disque partagé et les systèmes tolérants aux pannes.
Cluster miroir SafeKit : avantages par rapport aux approches alternatives de réplication et de clustering
| Critère | Avantage SafeKit | Limitation des alternatives |
|---|---|---|
| 3 produits en 1 | Économise sur Windows et Linux le coût du stockage externe partagé/répliqué, des boîtiers de répartition de charge et des éditions entreprise des OS et bases de données. Inclut toutes les fonctionnalités de clustering : réplication synchrone de fichiers en temps réel, surveillance des pannes, redémarrage automatique, basculement d’adresse IP virtuelle. | Les approches traditionnelles nécessitent des produits séparés pour la réplication du stockage, la répartition de charge et le clustering — augmentant les coûts et la complexité. |
| Configuration très simple | Configuration via des modules applicatifs. De nouveaux services et répertoires répliqués peuvent être ajoutés facilement. Le tout géré via une console web centralisée. Aucun contrôleur de domaine ni Active Directory requis. | Microsoft cluster et les solutions similaires nécessitent une configuration complexe d’Active Directory et des contrôleurs de domaine. |
| Réplication synchrone | La réplication en temps réel est synchrone sans perte de données en cas de panne (RPO = 0). | La réplication asynchrone peut perdre les transactions récentes non encore répliquées au moment de la panne. |
| Failback entièrement automatisé | Après une panne, lorsqu’un serveur redémarre, le failback de réplication est entièrement automatique. Le serveur défaillant réintègre le cluster sans arrêter l’application sur le serveur restant. | La plupart des solutions de réplication (notamment au niveau base de données) nécessitent une resynchronisation manuelle. L’application peut même être arrêtée pendant le failback. |
| Réplication de tout type de données | La réplication fonctionne pour les bases de données et pour tout fichier devant être répliqué. | La réplication au niveau base de données ne protège que la base de données, pas les fichiers de configuration, les journaux ni les autres données applicatives. |
| Réplication de fichiers vs réplication de disque | La réplication est basée sur des répertoires de fichiers pouvant être situés n’importe où, même sur le disque système. | La réplication de disque nécessite une partition dédiée et une configuration applicative spéciale pour y stocker les données. |
| Réplication de fichiers vs disque partagé | Les serveurs peuvent être déployés sur deux sites distants sans infrastructure partagée. | Les solutions à disque partagé nécessitent une proximité physique et ne peuvent pas couvrir des sites distants. |
| Sites distants et IP virtuelle | Toutes les fonctionnalités de clustering fonctionnent pour 2 serveurs sur des sites distants. Un LAN étendu permet le reroutage VIP de niveau 2. Pour des réseaux IP différents, la VIP est gérée via un répartiteur de charge avec le health check SafeKit. | De nombreuses solutions de clustering ne prennent pas en charge le basculement entre sites distants ou nécessitent une redirection DNS complexe avec des temps de reprise imprévisibles. |
| Quorum et split brain | Fonctionne avec seulement 2 serveurs. Un simple vérificateur de split brain vers un routeur gère l’isolation réseau entre les sites. | La plupart des solutions de clustering nécessitent un 3ème serveur pour la gestion du quorum. |
| Cluster actif/actif | Le serveur secondaire n’est pas dédié. Le cluster peut fonctionner en actif/actif avec 2 modules miroir différents. | Les systèmes tolérants aux pannes dédient le secondaire à l’exécution de la même application synchronisée au niveau des instructions. |
| Solution HA uniforme | SafeKit implémente à la fois le cluster miroir (réplication + basculement) et le cluster farm (répartition de charge + basculement). Une architecture N-tiers peut être rendue hautement disponible avec une seule solution sur Windows et Linux. | Les architectures typiques mélangent différentes technologies pour la répartition de charge, la réplication et le basculement — augmentant la complexité opérationnelle. |
| RTO / RPO | Redémarrage rapide de l’application en cas de panne : environ 1 minute ou moins. Aucune perte de données (réplication synchrone). | La réplication complète de VM (VMware HA, Hyper-V cluster) nécessite le redémarrage de l’OS entier sur un nouvel hyperviseur, entraînant des temps de reprise plus longs. |
En résumé , le cluster miroir SafeKit offre une solution de haute disponibilité unifiée et économique qui combine réplication synchrone de fichiers, basculement et failback automatiques, répartition de charge et prise en charge de sites distants — le tout sans nécessiter de matériel dédié, de stockage partagé ni de troisième serveur de quorum. Cette simplicité le rend particulièrement adapté aux éditeurs de logiciels et aux organisations nécessitant une HA fiable sur des serveurs Windows et Linux standard.
Principaux Éléments Différenciateurs du Cluster Farm SafeKit
Le SafeKit Farm Cluster est une solution de haute disponibilité spécialement conçue pour les environnements applicatifs évolutifs où la répartition de charge et le basculement rapide sont essentiels. Contrairement aux méthodes traditionnelles qui nécessitent des répartiteurs de charge matériels dédiés ou des configurations réseau complexes, SafeKit fournit une solution de clustering intégrée, définie par logiciel, installée directement sur les serveurs d’application. Le tableau ci-dessous détaille les fonctionnalités principales et les avantages uniques du SafeKit Farm Cluster, en mettant l’accent sur la simplification de la répartition de charge réseau et la garantie de disponibilité continue des services sur les plateformes Windows et Linux.
Principaux différenciateurs du SafeKit Farm Cluster avec répartition de charge et basculement
| Avantage | Bénéfice détaillé et mécanisme |
|---|---|
| Pas de répartiteur de charge, de serveurs proxy dédiés ou d’adresse Ethernet multicast spéciale | • La solution ne nécessite ni répartiteurs de charge ni serveurs proxy dédiés au-dessus de la ferme pour mettre en œuvre la répartition de charge. SafeKit est installé directement sur les serveurs d’application de la ferme. La répartition de charge repose sur une adresse IP virtuelle standard / adresse MAC Ethernet et fonctionne avec des serveurs physiques ou des machines virtuelles sous Windows et Linux sans configuration réseau particulière • Ce n’est pas le cas avec les répartiteurs de charge réseau • Ce n’est pas le cas avec les proxies dédiés sous Linux • Ce n’est pas le cas avec uneadresse Ethernet multicast spécifiquesous Windows |
| Toutes les fonctionnalités de clustering | • La solution inclut toutes les fonctionnalités de clustering : adresse IP virtuelle, répartition de charge sur l’adresse IP du client ou sur les sessions, surveillance des pannes serveur / réseau / logiciel, redémarrage automatique de l’application avec un temps de reprise rapide et uneoption de réplication avec un module miroir • Ce n’est pas le cas avec les autres solutions de répartition de charge. Elles sont capables de répartir la charge mais n’incluent pas une solution de clustering complète avec des scripts de redémarrage et un redémarrage automatique de l’application en cas de panne. Elles n’offrent pas d’option de réplication • La configuration du cluster est très simple et se fait au moyen demodules applicatifs. Il n’y a pas de contrôleur de domaine ou d’Active Directory à configurer sous Windows. La solution fonctionne sous Windows et Linux |
| Sites distants et adresse IP virtuelle | • Si les serveurs sont connectés au même réseau IP via un LAN étendu entre sites distants, l’adresse IP virtuellede SafeKit fonctionne avec la répartition de charge au niveau 2 • Si les serveurs sont connectés à des réseaux IP différents entre sites distants, l’adresse IP virtuelle peut être configurée au niveau d’un répartiteur de charge à l’aide du health check SafeKit. Ainsi, vous pouvez mettre en œuvre la répartition de charge mais aussi toutes les fonctionnalités de clustering de SafeKit, en particulier la surveillance et la reprise automatique de l’application critique sur les serveurs d’application |
| Solution de haute disponibilité uniforme | • SafeKit implémente un cluster ferme avec répartition de charge et basculement. Mais il implémente également uncluster miroir avec réplication et basculement. • Ainsi, une architecture N-tiers peut être rendue hautement disponible et à charge répartie avec la même solution sous Windows et Linux (même installation, configuration, administration avec la console SafeKit ou avec l’interface en ligne de commande). C’est unique sur le marché • Ce n’est pas le cas avec une architecture mélangeant différentes technologies pour la répartition de charge, la réplication et le basculement |
En résumé , le SafeKit Farm Cluster offre une approche unifiée et logicielle de la répartition de charge et de la haute disponibilité qui réduit considérablement la complexité et les coûts. En intégrant la répartition de charge et le basculement directement dans la couche des serveurs d’application à l’aide d’une adresse IP virtuelle standard, il évite le recours à du matériel réseau externe (répartiteurs de charge ou proxies) et à des configurations multicast spécialisées. Cette approche intégrée, combinée à sa capacité de se combiner avec le cluster miroir pour une haute disponibilité N-tiers complète, fait de SafeKit une solution d’une simplicité et d’une complétude uniques pour un déploiement applicatif évolutif et résilient dans des environnements variés.
Haute Disponibilité VM : SafeKit sans SAN vs. Hyper-V/VMware HA
Lors de la mise en œuvre de la haute disponibilité, une décision clé est de protéger au niveau de la machine virtuelle (VM) ou au niveau de l’application. La HA au niveau VM réplique et bascule des machines virtuelles entières, offrant une solution générique pour toute application. La HA au niveau applicatif cible uniquement les données et services de l’application, ce qui permet des temps de reprise plus rapides et une utilisation moindre des ressources. SafeKit offre de manière unique les deux approches — sans nécessiter de stockage partagé (SAN) dans les deux cas — vous permettant de choisir la solution la mieux adaptée à votre infrastructure et à vos exigences de reprise.
SafeKit HA VM vs HA applicative vs Hyper-V Cluster & VMware HA traditionnels
| Critère | HA VM avec module SafeKit Hyper-V ou KVM | HA applicative avec modules applicatifs SafeKit | Microsoft Hyper-V Cluster & VMware HA |
|---|---|---|---|
| Architecture | SafeKit installé dans 2 hyperviseurs. Réplication et basculement de la VM complète. | SafeKit installé dans 2 machines virtuelles ou physiques. Réplication et basculement au niveau applicatif. | Cluster d’hyperviseurs avec stockage partagé. Redémarrage de la VM sur un autre hôte si l’hyperviseur tombe en panne. |
| Stockage | Pas de disque partagé — réplication synchrone en temps réel sans perte de données | Pas de disque partagé — réplication synchrone des données applicatives uniquement | Nécessite un disque partagé et une baie de disques externe spécifique |
| Données répliquées | Réplique plus de données (application + OS) | Réplique uniquement les données applicatives | Pas de réplication — stockage partagé accessible par tous les hôtes |
| Temps de reprise | Redémarrage de la VM sur l’hyperviseur 2 si l’hyperviseur 1 tombe en panne. Temps de reprise = temps de redémarrage de la VM. Basculement si la VM tombe en panne. | Reprise rapide avec redémarrage de l’application sur le serveur 2. Environ 1 minute ou moins (voir RTO/RPO ici). Vérificateur applicatif avancé et basculement logiciel. | Redémarrage complet de la VM sur un nouvel hyperviseur. Temps de reprise = redémarrage de l’OS + démarrage de l’application. |
| Reprise après sinistre / Sites distants | Pas de SAN nécessaire — réplication intégrée à SafeKit entre sites distants | Pas de SAN nécessaire — réplication intégrée à SafeKit entre sites distants | Nécessite des baies de disques répliquées via un SAN ou vSAN |
| Configuration | Définir l’emplacement du dossier des fichiers VM où l’application est installée. Solution générique pour toute application/OS. | Définir les services à redémarrer, les dossiers applicatifs à répliquer et une adresse IP virtuelle pour le basculement dans un module applicatif. | Compétences IT spécifiques requises pour configurer le système |
| Plateformes supportées | Fonctionne avec Hyper-V et KVM (pas VMware directement, sauf en imbriquant Hyper-V ou KVM dans VMware). | Fonctionne sur toute infrastructure : serveurs physiques, machines virtuelles VMware, Hyper-V, KVM, cloud. | Limité aux environnements VMware vSphere ou Microsoft Hyper-V |
| Compétences IT | Aucune compétence IT spécifique requise. Basculement automatique. | Aucune compétence IT spécifique requise. Basculement automatique. | Compétences IT spécifiques requises pour configurer le système |
En résumé , SafeKit est la seule solution offrant à la fois la haute disponibilité au niveau VM et au niveau applicatif sans stockage partagé. Pour une flexibilité maximale et les temps de reprise les plus rapides (environ 1 minute), la HA applicative est l’approche privilégiée — elle fonctionne sur toute plateforme (physique, virtuelle ou cloud) et ne réplique que les données essentielles. Pour les environnements où protéger la VM entière est plus simple, le module Hyper-V/KVM de SafeKit offre une alternative générique sans SAN aux solutions traditionnelles Microsoft Hyper-V Cluster ou VMware HA — éliminant le coût et la complexité de l’infrastructure de stockage partagé tout en garantissant zéro perte de données grâce à la réplication synchrone en temps réel.
À noter que les solutions SafeKit sont les plus simples à mettre en œuvre mais sont limitées à la réplication de quelques téraoctets et au basculement de 32 VM.
Ressources, Téléchargements et Documentation sur la Haute Disponibilité SafeKit
💡 Pour démarrer votre parcours de haute disponibilité avec SafeKit, commencez par les Guides d’Installation Rapide.
📦 Logiciels HA SafeKit - Version 8.2
Ce tableau fournit les fichiers d’installation SafeKit pour la version actuelle, organisés par système d’exploitation et par type d’installateur.
| OS / Plateforme | Type d’installateur | Bénéfice clé / Documentation | Lien de téléchargement |
|---|---|---|---|
| Toutes plateformes | Document PDF | Bulletin officiel de version (Support OS & Correctifs) | 📄 Voir le SRB SafeKit 8.2 |
| Windows (Intel 64-bit) | Installateur .exe | Inclut Microsoft VC++ Redistributable | ⬇️ Télécharger SafeKit 8.2 Windows EXE |
| Windows (Intel 64-bit) | Installateur .msi | N’inclut pas Microsoft VC++ Redistributable | ⬇️ Télécharger SafeKit 8.2 Windows MSI |
| Linux (Intel 64-bit) | .BIN auto-extractible | Inclut le package Linux et le script d’installation | ⬇️ Télécharger SafeKit 8.2 Linux BIN (Intel) |
| Linux (ARM 64-bit) | .BIN auto-extractible | Inclut le package Linux et le script d’installation | ⬇️ Télécharger SafeKit 8.2 Linux BIN (ARM) |
🔑 Clé d’Essai HA SafeKit
Le lien suivant donne accès à une version d’essai complète conçue pour tester et configurer un cluster de Haute Disponibilité avec SafeKit.
➡️ Obtenez Votre Clé d’Essai Gratuite d'1 Mois pour Tester la Haute Disponibilité de SafeKit
📚 Guides de configuration SafeKit pour votre cluster HA
Documentation essentielle pour configurer et gérer votre cluster de Haute Disponibilité SafeKit.
- Guides d’installation rapide SafeKit
- Guide de l’utilisateur SafeKit en HTML (Version 8.2) / Télécharger le PDF
- Notes de version SafeKit en HTML (Version 8.2) / Télécharger le PDF
- Bulletin de version logicielle SafeKit 8.2 (SRB)
- Base de connaissances SafeKit
📞/🤖 Support SafeKit
🎓 Formation et Certification Gratuites sur SafeKit
Acquérez une expertise précieuse en Haute Disponibilité (HA) grâce à notre programme de certification gratuit.
ℹ️ Documentation Marketing Produit
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)
- Livre blanc – Guide de haute disponibilité (PDF)
- Référence technique pour la préparation des RFI et RFP
Bibliothèque des modules applicatifs SafeKit : solutions HA prêtes à l’emploi
Ce tableau présente les solutions de Haute Disponibilité (HA) SafeKit, classées par type d’application et environnement d’exploitation (bases de données, serveurs web, VM, conteneurs, cloud). Identifiez le module .safe préconfiguré adapté (par ex. mirror.safe, farm.safe, etc.) pour la réplication en temps réel, l’équilibrage de charge et le basculement automatique des applications métier critiques sous Windows ou Linux. Simplifiez la mise en place de votre cluster HA grâce à des liens directs vers les guides d’installation rapide.
Un module .safe SafeKit est essentiellement un modèle de Haute Disponibilité (HA) préconfiguré qui définit la manière dont une application donnée sera clusterisée et protégée par le logiciel SafeKit. En pratique, il s’agit d’un fichier zip contenant un fichier de configuration (userconfig.xml) et des scripts de redémarrage.
⚠️ Remarque : * Les modules mirror.safe et farm.safe sont inclus par défaut dans le package d’installation SafeKit.
Solutions SafeKit de Haute Disponibilité (HA) : guides d’installation rapide (avec modules .safe téléchargeables)
