eviden-logo

Evidian > Produits > SafeKit : Logiciel de haute disponibilité simple et économique > Solutions SafeKit sur Windows et Linux avec des modules applicatifs

Solutions SafeKit sur Windows et Linux avec des modules applicatifs

Evidian SafeKit

Solutions HA SafeKit et Guides d'Installation Rapide (avec modules .safe préconfigurés)

Comment Configurer la HA pour les Nouvelles Applications avec Réplication en Temps Réel et Basculement?


Comment Configurer la HA pour les Nouvelles Applications avec Équilibrage de Charge Réseau et Basculement?


Comment Configurer la HA pour les Services Cloud Amazon AWS?


  • AWS (Réplication en Temps Réel et Basculement - mirror.safe)
  • AWS (Équilibrage de Charge Réseau et Basculement - farm.safe)

Comment Configurer la HA pour les Services Cloud Google GCP?


  • GCP (Réplication en Temps Réel et Basculement - mirror.safe)
  • GCP (Équilibrage de Charge Réseau et Basculement - farm.safe)

Comment Configurer la HA pour les Services Cloud Microsoft Azure?


  • Azure (Réplication en Temps Réel et Basculement - mirror.safe)
  • Azure (Équilibrage de Charge Réseau et Basculement - farm.safe)

Comment fonctionne la configuration d'un cluster avec des modules applicatifs

Simplicité de configuration d'un cluster SafeKit avec des modules de haute disponibilité

Avec le logiciel SafeKit, la configuration d'un cluster de basculement est très simple. Il faut configurer soit un module applicatif ferme, soit un module applicatif miroir suivant l'architecture de haute disponibilité adaptée à l'application critique à sécuriser.

Modules applicatifs

Un module applicatif inclut :

  1. les scripts start et stop de l'application pour réaliser automatiquement son basculement dans le cluster,
  2. le fichier de configuration userconfig.xml qui contient :
    • les noms ou les adresses IP physiques des serveurs dans le cluster,
    • le nom ou l'adresse IP virtuelle du cluster pour le basculement automatique d'une adresse IP,
    • les répertoires de fichiers pour la réplication temps réel de données entre les 2 serveurs d'un module miroir,
    • les critères de load balancing entre les N serveurs d'un module ferme,
    • la configuration des détecteurs de panne logicielles et matérielles.

Simplicité de déploiement d'un cluster de basculement

Une fois un module applicatif configuré et testé, le déploiement d'un cluster de basculement avec le logiciel SafeKit ne requiert pas de compétence informatique spécifique :

  1. installer l'application sur 2 serveurs standards Windows ou Linux,
  2. installer le logiciel SafeKit sur 2 serveurs,
  3. installer le module applicatif sur 2 serveurs,
  4. configurer les nouveaux noms (ou adresses IP) des serveurs et le nouveau nom (ou adresse IP virtuelle) du cluster,
  5. démarrer le cluster.

La configuration est simplifiée grâce à une console web.

SafeKit : Haute Disponibilité (HA) et Choix de Redondance

Quels sont les deux principaux choix pour garantir la haute disponibilité et la redondance ?

Vous pouvez choisir entre la mise en place de la redondance :

  • Au niveau de l’application
  • Au niveau de la machine virtuelle (VM)

Qu’est-ce que la « Redondance au niveau de l’application » ?

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.

Diagramme SafeKit pour la Haute Disponibilité (HA) au niveau de l’application : illustre la réplication synchrone des données critiques de l’application entre serveurs actif et passif, permettant un basculement rapide sans redémarrage complet de la VM.

Exigences techniques :

  • Nécessite une compréhension technique de l’application elle-même.
  • Vous devez définir manuellement :
    • Quels services doivent être redémarrés.
    • Les dossiers spécifiques de l’application à répliquer en temps réel.
    • La configuration d’une adresse IP virtuelle pour le basculement.

Compatibilité plateforme :

  • Cette solution est indépendante de la plateforme.
  • Elle fonctionne sur des machines physiques, des machines virtuelles ou dans le Cloud.
  • Tous les hyperviseurs sont pris en charge (ex. : VMware, Hyper-V, etc.).
  • Plus d’informations : Windows, Linux

Qu’est-ce que la « Redondance au niveau de la machine virtuelle (VM) » ?

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.

Diagramme SafeKit pour la Haute Disponibilité (HA) au niveau de la VM : illustre la réplication complète de la VM, incluant l’OS et l’application, entre deux serveurs physiques pour assurer la continuité de service en cas de panne matérielle.

Principaux avantages :

  • Ne nécessite pas de compréhension technique de l’application installée dans la VM.
  • C’est la meilleure solution si vous ne connaissez pas le fonctionnement de l’application.
  • Vous devez seulement définir l’emplacement des fichiers de la VM.

Compatibilité plateforme :

  • Cette solution fonctionne avec Windows/Hyper-V et Linux/KVM.
  • Elle ne prend pas en charge VMware pour ce type de redondance.
  • C’est généralement une solution active/active où plusieurs machines virtuelles peuvent être répliquées et redémarrées entre deux nœuds.
  • Plus d’informations : Windows/Hyper-V, Linux/KVM

Comment fonctionne le cluster miroir SafeKit?

Étape 1. Réplication en temps réel

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.

Réplication de fichiers au niveau octet dans un cluster miroir

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.

Étape 2. Bascule automatique (failover)

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.

Bascule (failover) dans un cluster miroir

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.

Étape 3. Reprise automatique (failback)

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é.

Reprise (failback) dans un cluster miroir

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

Étape 4. Retour à la normale

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.

Retour au fonctionnement normal dans un cluster miroir

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.

Utilisation typique avec 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

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.

Comment fonctionne le cluster ferme de SafeKit ?

Adresse IP virtuelle dans un cluster feme

Equilibrage de charge et haute disponibilité

Sur la figure précédente, l'application tourne 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 de la ferme.

Le trafic du réseau à destination de l'adresse IP virtuelle est reçu par l'ensemble des serveurs. Puis ce trafic est distribué entre les serveurs grâce à un filtre réseau chargé dans le noyau du système d'exploitation de chaque serveur.

SafeKit détecte les pannes matérielles et logicielles, reconfigure les filtres réseau en cas de panne et offre des checkers et des scripts de reprise applicatifs configurables.

Partage de charge dans un filtre réseau

L'algorithme de load balancing dans le filtre réseau est basé sur l'identité des paquets client (adresse IP client, port TCP client). Suivant l'identité du paquet client en entrée, seul un filtre dans un serveur accepte le paquet ; les autres filtres dans les autres serveurs le rejettent.

Une fois un paquet 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 retour de l'application sont envoyés directement du serveur vers le client.

Lorsqu'un serveur est défaillant, le protocole de gestion du groupe des serveurs en vie reconfigure les filtres pour redistribuer le trafic vers les serveurs disponibles.

Applications à état et sans état

Avec une application à état, il y a affinité de session. Le même client doit être connecté sur le même serveur sur plusieurs sessions TCP pour retrouver son contexte sur le serveur. Dans ce cas, la règle de load balancing SafeKit est configurée sur l'adresse IP des clients. Ainsi, le même client est toujours connecté sur le même serveur sur plusieurs sessions TCP. Et différents clients sont répartis sur les différents serveurs de la ferme.

Avec une application sans état, il n'y a pas d'affinité de session. Le même client peut être connecté sur des serveurs différents dans la ferme lors de sessions TCP successives. Dans ce cas, la règle de load balancing SafeKit est configurée sur l'identité de la session TCP du client. Cette configuration est celle qui répartit le mieux les sessions entre les serveurs mais elle requiert un service TCP sans affinité de session.