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.
# Migration de base de données homogène pour SQL Server
AWS vous permet d'exécuter des bases de données SQL Server dans un environnement cloud. Pour les développeurs et les administrateurs de base de données, l'exécution de la base de données SQL Server dans le AWS cloud est très similaire à l'exécution de la base de données SQL Server dans un centre de données. Cette section décrit les options de migration de votre base de données SQL Server depuis un environnement sur site ou un centre de données vers le AWS cloud.
AWS propose trois options pour exécuter SQL Server sur AWS, comme décrit dans le tableau suivant.
****
| Option | Éléments principaux | En savoir plus |
| --- | --- | --- |
| SQL Server sur Amazon RDS | Service géré, qui facilite le provisionnement et les licences, est rentable, facile à configurer, à gérer et à entretenir. | [Section Amazon RDS pour SQL Server](rds-sql.md) |
| SQL Server sur Amazon RDS personnalisé | Service géré, mais vous conservez les droits d'administration sur la base de données et le système d'exploitation sous-jacent. | [Section Amazon RDS personnalisée pour SQL Server](rds-custom-sql.md) |
| SQL Server sur Amazon EC2 | Autogéré, offre un contrôle et une flexibilité complets. | [Section Amazon EC2 pour SQL Server](ec2-sql.md) |
| SQL Server sur VMware Cloud sur AWS | Configurez, dimensionnez et gérez vos charges de travail SQL Server sur VMware Cloud on AWS et intégrez-les Directory Serviceà Active Directory Connector et Amazon S3. | VMware Section [Cloud on AWS for SQL Server](vmware-sql.md) |
**Notice (Avis)**
Depuis le 30 avril 2024, VMware Cloud on n' AWS est plus revendu AWS ni par ses partenaires de distribution. Le service continuera d'être disponible via Broadcom. Nous vous encourageons à contacter votre AWS représentant pour plus de détails.
Les exigences de votre application, les caractéristiques de la base de données, les fonctionnalités, la capacité de croissance et la complexité globale de l'architecture détermineront l'option à choisir. Si vous migrez plusieurs bases de données SQL Server vers AWS, certaines d'entre elles conviennent parfaitement à Amazon RDS, tandis que d'autres peuvent être mieux adaptées pour être exécutées directement sur Amazon EC2. Vous avez peut-être des bases de données qui s'exécutent sur l'édition Enterprise de SQL Server, mais qui conviennent parfaitement à l'édition Standard de SQL Server. Vous souhaiterez peut-être également moderniser votre base de données SQL Server exécutée sous Windows pour l'exécuter sur un système d'exploitation Linux afin de réduire les coûts et les licences. De nombreux AWS clients exécutent plusieurs charges de travail de base de données SQL Server sur Amazon RDS, Amazon EC2 et Cloud on. VMware AWS
**Note**
Vous pouvez utiliser Migration Hub Orchestrator pour automatiser et orchestrer les migrations de vos bases de données SQL Server vers Amazon EC2 ou Amazon RDS en utilisant la sauvegarde et la restauration natives. Pour plus d'informations, consultez la [Orchestrateur de l'AWS Migration Hub section](mho.md).
# Amazon RDS for SQL Server
Amazon RDS for SQL Server est un service de base de données géré qui simplifie le provisionnement et la gestion de SQL Server sur. AWS Amazon RDS facilite la configuration, l'exploitation et le dimensionnement des déploiements de SQL Server dans le cloud. Avec Amazon RDS, vous pouvez déployer plusieurs versions de SQL Server (2014, 2016, 2017, 2019 et 2022) et plusieurs éditions (notamment Express, Web, Standard et Enterprise) en quelques minutes, avec une capacité de calcul rentable et redimensionnable. Vous pouvez provisionner les instances de base de données Amazon RDS for SQL Server avec un SSD à usage général ou un stockage SSD IOPS provisionné. (Pour plus de détails, consultez la section [Types de stockage Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html#Concepts.Storage) dans la AWS documentation.) Le SSD IOPS provisionné est conçu pour fournir des I/O performances rapides, prévisibles et cohérentes, et est optimisé pour les charges de travail de base de données transactionnelles (OLTP) intensives en E/S.
Amazon RDS vous permet de vous concentrer sur le développement d'applications, car il gère les tâches fastidieuses d'administration des bases de données, notamment le provisionnement, les sauvegardes, l'application de correctifs logiciels, la surveillance et le dimensionnement du matériel. Amazon RDS for SQL Server propose également des déploiements multi-AZ et des répliques de lecture (pour l'édition SQL Server Enterprise) afin de garantir une disponibilité, des performances, une évolutivité et une fiabilité élevées pour les charges de travail de production.
## Quand choisir Amazon RDS
Amazon RDS pour SQL Server est une option de migration lorsque :
+ Vous souhaitez vous concentrer sur votre activité et vos applications, et vous devez vous occuper de tâches complexes et indifférenciées telles que le provisionnement de la base de données, la gestion des tâches de sauvegarde et de restauration, la gestion des correctifs de sécurité, les mises à niveau mineures des versions de SQL Server et la gestion du stockage. AWS
+ Vous avez besoin d'une solution de base de données à haute disponibilité et vous souhaitez tirer parti de la réplication multi-AZ synchrone par bouton-poussoir proposée par Amazon RDS, sans avoir à configurer et à gérer manuellement la mise en miroir des bases de données, les clusters de basculement ou les groupes de disponibilité Always On.
+ Vous souhaitez payer la licence SQL Server dans le cadre du coût de l'instance sur une base horaire au lieu de réaliser un investissement initial important.
+ La taille de votre base de données et vos besoins en IOPS sont pris en charge par Amazon RDS for SQL Server. Consultez la section [Amazon RDS DB Instance Storage](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) dans la AWS documentation pour connaître les limites maximales actuelles.
+ Vous ne souhaitez pas gérer les sauvegardes ou les point-in-time restaurations de votre base de données.
+ Vous souhaitez vous concentrer sur des tâches de haut niveau, telles que le réglage des performances et l'optimisation des schémas, plutôt que sur l'administration quotidienne de la base de données.
+ Vous souhaitez augmenter ou diminuer le type d'instance en fonction de vos modèles de charge de travail sans vous soucier de la complexité des licences.
Après avoir évalué les exigences de votre base de données et de votre projet, si vous décidez de migrer vers Amazon RDS for SQL Server, consultez les informations fournies dans les sections suivantes, ainsi que [les meilleures pratiques de migration](best-practices.md) dont nous parlerons plus loin dans ce guide.
Pour connaître les fonctionnalités, versions et options de SQL Server actuellement prises en charge, consultez les fonctionnalités d'[Amazon RDS for SQL Server](https://aws.amazon.com/rds/sqlserver/features/) sur AWS le site Web[, Choosing between Amazon EC2 and](comparison.md) Amazon RDS plus loin dans ce guide[, et Microsoft SQL Server on](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html) Amazon AWS RDS dans la documentation. Si vous passez à Amazon RDS Custom, assurez-vous de consulter les [exigences et les limites d'Amazon RDS Custom pour SQL Server](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-reqs-limits-MS.html).
## Haute disponibilité
Amazon RDS fournit une haute disponibilité et un support de basculement pour les bases de données déployées avec l'option Multi-AZ. Lorsque vous approvisionnez votre base de données avec l'option Multi-AZ, Amazon RDS provisionne et gère automatiquement une instance de secours synchrone dans une autre zone de disponibilité. La base de données principale réplique les données de manière synchrone vers l'instance de secours. En cas de problème, Amazon RDS répare automatiquement l'instance défectueuse et rétablit la synchronisation. En cas de défaillance de l'infrastructure ou d'interruption de la zone de disponibilité, Amazon RDS effectue un basculement automatique vers l'instance de secours. Le basculement ne se produit que si les bases de données principale et de secours sont entièrement synchronisées. Comme le point de terminaison reste le même pour les instances principales et de secours, vous pouvez reprendre les opérations de base de données dès que le basculement est terminé, sans effectuer d'intervention manuelle. Le temps de basculement dépend du temps nécessaire pour terminer le processus de restauration. Le délai de basculement est allongé pour les transactions de volume important.
Le schéma suivant illustre l'option de déploiement multi-AZ d'Amazon RDS for SQL Server.
![\[Amazon RDS for SQL Server in a Multi-AZ configuration\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/migration-sql-server/images/sql-migration-rds-ha.png)
Lorsque vous configurez SQL Server dans une configuration multi-AZ, Amazon RDS configure automatiquement une instance de base de données de secours à l'aide de la mise en miroir de bases de données ou de groupes de disponibilité Always On, en fonction de la version de SQL Server que vous déployez. Les versions et éditions spécifiques de SQL Server sont répertoriées dans la [documentation Amazon RDS.](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_SQLServerMultiAZ.html)
Dans les déploiements multi-AZ, les opérations telles que le dimensionnement des instances ou les mises à niveau du système telles que l'application de correctifs au système d'exploitation (OS) sont appliquées d'abord sur l'instance de secours, avant le basculement automatique de l'instance principale, pour une disponibilité accrue.
En raison de l'optimisation du basculement de SQL Server, certaines charges de travail peuvent générer une charge d'E/S plus importante sur l'instance de secours que sur l'instance principale, en particulier dans les déploiements de mise en miroir de bases de données. Cette fonctionnalité peut entraîner des IOPS plus élevées sur l'instance de secours. Nous vous recommandons de prendre en compte les besoins en IOPS maximaux des instances principale et de secours lorsque vous provisionnez le type de stockage et les IOPS de votre instance de base de données Amazon RDS for SQL Server. Vous pouvez également spécifier`MultiSubnetFailover=True`, si votre pilote client le prend en charge, de réduire considérablement le temps de basculement.
### Limitations
+ L'option Multi-AZ n'est pas disponible pour les éditions SQL Server Express et Web. Il n'est disponible que pour les éditions SQL Server Standard et Enterprise.
+ Vous ne pouvez pas configurer l’instance de base de données de secours pour accepter l’activité de lecture de base de données.
+ Le multi-AZ entre régions n'est pas pris en charge.
+ Dans Amazon RDS, vous pouvez envoyer une commande d'arrêt à une instance de base de données autonome et maintenir l'instance dans un état arrêté afin d'éviter d'encourir des frais de calcul. Vous ne pouvez pas arrêter une instance de bases de données Amazon RDS for SQL Server dans une configuration multi-AZ. Au lieu de cela, vous pouvez mettre fin à l'instance, prendre un instantané final avant la résiliation et recréer une nouvelle instance Amazon RDS à partir de l'instantané lorsque vous en avez besoin. Vous pouvez également supprimer d'abord la configuration multi-AZ, puis arrêter l'instance. Au bout de sept jours, votre instance arrêtée redémarrera afin que toute maintenance en attente puisse être appliquée.
Pour connaître les limites supplémentaires, consultez les [notes et recommandations relatives au déploiement multi-AZ de Microsoft SQL Server](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_SQLServerMultiAZ.html#USER_SQLServerMultiAZ.Recommendations) dans la documentation Amazon RDS.
## Réplicas en lecture
Les répliques en lecture assurent l'évolutivité et l'équilibrage de charge. Une réplique en lecture de SQL Server est une copie physique d'une instance de base de données Amazon RDS for SQL Server utilisée en lecture seule. Amazon RDS contribue à réduire la charge sur l'instance de base de données principale en transférant les charges de travail en lecture seule vers l'instance de base de données en lecture réplique. Les mises à jour apportées à votre instance de base de données principale sont copiées de manière asynchrone sur l'instance de réplication lue.
Lorsque vous demandez une réplique en lecture, Amazon RDS prend un instantané de l'instance de base de données source, et cet instantané devient la réplique en lecture. Il n'y a aucune interruption lors de la création et de la suppression d'une réplique en lecture. Amazon RDS for SQL Server met à niveau la base de données principale immédiatement après la mise à niveau des répliques en lecture, quelle que soit la fenêtre de maintenance. Chaque réplique de lecture est fournie avec un point de terminaison distinct que vous utilisez pour vous connecter à la base de données de répliques de lecture.
Amazon RDS for SQL Server facilite la création de répliques en lecture en configurant les groupes de disponibilité Always On et en maintenant des connexions réseau sécurisées entre une instance de base de données principale et ses répliques en lecture.
Vous pouvez configurer une réplique en lecture dans la même AWS région que votre base de données principale ou dans une autre région. Vous pouvez créer jusqu'à cinq répliques de lecture pour une instance de base de données source.
**Note**
Les répliques en lecture ne sont disponibles qu'avec les versions et éditions de SQL Server suivantes :
SQL Server 2017 Enterprise Edition 14.00.3049.1 ou version ultérieure
SQL Server 2016 Enterprise Edition 13.00.5216.0 ou version ultérieure
Les versions et éditions de SQL Server qui prennent en charge la mise en miroir de bases de données pour les environnements multi-AZ ne proposent pas de répliques en lecture.
Le schéma suivant illustre une instance de base de données Amazon RDS for SQL Server dans un environnement multi-AZ avec une réplique en lecture dans une autre zone de disponibilité de la AWS même région. Toutes les AWS régions ne proposent pas plus de deux zones de disponibilité. Vous devez donc [vérifier la région](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) que vous prévoyez d'utiliser avant d'adopter cette stratégie.
![\[Amazon RDS for SQL Server with a read replica in another Availability Zone in the same Region\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/migration-sql-server/images/sql-migration-rds-rr-same-region.png)
Une réplique en lecture de SQL Server n'autorise pas les opérations d'écriture. Cependant, vous pouvez promouvoir la réplique lue pour la rendre inscriptible. Une fois que vous l'avez promue, vous ne pouvez pas la reconvertir en une réplique lue. Elle deviendra une instance de base de données unique et autonome qui n'a aucune relation avec son instance de base de données principale d'origine. Les données de la réplique de lecture promue correspondront aux données de l'instance de base de données source jusqu'au moment où la demande de promotion a été faite. La version du moteur de base de données SQL Server de l'instance de base de données source et toutes ses répliques de lecture seront identiques.
Pour une réplication efficace, nous recommandons ce qui suit :
+ Configurez chaque réplique de lecture avec les mêmes ressources de calcul et de stockage que l'instance de base de données source.
+ Vous devez activer les sauvegardes automatiques sur l'instance de base de données source en définissant la période de rétention des sauvegardes sur une valeur autre que 0 (zéro).
+ L'instance de base de données source doit être déployée dans un environnement multi-AZ avec des groupes de disponibilité Always On.
Pour connaître le support, les éditions et les limites des versions de SQL Server, consultez la section [Lire les limites relatives aux répliques avec SQL Server](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.ReadReplicas.html#SQLServer.ReadReplicas.Limitations) dans la documentation Amazon RDS.
Pour plus d'informations sur l'utilisation des répliques en lecture, consultez les [sections Utilisation des répliques en lecture](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) et [Utilisation des répliques en lecture SQL Server pour Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.ReadReplicas.html) dans la documentation. AWS Pour plus d’informations sur la tarification du transfert des données, consultez [Tarification d’Amazon RDS](https://aws.amazon.com/rds/pricing/).
## Reprise après sinistre
Avec Amazon RDS for SQL Server, vous pouvez créer une stratégie de reprise après sinistre (DR) fiable et interrégionale. Les principales raisons de créer une solution de reprise après sinistre sont la continuité des activités et la conformité :
+ Une stratégie de reprise après sinistre efficace vous aide à maintenir vos systèmes opérationnels avec un minimum d'interruptions, voire aucune, en cas de catastrophe. Une stratégie de reprise après sinistre interrégionale fiable et efficace permet à votre entreprise de continuer à fonctionner même si une région entière est hors ligne.
+ Une solution de reprise après sinistre interrégionale vous aide à répondre aux exigences d'audit et de conformité.
L'objectif du point de reprise (RPO), l'objectif du temps de restauration (RTO) et le coût sont trois indicateurs clés à prendre en compte lors de l'élaboration de votre stratégie de reprise après sinistre. Pour d'autres options permettant de fournir des répliques entre régions, consultez. [AWS Marketplace](https://aws.amazon.com/marketplace/) Pour plus d'informations sur ces approches, consultez la section Reprise [après sinistre interrégionale d'Amazon RDS for SQL Server](https://aws.amazon.com/blogs/database/cross-region-disaster-recovery-of-amazon-rds-for-sql-server/) sur AWS le blog de base de données.
# Amazon RDS Custom for SQL Server
Si vous ne parvenez pas à passer à un service entièrement géré tel qu'Amazon RDS en raison des exigences de personnalisation des applications tierces, vous pouvez migrer vers Amazon RDS Custom for SQL Server. Avec Amazon RDS Custom, vous pouvez conserver les droits administratifs sur la base de données et son système d'exploitation sous-jacent afin d'activer les applications dépendantes.
## Quand choisir Amazon RDS Custom pour SQL Server
Amazon RDS Custom pour SQL Server est une bonne option de migration lorsque :
+ Vous disposez d'applications existantes, personnalisées et packagées qui nécessitent un accès au système d'exploitation et à l'environnement de base de données sous-jacents.
+ Vous avez besoin d'un accès utilisateur administratif pour répondre aux exigences de déploiement d'applications basées sur les fournisseurs.
+ Vous devez accéder au système d'exploitation sous-jacent pour configurer les paramètres, installer les correctifs et activer les fonctionnalités natives afin de répondre aux exigences de l'application dépendante.
+ Vous souhaitez accéder à l'environnement de base de données et le personnaliser (en appliquant des correctifs de base de données personnalisés ou en modifiant les packages du système d'exploitation) afin de répondre aux besoins de votre base de données et de vos applications.
## Comment ça marche
Pour utiliser Amazon RDS Custom pour SQL Server, consultez les [exigences](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-reqs-limits-MS.html#custom-reqs-limits.reqsMS) de la documentation Amazon RDS Custom pour SQL Server. Vous devez d'abord configurer votre environnement pour Amazon RDS Custom for SQL Server, comme expliqué dans la documentation [Amazon RDS.](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-setup-sqlserver.html) Une fois l'environnement configuré, suivez ces étapes, illustrées dans le schéma suivant :
1. Créez une instance de base de données Amazon RDS Custom pour SQL Server à partir d'une version du moteur SQL Server proposée par Amazon RDS Custom.
Amazon RDS Custom pour SQL Server prend actuellement en charge SQL Server 2019 et SQL Server 2022 sous Windows 2019 avec les [classes d'instances de base de données prises en charge](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-reqs-limits-MS.html#custom-reqs-limits.instancesMS) répertoriées dans la documentation. Pour plus d'informations, consultez [Création d'une instance de base de données personnalisée RDS pour SQL Server](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-creating-sqlserver.html#custom-creating-sqlserver.create).
1. Connectez votre application au point de terminaison de l'instance de base de données personnalisée Amazon RDS.
Pour plus d'informations, consultez [Connexion à votre instance de base de données personnalisée RDS à l'aide AWS Systems Manager et Connexion à votre instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-creating-sqlserver.html#custom-creating-sqlserver.ssm) [de base de données personnalisée RDS à l'aide de RDP](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-creating-sqlserver.html#custom-creating-sqlserver.rdp).
1. (Facultatif) Accédez à l'hôte pour personnaliser votre logiciel.
1. Surveillez les notifications et les messages générés par l'automatisation personnalisée d'Amazon RDS.
Pour plus d'informations sur ces étapes, consultez la [documentation personnalisée Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-sqlserver.workflow.html).
![\[Flux de travail Amazon RDS personnalisé pour SQL Server\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/migration-sql-server/images/custom-rds-sql-server.png)
Amazon RDS Custom est un service de base de données géré qui automatise la configuration, le fonctionnement et le dimensionnement des bases de données dans le cloud tout en vous donnant accès au système d'exploitation et à l'environnement de base de données sous-jacents. Dans Amazon RDS Custom pour SQL Server, vous pouvez installer des logiciels pour exécuter des applications et des agents personnalisés. Étant donné que vous disposez d'un accès privilégié à l'hôte, vous pouvez modifier les systèmes de fichiers pour prendre en charge des applications héritées. Vous pouvez également appliquer des correctifs de base de données personnalisés ou modifier des packages de système d'exploitation sur vos instances de base de données personnalisées Amazon RDS.
Si vous souhaitez personnaliser votre instance, vous pouvez suspendre l'automatisation personnalisée d'Amazon RDS pendant 24 heures au maximum, puis la reprendre une fois votre travail de personnalisation terminé. La suspension de l'automatisation empêche l'automatisation d'Amazon RDS d'interférer directement avec vos personnalisations.
Lorsque vous reprenez l'automatisation, le [périmètre de support](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-troubleshooting.html#custom-troubleshooting.support-perimeter) détermine si votre personnalisation de la base de données ou de l'environnement du système d'exploitation interfère ou interrompt l'automatisation personnalisée d'Amazon RDS. Amazon RDS Custom prend en charge la personnalisation de l'hôte et de l'environnement de base de données tant que vos modifications ne placent pas l'instance de base de données en dehors du périmètre de support. Les vérifications du périmètre de support sont effectuées toutes les 30 minutes par défaut et ont également lieu après des événements tels que la suppression d'instantanés ou la désinstallation de l'agent personnalisé Amazon RDS, qui surveille l'instance de base de données. L'agent Amazon RDS Custom est un composant essentiel pour garantir le fonctionnement d'Amazon RDS Custom. Si vous désinstallez l'agent, Amazon RDS Custom exécute la vérification du périmètre de support au bout d'une minute et déplace l'instance de base de données en dehors du périmètre de support.
Lorsque vous configurez une instance de base de données Amazon RDS Custom pour SQL Server, la licence logicielle est incluse. En d'autres termes, il n'est pas nécessaire d'acheter des licences SQL Server séparément. Pour plus d'informations sur les licences, consultez la section 10.5 des [conditions AWS de service](https://aws.amazon.com/service-terms/). Si vous avez un compte AWS Premium Support actif, vous pouvez contacter le support AWS Premium pour Amazon RDS Custom pour les problèmes spécifiques à SQL Server.
Amazon RDS Custom for SQL Server est pris en charge dans une sélection limitée Régions AWS et avec un nombre limité de classes d'instances de base de données. Pour connaître ces limitations et d'autres, consultez la page [des exigences et des limites](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-reqs-limits-MS.html) de la documentation Amazon RDS Custom for SQL Server.
Si vous disposez d'une base de données SQL Server sur site, vous pouvez suivre le processus décrit dans la [documentation Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-migrating.html) pour la migrer vers Amazon RDS Custom for SQL Server à l'aide d'utilitaires de sauvegarde et de restauration natifs.
Pour plus d'informations, consultez les ressources suivantes :
+ [Nouveau — Amazon RDS Custom pour SQL Server est généralement disponible](https://aws.amazon.com/blogs/aws/new-amazon-rds-custom-for-sql-server-is-generally-available/) (blog d'AWS actualités)
+ [Configuration de la réplication SQL Server entre Amazon RDS Custom pour SQL Server et Amazon RDS for SQL Server](https://aws.amazon.com/blogs/database/configure-sql-server-replication-between-amazon-rds-custom-for-sql-server-and-amazon-rds-for-sql-server/)AWS (blog de base de données)
+ [Automatisez la migration de SQL Server vers Amazon RDS sur site ou Amazon EC2 pour SQL Server à l'aide de l'envoi de journaux personnalisés (blog de base](https://aws.amazon.com/blogs/database/automate-on-premises-or-amazon-ec2-sql-server-to-amazon-rds-for-sql-server-migration-using-custom-log-shipping/) de données)AWS
+ [Configurer la haute disponibilité avec les groupes de disponibilité Always On sur Amazon RDS Custom for SQL Server](https://aws.amazon.com/blogs/database/configure-high-availability-with-always-on-availability-groups-on-amazon-rds-custom-for-sql-server/) (blog AWS de base de données)
+ [Commencez à utiliser Amazon RDS Custom pour SQL Server à l'aide d'un CloudFormation modèle (configuration réseau)](https://aws.amazon.com/blogs/database/get-started-with-amazon-rds-custom-for-sql-server-using-an-aws-cloudformation-template-network-setup/) (blog de AWS base de données)
+ [Migrer les charges de travail SQL Server locales vers Amazon RDS Custom for SQL Server à l'aide de groupes de disponibilité distribués](https://aws.amazon.com/blogs/database/migrate-on-premises-sql-server-workloads-to-amazon-rds-custom-for-sql-server-using-distributed-availability-groups/) (AWS blog de base de données)
+ [Optimisez les coûts de SQL Server en utilisant Bring your own media (BYOM) sur Amazon RDS Custom for SQL Server](https://aws.amazon.com/blogs/database/optimize-your-sql-server-costs-by-using-bring-your-own-media-byom-on-amazon-rds-custom-for-sql-server/) (blog de AWS base de données)
# 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.
# VMware Cloud activé AWS pour SQL Server
**Notice (Avis)**
Depuis le 30 avril 2024, VMware Cloud on n' AWS est plus revendu AWS ni par ses partenaires de distribution. Le service continuera d'être disponible via Broadcom. Nous vous encourageons à contacter votre AWS représentant pour plus de détails.
[VMware Cloud on AWS](https://aws.amazon.com/vmware/) est une offre cloud intégrée développée conjointement par AWS et VMware. SQL Server s'intègre facilement à VMware Cloud on AWS. Cette option de migration vous permet de tirer parti de votre investissement existant dans la virtualisation.
Vous pouvez accéder au VMware Cloud AWS sur une base horaire, à la demande ou sous forme d'abonnement. Il inclut les mêmes VMware technologies de base que celles que vous exécutez dans vos centres de données, notamment vSphere Hypervisor (ESXi), Virtual SAN (vSAN) et la plate-forme de virtualisation réseau NSX, et est conçu pour fournir une expérience efficace et fluide de gestion de vos bases de données SQL Server. Vous pouvez adapter le stockage, le calcul et la mémoire de vos bases de données SQL Server sur le VMware Cloud AWS en quelques minutes.
VMware Cloud on AWS s'exécute directement sur le matériel physique, mais tire parti des fonctionnalités réseau et matérielles conçues pour prendre en charge le modèle d'infrastructure AWS axé sur la sécurité. Cela signifie que la pile de VMware virtualisation s'exécute sur l' AWS infrastructure sans qu'il soit nécessaire d'utiliser la virtualisation imbriquée.
VMware Cloud on AWS facilite la configuration, le dimensionnement et l'exploitation des charges de travail de vos bases de données SQL Server. AWS Il fournit des solutions de haute disponibilité, s'intègre à Active Directory sur site et donne accès à AWS des services tels que AWS Directory Service for Microsoft Active Directory AD Connector, Amazon Route 53 CloudWatch, Amazon et Amazon S3. Vous pouvez stocker vos sauvegardes dans Amazon S3 et moderniser et simplifier votre processus de reprise après sinistre.
## Quand choisir VMware Cloud on AWS
VMware Cloud on AWS est une option pour votre base de données SQL Server lorsque :
+ Vos bases de données SQL Server s'exécutent déjà dans un centre de données sur site dans un environnement virtualisé vSphere.
+ Vous disposez d'un grand nombre de bases de données et vous avez besoin d'une migration rapide (par exemple, quelques heures seulement) vers le cloud pour l'une des raisons suivantes, sans que l'équipe de migration n'ait à effectuer de travail supplémentaire :
+ Extension du centre de données. Vous avez besoin d'une capacité à la demande pour exécuter des postes de travail virtualisés, publier des applications ou fournir un development/testing environnement.
+ Reprise après sinistre. Vous souhaitez configurer un nouveau système de reprise après sinistre ou remplacer votre système existant.
+ Migration vers le cloud. Vous souhaitez migrer l'ensemble de votre centre de données vers le cloud ou actualiser votre infrastructure.
Si votre base de données SQL Server nécessite plus de 80 000 IOPS, vous pouvez utiliser vSAN.
Pour plus d'informations, consultez [In the Works — VMware Cloud on AWS](https://aws.amazon.com/blogs/aws/in-the-works-vmware-cloud-on-aws/) sur le blog AWS News et [Deploy Microsoft SQL Server on VMware Cloud AWS sur](https://aws.amazon.com/solutionspace/solutions/sql-server-vmware-cloud-on-aws/) le AWS site Web.