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.
# Amazon EC2 pour SQL Server
Amazon EC2 prend en charge une base de données SQL Server autogérée. En d'autres termes, il vous donne un contrôle total sur la configuration de l'infrastructure et de l'environnement de base de données. L'exécution de la base de données sur Amazon EC2 est très similaire à l'exécution de la base de données sur votre propre serveur. Vous avez le contrôle total de la base de données et de l'accès au niveau du système d'exploitation. Vous pouvez donc utiliser les outils de votre choix pour gérer le système d'exploitation, le logiciel de base de données, les correctifs, la réplication des données, la sauvegarde et la restauration. Cette option de migration vous oblige à configurer, gérer et régler tous les composants, y compris les instances EC2, les volumes de stockage, l'évolutivité, le réseau et la sécurité, conformément aux meilleures pratiques en matière d' AWS architecture. Vous êtes responsable de la réplication et de la restauration des données sur vos instances situées dans la même région ou dans des AWS régions différentes.
## Quand choisir Amazon EC2
Amazon EC2 est une bonne option de migration pour votre base de données SQL Server lorsque :
+ Vous devez avoir le contrôle total de la base de données et accéder à son système d'exploitation sous-jacent, à son installation et à sa configuration.
+ Vous souhaitez administrer votre base de données, notamment en effectuant des sauvegardes et des restaurations, en appliquant des correctifs au système d'exploitation et à la base de données, en ajustant les paramètres du système d'exploitation et de la base de données, en gérant la sécurité et en configurant la haute disponibilité ou la réplication.
+ Vous souhaitez utiliser des fonctionnalités et des options qui ne sont actuellement pas prises en charge par Amazon RDS. Pour plus de détails, consultez les [sections Fonctionnalités non prises en charge et Fonctionnalités avec prise en charge limitée](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.FeatureNonSupport) dans la documentation Amazon RDS.
+ Vous avez besoin d'une version spécifique de SQL Server qui n'est pas prise en charge par Amazon RDS. Pour obtenir la liste des versions et éditions prises en charge, consultez [les versions de SQL Server sur Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.VersionSupport) dans la documentation Amazon RDS.
+ La taille et les besoins en performances de votre base de données dépassent les offres Amazon RDS for SQL Server actuelles. Pour plus de détails, consultez le [stockage des instances de base de données Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) dans la documentation Amazon RDS.
+ Vous souhaitez éviter les correctifs logiciels automatiques susceptibles de ne pas être compatibles avec vos applications.
+ Vous souhaitez apporter votre propre licence au lieu d'utiliser le modèle avec licence Amazon RDS for SQL Server inclus.
+ Vous souhaitez obtenir des IOPS et une capacité de stockage supérieures aux limites actuelles. Pour plus de détails, consultez le [stockage des instances de base de données Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) dans la documentation Amazon RDS.
Pour obtenir la liste des fonctionnalités et versions de SQL Server actuellement prises en charge sur Amazon EC2, consultez [Choisir entre Amazon EC2 et Amazon](comparison.md) RDS plus loin dans ce guide.
# Haute disponibilité
Vous pouvez utiliser n'importe quelle technologie de réplication prise en charge par SQL Server avec votre base de données SQL Server sur Amazon EC2 pour garantir la haute disponibilité, la protection des données et la reprise après sinistre. Parmi les solutions les plus courantes figurent l'expédition des journaux, la mise en miroir de bases de données, les groupes de disponibilité Always On et les instances de cluster Always On Failover.
Le schéma suivant montre comment utiliser SQL Server sur Amazon EC2 dans plusieurs zones de disponibilité au sein d'une même AWS région. La base de données principale est une base de données en lecture-écriture, et la base de données secondaire est configurée avec l'expédition des journaux, la mise en miroir de bases de données ou des groupes de disponibilité Always On pour une haute disponibilité. Toutes les données de transaction de la base de données principale sont transférées et peuvent être appliquées à la base de données secondaire de manière asynchrone pour l'expédition des journaux, et de manière asynchrone pour les groupes de disponibilité Always On et la mise en miroir.
![\[SQL Server on Amazon EC2 in a Multi-AZ configuration in one AWS Region\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/migration-sql-server/images/sql-migration-ec2.png)
# Expédition de journaux
L'expédition des journaux vous permet d'envoyer automatiquement des sauvegardes du journal des transactions d'une instance de base de données principale vers une ou plusieurs bases de données secondaires (également appelées « hot *standby* ») sur des instances de base de données distinctes. L'expédition des journaux utilise les tâches de l'agent SQL Server pour automatiser le processus de sauvegarde, de copie et d'application des sauvegardes du journal des transactions. Bien que l'expédition des journaux soit généralement considérée comme une fonctionnalité de reprise après sinistre, elle peut également fournir une haute disponibilité en permettant de promouvoir les instances de base de données secondaires en cas de défaillance de l'instance de base de données principale. Si vos RTO et RPO sont flexibles ou si vos bases de données ne sont pas considérées comme hautement critiques, envisagez d'utiliser l'expédition de journaux pour améliorer la disponibilité de vos bases de données SQL Server.
L'expédition des journaux augmente la disponibilité des bases de données en fournissant un accès aux bases de données secondaires à utiliser comme copies en lecture seule de la base de données principale en cas de besoin. Vous pouvez configurer un délai de latence (délai plus long) pendant lequel vous pouvez récupérer les données modifiées accidentellement dans la base de données principale avant que ces modifications ne soient envoyées à la base de données secondaire.
Nous recommandons d'exécuter les instances de base de données principale et secondaire dans des zones de disponibilité distinctes et de déployer une instance de surveillance pour suivre tous les détails de l'expédition des journaux. Les événements de sauvegarde, de copie, de restauration et de défaillance relatifs à un groupe d'expédition de journaux sont disponibles depuis l'instance de surveillance. Une configuration d'expédition de journaux ne bascule pas automatiquement du serveur principal vers le serveur secondaire. Cependant, toutes les bases de données secondaires peuvent être mises en ligne manuellement si la base de données principale devient indisponible.
L'expédition de journaux est souvent utilisée comme solution de reprise après sinistre, mais peut également être utilisée comme solution de haute disponibilité, en fonction des exigences de votre application. Utilisez l'expédition de journaux lorsque :
+ Vous avez des exigences flexibles en matière de RTO et de RPO. L'expédition de journaux fournit un RPO de quelques minutes et un RTO de quelques minutes à quelques heures.
+ Vous n'avez pas besoin d'un basculement automatique vers la base de données secondaire.
+ Vous souhaitez lire à partir de la base de données secondaire, mais vous n'avez pas besoin de lisibilité lors d'une opération de restauration.
Pour plus d'informations sur l'expédition des journaux, consultez la [documentation Microsoft SQL Server](https://docs.microsoft.com/en-us/sql/database-engine/log-shipping/about-log-shipping-sql-server).
# Mise en miroir de bases de données
La mise en miroir de bases de données prend une base de données qui se trouve sur une instance EC2 et fournit une copie complète ou presque complète en lecture seule (miroir) de celle-ci sur une instance de base de données distincte. Amazon RDS utilise la mise en miroir de bases de données pour fournir un support multi-AZ pour Amazon RDS for SQL Server. Cette fonctionnalité augmente la disponibilité et la protection des bases de données et fournit un mécanisme permettant de maintenir la disponibilité des bases de données pendant les mises à niveau.
**Note**
Selon la [documentation Microsoft](https://docs.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server), la mise en miroir des bases de données sera supprimée dans une future version de SQL Server. Vous devriez plutôt prévoir d'utiliser des groupes de disponibilité Always On.
Dans le cadre de la mise en miroir de bases de données, les serveurs SQL peuvent jouer l'un des trois rôles suivants :
+ Le serveur principal, qui héberge la read/write version principale de la base de données.
+ Le serveur miroir, qui héberge une copie de la base de données principale.
+ Un serveur témoin en option. Ce serveur n'est disponible qu'en mode haute sécurité. Il surveille l'état du miroir de base de données et automatise le basculement de la base de données principale vers la base de données miroir.
Une session de mise en miroir est établie entre le serveur principal et le serveur miroir. Pendant la mise en miroir, toutes les modifications de base de données effectuées dans la base de données principale sont également effectuées sur la base de données miroir. La mise en miroir de bases de données peut être une opération synchrone ou asynchrone. Ceci est déterminé par deux modes de fonctionnement de la mise en miroir : le mode haute sécurité et le mode haute performance.
+ Mode **haute sécurité : ce mode** utilise des opérations synchrones. Dans ce mode, la session de mise en miroir de base de données synchronise les opérations d'insertion, de mise à jour et de suppression de la base de données principale vers la base de données miroir le plus rapidement possible. Dès que la base de données est synchronisée, la transaction est validée dans la base de données principale et dans la base de données miroir. Nous vous recommandons d'utiliser ce mode de fonctionnement lorsque les bases de données miroir se trouvent dans la même zone de disponibilité ou dans des zones différentes, mais hébergées dans la même AWS région.
+ **Mode haute performance :** ce mode utilise des opérations asynchrones. Dans ce mode, la session de mise en miroir de base de données synchronise les opérations d'insertion, de mise à jour et de suppression de la base de données principale vers la base de données miroir, mais il peut y avoir un décalage entre le moment où la base de données principale valide les transactions et le moment où la base de données miroir valide les transactions. Nous vous recommandons d'utiliser ce mode lorsque les bases de données miroir se trouvent dans différentes AWS régions.
Utilisez la mise en miroir de bases de données lorsque :
+ Vous avez des exigences strictes en matière de RTO et de RPO, et vous ne pouvez pas avoir de délais entre les bases de données principales et secondaires. La mise en miroir de bases de données fournit un RPO de zéro seconde (avec validation synchrone) et un RTO de quelques secondes à quelques minutes.
+ Vous n'êtes pas obligé de lire à partir de la base de données secondaire.
+ Vous souhaitez effectuer un basculement automatique lorsqu'un serveur témoin est configuré en mode synchronisation.
+ Vous ne pouvez pas utiliser les groupes de disponibilité Always On, qui constituent l'option préférée.
Limites:
+ Seul le one-to-one basculement est pris en charge. Vous ne pouvez pas synchroniser plusieurs destinations de base de données avec la base de données principale.
Pour plus d'informations sur la mise en miroir, consultez la [documentation Microsoft SQL Server](https://docs.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server).
# Groupes de disponibilité Always On
Les groupes de disponibilité SQL Server Always On fournissent des solutions de haute disponibilité et de reprise après sinistre pour les bases de données SQL Server. Un groupe de disponibilité se compose d'un ensemble de bases de données utilisateur qui basculent ensemble. Il comprend un ensemble unique de read/write bases de données primaires et plusieurs (un à huit) ensembles de bases de données secondaires connexes. Vous pouvez mettre les bases de données secondaires à la disposition du niveau application sous forme de copies en lecture seule des bases de données principales (édition SQL Server Enterprise uniquement), afin de fournir une architecture évolutive pour les charges de travail en lecture. Vous pouvez également utiliser les bases de données secondaires pour les opérations de sauvegarde.
Les groupes de disponibilité Always On de SQL Server prennent en charge les modes de validation synchrone et asynchrone. En mode synchrone, le réplica principal valide les transactions de base de données une fois les modifications validées ou écrites dans le journal du réplica secondaire. Ce mode vous permet d'effectuer un basculement manuel planifié et un basculement automatique si les répliques sont synchronisées. Vous pouvez utiliser le mode de validation synchrone entre les instances de SQL Server au sein d'un même environnement (par exemple, si toutes les instances sont locales ou si toutes les instances le sont). AWS
En mode de validation asynchrone, le réplica principal valide les transactions de base de données sans attendre le réplica secondaire. Vous pouvez utiliser le mode de validation asynchrone entre des instances de SQL Server situées dans des environnements différents (par exemple, si vous avez des instances sur site et dans AWS).
Vous pouvez utiliser les groupes de disponibilité Always On pour la haute disponibilité ou la reprise après sinistre. Utilisez cette méthode dans les cas suivants :
+ Vous avez des exigences strictes en matière de RTO et de RPO. Les groupes de disponibilité Always On fournissent un RPO de quelques secondes et un RTO de quelques secondes à quelques minutes.
+ Vous souhaitez gérer et basculer sur un groupe de bases de données. Les groupes de disponibilité Always On prennent en charge 0 à 4 répliques secondaires en mode de validation synchrone pour SQL Server 2019.
+ Vous souhaitez utiliser le basculement automatique en mode de validation synchrone, sans avoir besoin d'un serveur témoin.
+ Vous souhaitez lire depuis la base de données secondaire.
+ Vous souhaitez synchroniser plusieurs destinations de base de données avec votre base de données principale.
À partir de SQL Server 2016 SP1, l'édition Standard de SQL Server fournit une haute disponibilité de base pour une seule base de données secondaire illisible et un seul écouteur par groupe de disponibilité. Il prend également en charge un maximum de deux nœuds par groupe de disponibilité.
# Instances de cluster Always On Failover
Les instances de cluster SQL Server Always On Failover (FCIs) utilisent le cluster Windows Server Failover (WSFC) pour fournir une haute disponibilité au niveau de l'instance de serveur. Une FCI est une instance unique de SQL Server installée sur les nœuds WSFC afin de fournir une haute disponibilité pour l'ensemble de l'installation de SQL Server. Si le nœud sous-jacent rencontre des défaillances matérielles, du système d'exploitation, des applications ou des services, tout ce qui se trouve à l'intérieur de l'instance SQL Server est déplacé vers un autre nœud WSFC. Cela inclut les bases de données système, les connexions SQL Server, les tâches de l'agent SQL Server et les certificats.
Un FCI est généralement préférable à un groupe de disponibilité Always On lorsque :
+ Vous utilisez l'édition Standard de SQL Server au lieu de l'édition Enterprise.
+ Vous disposez d'un grand nombre de petites bases de données par instance.
+ Vous modifiez constamment des objets au niveau de l'instance, tels que les tâches de l'agent SQL Server, les connexions, etc.
Il existe quatre options de déploiement FCIs sur AWS :
+ Amazon EBS Multi-Attach avec réservations persistantes
+ Serveur FSx de fichiers Amazon pour Windows
+ Amazon FSx pour NetApp ONTAP
+ Solutions proposées par des AWS partenaires
## Utilisation d'Amazon EBS Multi-Attach avec des réservations persistantes
[Amazon EBS Multi-Attach with NVMe reservations](https://docs.aws.amazon.com/ebs/latest/userguide/nvme-reservations.html) prend en charge la création de SQL Server avec des `io2` volumes FCIs Amazon EBS comme stockage partagé sur les clusters de basculement Windows Server. Cette fonctionnalité simplifie le processus de configuration du cluster de basculement en vous permettant de créer un cluster de basculement à l'aide de volumes Amazon `io2` EBS. Ces volumes ne peuvent être attachés qu'à des instances situées dans la même zone de disponibilité. Pour déployer des clusters de basculement Windows Server à l'aide de `io2` volumes Amazon EBS, vous devez utiliser les derniers AWS NVMe pilotes.
Les volumes Amazon EBS et les volumes de stockage d'instances sont exposés sous forme de périphériques en mode NVMe bloc sur les instances [basées sur Nitro](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances). Le [AWS NVMe pilote](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-nvme-drivers.html) doit être installé avec la [fonctionnalité de réservation persistante SCSI](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-nvme-drivers.html#configure-scsi-persistent-reservations) configurée lorsque vous utilisez des `io2` volumes Amazon EBS pour former WSFC et SQL Server. FCIs
Pour plus d'informations sur cette fonctionnalité, consultez le billet de AWS blog [Comment déployer un cluster de basculement SQL Server avec Amazon EBS Multi-Attach on](https://aws.amazon.com/blogs/modernizing-with-aws/how-to-deploy-a-sql-server-failover-cluster-with-amazon-ebs-multi-attach-on-windows-server/) Windows Server.
## Utilisation du serveur FSx de fichiers Amazon pour Windows
[Amazon FSx pour Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) fournit un stockage de fichiers partagé entièrement géré. Il réplique automatiquement le stockage de manière synchrone sur deux zones de disponibilité pour garantir une haute disponibilité. L'utilisation de FSx for Windows File Server pour le stockage de fichiers permet de simplifier et d'optimiser les déploiements de haute disponibilité de SQL Server sur Amazon EC2.
Avec Microsoft SQL Server, la haute disponibilité est généralement déployée sur plusieurs nœuds de base de données d'un WSFC, et chaque nœud a accès au stockage de fichiers partagé. Vous pouvez utiliser Windows File Server comme stockage partagé FSx pour les déploiements de haute disponibilité de SQL Server de deux manières : en tant que stockage pour les fichiers de données actifs et en tant que témoin de partage de fichiers SMB.
Pour savoir comment réduire la complexité et le coût liés à l'exécution des déploiements FCI de SQL Server en utilisant FSx Windows File Server, consultez le billet de blog [Simplifiez vos déploiements de haute disponibilité Microsoft SQL Server à l'aide d'Amazon FSx pour Windows](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/) File Server. Le billet de blog fournit également des step-by-step instructions pour déployer SQL Server FCIs en utilisant un système de fichiers Amazon FSx Multi-AZ comme solution de stockage partagé. Pour plus d'informations, consultez la documentation du [serveur de fichiers Amazon FSx pour Windows](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html).
## Utilisation d'Amazon FSx pour NetApp ONTAP
Amazon FSx for NetApp ONTAP est un service entièrement géré qui fournit un stockage de fichiers hautement fiable, évolutif, performant et riche en fonctionnalités, basé sur le NetApp système de fichiers ONTAP. FSx for ONTAP combine les fonctionnalités, les performances, les capacités et les opérations d'API habituelles des systèmes de NetApp fichiers avec l'agilité, l'évolutivité et la simplicité d'un service entièrement géré AWS .
FSx for ONTAP fournit un accès multiprotocole aux données via les protocoles NFS, SMB et iSCSI pour les systèmes Windows et Linux. Vous pouvez créer une architecture SQL Server Always On FCI hautement disponible, comme expliqué en détail dans le billet de blog [SQL Server High Availability Deployments Using Amazon FSx for NetApp ](https://aws.amazon.com/blogs/modernizing-with-aws/sql-server-high-availability-amazon-fsx-for-netapp-ontap/) ONTAP. FSx for ONTAP peut également fournir un moyen rapide de basculer votre environnement SQL Server vers un autre Région AWS afin de répondre aux exigences des objectifs de temps de restauration (RTO) et des objectifs de point de restauration (RPO). Pour plus d'informations, consultez le billet de blog Implémentation de la [haute disponibilité et de la reprise après sinistre pour une instance de cluster SQL Server Always-On Failover à l'aide FSx ](https://aws.amazon.com/blogs/storage/implementing-ha-and-dr-for-sql-server-always-on-failover-cluster-instance-using-amazon-fsx-for-netapp-ontap/) d'ONTAP.
Vous pouvez également les utiliser AWS Launch Wizard pour déployer des solutions SQL Server sur AWS, avec la prise en charge des groupes de disponibilité Always On et des déploiements à nœud unique. Launch Wizard prend en charge le déploiement de SQL Server Always on FCI sur Amazon EC2 FSx avec ONTAP comme stockage partagé. Ce service vous permet d'économiser du temps et des efforts en remplaçant un processus de déploiement manuel complexe par un assistant guidé basé sur une console qui accélère la migration de vos charges de travail SQL Server sur site qui reposent sur un stockage partagé. Pour plus d'informations sur la façon dont Launch Wizard peut vous aider à approvisionner et à configurer SQL Server FCIs en quelques heures, consultez le billet de blog [Simplify SQL Server Always On déploiements avec AWS Launch Wizard et Amazon FSx](https://aws.amazon.com/blogs/storage/simplify-sql-server-always-on-deployments-with-the-aws-launch-wizard-and-amazon-fsx/). Launch Wizard prend également en charge le déploiement de SQL Server Always [On en FCIs utilisant Amazon FSx pour Windows File Server](https://aws.amazon.com/fsx/windows/) comme solution de stockage partagé.
## Utilisation de solutions proposées par des AWS partenaires
+ Le [SIOS DataKeeper](https://us.sios.com/) fournit un support de basculement de clusters à haute disponibilité entre les zones de disponibilité Régions AWS et les zones de disponibilité. SIOS DataKeeper est disponible en. [AWS Marketplace](https://aws.amazon.com/marketplace/seller-profile?id=3c91e2f7-fc8d-4cce-a8aa-1e37abcb4408)
+ [DxEnterprise](https://dh2i.com/dxenterprise-high-availability/)de DH2i permet le basculement entièrement automatique des groupes de disponibilité de SQL Server dans Kubernetes et le basculement d'instance unifié pour Windows et Linux. D2HI est disponible en. [AWS Marketplace](https://aws.amazon.com/marketplace/seller-profile?id=4e97d4b7-3366-42fd-8be8-732d38c9e24b)
# FSx pour le serveur de fichiers Windows
FSx pour Windows File Server fournit un stockage de fichiers entièrement géré, hautement fiable et évolutif, accessible à l'aide du protocole SMB (Server Message Block). Il repose sur Windows Server et fournit un large éventail de fonctionnalités administratives telles que les quotas d'utilisateurs, la restauration de fichiers pour les utilisateurs finaux et l'intégration à Microsoft Active Directory (AD). Il propose des options de déploiement mono-AZ et multi-AZ, des sauvegardes entièrement gérées et le chiffrement des données au repos et en transit. Vous pouvez optimiser les coûts et les performances de vos charges de travail grâce aux options de stockage sur disques SSD (SSD) et sur disque dur (HDD). Vous pouvez également faire évoluer le stockage et modifier les performances de débit de votre système de fichiers à tout moment. FSx Le stockage de fichiers Amazon est accessible à partir d'instances de calcul Windows et Linux exécutées sur AWS site ou sur site.
Amazon FSx facilite le déploiement du stockage Windows partagé pour les déploiements SQL Server à haute disponibilité grâce à sa prise en charge des partages de fichiers disponibles en continu (CA) et des systèmes de fichiers plus petits. Cette option convient aux cas d'utilisation suivants :
+ En tant que stockage partagé utilisé par les nœuds SQL Server dans une instance WSFC.
+ En tant que témoin de partage de fichiers SMB pouvant être utilisé avec n'importe quel cluster SQL Server doté de WSFC.
Amazon FSx fournit des performances rapides avec un débit de base pouvant atteindre 2 GB/second par système de fichiers, des centaines de milliers d'IOPS et des latences constantes inférieures à la milliseconde.
Pour fournir les bonnes performances à vos instances SQL, vous pouvez choisir un niveau de débit indépendant de la taille de votre système de fichiers. Des niveaux de capacité de débit plus élevés s'accompagnent également de niveaux d'IOPS plus élevés que le serveur de fichiers peut transmettre aux instances SQL Server qui y accèdent.
La capacité de stockage détermine non seulement la quantité de données que vous pouvez stocker, mais également le nombre d'IOPS que vous pouvez effectuer sur le stockage. Chaque gigaoctet de stockage fournit 3 IOPS. Vous pouvez configurer chaque système de fichiers pour une taille maximale de 64 To.
Pour plus d'informations sur la configuration et l'utilisation FSx d'Amazon afin de réduire la complexité et les coûts de vos déploiements de haute disponibilité de SQL Server, consultez [Simplifier vos déploiements de haute disponibilité Microsoft SQL Server à l'aide FSx de Windows File Server sur le blog](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/) consacré au AWS stockage. Pour en savoir plus sur la création d'un nouveau partage CA, consultez la [FSx documentation relative au serveur de fichiers Windows](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/managing-file-shares.html#create-ca-share).
# Reprise après sinistre
De nombreuses entreprises mettent en œuvre la haute disponibilité pour leurs bases de données SQL Server, mais cela n'est pas suffisant pour les entreprises qui ont besoin d'une véritable résilience informatique. Nous vous recommandons de mettre en œuvre une solution de reprise après sinistre afin d'éviter les pertes de données et les interruptions de service des bases de données critiques. L'adoption d'une architecture de reprise après sinistre multirégionale pour vos déploiements SQL Server vous permet de :
+ Assurez la continuité des activités
+ Améliorez le temps de latence pour votre clientèle distribuée géographiquement
+ Répondez à vos exigences réglementaires et d'audit
Les options de reprise après sinistre incluent l'[expédition des journaux](ec2-log-shipping.md), les [groupes de disponibilité Always](ec2-always-on.md) On, les [instantanés Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-copy-snapshot.html) stockés dans Amazon S3 et répliqués entre les AWS régions, les [instances de cluster Always On Failover (FCIs)](ec2-fci.md) associées à des groupes de disponibilité Always On et les groupes de disponibilité distribués.
## Groupes de disponibilité distribués
Une architecture avec des groupes de disponibilité distribués constitue une approche optimale pour le déploiement multirégional de SQL Server. Un groupe de disponibilité distribué est un type spécial de groupe de disponibilité qui couvre deux groupes de disponibilité distincts. Vous pouvez le considérer comme un groupe de disponibilité composé de groupes de disponibilité. Les groupes de disponibilité sous-jacents sont configurés sur deux clusters WSFC différents.
Les groupes de disponibilité distribués sont faiblement couplés, ce qui signifie qu'ils ne nécessitent pas un seul cluster WSFC et qu'ils sont gérés par SQL Server. Comme les clusters WSFC sont gérés individuellement et que les transmissions sont principalement asynchrones entre deux groupes de disponibilité, il est plus facile de configurer la reprise après sinistre sur un autre site. Les répliques principales de chaque groupe de disponibilité synchronisent leurs propres répliques secondaires.
Les groupes de disponibilité distribués prennent uniquement en charge le basculement manuel pour le moment. Pour vous assurer qu'aucune donnée n'est perdue, arrêtez toutes les transactions sur les bases de données principales globales (c'est-à-dire sur les bases de données du groupe de disponibilité principal). Définissez ensuite le groupe de disponibilité distribuée sur validation synchrone.