eviden-logo

Evidian > Produits > SafeKit : Logiciel de haute disponibilité simple et économique > HA au niveau VM vs HA au niveau Application

HA au niveau VM vs HA au niveau Application

Evidian SafeKit

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

Comparaison entre la HA au niveau des VMs et la HA au niveau application

HA de VMs avec le module Hyper-V ou KVM de SafeKit HA d'application avec les modules applicatifs de SafeKit
SafeKit dans 2 hyperviseurs

VM HA

Réplication et reprise de VM complète

SafeKit dans 2 machines virtuelles ou physiques

Application HA

Réplication et reprise au niveau applicatif

Réplique plus de données (App+OS) Réplique seulement les données applicatives
Reboot de la machine virtuelle sur l'hyperviseur 2 si l'hyperviseur 1 crash
Temps de reprise = temps de reboot de la VM
Basculement si la VM crash
Temps de reprise rapide avec redémarrage de l'application sur OS2 en cas de panne du serveur 1
Autour d'1 mn ou moins (voir RTO/RPO ici)
Checker applicatif et reprise sur panne logicielle avancés
Définir l'emplacement du dossier des fichiers de la VM où l'application est installée. Solution générique pour n'importe quelle application / OS. Définir les services à redémarrer, les dossiers d'application à répliquer, une adresse IP virtuelle pour le basculement dans un module applicatif
La solution fonctionne avec Hyper-V et KVM mais pas avec VMware (sauf en imbriquant Hyper-V ou KVM dans VMware) La solution fonctionne dans n'importe quelle infrastructure (serveurs physiques, machines virtuelles VMware Hyper-V KVM, cloud...)

Comparaison entre SafeKit et des clusters Microsoft Hyper-V ou VMware HA

SafeKit avec le module Hyper-V ou le module KVM Microsoft Hyper-V Cluster & VMware HA
SafeKit with Hyper-V VMware HA or Hyper-V cluster
Like  Pas de disque partagé - réplication temps réel synchrone à la place avec 0 perte de données Dislike  Disque partagé et baie de disques externe spécifique
Like  Sites distants = pas de SAN pour la réplication Dislike  Sites distants = baies de disques répliquées à travers un SAN ou vSAN
Dislike  Compétence informatique spécifique pour configurer le système

Notez que les solutions SafeKit sont les plus simples à mettre en œuvre mais se limitent à la réplication de quelques téra-octets et au basculement de 32 VMs.

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 miroir SafeKit avec Windows ou Linux?

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

Le Serveur 1 (PRIM) exécute l'application Windows ou Linux. 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 Windows ou Linux

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 Windows ou Linux 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) de Windows ou Linux 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 Windows ou Linux

La reprise a lieu sans perturber l'application Windows ou Linux, 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 Windows ou Linux 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 Windows ou Linux

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.

Différentiateurs de la solution de haute disponibilité 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)