skip to Main Content
01 83 79 95 95 contact@voxy.fr

RTO / RPO : quels moyens faut-il pour tenir ces objectifs ?

LOUPELorsqu’il s’agit de plan de reprise ou de continuité, il convient de ne pas aborder seulement les aspects techniques, mais également les dimensions organisationnelles.

Pour commencer rappelons les définitions :

RTO : Recovery Time Objective ou Temps de Rétablissement

RPO : Recovery Point Objective ou Point de Rétablissement.

Satisfaire l’objectif de Temps de Rétablissement (RTO) implique :

  • de détecter très tôt un incident grave et décider rapidement le déclenchement du plan de reprise → information des décideurs et diffusion des procédures,
  • de disposer de copies à jour des systèmes sur disque permettant un redémarrage quasi-immédiat des applications.

Satisfaire l’objectif de Point de Rétablissement (RPO=x)  implique :

  • de disposer de copies à jour des données datant de moins de x heures,
  • de pouvoir recharger ces données dans un délai compatible avec l’objectif RTO.

Lorsqu’un incident survient, il est essentiel de garder à l’esprit que la résolution de celui-ci peut parfois prendre plus de temps que fixé par l’objectif RTO. Il convient donc :

  • de disposer d’un système efficace de remontée d’alertes,
  • d’être organisé pour traiter ces alertes à coup sûr !
  • d’anticiper éventuellement la mise en service des moyens de secours,
  • de ne pas s’acharner à résoudre à tout prix l’incident s’il est plus rapide de s’appuyer sur ces moyens de secours.

Il est donc primordial de décider de déclencher le plan de reprise au bon moment, c’est-à-dire avant qu’il ne soit trop tard pour respecter l’objectif de délai de reprise. Si les moyens de secours sont dissociés des moyens normaux de production, il est parfaitement possible, et même recommandé, de poursuivre la recherche d’une solution sur l’environnement nominal, et en cas de succès d’abandonner le plan de reprise en cours de route.

On relève sur le graphique ci-dessus (durées indicatives pour un RTO de 12 heures) que les phases de détection, de diagnostic et de décision représentent des durées significatives qui peuvent retarder considérablement la reprise d’activité (fail-over). Les temps de démarrage, de rechargement des données et de tests étant incompressibles (pour une architecture donnée), les intervenants doivent impérativement être mobilisés et formés pour que l’objectif puisse être tenu. Dans cet exemple, la décision de déclencher le plan de reprise doit être prise au plus tard 2 heures après détection de l’incident. Si, à ce moment, le diagnostic reste inconnu ou incertain, il est préférable de procéder au plus tôt au démarrage des moyens de secours pendant que l’on poursuit les investigations. Même si les spécialistes affirment que l’incident peut être résolu avant 12 heures, cette résolution peut échouer ; il vaut donc mieux poursuivre les opérations de reprise jusqu’à résolution complète de l’incident.

Pour que ces moyens soient opérationnels le moment venu, les exploitants doivent les prendre en compte dans la plupart de leurs actions :

  • tous nouveaux matériels et toutes nouvelles applications doivent être mis sous surveillance avec remontée d’alertes,
  • toute modification apportée à un système (autres que des données) doit être aussitôt reportée sur le système de secours, et doit être compatible avec la remise en service des moyens de production normaux (fail-back),
  • toute augmentation importante des volumes de données doit faire l’objet d’une étude pour vérifier qu’elle reste compatible avec les moyens de secours et les temps de rechargement, (inversement la réduction de ces volumes peut parfois être répercutée sur les moyens de secours et sur le délai imparti aux investigations avant décision de déclenchement du plan de reprise),
  • des tests fréquents doivent être effectués pour s’assurer que les moyens de secours et les rechargements fonctionnent.

Pour un objectif RTO très court (inférieur à 4 heures voire à 1 heure), on aura nécessairement recours à des architectures techniques permettant de raccourcir voire d’annuler :

  • les temps de démarrage : virtualisation, systèmes en stand-by*, en haute disponibilité** ou en load balancing***,
  • les temps de rechargement des données : réplications asynchrones, synchrones.
(*) stand-by : systèmes de secours recevant les données en continu, prêts à redémarrer sans délais
 
(**) haute disponibilité : systèmes capables de détecter automatiquement les défaillances et de redémarrer la production en moins de 5 mn
 
(***) load balancing : systèmes coactifs se partageant la charge, en cas de défaillance d’un système, la productiuon continue sur les autres systèmes sans interruption de service
Back To Top
Rechercher