Amazon Web Services : Utilisation d'AWS pour la reprise sur sinistre Janvier 2012

Page 1 sur 20

Utilisation d'Amazon Web Services pour la reprise sur sinistre Octobre 2011

Dernière mise à jour : janvier 2012

Glen Robinson, Ianni Vamvadelis et Attila Narin

Amazon Web Services : Utilisation d'AWS pour la reprise sur sinistre Janvier 2012

Page 2 sur 20

Table des matières

Résumé.................................................................................................................................................................................... 3

Introduction ............................................................................................................................................................................ 3

Objectif de temps de reprise et objectif de point de reprise ................................................................................................. 4

Pratiques d'investissement traditionnelles en termes de reprise sur sinistre ....................................................................... 4

Services et fonctionnalités AWS essentiels dans le cadre d'une reprise sur sinistre ............................................................. 5

Régions ............................................................................................................................................................................ 5

Stockage .......................................................................................................................................................................... 5

Calcul ............................................................................................................................................................................... 6

Mise en réseau ................................................................................................................................................................ 6

Bases de données ........................................................................................................................................................... 7

Orchestration du déploiement ....................................................................................................................................... 7

Sécurité ........................................................................................................................................................................... 7

Exemples de scénarios de reprise sur sinistre avec AWS ....................................................................................................... 8

Sauvegarde et restauration ................................................................................................................................................ 8

Veilleuse de récupération rapide dans AWS ..................................................................................................................... 10

Solution de secours « à chaud » dans AWS ...................................................................................................................... 12

Solution multi-site déployée sur AWS et sur site.............................................................................................................. 14

Réplication de données ......................................................................................................................................................... 17

Réplication synchrone ................................................................................................................................................... 17

Réplication asynchrone ................................................................................................................................................. 17

Amélioration de votre plan de reprise sur sinistre ............................................................................................................... 18

Test ................................................................................................................................................................................ 18

Surveillance et alerte .................................................................................................................................................... 18

Sauvegardes .................................................................................................................................................................. 18

Accès utilisateur ............................................................................................................................................................ 18

Automatisation ............................................................................................................................................................. 19

Gestion des licences logicielles et reprise sur sinistre .......................................................................................................... 19

Conclusion ............................................................................................................................................................................. 19

Pour en savoir plus ................................................................................................................................................................ 20

Amazon Web Services : Utilisation d'AWS pour la reprise sur sinistre Janvier 2012

Page 3 sur 20

Résumé

En cas de sinistre, vous pouvez rapidement lancer des ressources dans Amazon Web Services (AWS) pour assurer la continuité de l'activité. Après avoir présenté les fonctionnalités et services AWS utiles pour vos procédures de reprise sur sinistre, ce document détaille quelques exemples de scénarios types. Il fournit, en plus, des recommandations permettant d'améliorer le plan de reprise sur sinistre et de tirer le meilleur parti du potentiel d'AWS dans le cadre de procédures de reprise sur sinistre.

Introduction

La reprise sur sinistre a pour objet de préparer un système à la survenue d'un sinistre et de lui permettre de reprendre ses activités normales par la suite. Tout événement ayant un impact négatif sur la continuité ou sur les finances de votre activité peut être qualifié de sinistre. Il peut s'agir d'une défaillance matérielle ou logicielle, d'une indisponibilité du réseau, d'une panne de courant, de dégâts physiques subis par un bâtiment (incendie, inondations, etc.), d'une erreur humaine ou de tout autre sinistre important.

Pour réduire l'impact d'un sinistre sur leur activité, les entreprises consacrent des ressources et du temps à la planification, à la préparation, à la répétition, à la documentation, à la formation et à la mise à jour des procédures permettant d'affronter de tels événements. Le montant des investissements consacrés à la planification des reprises sur sinistre d'une structure particulière peut varier considérablement en fonction du coût d'une éventuelle panne. Ce livre blanc décrit quelques approches types : investissements minimum, disponibilité intégrale et tolérance aux pannes.

Aujourd'hui, il est indispensable d'être bien préparé à la reprise sur sinistre et le présent document présente des exemples de bonnes pratiques pour améliorer vos plans et vos procédures de reprise sur sinistre.

La reprise sur sinistre est un processus continu d'analyse et d'amélioration, à mesure que l'activité et les systèmes évoluent. Pour chaque service métier, les clients doivent définir un point et un temps de reprise acceptables, puis développer une solution de reprise adaptée.

Dans un environnement physique traditionnel, l'approche type consisterait normalement à dupliquer l'infrastructure pour garantir la disponibilité de la capacité de réserve en cas de sinistre. Cette infrastructure doit être achetée, installée et entretenue pour se tenir prête à traiter les besoins de capacité prévus. En temps normal, cette infrastructure serait sous-utilisée ou dimensionnée sur une durée trop longue.

AWS vous permet de faire évoluer votre infrastructure selon vos besoins. Vous bénéficiez d'un accès à la même infrastructure hautement évolutive, fiable, sécurisée, rapide et peu coûteuse qu'Amazon utilise pour faire fonctionner son réseau mondial de sites Internet. De plus, vous ne payez qu'en fonction de votre utilisation. Dans le cas d'une solution de reprise sur sinistre, cela se traduit par d'importantes économies de coûts. De plus, face à une telle situation, vous pourrez modifier et optimiser les ressources avec une plus grande souplesse.

C'est souvent l'erreur humaine qui est à l'origine des temps morts d'un système. AWS fournit des outils autorisant la répartition des tâches pour permettre une conception selon le principe des privilèges minimum1. Grâce à AWS, vous pourrez aussi automatiser le déploiement d'environnements entiers, permettant des configurations prévisibles et reproductibles. Les environnements de test de reprise sur sinistre peuvent être installés très rapidement ; vous pouvez alors les considérer comme une ressource pouvant être supprimée. Les organisations peuvent ainsi tester des changements de configuration dans un environnement dupliqué avant de les envoyer en production, sans avoir besoin d'un environnement de test dédié à l'échelle, lequel serait souvent sous-utilisé.

1 http://en.wikipedia.org/wiki/Principle_of_least_privilege

Amazon Web Services : Utilisation d'AWS pour la reprise sur sinistre Janvier 2012

Page 4 sur 20

Objectif de temps de reprise et objectif de point de reprise

Ce document utilise deux termes techniques souvent utilisés dans le cadre de la planification des sinistres :

Objectif de temps de reprise (RTO, Recovery Time Objective)2 : Correspond à la durée et au niveau de service auquel un processus métier doit être restauré après un sinistre (ou une interruption) pour éviter des conséquences inacceptables associées à une rupture de continuité de l'activité. Par exemple, si un sinistre a lieu à 12h (midi) et que le RTO est de 8 heures, le processus de reprise sur sinistre veillerait à ce que l'activité reprenne à un niveau de service acceptable d'ici 20 h.

Objectif de point de reprise (RPO, Recovery Point Objective)3 : Décrit la quantité de perte de données acceptable évaluée dans le temps. Par exemple, si le RPO était 1 heure, après sa reprise, le système contiendrait l'ensemble des données présentes jusqu'à 11h, puisque le sinistre a eu lieu à midi.

Une entreprise décide normalement d'un RTO et d'un RPO acceptables en fonction de l'impact financier de l'indisponibilité des systèmes pour l'entreprise. Pour l'évaluer, il faut souvent prendre en compte plusieurs facteurs comme la perte d'activité et l'atteinte à la réputation en raison d'un temps mort et du manque de disponibilité des systèmes.

Les entreprises informatiques planifient alors des solutions permettant de fournir une récupération du système sans trop de frais supplémentaires en fonction du RPO dans le calendrier et le niveau de service définis par le RTO.

Pratiques d'investissement traditionnelles en termes de reprise sur sinistre Une approche traditionnelle de la reprise sur sinistre implique différents niveaux de duplication hors site des données et de l'infrastructure. Les services métier critiques sont installés et mis à jour sur cette infrastructure ; ils sont également testés à intervalles réguliers. L'emplacement de l'environnement de reprise sur sinistre et l'infrastructure source doivent être physiquement assez éloignés l'un de l'autre pour s'assurer que l'environnement de reprise sur sinistre est bien isolé des défaillances susceptibles d'agir sur le site source.

L'infrastructure nécessaire pour prendre en charge l'environnement dupliqué inclurait les éléments suivants, sans s'y limiter :

Equipements permettant de loger l'infrastructure, électricité et refroidissement y compris.

Sécurité pour garantir la protection physique des ressources.

Capacité adaptée à la mise à l'échelle de l'environnement.

Prise en charge des réparations, des remplacements et de l'actualisation de l'infrastructure.

Des accords contractuels avec un fournisseur d'accès Internet (FAI) qui offrira une connectivité Internet pouvant

supporter une utilisation de la bande passante dans l'environnement sous une charge totale.

Une infrastructure réseau de type pare-feux, routeurs, commutateurs et équilibreurs de charge.

Une capacité de serveur suffisante pour exécuter tous les services vitaux comme des appareils de stockage

pour les données connexes, des serveurs permettant d'exécuter des applications et des services dorsaux tels

que l'authentification de l'utilisateur, le système de noms de domaine (DNS), le protocole DHCP (Dynamic Host

Configuration Protocol), la surveillance et l'alerte.

En fonction de la criticité des services, l'environnement dupliqué peut être configuré de façon à tolérer les pannes. Cela implique normalement la duplication de l'intégralité de l'infrastructure décrite précédemment.

2 Extrait de http://en.wikipedia.org/wiki/Recovery_time_objective 3 Extrait de http://en.wikipedia.org/wiki/Recovery_point_objective

Amazon Web Services : Utilisation d'AWS pour la reprise sur sinistre Janvier 2012

Page 5 sur 20

Services et fonctionnalités AWS essentiels dans le cadre d'une reprise sur sinistre Avant d'analyser les différentes façons d'aborder la reprise sur sinistre, il importe d'examiner les services et les fonctionnalités AWS les plus adaptés à ce type de situation. Cette section en présente un récapitulatif.

Dans la phase de préparation de la reprise après sinistre, il est important de réfléchir à l'utilisation des services et des fonctionnalités qui prennent en charge la migration des données et un stockage durable, car ce sont eux qui vous permettent de restaurer les données critiques sauvegardées sur AWS en cas de sinistre. Dans certains scénarios de déploiement de votre système dans AWS, que ce soit à échelle réduite ou à grande échelle, des ressources de calcul seront également requises.

Face à un sinistre, il est essentiel soit de mettre en service rapidement des ressources de calcul pour exécuter votre système dans AWS, soit d'orchestrer le basculement vers des ressources déjà en fonctionnement dans AWS. Les éléments essentiels de l'infrastructure comprennent ici le DNS, les fonctionnalités de mise en réseau et diverses fonctionnalités Amazon Elastic Compute Cloud (Amazon EC2) décrites plus loin.

Régions

Amazon Web Services étant disponible dans plusieurs régions, vous pouvez choisir de situer votre site de reprise sur sinistre à l'emplacement le plus approprié, en plus du site sur lequel votre système est entièrement déployé. Au moment de la rédaction de ce document, AWS est disponible dans cinq régions : USA Est (Virginie du Nord), US Ouest (Californie du Nord), UE (Irlande), Asie Pacifique (Singapour) et Asie Pacifique (Tokyo).

Stockage

Amazon Simple Storage Service (Amazon S3) offre une infrastructure de stockage hautement durable conçue pour le stockage de données primaires et critiques. Les objets sont stockés de manière redondante sur plusieurs périphériques, dans plusieurs installations au sein d'une région. AWS fournit une protection supplémentaire pour la rétention des données et l'archivage via le contrôle de version dans Amazon S3, AWS Multi-Factor Authentication, les stratégies de compartiments et Identity and Access Management (IAM).

Amazon Elastic Block Store (Amazon EBS) permet de créer des instantanés de volumes de données à un moment donné. Ces instantanés peuvent être utilisés comme point de départ de nouveaux volumes Amazon EBS et pour la protection des données en vue d'une durabilité à long terme. Une fois un volume créé, il peut être associé à une instance Amazon EC2 en cours d'exécution. Les volumes Amazon EBS fournissent un stockage hors instance qui persiste indépendamment de la durée de vie d'une instance.

AWS Import/Export accélère le déplacement de grandes quantités de données vers et hors des périphériques de stockage portables. AWS transfère vos données directement dans et hors des périphériques de stockage au moyen du réseau haut débit interne d'Amazon et en contournant Internet. Pour des jeux de données volumineux, AWS Import/Export est souvent plus rapide qu'un transfert via Internet et plus économique que la mise à niveau de votre connectivité. Vous pouvez migrer des données vers et hors des compartiments Amazon S3 ou vers des instantanés Amazon EBS à l'aide d'AWS Import/Export.

AWS Storage Gateway permet de migrer en toute transparence des données depuis les services de stockage du nuage AWS vers les applications sur site et inversement. AWS Storage Gateway stocke les données du volume en local sur votre infrastructure et sur AWS. Les applications sur site existantes peuvent ainsi stocker des données en toute transparence sur l'infrastructure de stockage économique, sécurisée et durable d'AWS, tout en préservant un accès à faible latence à ces données.

Amazon Web Services : Utilisation d'AWS pour la reprise sur sinistre Janvier 2012

Page 6 sur 20

Calcul

Amazon Elastic Compute Cloud (Amazon EC2) fournit une capacité de calcul redimensionnable dans le nuage. En quelques minutes, vous pouvez créer des instances EC2, qui sont des ordinateurs virtuels sur lesquels vous avez un contrôle complet. Dans le contexte de la reprise sur sinistre, il est important de pouvoir créer rapidement des ordinateurs virtuels qu'il est possible de contrôler. Ce document n'a pas pour ambition de décrire chaque fonctionnalité d'Amazon EC2, il se concentre sur les aspects les plus intéressants d'Amazon EC2 dans le cadre d'une reprise sur sinistre.

Des images machine Amazon (AMI) sont préconfigurées avec les systèmes d'exploitation ; certaines AMI préconfigurées peuvent également inclure des piles d'applications. Vous pouvez aussi configurer vos propres AMI. Dans le contexte de la reprise sur sinistre, il est vivement recommandé de disposer d'AMI configurées et identifiées de sorte qu'elles puissent se lancer lors de la procédure de reprise. Ces AMI doivent être préconfigurées avec le système d'exploitation de votre choix en plus des éléments appropriés de la pile d'applications.

Les instances réservées Amazon EC2, qui sont souvent utilisées pour bénéficier d'une remise sur le coût d'exécution d'une instance EC2, présentent un autre avantage particulièrement intéressant dans le cadre d'une reprise sur sinistre. Les instances réservées aident à s'assurer que la capacité nécessaire est disponible lorsque vous en avez besoin.

Les zones de disponibilité sont des emplacements distincts qui sont conçus pour être isolés des défaillances d'autres zones de disponibilité. Elles fournissent une connectivité réseau à faible latence dans les autres zones de disponibilité de la même région. En lançant des instances dans des zones de disponibilité distinctes, vous pouvez protéger vos applications de la défaillance d'un seul emplacement. Les régions comportent au moins une zone de disponibilité.

La fonctionnalité Amazon EC2 VM Importvous permet d'importer des images d'ordinateurs virtuels depuis votre environnement existant vers les instances Amazon EC2.

Mise en réseau

Face à un sinistre, il est extrêmement probable que vous ayez à modifier les paramètres du réseau au moment de basculer vers un autre site.

Amazon Route 53 est un service Web de système de noms de domaine (DNS) hautement disponible et évolutif. Il est destiné à offrir aux développeurs et aux entreprises un moyen extrêmement fiable et économique d'acheminer les utilisateurs finaux vers les applications Internet.

Les adresses Elastic IP sont des adresses IP statiques conçues pour l'informatique en nuage dynamique. Toutefois, contrairement aux adresses IP statiques traditionnelles, les adresses Elastic IP vous permettent de masquer des défaillances de l'instance ou de la zone de disponibilité en remappant vos adresses IP publiques par programmation vers des instances de votre compte dans une région particulière. Pour la reprise sur sinistre, vous pouvez aussi pré-allouer certaines adresses IP pour les systèmes les plus critiques afin qu'elles soient déjà connues avant le sinistre. Cela peut simplifier l'exécution du plan de reprise sur sinistre.

Elastic Load Balancing distribue automatiquement un trafic d'application entrant à travers plusieurs instances Amazon EC2. Il vous permet d'équiper vos applications d'une plus grande tolérance à la défaillance, sans heurts, en fournissant la quantité de capacité d'équilibrage de charge nécessaire en réponse au trafic d'application entrant. Tout comme il est possible de pré-allouer des adresses Elastic IP, il est possible de pré-allouer votre programme Elastic Load Balancer pour que son nom DNS soit déjà connu, ce qui peut simplifier l'exécution de votre plan de reprise sur sinistre.

Amazon Web Services : Utilisation d'AWS pour la reprise sur sinistre Janvier 2012

Page 7 sur 20

Amazon Virtual Private Cloud (Amazon VPC) vous permet de dimensionner une section privée et isolée du nuage Amazon Web Services afin de lancer des ressources AWS dans un réseau virtuel que vous définissez. Vous conservez la totale maîtrise de votre environnement virtuel de réseau, y compris la sélection de votre propre plage d'adresses IP, la création de sous-réseaux et la configuration de tables de routage et de passerelles entre réseaux. Cela vous permet, par exemple, de créer une connexion VPN entre le centre de données de votre entreprise et votre VPC et d'exploiter le nuage AWS comme une extension de votre centre de données interne. Dans le contexte de la reprise sur sinistre, vous pouvez utiliser Amazon VPC pour étendre la topologie actuelle de votre réseau dans le nuage. Cela peut s'avérer particulièrement utile lors de la récupération d'applications d'entreprise qui se trouvent normalement sur le réseau interne.

Amazon Direct Connect facilite la configuration d'une connexion réseau dédiée à partir de votre site vers AWS. Bien souvent, cela permet de réduire les coûts liés à votre réseau, d'augmenter le débit de la bande passante et de fournir une expérience réseau plus stable que des connexions Internet.

Bases de données

Pour vos besoins en bases de données, vous pouvez envisager d'utiliser ces services AWS :

Amazon Relational Database Service (Amazon RDS) vous permet d'installer, de gérer et de mettre à l'échelle facilement une base de données relationnelle dans le nuage. Vous pouvez aussi utiliser Amazon RDS au cours de la phase de préparation de la reprise sur sinistre pour conserver vos données critiques dans une base de données déjà en cours d'exécution ou bien au cours de la phase de récupération pour exécuter votre base de données de production.

Amazon SimpleDB est un stockage de données non relationnelles combinant flexibilité et haute disponibilité, et déchargeant le client des tâches d'administration de base de données. Il peut aussi être utilisé au cours des phases de préparation et de récupération de la reprise sur sinistre.

Vous pouvez aussi installer et exécuter les logiciels de bases de données que vous préférez sur Amazon EC2. Vous avez le choix parmi plusieurs grands systèmes de bases de données.

Pour obtenir plus d'informations sur les options de bases de données sur AWS, reportez-vous à Exécution de bases de données sur AWS.

Orchestration du déploiement

Amazon EC2 permet d'utiliser des processus et des outils de configuration et d'installation de logiciels post-démarrage et d'automatisation de déploiement. Il est vivement recommandé d'investir dans ce domaine. En effet, vous pourrez en avoir besoin pendant la phase de récupération afin de créer l'ensemble des ressources requises de manière automatisée.

AWS CloudFormation permet aux développeurs et aux administrateurs système de créer facilement un ensemble de ressources liées à AWS et de les organiser de manière ordonnée et prévisible. Vous pouvez créer des modèles pour vos environnements et déployer, au besoin, les ensembles de ressources associés (appelés « pile »).

Sécurité

Les services AWS comportent de nombreuses fonctionnalités liées à la sécurité. Il est recommandé aux clients de se reporter au livre blanc Security Best Practices. AWS fournit également d'autres informations liées aux risques et à la conformité dans le Centre de sécurité AWS. Le présent document ne se définit pas comme une analyse en profondeur de la sécurité.

Amazon Web Services : Utilisation d'AWS pour la reprise sur sinistre Janvier 2012

Page 8 sur 20

Exemples de scénarios de reprise sur sinistre avec AWS

Cette partie décrit quatre scénarios de reprise après sinistre qui mettent en avant l'utilisation d'AWS, puis compare cette solution aux méthodes traditionnelles :

Sauvegarde et restauration

Veilleuse de récupération simple dans AWS

Solution de secours « à chaud »

Solution multi-site

Amazon Web Services permet aux clients de mettre en place, à moindres frais, chacun de ces trois exemples de stratégies de reprise sur sinistre. Il est à noter qu'il ne s'agit que d'exemples de solutions possibles. Vous pouvez envisager de les modifier ou de les combiner.

Sauvegarde et restauration Dans la plupart des environnements traditionnels, les données sont sauvegardées sur bande et envoyées régulièrement hors site. C'est avec cette méthode que la durée de la récupération est la plus longue. Amazon S3 est une destination idéale pour les données de sauvegarde, car elle a pour objectif de fournir aux objets une durabilité de 99,999999999 % (« 11 neuf ») sur une année donnée. C'est par le réseau qu'ont normalement lieu les échanges de données avec Amazon S3. Celles-ci sont donc accessibles à partir de n'importe quel emplacement. Il existe de nombreuses solutions de sauvegarde commerciales et open source sur Amazon S3. Le service AWS Import/Export permet les transferts de jeux de données très volumineux en expédiant des périphériques de stockage directement vers AWS.

Le service AWS Storage Gateway permet, en toute transparence, la copie d'instantanés de vos volumes de données sur site sur Amazon S3 à des fins de sauvegarde. Vous pouvez ultérieurement créer des volumes en local ou des volumes EBS AWS à partir de ces instantanés.

Pour les systèmes s'exécutant sur AWS, les clients sauvegardent également dans Amazon S3. Les instantanés des volumes Elastic Block Store (EBS) et les sauvegardes d'Amazon RDS sont stockés dans Amazon S3. Autrement, vous pouvez copier des fichiers directement dans Amazon S3 ou créer des fichiers de sauvegarde et les copier vers Amazon S3. Il existe de nombreuses solutions de sauvegarde qui stockent des données de sauvegarde dans Amazon S3 ; celles-ci peuvent également être utilisées à partir de systèmes Amazon EC2.

Amazon Web Services : Utilisation d'AWS pour la reprise sur sinistre Janvier 2012

Page 9 sur 20

lllustration 1 : Options de sauvegarde de données vers S3 à partir d'une infrastructure sur site ou à partir d'AWS.

Toutefois, cela ne s'arrête pas à la sauvegarde de vos données. En effet, dans un scénario de reprise, la récupération des données doit être testée et obtenue rapidement de manière fiable. Les clients doivent s'assurer que leurs systèmes sont configurés sur une rétention et une sécurité appropriées pour leurs données et que leurs processus de récupération ont été testés.

Illustration 2 : Restauration d'un système à partir de sauvegardes S3 vers AWS EC2

Amazon Web Services : Utilisation d'AWS pour la reprise sur sinistre Janvier 2012

Page 10 sur 20

Procédure générale à suivre pour la sauvegarde et la restauration :

Sélectionnez un outil ou une méthode qui convient à la sauvegarde de vos données dans AWS.

Vérifiez que vous disposez d'une stratégie de rétention adéquate pour ces données.

Assurez-vous que des mesures de sécurité appropriées sont bien en place pour ces données, notamment des stratégies de chiffrement et d'accès.

Testez régulièrement la récupération de ces données et la restauration de votre système.

Veilleuse de récupération rapide dans AWS L'idée de la veilleuse provient d'une comparaison avec un appareil de chauffage au gaz. Dans un système de chauffage au gaz, une petite flamme inactive et qui est toujours allumée peut rapidement déclencher la chaudière pour chauffer une maison en cas de besoin. Ce scénario est similaire à celui de la sauvegarde et de la restauration, mais vous devez vous assurer que les éléments les plus critiques de votre système sont déjà configurés et en cours d'exécution dans AWS (la veilleuse). Au moment de la reprise, vous mettez ainsi rapidement en place un environnement de production à l'échelle autour de l'élément critique.

Les éléments de l'infrastructure pour la veilleuse elle-même comprennent généralement vos serveurs de base de données, qui répliquent les données vers Amazon EC2. En fonction du système, d'autres données critiques à l'extérieur de la base de données devront peut-être être répliquées dans AWS. C'est le noyau critique du système (la veilleuse) autour duquel tous les autres éléments de l'infrastructure d'AWS peuvent être rapidement mis en service (les autres composants de la chaudière) pour restaurer l'intégralité du système.

Pour mettre en service le reste de l'infrastructure afin de restaurer des services stratégiques, vous disposez normalement de serveurs préconfigurés regroupés sous forme d'image machine Amazon (AMI), prêts à être démarrés à tout moment. Lors du lancement de la récupération, les instances de ces AMI arrivent rapidement pour trouver leur rôle au sein du déploiement autour de la veilleuse. Du point de vue de la mise en réseau, vous pouvez soit utiliser des adresses Elastic IP (qui peuvent être pré-allouées au cours de la phase de préparation de la reprise sur sinistre) pour les associer à vos instances, soit utiliser Elastic Load Balancing afin de répartir le trafic sur plusieurs instances. Ensuite, vous mettez à jour vos enregistrements DNS pour les faire pointer sur votre instance Amazon EC2 ou votre programme Elastic Load Balancing à l'aide d'un enregistrement CNAME.

Pour les systèmes moins critiques, vous pouvez vérifier que les packages d'installation et les informations relatives à la configuration sont disponibles dans AWS, sous la forme d'un instantané EBS par exemple. La configuration du serveur d'applications s'en trouvera accélérée, car vous pourrez créer rapidement plusieurs volumes dans plusieurs zones de disponibilité, pour les associer à des instances EC2. Vous pouvez ensuite installer et configurer les différents éléments comme il se doit.

La méthode de la veilleuse vous offre un temps de reprise plus rapide que le scénario « Sauvegarde et restauration » précédent, car les éléments essentiels du système sont déjà en cours d'exécution et sont continuellement mis à jour. Certaines tâches d'installation et de configuration doivent pourtant être effectuées pour récupérer entièrement les applications. AWS vous permet d'automatiser la mise en service et la configuration des ressources de l'infrastructure, ce qui peut s'avérer un grand avantage pour gagner du temps et se mettre à l'abri des erreurs humaines.

Amazon Web Services : Utilisation d'AWS pour la reprise sur sinistre Janvier 2012

Page 11 sur 20

Phase de préparation : L'illustration suivante montre la phase de préparation, au cours de laquelle vos données les plus variables doivent être répliquées sur la veilleuse, cet élément autour duquel l'ensemble de l'environnement sera démarré pendant la phase de récupération. Les données que vous actualisez moins fréquemment (par ex. les systèmes d'exploitation et les applications) peuvent être mises à jour de façon périodique et stockées sous la forme d'image machine Amazon (AMI).

Illustration 3 : Phase de préparation du scénario de la veilleuse

Principaux points à suivre lors de la préparation :

Installez les instances EC2 de façon à répliquer ou à reproduire les données.

Vérifiez que tous les packages de logiciels personnalisés complémentaires sont disponibles dans AWS.

Créez et tenez à jour une image machine Amazon (AMI) des principaux serveurs pour lesquels une reprise rapide est nécessaire.

Exécutez ces serveurs régulièrement, testez-les et appliquez toutes les mises à jour de logiciels et les modifications de configuration.

Pensez à automatiser la mise en service des ressources AWS.

Phase de récupération :

Pour récupérer les autres éléments de l'environnement se trouvant autour de la veilleuse, vous démarrez en quelques minutes vos systèmes à partir de l'image machine Amazon (AMI) sur les types d'instance appropriés. Vous pouvez redimensionner vos serveurs de données dynamiques pour traiter les volumes de production nécessaires ou pour ajouter de la capacité en conséquence. Dans la mesure du possible, la mise à l'échelle horizontale est souvent la façon la plus économique et le moyen le plus évolutif d'ajouter de la capacité à un système. Il est toutefois possible de choisir des types d'instance EC2 plus volumineux, puis de les mettre à l'échelle verticalement. Du point de vue de la mise en réseau, les mises à jour de DNS requises peuvent être réalisées en parallèle.

Amazon Web Services : Utilisation d'AWS pour la reprise sur sinistre Janvier 2012

Page 12 sur 20

Après la récupération, vous devez vérifier que la redondance est restaurée dans les plus brefs délais. Bien qu'il soit peu probable qu'une défaillance de votre environnement de reprise sur sinistre se produise juste après l'arrêt de votre environnement de production, vous devez être au courant de ce risque. Continuez de faire régulièrement des sauvegardes de votre système et envisagez une redondance supplémentaire sur la couche de données.

Illustration 4 : Phase de récupération dans le scénario de la veilleuse.

Principaux points à suivre lors de la récupération :

Lancez les instances EC2 de votre application à partir de vos AMI personnalisées.

Si nécessaire, redimensionnez ou mettez à l'échelle les instances de bases de données / magasins de données.

Modifiez le DNS pour qu'il pointe vers les serveurs EC2.

Installez et configurez les systèmes qui ne se basent pas sur des AMI, dans l'idéal de manière automatisée.

Solution de secours « à chaud » dans AWS Une solution de secours « à chaud » prolonge les éléments de la veilleuse et la préparation. Elle permet de diminuer plus encore le temps de reprise, car, dans ce cas, certains services sont toujours en cours d'exécution. En identifiant vos systèmes stratégiques, vous dupliquez entièrement ces systèmes sur AWS. Ceux-ci sont alors toujours actifs.

Ces serveurs peuvent être exécutés sur une flotte d'instances EC2 d'une taille minimale sur les plus petites tailles possibles. Cette solution n'est pas mise à l'échelle pour assurer une charge de production complète, mais elle est entièrement fonctionnelle. Elle peut servir dans le cadre de tâches non liées à la production, comme les tests, les contrôles qualité, une utilisation interne, etc.

Lors d'un sinistre, le système est rapidement mis à l'échelle pour pouvoir traiter la charge de production. Dans AWS, ce résultat peut être atteint en ajoutant plus d'instances à l'équilibreur de charge et en redimensionnant les serveurs à faible capacité pour les exécuter sur des types d'instances EC2 plus volumineux. Comme indiqué précédemment, une mise à l'échelle est souvent préférée à une mise à l'échelle verticale, dans la mesure du possible.

Amazon Web Services : Utilisation d'AWS pour la reprise sur sinistre Janvier 2012

Page 13 sur 20

Phase de préparation :

Le schéma suivant illustre la phase de préparation d'une solution de secours « à chaud », dans laquelle une solution sur site et une solution AWS sont exécutées côte à côte.

Illustration 5 : Phase de préparation d'un scénario de secours « à chaud »

Principaux points à suivre lors de la préparation :

Installez les instances EC2 de façon à répliquer ou à reproduire les données.

Créez et tenez à jour des images machine Amazon (AMI).

Exécutez votre application à l'aide d'un volume minimal d'instances EC2 ou d'infrastructure AWS.

Corrigez et mettez à jour les fichiers de vos logiciels et de votre configuration conformément à votre environnement réel.

Phase de récupération :

En cas de défaillance du système de production, l'environnement de secours sera mis à l'échelle en fonction de la charge de production et les enregistrements DNS seront modifiés pour acheminer l'ensemble du trafic vers AWS.

Amazon Web Services : Utilisation d'AWS pour la reprise sur sinistre Janvier 2012

Page 14 sur 20

Illustration 6 : Phase de récupération d'un scénario de secours « à chaud »

Principaux points à suivre lors de la récupération :

Si besoin, lancez les applications sur des types d'instance EC2 plus volumineux (mise à l'échelle verticale).

Augmentez la taille des flottes EC2 en service avec l'équilibreur de charge (mise à l'échelle horizontale).

Modifiez les enregistrements DNS pour que l'ensemble du trafic soit acheminé vers l'environnement AWS.

Pensez à utiliser la mise à l'échelle automatisée pour dimensionner la flotte comme il convient ou pour adapter la charge accrue.

Solution multi-site déployée sur AWS et sur site Une solution multi-site s'exécute dans AWS ainsi que sur l'infrastructure sur site existante dans une configuration active-active. Le mode de réplication de données que vous employez est déterminé par le point de reprise (voir ci-dessus « RPO ») choisi. Plusieurs modes de réplication existent (voir ci-dessous).

Un service DNS pondéré, comme Amazon Route 53, sert à acheminer le trafic de la production vers les différents sites. Une partie du trafic sera dirigée vers votre infrastructure dans AWS et le reste sera acheminé vers votre infrastructure sur site.

Dans une situation de sinistre sur site, vous pouvez ajuster la pondération DNS et envoyer l'ensemble du trafic vers les serveurs AWS. La capacité du service AWS peut être rapidement augmentée pour traiter l'intégralité de la charge de production. La mise à l'échelle automatisée EC2 peut être utilisée pour automatiser ce processus. Vous aurez peut-être besoin d'une logique d'application pour détecter la défaillance des services de base de données primaires et pour basculer vers les services de base de données parallèles en cours d'exécution dans AWS.

Amazon Web Services : Utilisation d'AWS pour la reprise sur sinistre Janvier 2012

Page 15 sur 20

Le coût de ce scénario est déterminé par la quantité de trafic de production gérée par AWS en temps normal. Pendant la phase de récupération, vous ne payez que pour ce que vous utilisez en plus et pendant la durée au cours de laquelle l'environnement de reprise sur sinistre doit être mis à l'échelle. Vous pouvez diminuer ce coût en achetant des instances réservées pour les serveurs AWS qui sont actifs en permanence.

Phase de préparation :

L'illustration ci-dessous montre l'utilisation d'un DNS qui achemine une partie du trafic vers le site AWS. L'application sur AWS peut avoir accès à des sources de données dans le système de production sur site. Les données sont répliquées ou reproduites dans l'infrastructure AWS.

Illustration 7 : Phase de préparation du scénario « Multi-site »

Principaux points à suivre lors de la préparation :

Configurez votre environnement AWS de façon à ce qu'il duplique votre environnement de production.

Configurez la pondération DNS ou une technologie similaire pour répartir les requêtes entrantes sur les deux sites.

Phase de récupération :

L'illustration ci-dessous montre ce qui se produit dans le cas d'un sinistre sur site. Le trafic vers l'infrastructure AWS est interrompu par la mise à jour du DNS.

Amazon Web Services : Utilisation d'AWS pour la reprise sur sinistre Janvier 2012

Page 16 sur 20

Illustration 8 : Phase de récupération du scénario « Multi-site » impliquant l'infrastructure sur site et AWS.

Principaux points à suivre lors de la récupération :

Modifiez la pondération DNS pour envoyer toutes les demandes vers le site AWS.

Faites en sorte que la logique d'application de basculement utilise les serveurs de bases de données AWS locaux.

Envisagez d'utiliser la mise à l'échelle automatisée pour mettre automatiquement la flotte AWS à la bonne taille.

Vous pouvez encore augmenter la disponibilité de votre solution multi-site en concevant des architectures Multi-AZ. Pour plus d'informations sur la conception d'applications s'étendant sur plusieurs zones de disponibilité, reportez-vous au livre blanc Designing Fault-Tolerant Applications in the AWS Cloud.

Amazon Web Services : Utilisation d'AWS pour la reprise sur sinistre Janvier 2012

Page 17 sur 20

Réplication de données

Plusieurs éléments sont à prendre en compte lors de la réplication de données vers un emplacement distant.

La distance séparant les sites : en général, les distances plus grandes sont exposées à une latence plus

importante et/ou à une plus grande instabilité.

La bande passante disponible : quelles sont la largeur et la variabilité des interconnexions ?

Le débit de données requis par votre application : le débit de données doit être inférieur à la bande

passante disponible.

La technologie de réplication doit être parallèle (pour pouvoir utiliser le réseau de manière efficace).

Il existe deux grands modes de réplication de données : synchrone et asynchrone.

Réplication synchrone

Les données sont mises à jour de façon atomique dans plusieurs emplacements. Cela place une dépendance sur les performances et la disponibilité du réseau.

Réplication asynchrone

Les données ne sont pas mises à jour de façon atomique dans plusieurs emplacements. Elles sont transférées à mesure que les performances et la disponibilité du réseau le permettent et l'application continue d'écrire des données qui ne seront pas encore forcément répliquées dans leur intégralité.

Un grand nombre de systèmes de base de données prennent en charge la réplication de données asynchrones. La réplique d'une base de données peut se situer à distance. Elle ne doit pas forcément être entièrement synchronisée avec le serveur de base de données primaire. Cela est acceptable dans de nombreux scénarios, comme des cas d'utilisation en création de rapports en lecture seule ou de source de sauvegarde. Il est conseillé aux clients de bien comprendre la technologie de réplication employée dans leur solution logicielle. Le présent document n'a pas pour objet d'analyser en détail la technologie de réplication. Dans AWS, les zones de disponibilité au sein d'une région sont bien reliées, mais elles sont séparées physiquement. Par exemple, lors d'un déploiement en mode Multi-AZ, Amazon Relational Database Service utilise une réplication asynchrone pour dupliquer les données dans une deuxième zone de disponibilité. Cela permet de s'assurer que les données ne seront pas perdues en cas d'indisponibilité de la zone de disponibilité primaire.

Les régions AWS sont entièrement indépendantes les unes des autres. Il n'existe toutefois aucune différence d'accès et d'utilisation entre elles. Cela permet aux clients de créer des processus de reprise sur sinistre qui couvrent des distances à l'échelle de continent, sans les difficultés ni les coûts que cela représenterait en temps normal. Les clients peuvent sauvegarder des données et des systèmes dans au moins deux régions AWS permettant la restauration de services, même en cas de sinistres à très grande échelle. Les clients peuvent utiliser les régions AWS pour répondre aux besoins de leurs clients finaux aux quatre coins du monde avec des processus opérationnels d'une complexité relativement faible.

Amazon Web Services : Utilisation d'AWS pour la reprise sur sinistre Janvier 2012

Page 18 sur 20

Amélioration de votre plan de reprise sur sinistre

La mise en place d'un plan de reprise sur sinistre robuste doit passer par certaines étapes importantes. Cette section en décrit quelques-unes.

Test

Après avoir été mise en place, votre solution de reprise sur sinistre doit être testée. Un exercice appelé « Game Day » (journée de jeu) permet de tester la mise en pratique du basculement vers l'environnement de reprise sur sinistre. Il permet de vérifier qu'une documentation suffisante est en place pour rendre le processus le plus simple possible au cas où l'événement aurait vraiment lieu. Sur AWS, il est très simple et économique de basculer vers un environnement dupliqué à des fins de test. Normalement, l'environnement de production ne requiert aucune manipulation. Vous pouvez déployer des environnements complets sur AWS à l'aide d'AWS CloudFormation. Cette solution utilise un modèle pour décrire les ressources AWS ainsi que l'ensemble des paramètres d'exécution ou des dépendances associés requises pour créer un environnement complet.

Il est important de différencier vos tests pour vous assurer que vous êtes couvert contre de nombreux types de sinistres différents. Voici des exemples de scénarios de « Game Day » (journée de jeu) :

Perte de puissance sur un site ou un ensemble d'ordinateurs

Perte de la connectivité du FAI vers un seul site

Virus avec des conséquences sur des services métier stratégiques touchant plusieurs sites

Erreur de l'utilisateur ayant entraîné la perte de données exigeant une récupération à un moment donné

Surveillance et alerte

Vous devez mettre en place des contrôles réguliers et une surveillance suffisante pour vous alerter si votre environnement de reprise sur sinistre a été touché par une panne de serveur, des problèmes de connectivité et d'application. Amazon CloudWatch offre un accès aux mesures relatives aux ressources AWS. Des alarmes peuvent être configurées à partir de seuils définis sur n'importe quelle mesure, et, au besoin, des messages Amazon Simple Notification Service peuvent être envoyés pour donner l'alerte en cas de comportement inattendu. Vous pouvez utiliser n'importe quelle solution de surveillance sur AWS.

Vous pouvez également continuer d'utiliser tous les outils de surveillance et d'alerte existants que votre entreprise utilise pour suivre les mesures de vos instances ainsi que les statistiques des systèmes d'exploitation invités et la santé de vos applications.

Sauvegardes

Après avoir basculé sur votre environnement de reprise sur sinistre, il est conseillé d'effectuer régulièrement des sauvegardes. Il est essentiel de tester périodiquement les sauvegardes et la restauration comme solution de repli.

AWS vous permet de procéder fréquemment et à moindres frais à des tests de reprise sur sinistre sans que l'infrastructure de reprise soit en permanence active.

Accès utilisateur

Vous pouvez accéder aux ressources de votre environnement de reprise sur sinistre à l'aide d'Identity and AWS Access Management (IAM). Vous pouvez ainsi créer des stratégies de sécurité rôle/utilisateur qui séparent les responsabilités des utilisateurs tandis qu'ils travaillent sur votre environnement de reprise sur sinistre.

Amazon Web Services : Utilisation d'AWS pour la reprise sur sinistre Janvier 2012

Page 19 sur 20

Automatisation

Vous pouvez automatiser le déploiement d'applications sur les serveurs AWS et sur vos serveurs sur site à l'aide de logiciels de gestion de la configuration ou de logiciels d'orchestration. Cela vous permet de gérer aisément les modifications apportées à la configuration et aux applications sur les deux environnements. La page Fournisseur de solutions présente plusieurs choix de logiciels d'orchestration répandus qui sont disponibles actuellement sur le marché ainsi que des fournisseurs de solutions possibles4. AWS CloudFormation fonctionne conjointement avec plusieurs outils pour mettre en place de manière automatisée les services d'infrastructure. Les données utilisateur peuvent être transmises à l'instance au premier démarrage, puis être communiquées à un outil de gestion de la configuration pour déterminer le type d'instance ou son rôle afin de déployer le logiciel et la configuration adaptés. L'objectif est que vos instances arrivent à l'état final dans lequel vous en avez besoin de manière aussi automatique que possible.

La mise à l'échelle automatique peut servir à vous assurer que votre pool d'instances présente la dimension adéquate pour répondre à la demande à partir des mesures spécifiées dans CloudWatch. Autrement dit, dans une solution de reprise sur sinistre, à mesure que votre base d'utilisateurs commence à davantage utiliser l'environnement, la solution peut être mise à l'échelle de façon dynamique pour répondre à l'augmentation de la demande. A la fin de l'événement et après une éventuelle diminution de l'utilisation, la solution peut être réduite à l'échelle au niveau de serveurs minimum.

Gestion des licences logicielles et reprise sur sinistre

Il est aussi important de vérifier que vous disposez des licences adéquates pour votre environnement AWS que pour tout autre environnement. Amazon propose différents modèles facilitant la gestion des licences. Par exemple, le concept « Bring Your Own License » (licence à fournir) est possible pour plusieurs composants logiciels ou systèmes d'exploitation. Sinon, il existe une gamme de logiciels pour lesquels le coût de la licence est compris dans le tarif horaire. C'est ce que l'on appelle le modèle « Licence incluse ».

Le concept « Bring Your Own License » (licence à fournir) vous permet d'exploiter vos investissements logiciels existants au cours d'un sinistre. Le concept « Licence incluse » minimise les coûts de licence initiaux d'un site de reprise sur sinistre qui n'est pas utilisé quotidiennement, c'est-à-dire qui est utilisé pendant les tests de reprise sur sinistre uniquement.

A tout moment, si vous avez une question concernant vos licences et leur applicabilité sur AWS, contactez votre revendeur de licences.

Conclusion

Il existe plusieurs options et déclinaisons au sujet de la reprise sur sinistre. Des solutions de sauvegarde et restauration simples aux solutions multi-sites tolérantes aux pannes, ce document met en avant des situations courantes. AWS fournit un contrôle affiné et de nombreux blocs élémentaires pour créer la solution de reprise sur sinistre les plus adaptés à vos objectifs (RTO et RPO) et à votre budget. Les services AWS sont disponibles à la demande ; vous ne payez qu'en fonction de votre utilisation. Il s'agit là d'un avantage clé dans le cadre d'une reprise sur sinistre : une infrastructure de taille s'avère rapidement nécessaire, mais uniquement en cas de sinistre.

Ce document a montré comment AWS fournit des solutions d'infrastructure flexibles et économiques, permettant de mettre en place un plan de reprise sur sinistre plus efficace.

4 Vous pourrez trouver des fournisseurs de solution à la page http://aws.amazon.com/solutions/solution-providers/

Amazon Web Services : Utilisation d'AWS pour la reprise sur sinistre Janvier 2012

Page 20 sur 20

Pour en savoir plus

Manuel S3 Getting Started : http://docs.amazonwebservices.com/AmazonS3/latest/gsg/

Manuel EC2 Getting Started Guide : http://docs.amazonwebservices.com/AWSEC2/latest/GettingStartedGuide/

Recherchez un fournisseur de solution AWS : http://aws.amazon.com/solutions/solution-providers/

Livre blanc Designing Fault-Tolerant Applications in the AWS Cloud : http://aws.amazon.com/whitepapers/

Centre de sécurité et de conformité AWS : http://aws.amazon.com/security/

Centre d'architecture AWS : http://aws.amazon.com/architecture

Livres blancs techniques AWS : http://aws.amazon.com/whitepapers