« Toute chose a des défaillances, tout le temps. » Werner Vogels, CTO d'Amazon.
Les choses et les humains ont des défaillances
Ouragans, mises à jour de BIOS, tremblements de terre, défaillances DNS, certificats SSL, orages électriques... Tous ces éléments ont été responsables des dernières grosses pannes du cloud (et également des infrastructures traditionnelles de centres de données). Qu'ont-ils en commun ?
Malchance ? Mauvaises pratiques ? Conséquences ?
Peut-être, mais ils nous apprennent en tout cas que nous avons vraiment besoin d'un « Plan B ».
Si le cœur de nos activités se trouve sur le net, nous avons besoin d'une infrastructure qui résiste aux sinistres et qui nous permette de rester en ligne (ou de récupérer la connexion) dans un laps de temps défini comme viable dans notre plan de continuité d'activité.
Nous avons déjà parlé des architectures cloud résistantes aux pannes qui affectent un continent entier. Nous nous concentrerons maintenant sur la reprise après sinistre et ses différents aspects. Avant d'aborder la partie technique, révisons certains concepts fondamentaux :
Termes et définitions
La reprise après sinistre est juste un aspect, un petit sous-ensemble du plan de continuité d'activité général. Elle représente l'ensemble des processus et des procédures qui assurent la continuité de l'infrastructure technologique indispensable à une entreprise en cas de catastrophe majeure (catastrophe naturelle ou d'origine anthropique).
Le plan de continuité de l'activité se réfère généralement à la gestion et à la planification de la continuité opérationnelle minimale en cas d'événements perturbateurs, alors que la reprise après sinistre se concentre seulement sur les fonctions informatiques.
La sauvegarde est simplement le processus de stockage ayant le double objectif de récupération des données en cas de perte et de retour à une version antérieure. Étant donné que la sauvegarde ne comprend que les données et pas l'infrastructure informatique, elle doit être considérée comme une simple composante de la reprise après sinistre.
L'objectif de la reprise après sinistre est de récupérer l'infrastructure et les données en réalisant deux objectifs définis dans le plan de continuité d'activité :
- L'objectif de temps de récupération (RTO) est le temps maximal admissible au terme duquel les opérations doivent être restaurées à un niveau normal ou réduit après un sinistre (ou une interruption), dans le but d'éviter des conséquences indésirables liées à un arrêt.
- La perte de données maximale admissible (PDMA) est la quantité maximale admissible de données perdues après un incident non planifié, exprimée en unités de temps.
- La haute disponibilité est, en substance, une reprise après sinistre où le RTO et la PDMA sont égales à zéro. Dans ce cas nous pouvons la définir comme une disponibilité continue. En fonction de notre plan de continuité de l'activité, cela peut constituer une condition sine qua non.
Modèles architecturaux
Nous allons faire la liste des modèles architecturaux les plus fréquents pour la mise en œuvre de la reprise après sinistre, classés par un RTO décroissant, tout en comparant la méthodologie traditionnelle avec celle que rend possible le cloud computing en général et Amazon Web Services en particulier.
Sauvegarde et restauration
Un sinistre peut impliquer l’achat/la location d’un nouveau hardware dans un centre de données différent afin de restaurer nos données. En termes de RTO (et parfois de PDMA), c'est la pire des situations. Dès lors que les données ont été vérifiées et nettoyées, cette procédure peut prendre des jours ou des semaines.
Le coût en temps de ce type de reprise après sinistre est élevé, mais le coût économique du stockage et l'acquisition de hardware peut l’être encore plus, car le hardware peut ne pas être disponible après un sinistre local, ou simplement se trouver en rupture de stock.
Comment gérer cela sur AWS pour réduire les coûts, le RTO et (éventuellement) la PDMA ?
Architecture de sauvegarde et restauration en utilisant AWS : situation de secours
Comme nous pouvons le voir sur l'image, nous pouvons utiliser les services d'AWS suivants :
- S3 pour stocker les données
- le service Import/Export, utilisé au départ pour charger les données lorsque le volume est « considérable »
- EC2 pour paramétrer les instances qui remplaceront notre structure défaillante
- Route 53 pour changer facilement les fichiers DNS et tendre vers une nouvelle structure sur AWS.
Architecture de sauvegarde et restauration en utilisant AWS : restaurer les données et l'infrastructure
C'est l'architecture de reprise après sinistre classique, facile à mettre en œuvre et économique, que nous pouvons déployer sur AWS : les instances EC2 démarrent uniquement pour les tests ou quand cela est nécessaire et les tarifs du stockage par S3 commencent à 0,01 $ par Go stocké.
Le RTO dépend uniquement de notre vitesse de déploiement ou de lancement de la structure et de restauration des données après le sinistre. La PDMA dépend en général de notre capacité à stocker efficacement les données, mais pas de la santé des disques ou de la bande.
Pilot Light
Il s’agit d’une autre architecture économique pouvant être mise en œuvre à la fois dans un centre de données et sur AWS en suivant le même modèle : une petite partie de la structure, toujours en fonctionnement, synchronise les données changeantes (comme les bases de données ou les documents), alors qu’une autre partie, en général éteinte, est allumée uniquement pour des tests ou pour se substituer à la structure originale.
Mettre en œuvre cette architecture de manière traditionnelle nécessiterait l'existence d'une structure aux dimensions adéquates dans un autre centre de données. Les exigences en termes de hardware incluraient le matériel nécessaire à la copie miroir ou à la réplication des données (toujours active) ainsi que celui nécessaire pour remplacer la structure originale. Comme vous pouvez le voir, il s'agit d'une structure coûteuse, à la fois en termes de consommation énergétique et d'achat de matériel (serveur et stockage).
Elle comporte, en outre, les inconvénients habituels des structures traditionnelles en centres de données : le volume de stockage doit être aménagé au fil du temps, des défaillances du hardware et des pannes locales peuvent se produire...
En utilisant Amazon Web Services, nous pouvons créer et définir une structure identique sur le cloud :
1. EC2 pour lancer l'application et les serveurs Web (arrêtés après la configuration initiale)
2. des instances RDS pour la réplication ou la copie miroir des données (toujours actives)
3. Route 53 pour changer facilement les fichiers DNS et tendre vers une nouvelle structure sur AWS.
Architecture Pilot Light sur AWS : situation de secours
Une fois que l'événement de reprise après sinistre se produit, nous pouvons lancer automatiquement la structure EC2 « en sommeil » et la mettre à l'échelle pour supporter la charge de production. Une fois la nouvelle structure vérifiée, nous pouvons utiliser Route 53 pour ajuster les fichiers DNS et tendre vers la nouvelle configuration.
Architecture Pilot Light sur AWS : activation et redimensionnement
Ce type d'architecture est plus coûteux que celui de sauvegarde et restauration mais il apporte un meilleur RTO, qui ne dépend que du temps nécessaire à la détection du besoin de reprise après sinistre et à la mise à l'échelle de la structure de remplacement. En fonction du système de réplication/copie miroir, la PDMA peut être proche de zéro. Le coût sur AWS dépend grandement de l'instance RDS et du volume des données mais il est dans tous les cas inférieur au coût de la plupart des services fournis par des centres de données traditionnels, tout en incluant la maintenance et les sauvegardes.
La prochaine fois, nous parlerons des deux dernières architectures : Architecture de secours de basse capacité et pleinement fonctionnelle et Architecture de secours multi-sites.
Partie 2 : Architectures haute disponibilité
References:
AWS documentation on Disaster Recovery: https://aws.amazon.com/disaster-recovery/
http://blog.celingest.com/en/2013/03/05/disaster-recovery-in-aws/