Quel est le RTO / RPO d'un cluster de haute disponibilité SafeKit ?

Evidian SafeKit

Quel est le temps de reprise (RTO) d'un cluster miroir ?

Le RTO (Recovery Time Objective) est le temps pendant lequel l'application est indisponible en cas de panne. Le RTO d'un cluster miroir de SafeKit est de l'ordre de 1 mn et peut être diminué si vous configurez le timeout des heartbeats.

Pour une panne matérielle dans un cluster miroir, RTO = timeout des heartbeats (par défaut 30 s, peut être modifié dans userconfig.xml) + délai pour redémarrer l'application.

Pour une défaillance logicielle ou un basculement administrateur, RTO = le temps d'arrêter (proprement) l'application + le temps de la redémarrer.

Avec les solutions qui redémarrent une machine virtuelle complète en cas de panne, le RTO inclut le temps de reboot de la machine virtuelle.

Quel est le temps de reprise (RTO) d'un cluster ferme ?

Le RTO (Recovery Time Objective) est le temps pendant lequel l'application est indisponible en cas de panne. Le RTO du cluster ferme de SafeKit est de l'ordre de quelques secondes sur panne matérielle.

Pour une panne matérielle, RTO = timeout sur la détection de panne via les voies de surveillance (par défaut quelques secondes) : après le timeout, les filtres de load balancing sont reconfigurés.

Pour une défaillance logicielle ou un basculement administrateur, RTO = le temps d'arrêter (proprement) l'application + le temps de la redémarrer.

Quelle est la perte de données (RPO) dans un cluster miroir ?

Le RPO (Recovery Point Objective) reflète la perte de données en cas de panne. Le RPO du cluster miroir de SafeKit est 0 car la réplication est synchrone et temps réel.

Attention, avec la réplication asynchrone, le RPO n'est pas 0 et il y a perte de données en cas de panne lorsque l'application redémarre sur le serveur secondaire.

Quelle est la perte de données (RPO) dans un cluster ferme ?

N/R. Il n'y a pas de réplication de données dans un cluster ferme.

SafeKit : une solution idéale pour une application partenaire

Cette solution indépendante de la plateforme est idéale pour un partenaire ayant une application critique et qui souhaite proposer une option de haute disponibilité simple à déployer auprès de nombreux clients.

Elle est également reconnue comme la plus simple à mettre en œuvre par nos partenaires.

Quels sont les avantages d'un cluster miroir ?

  • Faible complexité
  • Déploiement Plug & Play sans compétences spécifiques
  • Convient aux déploiements sur de nombreux sites (très simple à déployer)
  • 2 nœuds virtuels ou physiques
  • Aucune exigence de stockage partagé
  • Aucune exigence de contrôleur de domaine
  • Même solution sous Windows et Linux
  • Supporte les éditions OS Windows Server et Client
  • API et support bien documentés
  • Réplication synchrone des données (aucune perte de données en cas de panne)
  • Les répertoires répliqués peuvent être dans le disque système
  • Multiples heartbeats et adresses IP virtuelles supportés
  • Offre des checkers logiciels, matériels et réseaux configurables
  • Pour le problème de split brain et de quorum, ne nécessite pas de disque spécial ou de troisième machine ou de lien spécifique entre les 2 serveurs
  • Basculement automatique de l'application avec un temps de reprise de l'ordre d'une minute
  • Réintégration automatique d'un serveur après panne (aucune opération manuelle)
  • Une console très simple pour déployer la solution et la maintenir ensuite pour le client final
  • Supporte les défaillances du matériel et de son environnement (20% des causes d'indisponibilité), y compris la panne complète d'une salle informatique avec 2 nœuds dans deux sites distants
  • Supporte les défaillances logicielles (40% des causes d'indisponibilité) : bug logiciel, régression sur les mises à jour logicielles (les versions N et N+1 peuvent coexister)
  • Supporte les erreurs humaines (40% des causes d'indisponibilité) : la simplicité d'utilisation évite l'erreur d'administration de l'application critique

Quels sont les avantages d'un cluster ferme ?

  • Faible complexité
  • Déploiement Plug & Play sans compétences spécifiques
  • Convient aux déploiements sur de nombreux sites (très simple à déployer)
  • 2 nœuds ou plus
  • Aucune exigence sur des load balancers réseaux
  • Aucune exigence sur des serveurs proxy (au dessus du cluster ferme)
  • Aucune exigence de contrôleur de domaine
  • Aucune restriction dans VMware dûe à une adresse multicast ou unicast
  • Même solution sur Windows et Linux
  • Supporte les éditions OS Windows Server et Client
  • API et support bien documentés
  • Supporte de multiples voies de surveillance sur de multiples réseaux pour détecter la panne d'un serveur
  • Supporte de multiples adresse IP virtuelles
  • Offre des checkers logiciel, matériel et réseau configurables
  • Offre le cluster miroir avec réplication temps réel synchrone et reprise sur panne pour mettre en œuvre une architecture 3-tiers ferme+miroir
  • Basculement automatique avec un temps de reprise de l'ordre de quelques secondes
  • Réintégration automatique d'un serveur après panne (aucune opération manuelle)
  • Une console très simple pour déployer la solution et la maintenir ensuite pour le client final
  • Supporte les défaillances du matériel et de son environnement (20% des causes d'indisponibilité), y compris la panne complète d'une salle informatique avec 2 nœuds dans deux sites distants
  • Supporte les défaillances logicielles (40% des causes d'indisponibilité) : bug logiciel, régression sur les mises à jour logicielles (les versions N et N+1 peuvent coexister)
  • Supporte les erreurs humaines (40% des causes d'indisponibilité) : la simplicité d'utilisation évite les erreurs d'administration de l'application critique

Modules SafeKit pour des solutions de haute disponibilité plug&play

SafeKit Modules for Plug&Play High Availability Solutions

Partage de charge réseau et reprise sur panne

Windows farm

Linux farm

Generic farm   > Generic farm   >
Microsoft IIS   > -
NGINX   > NGINX   >
Apache   > Apache   >
Amazon AWS farm   > Amazon AWS farm   >
Microsoft Azure farm   > Microsoft Azure farm   >
Google GCP farm   > Google GCP farm   >
Other cloud   > Other cloud   >

Note :

Plusieurs modules peuvent être déployés dans le même cluster. Ainsi, des architectures de clustering avancées peuvent être mises en œuvre :

Différentiateurs de la solution de haute disponibilité SafeKit par rapport à la concurrence

Démonstrations de solutions de haute disponibilité avec SafeKit

Webinaire SafeKit

Ce webinaire présente en 2 minutes Evidian SafeKit.

Dans ce webinaire, vous comprendrez les clusters ferme et miroir de SafeKit.

Cluster Microsoft SQL Server

Cette vidéo montre la configuration d'un module miroir avec réplication temps réel synchrone et reprise sur panne.

La réplication de fichiers et le basculement sont configurés pour Microsoft SQL Server mais fonctionnent de la même manière pour d'autres bases de données.

Essai gratuit ici

Cluster Apache

Cette vidéo montre une configuration d'un module ferme avec équilibrage de charge et reprise sur panne.

L'équilibrage de charge et le basculement sont configurés pour Apache mais fonctionnent de la même manière pour d'autres services Web.

Essai gratuit ici

Cluster Hyper-V

Cette vidéo montre un cluster Hyper-V avec des réplications complètes de machines virtuelles.

Les machines virtuelles peuvent s'exécuter sur les deux serveurs Hyper-V et elles sont redémarrées en cas de panne.

Essai gratuit ici