Services de DR dans le Cloud : l’alternative

La protection des données est un besoin vital pour assurer la disponibilité des informations et se protéger d’un éventuel sinistre. Les données requièrent la mise en œuvre de processus efficaces assurant leur disponibilité dans les meilleures conditions. Le coût de l’indisponibilité d’un système peut en effet se chiffrer en milliers voire en dizaines de milliers d’euros par heure selon le type et la taille de l’organisation. Et si l’indisponibilité se prolonge au-delà de quelques jours, elle peut même mener à la disparition de l’entreprise.

Historiquement, la reprise après sinistre (ou Disaster Recovery) était vue comme un processus de dernier recours. On ne pressait le bouton que si la société avait vécu un sinistre majeur (comme cela a par exemple été le cas dans les années 80 lors de l’incendie du siège du Crédit Lyonnais).

Le modèle historique de la reprise après désastre reposait sur la sauvegarde des données sur bande et sur l’externalisation de ces bandes sur un site de secours distant. Ce modèle était synonyme de temps de reprise assez longs (souvent comptés en jours), puisque les bandes devaient être extraites de leur stockage, remontées puis restaurées avant que la production informatique ne puisse reprendre.

Les organisations les plus sophistiquées utilisaient un site de secours proche sur lequel leurs données les plus critiques étaient répliquées (via un protocole comme SRDF) ou faisaient appel aux services de spécialistes du PRA comme Sungard AS ou IBM Resiliency Services (ex-BCRS). Ces modèles avaient toutefois l’inconvénient d’être extrêmement coûteux.

La montée en puissance de la virtualisation et du cloud a permis de démocratiser les services de reprise après désastre et surtout a mis à la portée du plus grand nombre les services de continuité d’activité ou du moins d’amélioration de la disponibilité.

Avec ces services, tout ou partie de la production informatique peut reprendre à la demande dans le cloud en cas d’incident. Cette reprise peut s’effectuer de façon automatisée ou de façon manuelle selon le niveau de sophistication du SI et selon le niveau du service souscrit. Dans certains cas, il est d’ailleurs plus approprié de parler de continuité d’activité que de reprise après désastre, l’interruption de service pouvant être minimale.

Logiciels pour la conduite d’une activité BIA (Business impact analysis)

La mise en œuvre des services de Disaster Recovery en cloud est rendue d’autant plus simple que les applications modernes sont par nature distribuées et s’appuient sur des infrastructures qui sont largement virtualisées. Cela a sensiblement modifié la façon dont les entreprises opèrent leurs sauvegardes et leur donne surtout plus de flexibilité pour restaurer tout ou partie de leur informatique si nécessaire.

Avec un service de reprise en cloud, les entreprises peuvent :

• Assurer la continuité d’exploitation de leurs services applicatifs quel que soit l’endroit depuis lequel ils sont délivrés.
• Basculer de façon tactique certaines applications vers le cloud en cas de défaillance logicielle ou matérielle affectant tout ou partie de leur production.
• Basculer de façon contrôlée certaines applications vers le service de reprise le temps de réaliser des opérations de maintenance affectant l’infrastructure « on premise » (par exemple la mise à jour de l’infrastructure réseau, ou la migration d’une baie de stockage ancienne vers un modèle plus récent).
• Transférer des applications vers le cloud pour faire face à un pic d’activité imprévu ou à une demande non planifiée.
• Tester les capacités de reprise après désastre à la demande sans impact sur le fonctionnement du système primaire.

Bien sûr l’objectif principal de la continuité d’activité et de la reprise après désastre reste de satisfaire les impératifs de l’entreprise en matière de SLA et d’objectifs de disponibilité des applications métiers.

Cela veut dire que le service de reprise après sinistre doit être capable de répondre aux objectifs spécifiques de RTO (Recovery Time Objectives) et de RPO (Recovery Point Objectives) définis pour chaque application.

Selon les contraintes de RTO/RPO de l’entreprise, on peut distinguer trois grandes catégories de services de reprise après désastre dans le cloud :

Protection des seules données : le processus de reprise se concentre essentiellement sur la sauvegarde et vise à s’assurer qu’il existe toujours dans le cloud une copie récente des données du site primaire « on premise » que l’on puisse utiliser pour reprendre la production en cas de sinistre. En cas de désastre, les données sont accessibles depuis le service cloud. Seul souci, en cas de sinistre, le temps de reprise peut être excessivement long en fonction de la quantité de données qu’il faudra restaurer vers le site « on premise ».

Il est donc recommandé pour ce type de service de s’assurer que l’on dispose de la bande passante réseau nécessaire dans une fenêtre de temps acceptable, ou de vérifier que le fournisseur de services cloud est à même de produire une copie sur support physique que l’on pourra faire livrer via un service de coursier rapide.

Protection basée sur les applications : le processus de DR se concentre sur la réplication des données applicative vers le cloud afin d’alimenter une instance secondaire de l’application. Les données sont migrées via un processus natif à l’application ou via un produit tiers. En cas de sinistre, la bascule consiste simplement en une bascule vers l’instance applicative dans le cloud (typiquement via une bascule DNS). Cette dernière s’appuie alors sur les données reçues en flux continu depuis l’instance primaire défaillante.

Image de VM : Le processus de DR réplique des images complètes des VM sur une base régulière. Cette copie est dormante et n’est activée qu’en cas de défaillance de la VM principale. Là encore, la bascule requiert typiquement une bascule DNS. Le mécanisme d’image de VM peut aussi être utilisé en mode bare metal typiquement via un logiciel de backup ou de P2V.

Les paramètres à surveiller

Bien sûr, basculer tout ou partie de sa production dans le cloud n’est pas sans écueil. Tout d’abord, le réseau reste en général un point à surveiller.

Bande passante réseau : Il faut s’assurer que l’on dispose de la bande passante nécessaire pour répliquer les données du site primaire dans des conditions acceptables (sous peine d’affecter le RPO). De même il faut suffisamment de bande passante pour effectuer un fail-back vers le site primaire, une fois que celui-ci est de nouveau opérationnel.

Sécurité réseau : la sécurité est un autre enjeu à surveiller. Les données dans le cloud seront la plupart du temps hors du périmètre de l’entreprise, donc il faut a minima s’assurer qu’elles seront chiffrées de façon appropriée pendant le transfert. Les impératifs de conformité peuvent aussi imposer l’hébergement dans un site répondant à des impératifs réglementaires (certifications PCI-DSS pour une application de paiement par exemple) et il peut être nécessaire de s’assurer que les données sont chiffrées sur le site de destination.

Adressage Réseau : il faut s’assurer que les utilisateurs peuvent accéder de façon transparente aux applications migrées vers le cloud. En particulier, le fait que la migration se traduit par un changement de plan d’adressage, ce qui requièrent a minima que le DNS de l’entreprise fournisse les informations nécessaires pour permettre l’accès aux instances dans le cloud.

Latence réseau : surveiller et gérer la latence réseau est un autre point crucial. Faire tourner tout ou partie d’une application dans le cloud du fait de la défaillance d’un composant ou d’une partie significative de l’infrastructure primaire peut se traduire par des impacts sur la latence et donc sur la performance des applications.

Licences logicielles : selon les termes de licence de l’éditeur d’applications, il faut prévoir des licences additionnelles. Parfois les conditions rendent l’utilisation d’un mécanisme de DR en cloud impossible.

Tout ceci nous amène indirectement à la question du coût d’une solution de DR en mode cloud.

Le coût global d’une telle solution inclut la fourniture du service cloud (stockage, hébergement des VM), le coût de la bande passante, et le coût des licences de logiciels (à la fois celui des applications et des logiciels utilisés pour gérer la bascule des données). Tous ces coûts doivent être inventoriés de façon exhaustive si l’on veut évaluer avec précision le coût global et éviter les mauvaises surprises.

En particulier, il faudra sélectionner avec prudence le type de stockage cloud utilisé pour le DR, tant pour des raisons de performances que de coûts (pour ceux qui envisagent d’utiliser Amazon, le transfert en masse de données d’Amazon S3 vers le site primaire en cas de fail-back est en particulier à étudier avec une très grande prudence !).

Bâtir sa propre solution ou choisir une offre clef en main

La dernière question est de savoir si l’on construit soit même sa solution de DR en cloud ou si l’on s’appuie sur un service tiers clef en main.

Pour une PME, il est possible de construire des solutions économiques avec des solutions comme Veeam, Acronis ou ArcServe. Mais des solutions plus sophistiquées devront sans doute être utilisées pour des implémentations complexes.

Par exemple, dans certains cas la seule intervention des équipes infrastructure ne peut être suffisante et les équipes applicatives doivent être impliquées dans le plan de DR. C’est le cas pour certaines bases de données, pour lesquels les processus de fail-over et de fail-back doivent être pilotés par le DBA (à moins que l’on mette en œuvre des applications spécifiques de disponibilité comme DoubleTake).

En général, les outils de réplication en mode bloc peuvent générer une image « crash consistent » d’une application qui peut être utilisée pour ressusciter une application dans le cloud. Mais encore faut-il pouvoir tester régulièrement que les images générées sont viables. Nombre de produits embarquent aujourd’hui des fonctions automatisées de test des images répliquées dans le cloud (c’est le cas de produits comme Veeam ou ArcServe, pour ne citer qu’eux). Et ces tests peuvent être réalisés de façon isolée sans impact sur la production.

Comparer les services DR en Cloud

Au final, quelques éléments doivent impérativement être étudiés lorsque l’on envisage d’utiliser ou de bâtir un service de DR dans le cloud.

Côté coûts, il faut analyser avec précision la façon dont le tout est facturé (quel coût pour le stockage, pour la bande passante, pour les VM). Il est ensuite impératif d’analyser les implications de la mise en place d’une solution de DR sur les licences logicielles.

Enfin, il faut valider que les applications sont éligibles à un DR dans le cloud et que les impératifs de sécurité de l’entreprise seront satisfaits.