• 20 hours
  • Medium

Free online content available in this course.

course.header.alt.is_certifying

Got it!

Last updated on 7/5/24

Découvrez les services pour restaurer votre site en cas de désastre

Bannière chapitre

Vous vous souvenez de ce qui s'est passé avec OVH ? En 2021, un incendie a endommagé un datacenter à Strasbourg, ce qui a rendu beaucoup de leurs sites inaccessibles, y compris le site du gouvernement français…

Vous voyez où je veux en venir ? En effet, malgré la sécurité et la surveillance mise en place pour le site web, celui-ci reste vulnérable aux événements physiques. En effet, si la région AWS utilisée était détruite par un désastre naturel, comme un tremblement de terre ou un incendie, vous perdriez le site de The Green Earth Post et ses données 😱 ! En tant qu’architecte de solutions, il est impératif de mettre en place une stratégie de restauration automatique en cas de désastre.

Il existe trois types de restauration :

  • la restauration traditionnelle : d’un datacenter on-premises vers un autre datacenter on-premises (non étudié ici) ;

  • la restauration hybride : d’un datacenter on-premises vers le cloud d’un fournisseur ;

  • la restauration cloud : d’une région AWS X vers une région AWS Y.

Quel sera le meilleur type dans notre cas ?

Pour The Green Earth Post, ça sera la restauration Cloud, car le site web est déjà installé dans une région AWS !

Explorez des services AWS dédiés pour la restauration hybride

Avant d’explorer les stratégies de restauration dans la prochaine section, intéressons-nous aux services AWS qui permettent de transférer des applications et des données pour une restauration hybride, puis pour une restauration Cloud.

Planifiez la migration hybride

Il faut définir un plan afin que les applications et données migrées vers le cloud depuis un datacenter on-premises fonctionnent correctement. Ce plan doit indiquer dans quel ordre migrer et avec quel service AWS. C’est là qu’intervient AWS Application Discovery Service, qui aide à planifier des projets de migration en recueillant des informations sur les datacenters on-premises. Par exemple : 

  • les noms d'hôte des serveurs ;

  • les adresses IP et MAC ;

  • l'allocation (mémoire, CPU) des ressources ;

  • les dépendances entre ressources et applications.

Les données du plan produit peuvent être consultées dans le service AWS Migration Hub et seront exploitées pour identifier quels services AWS ci-dessous utiliser.

Pour migrer des applications :

AWS Application Migration Service (MGN) est une solution de re-hébergement “lift-and-shift” (littéralement “soulever et déplacer”), qui simplifie la migration des applications vers AWS avec un temps d'interruption minimal. MGN réplique les serveurs sources dans le compte AWS en utilisant les services AWS appropriés pour que l’application s’exécute nativement.

Une flèche mène du DataCenter On-Premises qui comporte serveur et disques on-premises vers AWS Cloud qui comporte un région avec l'instance EC2 et volumes EBS. Au-dessus de la flèche se trouve AWS Application Migration Service.
Fonctionnement du service AWS Application Migration Service

VMware Cloud on AWS est un service qui permet de migrer des applications s’exécutant sur des machines virtuelles VMware vSphere.

Pour migrer des données depuis une base de données :
AWS Database Migration Service (DMS)

Ce service permet de migrer des bases de données vers AWS rapidement et en toute sécurité. La base de données source reste pleinement opérationnelle durant la migration, ce qui réduit au minimum les temps d'arrêt des applications qui reposent dessus. Il supporte également la réplication continue des données.

AWS DMS prend en charge les migrations homogènes (exemple : Oracle vers Oracle) et hétérogènes entre différentes plateformes de bases de données (exemple : Microsoft SQL Server vers Amazon Aurora). Il supporte un grand nombre de sources et de cibles.

De manière générale, AWS DMS exécute simplement une instance EC2 qui héberge une ou plusieurs tâches de réplication comme montré ci-dessous :

Un chèmin mene du serveur ou instance EC2 qui héberge l'outil SCT (1) vers la base de données cible, puis vers l'instance EC2 (2), puis vers la base de données source, et finit encore sur l'étape 1.
Fonctionnement du service AWS Database Migration Service

1 - L’exécution de l’outil SCT se fait uniquement si les schémas des bases de données source et cible ne correspondent pas.
L’outil peut s’exécuter sur un serveur ou une instance EC2 selon que la base de données cible est dans le cloud ou non.
2 - Après l’exécution de l’outil SCT, exécutez la tâche DMS qui peut charger les données en une fois ou en continu.

Pour migrer des données depuis un stockage orienté fichier :

AWS DataSync

Ce service simplifie et automatise le déplacement de grande quantité de données, dans les deux sens, depuis un datacenter on-premises ou une région AWS vers une autre région. DataSync peut copier des données vers et depuis plusieurs systèmes et services AWS (NFS, SMB, S3, EFS…) sur une connexion TLS.

Ci-dessous le fonctionnement dans une migration hybride :

Un chèmin à double sens mène du stockage On-Premises vers l'Agent DataSync, puis vers AWS DataSync, puis vers le bloc qui comporte les éléments suivantes: EFS, Compartiment S3, FSx for Lustre, FSx for OpenZFS, FSx for Windows File Server, FSx for Net
Fonctionnement du service AWS DataSync
AWS Transfer Family

Si la migration doit se faire via une connexion FTP et non TLS, utilisez alors AWS Transfer Family. C’est un service entièrement géré pour les transferts de fichiers vers et depuis S3 ou EFS à l'aide des protocoles :

  • SFTP (SSH File Transfer Protocol),

  • FTPS (File Transfer Protocol Secure),

  • FTP (Transfer Protocol Secure) – à éviter car non sécurisé.

Un chemin mène du Client FTP (A) vers AWS Transfer Family (AWS Transfer for FTPS, SFTP et FTP (B)), puis individuellement vers S3 et EFS (C)
Fonctionnement du service AWS Transfer Family

A - Application dans un datacenter On-Premises ou une région. AWS exécute un client FTP afin de transférer des fichiers.
B - Le seul type qui doit s’exécuter dans un VPC.
C - Un rôle IAM doit être utilisé pour écrire et lire dans S3 ou EFS.

AWS Storage Gateway

C’est un service de stockage en cloud hybride qui permet à des applications on-premises d’avoir un accès à un stockage cloud pratiquement illimité. En effet, au lieu de commander de nouveaux serveurs physiques, AWS Storage Gateway étend virtuellement l'infrastructure on-premises avec les services de stockages AWS (S3, EFS, FSx, EBS, Glacier). Si les applications on-premises subissent un sinistre, il est facile de les basculer dans le cloud AWS car les données y sont déjà présentes !

Storage Gateway fournit quatre types de passerelles  :

Ces passerelles sont installées côté infrastructure on-premises et permettent de transférer les données vers le cloud et de les mettre en cache localement avec un accès à faible latence.

Le bloc 'DataCenter On-Premises' comporte 4 chemins avec des passerelles de fichiers FSx, S3, de volume et de bande, dont les chèmins mènent vers AWS storage Gateway et puis vers differents services du AWS clou
Fonctionnement du service AWS Storage Gateway
AWS Snow Family

Si le volume de données se mesure en dizaines de téraoctets voire en pétaoctets, le transfert des données avec les services AWS précédents peut prendre des dizaines de jours, voire des mois.

 

Durée de transfert (≈)

 

1 Gbit/s

10 Gbit/s

10 To

23 heures

2 heures

100 To

10 jours

23 heures

1 Po

95 jours

10 jours

Si le transfert dépasse 1 semaine, AWS vous recommande AWS Snow family, un ensemble d’appareils hors ligne (reçus par voie postale, camion ou bateau…) qui permettent de migrer, en quelques jours, de grandes quantités de données vers et depuis le cloud sans dépendre des réseaux.

Etapes du schéma:  1. Datacenter reçoit un appareil de la gamme AWS Snow. 2. Copiez les données de l'appareil hors ligne. 3. L'appareil est renvoyé par voie postale, camion ou bateau. 4. AWS se charge de copier les données dans un compartiment S3. 5.
Principe d’utilisation du service AWS Snow family

La gamme est composée de 3 variantes :

  • AWS Snowcone : c’est un petit ordinateur de 2,1 Kg, portable, robuste, sécurisé et résistant aux environnements difficiles. Il est équipé de 8 ou 14 To de stockage.

Un petit ordinateur qui ressemble à un petit boitier à peine plus grand qu'une boîte de mouchoirs.
AWS Snowcone
  • AWS Snowball Edge : c’ est un appareil robuste qui transporte des données à des vitesses plus rapides qu'Internet. Il est équipé de 42 ou 80 To de stockage.

un appareil de la taille d'une petite valise
AWS Snowball Edge
  • AWS Snowmobile : c’est un camion 🚛 qui permet de transférer des exaoctets (Eo) de données (1 Eo = 1 000 Po 🤯). À utiliser s’il faut transférer plus de 10 To de données.

photo d'un camion Snowmobile
AWS Snowmobile

Explorez des services AWS dédiés pour la restauration cloud

AWS Backup est un service entièrement géré qui permet d’automatiser les sauvegardes d’une multitude de services AWS (EC2, DynamoDB, S3…) dans des compartiments S3, de manière centralisée, sans recourir à des scripts/codes personnalisés. À partir d’une sauvegarde, il est possible de restaurer le service, à un instant dans le passé (Point-In-Time Recovery), dans une autre région ou un autre compte AWS.

AWS Backup vous permet de planifier les sauvegardes en créant des plans de sauvegarde qui définissent notamment la fréquence de sauvegarde (toutes les 12 heures, quotidienne…) et leur période de rétention pour les services concernés.

Le chemin mène du premier bloc (A) qui comporte AWS Backup et plan de sauvegarde vers le deuxième qui comporte EBS, EC2, S3, Document DB, RDS, EFS, Neptune, Aurora, Dynamo DB, Storage Gateway et finit sur le AWS S3 (B)
Principe d’utilisation du service AWS Backup

A - Créez un plan de sauvegarde en spécifiant les services concernés, la fréquence et la période de rétention.
B - Les sauvegardes sont stockées automatiquement dans des compartiments S3. Utilisez-les pour restaurer le(s) service(s) à un instant du passé.

Migrez une base de données MySQL ou PostgreSQL vers Aurora

Les options dans le cas d’une base de données RDS (MySQL ou PostgreSQL) : 

  • Créez une base de données Aurora à partir d’un Instantané RDS MySQL.

Un chemin mène de Amazon RDS (MySQL ou PostgreSQL) vers AWS Backup puis vers Amazon Aurora
Migration, avec le service AWS Backup, d’une base de données RDS vers une base de données Aurora
  • Créez un réplica en lecture Aurora à partir de RDS. Lorsque le retard (lag) de réplication est nul, promouvez le réplica Aurora comme instance principale.

Une flèche mène de Amazon RDS vers Amazon Aurora. Créez un réplica en lecture Aurora. Quand le retard est nul, Aurora peut être une base de données indépendante
Migration, en créant un réplica en lecture Aurora, d’une base de données RDS vers une base de données Aurora

 Les options dans le cas d’une base de données on-premises (MySQL ou PostgreSQL) : 

  • PostgreSQL : créez et chargez une sauvegarde dans S3, puis créez une base de données Aurora depuis cette sauvegarde.

Un chemin mène du PostgreSQL on-premises vers Bucket S3 puis vers Amazon Aurora. Créez une sauvegarde dans un compartiment S3
Migration, via une sauvegarde dans un compartiment S3, d’une base de données PostSQL on-premises vers une base de données Aurora
  • MySQL :

    • Comme pour PostgreSQL, créez une sauvegarde dans S3 (avec l’utilitaire Percona XtraBackup).

Un chemin mène du MySQL on-premises vers Bucket S3 puis vers Amazon Aurora. Créez une sauvegarde dans un compartiment S3 avec l'utilitaire Percona XtraBackup
Migration, via une sauvegarde dans un compartiment S3, d’une base de données MySQL on-premises vers une base de données Aurora
  • Ou utilisez l’utilitaire mysqldump pour copier la base vers Aurora.

Un chemin mène du MySQL on-premises  Amazon Aurora. Copie effectuée grâce à l'utilitaire MySQLDump
Migration, via l’utilitaire mysqldump, d’une base de données MySQL on-premises vers une base de données Aurora

AWS DataSync

Je vous ai présenté ce service dans la section précédente. Voici ci-dessous son fonctionnement pour le cas d’une migration cloud :

Deux régions interagissent à travers les AWS DataSync correspondantes
Fonctionnement du service AWS DataSync dans le cas d’une migration cloud

Découvrez les termes principaux de la restauration après sinistre

Il est essentiel d’étudier les deux termes suivants qui seront utilisés tout au long du chapitre. Ils constituent un ensemble d'objectifs et de stratégies permettant de récupérer la disponibilité de la charge de travail en cas d’interruption de service.

  • La durée maximale d'interruption admissible (Recovery Time Objective - RTO) : correspond au délai maximum acceptable entre l'interruption de service et la restauration du service. Cela détermine le créneau de temps acceptable d'indisponibilité du service.

  • L'objectif de point de reprise (Recovery Point Objective - RPO) : correspond au temps maximal acceptable depuis le dernier point de reprise des données. Cela détermine la durée de perte de données acceptable.

Voici un schéma pour illustrer le sens de ces termes :

Une flèche indiquant le temps comporte les étapes suivantes: Point de reprise (RPO, A), Désastre, Temps de récupération (RTO, B, C). Partie du flèche entre RPO et désastre correspond à la perte de données; entre désastre et RTP - au temps d'arre
Illustration du rôle des termes RPO et RTO

A - Date de la dernière sauvegarde des données avant le désastre.
B - L’application redémarre avec les données de la dernière sauvegarde, c’est-à-dire à l’instant RPO.
C - Date à laquelle la récupération de l’application a pu se faire.

En résumé

  • Les services AWS suivants permettent de migrer des applications vers le cloud :

    • AWS Application Migration Service (MGN)

    • VMware Cloud on AWS

  • Les services AWS suivants permettent de migrer des données vers le cloud depuis un datacenter on-premises :

    • AWS Database Migration Service

    • AWS DataSync

    • AWS Transfer Family

    • AWS Storage Gateway

    • AWS Snow Family

  • Les services AWS suivants permettent de migrer des données vers le Cloud depuis une région AWS :

    • AWS Backup

    • AWS Database Migration Service

    • AWS DataSync

Dans le prochain chapitre, nous verrons comment mettre en place une stratégie de reprise après sinistre.

Example of certificate of achievement
Example of certificate of achievement