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.
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 :
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 :
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é.
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 :
Passerelle de fichiers FSx (FSx file gateway) : permet de connecter aux systèmes FSx à l'aide du protocole SMB.
Passerelle de fichiers S3 (S3 file gateway) : permet de connecter aux compartiments S3 à l'aide des protocoles NFS et SMB.
Passerelle de volume (volume gateway) : permet de connecter aux volumes EBS à l'aide du protocole iSCI en passant par S3.
Passerelle de bande (tape gateway) : permet de remplacer les bandes physiques par des bandes virtuelles dans AWS à l'aide du protocole iSCI-VTL (Virtual Tape Library).
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.
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.
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.
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.
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.
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.
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.
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.
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.
MySQL :
Comme pour PostgreSQL, créez une sauvegarde dans S3 (avec l’utilitaire Percona XtraBackup).
Ou utilisez l’utilitaire mysqldump pour copier la base vers 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 :
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 :
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.
