Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Scénarios de reprise après sinistre
Cette section fournit des exemples de défaillance d'une seule zone de disponibilité ou d'une seule AWS région, et décrit les options de reprise après sinistre (DR). Les exemples supposent un objectif de point de récupération (RPO) de 15 minutes et un objectif de temps de restauration (RTO) de 4 heures.
Défaillance de zone de disponibilité
Vous pouvez utiliser l'une des options suivantes pour effectuer une restauration après une défaillance d'une seule zone de disponibilité dans les paramètres définis (RPO de 15 minutes, RTO de 4 heures).
-
Provisionnez la restauration de l'application à l'aide de la dernière sauvegarde d'image Amazon Elastic Compute Cloud (Amazon EC2) et connectez-vous à l'instance de base de données Warm Standby existante via le déploiement d'un groupe de disponibilité Always On ou l'expédition de journaux.
-
Une configuration de groupe de disponibilité SQL Server Always On pour la reprise après sinistre avec deux nœuds ou plus permet un basculement automatique vers le nœud secondaire via le mode de validation synchrone ou asynchrone, de sorte que la base de données est disponible immédiatement. Pour une configuration HA, les deux nœuds sont disponibles pour les opérations de lecture. Cette option répond facilement aux exigences RTO et RPO. Dans l'édition standard de SQL Server, l'utilisation de groupes de disponibilité de base est également une option, mais elle est limitée à deux nœuds, car un groupe de disponibilité ne peut inclure qu'une seule base de données. Toutefois, vous pouvez configurer plusieurs groupes de disponibilité au sein d'une même région ou entre plusieurs régions. Cette configuration permet de réaliser des économies, car il n'y a aucun coût supplémentaire pour le nœud secondaire, qui n'est pas accessible pour les opérations de lecture. L'édition SQL Server Enterprise fournit des fonctionnalités complètes et un basculement sur incident pour toutes les bases de données au sein d'un même groupe de disponibilité. Pour des exemples de cette option, consultez les diagrammes d'architecture suivants :
-
L'expédition des journaux SQL Server en tant que solution de reprise après sinistre nécessite un basculement manuel vers un serveur de secours et dépend de la fréquence des sauvegardes des journaux. Il s'agit de l'une des options de reprise après sinistre les moins coûteuses. Il n'est pas nécessaire que les éditions de SQL Server du site de reprise après sinistre principal et du site DR expédié par journal correspondent. Cette option répond au RPO (utilisation de sauvegardes du journal des transactions toutes les 5 minutes et au RTO), mais nécessite une maintenance par le biais de scripts manuels personnalisés. Pour un exemple de cette option, consultez le schéma d'architecture suivant :
-
-
Si vous disposez d'une application telle qu'une application SQL Server Reporting Services (SSRS) dotée d'un déploiement évolutif, l'équilibreur de charge peut rediriger tout le trafic vers le nœud secondaire.
-
Vous pouvez utiliser Amazon EC2 base AMIs pour le serveur d'applications et de base de données afin de provisionner l'infrastructure. Les bases de données peuvent être restaurées dans une nouvelle zone de disponibilité, en fonction de leur taille et de leur fréquence de sauvegarde, à partir des sauvegardes natives les plus récentes (sauvegarde complète, sauvegarde différentielle ou sauvegarde du journal des transactions toutes les 5 minutes) ou à l'aide de snapshots EBS. Cette option répond aux exigences RPO et RTO mais nécessite un script personnalisé. Vous devez également tenir compte du temps nécessaire pour provisionner l'infrastructure, et répondre aux exigences de RPO et de RTO peut s'avérer difficile.
-
EC2 Les images Amazon (y compris les volumes EBS) pour les applications et le serveur de base de données peuvent être restaurées dans une nouvelle zone de disponibilité. Le RPO peut s'avérer difficile, en fonction de la sauvegarde la plus récente, mais cette option peut être associée aux journaux de transactions les plus récents pour répondre aux exigences. Cette option prend en charge les instantanés Windows Volume Shadow Copy Service (VSS).
Défaillance régionale
Vous pouvez utiliser l'une des options suivantes pour effectuer une restauration après une défaillance d'une seule AWS région dans les limites des paramètres définis (RPO de 15 minutes, RTO de 4 heures).
-
Vous pouvez utiliser Amazon Machine Images (AMIs) de EC2 base Amazon pour le serveur d'applications et de base de données afin de provisionner l'infrastructure. Les bases de données peuvent être restaurées dans une nouvelle région, en fonction de leur taille et de leur fréquence de sauvegarde, à partir des sauvegardes natives les plus récentes (sauvegarde complète, sauvegarde différentielle ou sauvegarde du journal des transactions toutes les 5 minutes). Cette option répond aux exigences RPO et RTO mais nécessite un script personnalisé.
-
L'expédition des journaux SQL Server en tant que solution de reprise après sinistre nécessite un basculement manuel vers un serveur de secours et dépend de la fréquence des sauvegardes des journaux. Il s'agit de l'une des options de reprise après sinistre les moins coûteuses. Il n'est pas nécessaire que les éditions de SQL Server du site de reprise après sinistre principal et du site DR expédié par journal correspondent. Cette option répond au RPO (en utilisant des sauvegardes du journal des transactions toutes les 5 minutes) et au RTO, mais nécessite une maintenance par le biais de scripts manuels personnalisés. Les bases de données volumineuses nécessitent de longs délais de restauration.
-
-
Vous pouvez utiliser une EC2 AMI Amazon pour l'application et le serveur de base de données et le restaurer sur une cible dans une nouvelle région. Le RPO dépend de la taille et de la fréquence des sauvegardes.
-
Les images d'application les plus récentes peuvent être restaurées à l'aide d'une AMI. Vous pouvez utiliser des sauvegardes différentielles ou du journal des transactions natives récentes toutes les 5 minutes pour mettre la base de données à jour afin de respecter le RPO.
-
Le RTO dépend de la taille et du temps nécessaires pour transférer et restaurer les instantanés vers la nouvelle région, si la source n'est pas déjà synchronisée avec la cible.
-
-
La solution présentant le moins de temps d'arrêt consiste à restaurer l'image de sauvegarde de l'application et à disposer d'un nœud SQL Server de secours dans une région distante en utilisant une configuration de groupe de disponibilité à deux, trois ou quatre nœuds (de base, classique ou distribué) et à se connecter au serveur de base de données de secours après un basculement. La réplique en mode de validation synchrone répond aux exigences du RPO, tandis que la réplique en mode de validation asynchrone peut être retardée en fonction du volume de transactions. Vous pouvez utiliser une configuration de groupe de disponibilité distribué pour étendre les nœuds de base de données dans une nouvelle région, si nécessaire. Cette configuration réduit également la complexité car elle utilise deux groupes de disponibilité indépendants au lieu d'un seul groupe de disponibilité réparti entre les régions en mode de validation synchrone ou asynchrone, et répond facilement aux exigences RTO et RPO. Il est également possible d'utiliser les groupes de disponibilité de base de SQL Server dans l'édition Standard. Cependant, il présente des limites car il ne prend en charge que deux nœuds et qu'une seule base de données peut figurer dans un seul groupe de disponibilité, bien que plusieurs groupes de disponibilité soient pris en charge. Vous pouvez configurer l'édition standard de SQL Server dans une ou plusieurs régions. Cette édition permet de réaliser des économies car elle ne facture pas le nœud secondaire, qui n'est pas accessible pour les opérations de lecture. L'édition SQL Server Enterprise fournit des fonctionnalités complètes et prend en charge le basculement de toutes les bases de données en tant que basculement d'un seul groupe de disponibilité.
Cas d’utilisation courants
À titre d'exercice de dimensionnement, 80 % des applications SQL Server exécutées sur Amazon et EC2 dont la charge de travail est normale pour le traitement des transactions en ligne (OLTP) peuvent être regroupées dans l'une des trois catégories suivantes, en fonction de leur importance critique :
-
SQL Server HA/DR avec sauvegardes SQL Server, à l'aide de deux répliques en mode de validation synchrone et d'une réplique en mode de validation asynchrone
-
AWS Backup HA/DR avec sauvegardes SQL Server, à l'aide d'une EC2 AMI Amazon pour l'application et la base de données, et du stockage Amazon EBS
-
AWS Backup HA/DR avec sauvegardes SQL Server, à l'aide d'une EC2 AMI de base Amazon pour le serveur de base de données, d' EC2 une image Amazon pour l'application et de snapshots Amazon EBS
Le tableau suivant fournit des informations détaillées sur chaque catégorie.
| SQL Server HA/DR avec sauvegardes SQL Server | AWS Backup HA/DR avec AMIs stockage EBS et sauvegardes SQL Server | AWS Backup HA/DR avec AMIs, instantanés EBS et sauvegardes SQL Server | |
|---|---|---|---|
Processus de restauration en cas de sinistre |
|
|
|
Ressources principales |
|
|
|
HA/DR |
Offres HA et DR |
Offres DR uniquement |
Offres DR uniquement |
RPO |
Le basculement est géré par le groupe de disponibilité de SQL Server (DR est manuel) |
Script manuel ou personnalisé |
Script manuel ou personnalisé |
RTO |
Quelques secondes à quelques minutes |
De quelques minutes à quelques heures |
Plusieurs heures |
Risque de disparition SLAs |
Faible |
Medium |
Élevé |
Facilité de gestion |
Simplicité |
Moyen |
Moyen |
Dimensionnement |
Simplicité |
Moyen |
Moyen |
Limites de taille de fichier pour les téléchargements vers Amazon S3 ou les transferts entre régions |
N/A — Géré en mode de validation synchrone ou en mode de validation asynchrone pour une mise en veille prolongée |
Oui |
Oui |
Perte de données |
Près de zéro (dépend de la charge de travail et de l'infrastructure mises en service) |
Dépend de la fréquence des images de EC2 sauvegarde Amazon et des sauvegardes SQL Server |
Cela dépend de la fréquence des images de EC2 sauvegarde Amazon ou des instantanés EBS et des sauvegardes SQL Server |
Coût |
Moyen |
Faible à moyen |
Faible à moyen |
