Choisissez une solution de haute disponibilité et de reprise après sinistre

Présentation

Nous vous recommandons de concevoir une architecture pour le déploiement de votre SQL serveur AWS qui réponde aux besoins de votre entreprise tout en respectant vos objectifs de reprise après sinistre (DR), notamment votre objectif de temps de restauration (RTO) et votre objectif de point de reprise (RPO). Les solutions suivantes peuvent vous aider à concevoir la bonne architecture pour le SQL serveur sur Amazon Elastic Compute Cloud (AmazonEC2) tout en optimisant les coûts liés aux charges de travail de votre SQL serveur.

• SQLGroupes de disponibilité Server Always On — Les groupes de disponibilité SQLServer Always On fournissent une haute disponibilité et une reprise après sinistre (HA/DR) solutions for SQL Server databases. An availability group consists of a set of user databases that fail over together. Always On availability groups also provide redundancy at the database level, but don't require shared storage—each replica has its own local storage. You can deploy this feature as an HA/DRsolution). Pour plus d'informations, voir Qu'est-ce qu'un groupe de disponibilité permanent ? dans la documentation Microsoft.

• SQLInstances de cluster Server Always On failover (FCI) — SQLServer Always On FCIs utilise Windows Server Failover Clustering (WSFC) pour fournir la haute disponibilité au niveau de l'instance de SQL serveur. FCIsnécessitent un stockage partagé pour héberger les bases de données. Vous pouvez utiliser le stockage par blocs partagé ou le stockage de fichiers partagé. Par exemple, vous pouvez utiliser Amazon FSx pour Windows File Server ou Amazon FSx for NetApp ONTAP comme solution de stockage partagé avec plusieurs zones de disponibilité. Pour plus d'informations, consultez la section Instances de cluster Always On Failover (SQLserveur) dans la documentation Microsoft.

• SIOS DataKeeper— SIOS DataKeeper peut vous aider à répondre aux exigences de haute disponibilité et de reprise après sinistre en activant un SQL serveur FCI qui couvre à la fois les zones de disponibilité et Régions AWS. SIOS DataKeeper crée un environnement virtuel en cluster en SAN utilisant les volumes Amazon Elastic Block Store (AmazonEBS) locaux et utilise la réplication synchrone entre les zones de disponibilité pour la haute disponibilité, tout en utilisant la réplication asynchrone entre les régions et pour la reprise après sinistre. Pour plus d'informations, consultez la section Protection de haute disponibilité pour les applications Windows dans la SIOS documentation.

• Groupes de disponibilité distribués — Les groupes de disponibilité distribués sont un type spécial de groupe de disponibilité qui s'étend sur deux groupes de disponibilité Always On distincts. Un groupe de disponibilité peut résider dans deux régions distinctes (par exemple, us-east-1 etus-west-1). Vous pouvez considérer un groupe de disponibilité distribué comme un groupe de disponibilité composé de groupes de disponibilité, car les groupes de disponibilité Always On sous-jacents sont configurés sur deux WSFC clusters différents. SQLL'édition Server Enterprise est requise pour déployer des groupes de disponibilité distribués. Pour plus d'informations, consultez la section Groupes de disponibilité distribués dans la documentation Microsoft.

• Expédition des journaux : vous pouvez implémenter l'expédition des journaux pour protéger vos bases de données dans plusieurs régions, dans les rares cas où une région est affectée et devient indisponible. En fonction de la transaction et de la fréquence d'expédition des journaux, vous pouvez y parvenir RPO RTO en quelques minutes. Pour plus d'informations, consultez la section À propos de l'expédition du journal (SQLserveur) dans la documentation Microsoft.

• AWS Elastic Disaster Recovery— Elastic Disaster Recovery est une application logicielle en tant que service (SaaS) qui gère la réplication des serveurs depuis n'importe quelle infrastructure à AWS des fins de reprise après sinistre. Vous pouvez également utiliser Elastic Disaster Recovery pour répliquer le SQL serveur d'une région à l'autre. Elastic Disaster Recovery est une solution basée sur un agent qui réplique des machines virtuelles complètes, y compris le système d'exploitation, toutes les applications installées et toutes les bases de données dans une zone intermédiaire. Pour plus d'informations, consultez Qu'est-ce qu'Elastic Disaster Recovery ? dans la documentation d'Elastic Disaster Recovery.

• AWS Database Migration Service (AWS DMS) — AWS DMS prend en charge la migration en direct des données vers et depuis AWS, y compris une autre région. Vous pouvez utiliser cette fonctionnalité pour configurer une instance de SQL serveur distincte dans une région différente afin de servir de base de données de reprise après sinistre. Pour plus d'informations, voir Qu'est-ce que c'est AWS Database Migration Service ? dans la AWS DMS documentation.

SQLGroupes de disponibilité du serveur Always On

Si vous utilisez l'édition SQL Server Enterprise uniquement pour un groupe de disponibilité Always On à haute disponibilité, vous pouvez passer à l'édition SQL Server Standard en tirant parti des groupes de disponibilité de base. Vous pouvez réduire les coûts de 65 à 75 % en utilisant des groupes de disponibilité de base au lieu de groupes de disponibilité Always On.

Note

Pour plus d'informations sur les différences de coûts entre les différentes éditions de SQL Server, consultez la section Comparer les éditions de SQL Server de ce guide.

Fonctions

• Disponible dans l'édition SQL Server Standard

• Limite de deux répliques (principale et secondaire)

• Aucun accès en lecture sur la réplique secondaire

• Aucun contrôle d'intégrité sur les répliques secondaires

Limites

• Support pour une seule base de données de disponibilité par groupe de disponibilité

• Les groupes de disponibilité de base ne peuvent pas faire partie d'un groupe de disponibilité distribué

Le schéma suivant montre un exemple d'architecture pour une solution Windows Server Failover Cluster.

SQLInstances de cluster Server Always On failover

Vous pouvez utiliser des instances de cluster failover (FCIs) pour garantir la continuité des opérations de base de données tout en minimisant les temps d'arrêt et en réduisant le risque de perte de données. FCIsoffrez une solution fiable si vous recherchez une haute disponibilité pour la base de données de votre SQL serveur sans configuration de réplication en lecture.

Contrairement aux groupes de disponibilité, ils FCIs peuvent fournir une solution de basculement fiable sans nécessiter l'édition SQL Server Enterprise. FCIsExigez plutôt uniquement les licences de l'édition SQL Server Standard. Vous pouvez l'utiliser FCIs pour réduire les coûts de licence des SQL serveurs de 65 à 75 %.

Note

Pour plus d'informations sur les différences de coûts entre les éditions SQL Server, consultez la section Comparer les éditions SQL Server de ce guide.

Éléments à prendre en compte :

• Amazon FSx pour Windows File Server propose une solution puissante pour répondre aux exigences de stockage FCI partagé de votre SQL serveur. Vous pouvez utiliser Windows File Server FSx pour éviter d'avoir à acheter une licence pour une solution de réplication du stockage et pour gérer vous-même le stockage partagé. Cela peut entraîner d'importantes économies de 30 à 40 %. Pour plus d'informations, consultez le billet Simplifiez vos déploiements de haute disponibilité Microsoft SQL Server à l'aide d'Amazon FSx pour Windows File Server sur le blog sur le AWS stockage.

• Grâce au résumé des avantages de la Software Assurance (téléchargeablePDF) et au modèle Bring Your Own License (BYOL), vous pouvez bénéficier des avantages du basculement passif, à condition que le serveur secondaire soit passif. Cela permet de réaliser des économies en termes de SQL licences, car vous n'avez pas à fournir de licences au nœud passif du cluster.

Le schéma suivant montre un exemple d'architecture pour un SQL serveur à FCI l'aide d'FSxun serveur de fichiers Windows.

SIOS DataKeeper

Nous vous recommandons de prendre en compte les exigences de stockage partagé si vous prévoyez de déployer FCIs le SQL serveur sur AWS. Les installations sur site traditionnelles utilisent généralement un réseau de stockage (SAN) pour répondre aux exigences de stockage partagé, mais cette option n'est pas viable. AWS Amazon FSx pour Windows File Server est la solution de stockage recommandée pour SQL Server FCI on AWS, mais elle présente des limites qui empêchent d'ajouter des serveurs de cluster dans différents serveurs Régions AWS.

Vous pouvez l'utiliser SIOS DataKeeperpour créer un SQL serveur FCI qui couvre à la fois les zones de disponibilité et les régions tout en réduisant les coûts de 58 à 71 %. SIOS DataKeeper peut vous aider à bénéficier des avantages de haute disponibilité deFCI. Cela constitue SIOS DataKeeper une solution rentable et fiable pour les organisations.

Tenez compte des avantages supplémentaires suivants liés à l'utilisation SIOS DataKeeper :

• SIOS DataKeeper crée un environnement virtuel SAN en cluster à l'aide de EBS volumes locaux et utilise la réplication synchrone entre les zones de disponibilité pour une haute disponibilité. Pour la reprise après sinistre, SIOS DataKeeper utilise la réplication asynchrone entre les régions.

• SIOS DataKeeper fournit des fonctionnalités de clustering de niveau professionnel en utilisant l'édition SQL Server Standard. Cela permet de réduire les coûts de licence des SQL serveurs de 65 à 75 % par rapport à la mise en œuvre de la haute disponibilité avec les groupes de disponibilité SQL Server Always On qui utilisent l'édition SQL Server Enterprise. Vous pouvez ainsi créer un environnement de SQL serveur hautement disponible, flexible et rentable qui répond aux besoins de votre entreprise. SIOS DataKeeper

Note

Pour plus d'informations sur les différences de coûts entre les éditions SQL Server, consultez la section Comparer les éditions SQL Server de ce guide.

Le schéma suivant montre un exemple d'architecture pour un SQL serveur FCI utilisant une SAN solution virtuelle en cluster.

Groupes de disponibilité Always On

Vous pouvez utiliser les groupes de disponibilité Always On à des fins de haute disponibilité et de reprise après sinistre. Vous pouvez atteindre une haute disponibilité en déployant le SQL serveur dans deux zones de disponibilité d'une même région. Vous pouvez réaliser une reprise après sinistre en étendant les groupes de disponibilité à toutes les régions.

Le schéma suivant montre un exemple d'architecture pour une solution basée sur les groupes de disponibilité Always On. Les répliques de la région 1 du diagramme utilisent un commit synchrone, qui permet un basculement automatique du groupe de disponibilité. La réplique de la région 2 utilise un commit asynchrone, qui nécessitera un basculement manuel du groupe de disponibilité.

Groupes de disponibilité distribués

Pour les déploiements de SQL serveurs critiques où vous ne pouvez pas faire de compromis sur la fiabilité ou la reprise après sinistre, nous recommandons une approche multirégionale. Répartir vos groupes de disponibilité sur plusieurs régions est la solution la plus résiliente pour assurer la continuité des activités et minimiser les temps d'arrêt.

Cette architecture tire pleinement parti des fonctionnalités d'Amazon FSx pour Windows File Server, notamment le stockage partagé, la réplication synchrone au niveau des blocs et le serveur. SQL FCIs Ces fonctionnalités vous permettent de créer un environnement de SQL serveur hautement disponible qui couvre plusieurs zones de disponibilité. En reproduisant cette configuration dans une autre région, vous obtenez un système entièrement redondant capable de gérer les perturbations les plus graves. Ce qui distingue cette solution, c'est le niveau de flexibilité et de sécurité qu'elle fournit. L'architecture indépendante du domaine des groupes de disponibilité distribués permet aux serveurs de clusters Windows sous-jacents de rejoindre différents domaines Active Directory, tandis que l'authentification basée sur des certificats garantit une protection maximale de vos environnements de SQL serveurs RTO et RPO répond aux exigences élevées d'une stratégie de reprise après sinistre multirégionale. Pour plus d'informations sur la création d'une architecture multirégionale, voir Notes de terrain : création d'une architecture multirégionale pour l'utilisation de SQL serveurs FCI et de groupes de disponibilité distribués dans le blog sur l' AWS architecture.

Le schéma suivant montre un exemple d'architecture pour une solution multirégionale utilisant des groupes de disponibilité distribués.

Expédition de journaux

L'expédition des journaux est une méthode éprouvée, fiable et rentable pour protéger vos bases de données dans toutes les régions en cas de panne imprévue. Organisations utilisent le transport de logs pour protéger leurs données depuis des décennies.

Si vous implémentez l'expédition des journaux AWS, vous pouvez y parvenir RPO RTO en quelques minutes, en fonction de la fréquence des transactions et des tâches d'expédition des journaux. Dans le cas peu probable où une région deviendrait inaccessible, l'expédition des logs garantit la sécurité et la restauration de vos données.

Tenez compte des avantages supplémentaires suivants liés à l'utilisation de l'expédition de grumes :

• Réduisez les coûts et répondez aux exigences de votre entreprise en utilisant l'expédition de journaux pour renforcer la résilience en cas de sinistre dans toutes les régions. L'expédition des journaux réduit votre consommation TCO car vous n'avez besoin que de licences de l'édition SQL SQL Server Standard ou de l'édition Server Web.

• Supprimez les coûts de licence liés à un serveur passif ou de reprise après sinistre en utilisant l'expédition des journaux avec une assurance logicielle active. Seul le SQL serveur principal/actif doit être titulaire d'une licence lorsque vous utilisez l'expédition de journaux avec Software Assurance.

• Réduisez les coûts de licence des SQL serveurs de 65 à 75 % en supprimant le besoin de l'édition SQL Server Enterprise pour configurer des groupes de disponibilité distribués entre les régions. Pour ce faire, vous pouvez utiliser l'édition SQL Server Standard et SQL Server FCIs combinés à l'expédition des journaux pour répondre à vos exigences en matière de reprise après sinistre.

Note

Pour plus d'informations sur les différences de coûts entre les éditions SQL Server, consultez la section Comparer les éditions SQL Server de ce guide.

Pour plus d'informations, consultez la section Extend SQL Server DR using log shipping for SQL Server FCI with Amazon FSx for Windows configuration sur le blog AWS d'architecture.

Le schéma suivant montre un exemple d'architecture pour une solution d'expédition de journaux.

AWS Database Migration Service

Vous pouvez utiliser AWS Database Migration Service (AWS DMS) pour concevoir une solution HA/DR en fonction des besoins de votre application. AWS DMS vous permet de copier facilement des données vers une base de données de SQL serveur secondaire dans la même région (HA) ou entre régions (DR). Cette approche est techniquement solide et vous permet de maximiser votre investissement dans l' AWS infrastructure tout en optimisant l'utilisation de vos ressources.

AWS DMS est un service rentable. Vous êtes facturé uniquement pour les CPU ressources utilisées pendant le processus de transfert et pour tout stockage de journal supplémentaire. Cela signifie que vous pouvez bénéficier de cette solution sans encourir de coûts supplémentaires importants. Vous pouvez vous AWS DMS en servir pour garantir la disponibilité et l'accessibilité de vos données, tout en minimisant les coûts associés aux licences et à l'utilisation des ressources.

Le schéma suivant montre un exemple d'architecture pour une solution basée sur AWS DMS.

AWS Elastic Disaster Recovery

Certaines entreprises doivent s'assurer que toutes les applications métier critiques disposent d'un plan de reprise après sinistre. Dans le passé, bon nombre de ces entreprises ont investi massivement dans les solutions traditionnelles de reprise après sinistre, qui nécessitent la préconstruction et la maintenance d'une infrastructure dupliquée complète. Cette approche est coûteuse, chronophage et difficile à adapter.

Vous pouvez désormais l'utiliser AWS Elastic Disaster Recovery pour éliminer le besoin de pré-construire une infrastructure de reprise après sinistre. Les machines de reprise après sinistre ne sont démarrées dans Elastic Disaster Recovery que lorsque cela est nécessaire. Vous ne payez donc que ce que vous utilisez lorsque vous en avez besoin. Cela signifie que vous pouvez réduire de manière significative vos licences logicielles et vos coûts de calcul de haute performance.

En outre, la zone de transit de la solution de reprise après sinistre contient des volumes Amazon Elastic Block Store (AmazonEBS) à faible coût. EBSles volumes réduisent encore le coût de provisionnement des ressources dupliquées. Cela vous permet de réduire vos coûts globaux de reprise après sinistre tout en conservant une solution de reprise après sinistre robuste et fiable qui répond aux exigences de votre entreprise. Vous pouvez utiliser Elastic Disaster Recovery pour vous concentrer sur vos activités principales, AWS tout en gérant l'infrastructure sous-jacente de votre solution de reprise après sinistre.

Pour SQL Server, vous pouvez utiliser Elastic Disaster Recovery comme option de reprise après sinistre rentable. La licence pour le nœud passif dans une architecture de SQL serveur hautement disponible et tolérante aux pannes est couverte si vous utilisez l'assurance logicielle active. Cependant, vous devez toujours payer des frais de calcul pour que le serveur passif soit en ligne. Avec Elastic Disaster Recovery, le serveur principal peut effectuer une réplication vers l'environnement de reprise après sinistre sans avoir à maintenir une assurance logicielle active et sans avoir à payer les coûts de calcul liés à la reprise après sinistre. Cette combinaison d'économies peut réduire les coûts de reprise après sinistre de votre SQL serveur de 50 % ou plus.

Le schéma suivant montre un exemple d'architecture pour une solution basée sur Elastic Disaster Recovery.

Pour plus d'informations, consultez Comment configurer la haute disponibilité pour le site SQL Server at DR restauré à l'aide AWS Elastic Disaster Recovery du AWS blog Microsoft Workloads on.

Comparaison des coûts

Le tableau suivant compare les coûts des solutions HA/DR abordées dans cette section. Les hypothèses suivantes sont formulées aux fins de cette comparaison :

• Type d'instance : r5d.xlarge

• Type de licence : licence incluse pour Windows et SQL Server

• Région — us-east-1

Solution	Haute disponibilité	Reprise après sinistre	Édition Enterprise	Édition Standard	Coût
Expédition de journaux	Non	Oui	Oui	Oui	SQLÉdition Server Enterprise : 32 674,8$ (2 nœuds) SQLÉdition Server Standard : 14 804,4$ (2 nœuds)
Groupes de disponibilité Always On	Oui	Oui	Oui	Oui, mais les groupes de disponibilité de base (2 nœuds)	SQLÉdition Server Enterprise : 32 674,8$ (2 nœuds) SQLÉdition Server Standard : 14 804,4$ (2 nœuds)
Toujours allumé FCIs	Oui	Non	Oui	Oui (2 nœuds)	SQLÉdition Server Standard : 14 804,4$
Groupes de disponibilité distribués	Oui	Oui	Oui	Non	SQLÉdition Server Enterprise : 65 349,6$ (4 nœuds)
Reprise après sinistre Elastic	Non	Oui	Oui	Oui	Environ 107,48 $/mois pour la réplication d'une instance et de 1 To de stockage Remarque : Elastic Disaster Recovery est facturé à l'heure, par serveur de réplication. Le coût est le même, quels que soient le nombre de disques, la taille du stockage, le nombre de lancements d'exploration ou de restauration, ou la région que vous répliquez.
SIOSGardien de données	Oui	Oui	Oui	Oui	Groupes de disponibilité Always On avec Software Assurance (2 nœuds, 24 cœurs) : 213 480$ Cluster de SQL serveurs à 2 nœuds fonctionnant sur l'édition SQL Server Standard avec SIOS DataKeeper assurance logicielle : 61 530$ (2 nœuds)
AWS DMS	Non	Oui	Oui	Oui	745,38 $/mois pour une instance r5.xlarge et 1 To de stockage

Recommandations d'optimisation des coûts

Nous vous recommandons de suivre les étapes suivantes pour choisir une solution HA/DR répondant aux exigences de votre organisation :

• Consultez la section Sélectionnez l'EC2instance appropriée pour les charges de travail SQL du serveur de ce guide.

• Déterminez les exigences IOPS et le débit de vos charges de travail en exécutant des compteurs de performance pendant les pics de charge de travail :

  • IOPS= disque reads/sec + disk writes/sec

  • Débit = lecture du disque bytes/sec + disk write bytes/sec

• Utilisez les types de volumes de stockage suivants pour améliorer les performances et réaliser des économies :

  • NVMestockage d'instance pour extension tempdb du pool de mémoire tampon

  • volumes io2 pour fichiers de base de données

• AWS Trusted AdvisorÀ utiliser pour des recommandations sur l'optimisation des coûts pour SQL Server on AmazonEC2. Il n'est pas nécessaire d'installer un agent pour Trusted Advisor effectuer des vérifications d'optimisation SQL du serveur. Trusted Advisor inspecte les configurations d'instance incluses dans la licence Amazon EC2 SQL Server, telles que virtual CPUs (vCPUs), version et édition. Ensuite, Trusted Advisor formule des recommandations basées sur les meilleures pratiques.

• AWS Compute Optimizer À utiliser à la fois pour les recommandations relatives à l'EC2instance Amazon et à la EBS bonne taille d'Amazon.

• AWS Pricing CalculatorÀ utiliser pour concevoir votre stratégie HA/DR pour les estimations de coûts.

• Pour déterminer s'il est possible de passer de l'édition SQL Server Enterprise à l'édition SQL Server Standard, utilisez la vue de gestion dynamique sys dm_db_persisted_sku_features pour identifier les fonctionnalités spécifiques à l'édition qui sont actives dans la base de données actuelle.

  Note

  Side-by-side les migrations sont nécessaires pour modifier l'édition SQL du serveur lors de l'utilisation d'instances incluses dans une licenceEC2.

• Effectuez des exercices de reprise après sinistre semestriels ou annuels afin de mieux concevoir une conception capable de restaurer la base de données avec des paramètres définis RTO et. RPO Cela peut également vous aider à identifier les faiblesses de l'architecture.

Ressources supplémentaires

• Simplifiez vos déploiements de haute disponibilité Microsoft SQL Server à l'aide d'Amazon FSx pour Windows File Server (AWS Storage Blog)

• Notes de terrain : Création d'une architecture multirégionale pour l'utilisation de SQL serveurs FCI et de groupes de disponibilité distribués (blog AWS d'architecture)

• Concevez une reprise après sinistre pour le SQL serveur sur AWS : partie 1 (blog AWS de base de données)

• SQLHaute disponibilité de Microsoft avec Amazon FSx pour Windows (YouTube)

• Optimisation des performances de Microsoft SQL Server avec Amazon EBS (AWS Storage Blog)

• Comparaison de vos modèles de stockage sur site avec les services AWS de AWS stockage (Storage Blog)

• Planification du remplacement d'un centre de données NAS par Amazon FSx File Gateway (AWS Storage Blog)

• Optimisation des coûts pour vos déploiements de SQL serveurs à haute disponibilité sur AWS (AWS Storage Blog)

• Comment configurer la reprise après sinistre pour les groupes de disponibilité SQL Server Always On à l'aide de AWS Elastic Disaster Recovery(Microsoft Workloads activé AWS)

• Comment configurer la haute disponibilité pour un SQL serveur sur un site de reprise après sinistre qui a été restauré à l'aide de AWS Elastic Disaster Recovery(Microsoft Workloads activé AWS)