Que sont les RPO et les RTO ? Définitions, exemples et stratégies HA

Qu'est-ce que la Haute Disponibilité ?

La Haute Disponibilité (HA) est une architecture technique conçue pour garantir qu'un système reste opérationnel et accessible pendant un pourcentage de temps spécifié (par exemple, 99,99 %).

Pour atteindre les objectifs RPO et RTO définis dans un Plan de Continuité d'Activité (PCA), la haute disponibilité est généralement mise en œuvre via deux architectures principales :

• Système à disques partagés via un SAN : Un cluster traditionnel où 2 nœuds sont connectés à un réseau de stockage centralisé (SAN). Si un nœud tombe en panne, le second prend le relais pour accéder aux données partagées.
• Réplication synchrone sans SAN (SANless) : Une architecture moderne de type "shared-nothing" — mise en œuvre par le logiciel SafeKit — où les données sont répliquées en temps réel entre les disques locaux de 2 nœuds indépendants, éliminant ainsi le besoin d'un SAN.

Quel est le RPO d'une solution de Haute Disponibilité ?

Le RPO (Recovery Point Objective) définit le volume maximal de perte de données tolérable mesuré en temps. Pour une véritable solution de haute disponibilité, l'objectif de RPO est zéro.

Lors de la mise en œuvre d'un cluster de haute disponibilité avec basculement automatique, un RPO zéro garantit que l'application redémarre sans aucune perte de données.

• Système à disques partagés via un SAN : Étant donné que les deux nœuds accèdent aux mêmes blocs physiques de données, il n'y a pas de décalage (lag) entre les nœuds, ce qui assure une cohérence totale des données lors d'un basculement.
• Réplication synchrone logicielle : Une approche sans SAN (SANless) où chaque opération d'écriture est répliquée en temps réel sur le réseau. L'application ne reçoit un acquittement d'écriture que lorsque la donnée est sécurisée sur les deux nœuds. Ce processus de "double écriture" synchrone garantit zéro perte de données, même en cas de panne du serveur primaire.

Quel est le RTO d'une solution de Haute Disponibilité ?

Le RTO (Recovery Time Objective) représente la durée maximale tolérable d'indisponibilité après une interruption de service. Dans le contexte de la haute disponibilité, le RTO doit être minimal pour garantir un accès continu aux applications critiques.

Pour atteindre un RTO faible, une solution de haute disponibilité utilise le basculement automatique (failover) pour détecter les pannes matérielles ou logicielles et redémarrer l'application immédiatement. Dans un cluster de haute disponibilité classique, le RTO est d'environ une minute, calculé comme suit :

• Temps de détection de la panne : L'intervalle nécessaire au système pour identifier la perte du signal de vie (heart-beat) d'un nœud ou d'une application.
• Temps de redémarrage automatique : Le temps nécessaire pour que les services applicatifs s'initialisent sur le nœud survivant.

Qu'est-ce qu'une solution de sauvegarde ?

Une solution de sauvegarde est une stratégie de protection des données conçue pour créer des copies périodiques des données sur un dispositif de stockage secondaire ou dans le cloud. Contrairement à la Haute Disponibilité, la sauvegarde se concentre sur la rétention de données à long terme et la récupération après une corruption de données ou un sinistre majeur à l'échelle d'un site.

Pour répondre aux objectifs RPO et RTO définis dans un Plan de Reprise d'Activité (PRA), la sauvegarde est généralement mise en œuvre via deux méthodes principales :

• Snapshots programmés (Instantanés) : Un processus où des copies de données à un instant T sont effectuées à intervalles fixes (ex: quotidiennement). Cela définit le RPO, car toute donnée modifiée entre le dernier snapshot et la panne est perdue.
• Récupération hors site ou Cloud : Une architecture où les données sont stockées dans un emplacement physique distinct. Bien que cela garantisse la survie des données, cela entraîne un RTO plus élevé car les données doivent être transférées et restaurées avant que l'application ne puisse redémarrer.

Quel est le RPO d'une solution de sauvegarde ?

Le RPO (Recovery Point Objective) dans un contexte de sauvegarde définit l'ancienneté des fichiers qui doivent être récupérés depuis le stockage pour que les opérations normales reprennent. Contrairement à la haute disponibilité, une solution de sauvegarde implique généralement un RPO non nul, représentant le temps écoulé depuis la dernière sauvegarde réussie.

Le volume de perte de données dans une stratégie de sauvegarde est déterminé par la fréquence des sauvegardes. Selon l'architecture, ce RPO peut varier de quelques minutes à 24 heures :

• Snapshots incrémentaux : Une méthode où seuls les blocs de données modifiés sont enregistrés à intervalles définis. Si une sauvegarde est effectuée toutes les 4 heures, le RPO maximum est de 4 heures, ce qui signifie que toute donnée créée entre le dernier snapshot et le crash du système est définitivement perdue.
• Sauvegardes complètes quotidiennes : Une approche traditionnelle où une copie complète des données est réalisée une fois par jour (généralement la nuit). Cela entraîne un RPO de 24 heures, ce qui peut être acceptable pour des données non critiques mais est souvent insuffisant pour des bases de données transactionnelles.

Quel est le RTO d'une solution de sauvegarde ?

Le RTO (Recovery Time Objective) dans une stratégie de sauvegarde est la durée nécessaire pour restaurer les données depuis un support de sauvegarde et remettre l'application en état de fonctionnement. Contrairement à la haute disponibilité, le RTO pour la sauvegarde est nettement plus long car il implique des processus de restauration manuels ou scriptés.

Pour une solution de sauvegarde, le RTO peut varier de plusieurs heures à plusieurs jours, selon le volume de données et l'architecture de récupération. Le temps d'arrêt total est calculé comme suit :

• Temps de transfert des données : Le temps nécessaire pour déplacer les données du stockage de sauvegarde (disques locaux, bandes ou cloud) vers le serveur de production.
• Temps de reconfiguration du système : L'intervalle nécessaire pour intégrer les données dans l'application, reconstruire les index et vérifier l'intégrité des données avant que les utilisateurs ne puissent se reconnecter.

Qu'est-ce que le Cluster Miroir SafeKit ?

Le Cluster Miroir SafeKit est une solution de haute disponibilité logicielle qui met en œuvre une architecture de type « shared-nothing » (sans partage de ressources). Contrairement aux clusters traditionnels qui nécessitent un SAN coûteux, SafeKit utilise les ressources locales de deux serveurs standards pour créer un environnement hautement résilient.

Pour garantir une disponibilité maximale et la protection des données au sein de votre Plan de Continuité d'Activité (PCA), le cluster miroir SafeKit fonctionne via deux mécanismes intégrés :

• Réplication synchrone en temps réel : SafeKit réplique les données sur le réseau entre les disques locaux des nœuds primaire et secondaire. Cela garantit un RPO de zéro, car chaque octet de donnée est sécurisé sur les deux serveurs avant qu'une transaction ne soit finalisée.
• Basculement automatique de l'IP et de l'application : Si le nœud primaire tombe en panne, SafeKit détecte automatiquement la perte du signal de vie (heartbeat) et bascule l'application ainsi que son adresse IP virtuelle sur le nœud secondaire. Cela se traduit par un RTO d'environ une minute, offrant une continuité de service transparente.

Quel est le RPO d'un Cluster Miroir SafeKit ?

Le RPO d'un cluster miroir SafeKit est de zéro car la réplication des données entre les nœuds est synchrone et en temps réel.

Cette garantie de zéro perte de données est obtenue grâce à un processus d'acquittement d'écriture : une écriture sur disque n'est confirmée à l'application qu'une fois qu'elle a été effectuée avec succès sur les disques locaux des nœuds primaire et secondaire.

En revanche, avec une réplication asynchrone, le RPO est supérieur à zéro. Comme il existe un délai entre l'écriture primaire et la mise à jour secondaire, une panne entraînera une perte de données lors du basculement vers le serveur secondaire. Pour une Continuité d'Activité critique, la réplication synchrone est le seul moyen de garantir que l'application redémarre avec une intégrité des données de 100 %.

Quel est le RTO d'un Cluster Miroir SafeKit ?

Dans une configuration standard, le RTO d'un cluster miroir SafeKit est d'environ une minute. SafeKit offre la flexibilité de mettre en œuvre la haute disponibilité soit au niveau applicatif, soit au niveau VM, chacun impactant le temps de reprise différemment :

• HA au niveau applicatif : C'est l'approche optimisée de SafeKit où le logiciel surveille des services applicatifs spécifiques.
  • Panne matérielle : RTO = timeout du heartbeat (30s par défaut) + temps de redémarrage de l'application.
  • Panne logicielle : RTO = temps d'arrêt de l'application + temps de redémarrage de l'application.
  • Avantage clé : Comme le système d'exploitation est déjà en cours d'exécution sur le nœud secondaire, il n'y a pas de délai de boot de l'OS, ce qui permet la reprise la plus rapide pour la Continuité d'Activité.
• HA au niveau VM : Dans ce scénario, SafeKit protège l'ensemble de l'environnement de la machine virtuelle.
  • Reprise sur panne : RTO = détection de la panne + temps de reboot de l'OS + temps de redémarrage de l'application.
  • Compromis technique : Le RTO est naturellement plus long (plusieurs minutes) car le nœud secondaire doit effectuer un démarrage à froid complet du système d'exploitation avant même que l'application puisse commencer à s'initialiser.

En utilisant la haute disponibilité au niveau applicatif, SafeKit élimine la « pénalité de redémarrage » inhérente à la virtualisation standard, garantissant que votre Plan de Continuité d'Activité (PCA) atteigne le temps d'indisponibilité le plus bas possible.

Qu'est-ce que le Cluster Ferme SafeKit ?

Le Cluster Ferme SafeKit est une solution de haute disponibilité logicielle conçue pour les applications sans état (comme les serveurs web) qui nécessitent à la fois scalabilité et redondance. Contrairement à un cluster miroir qui se concentre sur la réplication de données, un cluster ferme distribue le trafic entrant sur plusieurs nœuds actifs.

Pour maintenir la Continuité d'Activité dans des environnements à fort trafic, le cluster ferme SafeKit fonctionne via deux mécanismes clés :

• Équilibrage de charge réseau (Load Balancing) : SafeKit utilise une adresse IP virtuelle pour répartir le trafic réseau entrant sur une « ferme » de plusieurs serveurs actifs. Cela garantit qu'aucun serveur n'est saturé et maximise les performances de l'application.
• Détection automatique de pannes et reconfiguration : Si un nœud de la ferme tombe en panne, SafeKit détecte la défaillance via des signaux de vie (heartbeats) et redistribue immédiatement son trafic entre les nœuds sains restants. Cela offre un RTO quasi nul pour le service global, car les autres nœuds sont déjà actifs et prêts à absorber la charge.

Quel est le RPO d'un Cluster Ferme SafeKit ?

Le RPO (Recovery Point Objective) pour un Cluster Ferme SafeKit est généralement considéré comme Non Applicable (N/A). En effet, un cluster ferme est spécifiquement conçu pour des applications sans état (stateless) où les données ne sont pas stockées localement sur les nœuds.

Étant donné qu'un cluster ferme se concentre sur l'équilibrage de charge réseau plutôt que sur la synchronisation des données, il n'y a pas de réplication de données entre les nœuds au sein du cluster lui-même. Dans un Plan de Continuité d'Activité (PCA) typique impliquant une architecture en ferme :

• Opérations sans état : Tous les nœuds de la ferme sont identiques et ne détiennent pas de données persistantes ; par conséquent, il n'y a pas de « perte de données » à mesurer lors de la panne d'un nœud.
• Stockage de données externe : Si l'application nécessite une persistance des données, celle-ci est généralement gérée par un Cluster Miroir SafeKit distinct en arrière-plan (backend), où le RPO serait alors de zéro.

Quel est le RTO d'un Cluster Ferme SafeKit ?

Dans une architecture en ferme (farm), le RTO est réduit à seulement quelques secondes car tous les nœuds sont généralement actifs simultanément. Le temps de reprise est déterminé par la vitesse à laquelle le cluster reconfigure sa distribution de trafic :

• Panne matérielle : Le RTO est égal au timeout de détection de panne via les canaux de surveillance (quelques secondes par défaut). Une fois la perte du heartbeat détectée, les filtres d'équilibrage de charge de l'IP virtuelle sont automatiquement reconfigurés pour rediriger le trafic vers les nœuds sains restants.
• Panne logicielle ou redémarrage planifié : Le RTO est calculé comme la somme du temps d'arrêt de l'application et du temps de redémarrage de l'application sur ce nœud spécifique, période pendant laquelle les autres nœuds de la ferme continuent de gérer l'intégralité du trafic entrant.

Ce mécanisme « Actif-Actif » garantit que pour les services sans état, l'impact sur la Continuité d'Activité est presque imperceptible pour l'utilisateur final, car il n'est pas nécessaire d'initialiser le service sur un nouveau nœud en attente (standby).