Rares sont aujourd’hui les entreprises qui peuvent se passer de leur informatique à tel point que dans bien des cas l’inaptitude à faire face à un incident informatique peut leur être fatale. Selon une étude du cabinet de conseil américain Eagle Rock, 40% des entreprises ayant subi un arrêt de 72 heures de leurs moyens informatiques et télécoms ne survivent pas à ce désastre C’est la raison pour laquelle de plus en plus de sociétés, de toutes tailles s’attachent à mettre en place un plan de reprise d’activité ou un plan de continuité d’activité.
Au fil du temps, la signification de ces deux termes a évolué. Historiquement, le plan de continuité s’attachait à analyser l’impact potentiel d’un désastre ou d’une défaillance sur le métier de l’entreprise et à définir les moyens et procédures à mettre en place pour en limiter les conséquences. Le plan de reprise d’activité s’intéressait quant à lui aux aspects informatiques du PCA.
Pour les informaticiens, la terminologie a évolué : de plus en plus le PCA décrit l’ensemble des moyens destinés à assurer la continuité d’activité des applications, c’est-à-dire à garantir la haute disponibilité de ces applications (ce qui implique l’impossibilité d’un arrêt de ces applications même en cas de sinistre sur un site). Le PRA quant à lui décrit l’ensemble des moyens et procédures destiné à assurer une reprise rapide et ordonnée de la production après un arrêt inopiné (lié par exemple à une défaillance technique, ou énergétique, à une erreur humaine ou à un sinistre naturel). La différence entre les deux approches tend donc à se limiter à une différence en matière de temps d’indisponibilité de l’infrastructure et des applications en cas de sinistre.
PCA : objectif haute disponibilité
Dans le cadre d’un PCA, l’entreprise veille à définir les architectures, les moyens et les procédures nécessaires pour assurer une haute disponibilité des infrastructures (datacenter, serveurs, réseau, stockage) supportant l’exécution des applications de l’entreprise. L’objectif est d’assurer que quelle que soit la situation, les infrastructures mises en place garantissent aux utilisateurs un service ininterrompu.
En général, la mise en œuvre d’un PCA suppose la mise en place d’équipements redondés entre plusieurs datacenters et fonctionnant de façon conjointe de telle sorte qu’en cas de défaillance d’un élément sur le site primaire, le relais soit automatiquement pris par le site secondaire.
Typiquement, une telle architecture suppose la mise en place d’un dispositif garantissant la cohérence des données sur les baies de stockage entre le site primaire et le site secondaire, comme la solution VPLEX d’EMC qui assure la réplication transparente des données entre deux sites ainsi que la bascule automatisée des applications d’un datacenter à l’autre en cas de défaillance sur le site primaire.
Il est à noter que toutes les applications de l’entreprise ne sont pas forcément concernées par la mise en œuvre d’un PCA, simplement parce que certaines ne sont pas jugées critiques et peuvent tolérer un arrêt, ou une éventuelle perte de données. Cette criticité est à définir avec les métiers de façon à définir quel sera le périmètre du PCA et quelles applications seront concernées par un « simple PRA ». Il convient aussi de dimensionner convenablement les infrastructures pour que la bascule vers le site secondaire n’affecte pas trop les performances. Dans le cas d’une architecture en mode actif/actif, la production est en effet répartie entre les deux datacenters de l’entreprise, ce qui fait qu’un sinistre sur l’un d’entre eux se traduit mécaniquement par une diminution de moitié de la capacité de traitement disponible, donc potentiellement par une dégradation des performances sur l’infrastructure survivante.
PRA : Assurer le redémarrage ordonné en cas de défaillance
Pour les entreprises qui n’ont pas les moyens ou le besoin d’un PCA, le PRA est la solution pour assurer un redémarrage ordonné et aussi rapide que possible de l’infrastructure informatique de l’entreprise en cas d’incident. Ce redémarrage s’effectue en général sur un site de secours, propriété de l’entreprise ou fourni par un prestataire tiers. Le PRA définit les architectures, les moyens et les procédures nécessaires à mettre en œuvre pour assurer la protection des applications qu’il couvre. Son objectif est de minimiser l’impact d’un sinistre sur l’activité de l’entreprise. On distingue plusieurs modes de redémarrage : le redémarrage à chaud s’appuie sur une copie synchrone ou asynchrone des données du site principal. Il s’agit de s’appuyer sur le dernier état cohérent connu des données comme base pour les serveurs positionnés sur le site de secours. La réplication des données (qui peut être assurée par une technologie comme RecoverPoint chez EMC) assure un redémarrage rapide des serveurs de secours dans un état aussi proche que possible de celui qui a précédé le sinistre. Le RTO (Recovery Time Objective – le temps nécessaire pour remettre l’application en production – est donc minimal et le RPO (Recovery Point Objective – le temps entre le dernier état cohérent des données et le sinistre) réduit à son minimum, souvent quelques minutes.
La situation est un peu différente en cas de secours à froid. Cette situation concerne encore nombre d’entreprises ne disposant pas des moyens financiers et/ou technique pour un PCA ou pour une reprise à chaud. Dans ce cas, le redémarrage après sinistre s’appuie sur les dernières sauvegardes réalisées par l’entreprise. Ces sauvegardes peuvent dans le meilleur des cas être des répliques provenant d’un système de sauvegarde dédupliqué sur disques comme une baie Data Domain ou dans le pire scénario, une simple sauvegarde sur bande.
En cas de sinistre, l’entreprise doit donc activer son site de secours, restaurer ex-nihilo ses données depuis leur support de sauvegarde (disque ou bande) et remettre en service ses applications. Il s’agit là de la solution la plus économique pour mettre en place un PRA, mais elle a un prix en matière de RTO et de RPO. Le RTO est au minimum le temps de restauration des données et de mise en service des serveurs, ce qui pour des environnements complexes peut vouloir dire plusieurs heures voire plusieurs jours. La bonne nouvelle est que la banalisation des solutions de sauvegarde sur disque comme Data Domain a largement permis de réduire le RTO (de 17 heures à 2 heures en moyenne selon une étude IDC de 2012).
Le RPO dépend de la fréquence des sauvegardes. Dans le pire des cas, il peut atteindre un ou plusieurs jours (notamment pour les applications dont les fenêtres de sauvegarde sont longues et qui ne sont sauvegardées qu’une fois par jour, voire moins). Là encore la sauvegarde sur disques dédupliquée a amélioré la situation en réduisant les fenêtres de sauvegarde (de 11 heures avec une librairie de bandes à 3 heures en moyenne avec systèmes comme Avamar ou Data Domain).
Il est à noter que le redémarrage à froid était la règle pour nombre de PME il y a encore 5 ans. Mais la généralisation de la virtualisation et du stockage en réseau a rendu accessible le redémarrage à chaud à un nombre croissant de société. Le PCA n’est pas encore forcément à portée de tous mais il est désormais accessible à nombre de PME de taille intermédiaire. Les progrès accomplis par les baies de stockage, les solutions de sauvegarde sur disque et les technologies de virtualisation devraient le rendre accessible au plus grand nombre au cours des prochaines années.