Options et considérations relatives à l'HA/DR

Bien qu'il soit extrêmement rare qu'une zone de AWS disponibilité ou une région soit complètement hors ligne, nous recommandons une approche à plusieurs volets pour la sauvegarde et la restauration en cas de sinistre, afin de garantir la redondance et de minimiser les pertes de données. Les processus de sauvegarde et de restauration doivent inclure le niveau de granularité approprié pour atteindre les objectifs de temps de restauration (RTO) et de point de restauration (RPO) pour la charge de travail et pour prendre en charge les processus métier, et dépendent souvent de l'application. Dans le cas des bases de données, prend AWS également en charge toutes les recommandations Microsoft relatives à l'installation et à la configuration de SQL Server pour la haute disponibilité et la reprise après sinistre (HA/DR). Different editions of SQL Server support various HA/DR options, and you should consider special cases such as very large databases (VLDBs) on a case-by-case basis. As with any DR configuration, testing is essential to ensure that each application meets its service-level agreements (SLAs) for HA/DR. For your test/developmentenvironnement). Pensez à utiliser l'édition SQL Server Developer, qui est gratuite mais comporte des limitations.

Pour un cas d'utilisation nécessitant un RPO de 15 minutes et un RTO de 4 heures, vous pouvez envisager une combinaison des options HA/DR suivantes :

• Options HA/DR natives de SQL Server avec mise en veille prolongée (au niveau de la base de données) — Pour des illustrations de certaines de ces architectures, consultez la Schémas d' EC2 architecture de SQL Server sur Amazon section plus loin dans ce guide.

  • Deux nœuds, multi-AZ dans une seule région (mode de validation synchrone) ou dans plusieurs régions (mode de validation asynchrone, groupe de disponibilité de base)

  • Trois nœuds (ou plus), multi-AZ dans plusieurs régions (modes de validation synchrone et de validation asynchrone)

  • Deux nœuds, multi-AZ et expédition de journaux dans plusieurs régions (avec des sauvegardes de journaux toutes les 5 minutes)

• Sauvegardes natives de SQL Server vers Amazon S3 (au niveau de la base de données, DR uniquement) — Sauvegardes complètes (une fois par jour)

  • Sauvegardes différentielles (toutes les 2 à 4 heures).

  • Enregistrez les sauvegardes (toutes les 5 à 10 minutes).

  • Les sauvegardes doivent être effectuées et copiées sur Amazon Simple Storage Service (Amazon S3) à l'aide de scripts personnalisés ou d'une option telle qu'une passerelle de fichiers pour une sauvegarde et un transfert efficaces.

  • Si vous possédez des centaines de bases de données, vous pouvez continuer à utiliser vos outils de sauvegarde existants (tels que Commvault ou Litespeed) pour gérer efficacement les sauvegardes et les stocker directement dans Amazon S3.

  • Utilisez Amazon S3 Cross-Region Replication (CRR) avec S3 Replication Time Control (RTC) pour contrôler et surveiller la réplication d'objets dans le cadre d'un SLA de 15 minutes.

  • Pour des raisons de conformité et de réduction des coûts, vous pouvez également utiliser la gestion du cycle de vie S3 pour déplacer et stocker les anciennes sauvegardes en vue d'un stockage à long terme.

  • Si vous utilisez des sauvegardes natives de SQL Server et que vous les déplacez régulièrement vers Amazon S3, en cas de sinistre, les sauvegardes seront facilement disponibles dans la région cible. Ainsi, il n'est plus nécessaire de transférer des sauvegardes ou de restaurer des instantanés.

  • Nous vous recommandons d'utiliser SQL Native Backup Compression pour réduire la taille des fichiers.

• AWS instantanés (niveau d'instance et de volume, DR uniquement)

  • Amazon Elastic Compute Cloud (Amazon EC2) Sauvegardes Amazon Machine Image (AMI) pour reconstruire des bases de données à partir de zéro

  • Instantanés de volumes Amazon Elastic Block Store (Amazon EBS) pour associer des volumes EBS à Amazon EC2

Gestion des ressources HA/DR dans AWS Backup

AWS Backupest un service entièrement géré qui permet de créer des plans et des plannings de sauvegarde, et d'affecter les AWS ressources impliquées dans la configuration HA/DR, telles que les volumes Amazon EBS pour créer des instantanés et Amazon, à ces plans de sauvegarde. EC2 AMIs Vous pouvez également l'utiliser AWS Backup pour planifier des copies multirégionales de ces instantanés EBS. Pour une utilisation optimale, AWS Backup il faut un mécanisme de balisage efficace pour que les ressources soient en place. AWS Backup prend également en charge les sauvegardes cohérentes avec les applications via le service Windows Volume Shadow Copy (VSS), que vous pouvez utiliser pour SQL Server. Pour une protection au niveau du stockage, nous vous recommandons d'utiliser des instantanés EBS. Les instantanés EBS initiaux sont complets et les instantanés suivants sont incrémentiels. Bien que les instantanés EBS offrent une protection au niveau du stockage, ils ne remplacent pas les sauvegardes natives basées sur des fichiers SQL Server qui offrent une restauration. point-in-time

Utilisation AWS DMS pour HA/DR

Si vous recherchez une alternative aux options Always On de SQL Server pour la réplication ou si vous disposez de bases de données source et cible hétérogènes, que ce soit dans une configuration hybride ou dans AWS, vous pouvez utiliser AWS Database Migration Service (AWS DMS) de la manière suivante.

Si vous l'utilisez AWS DMS avec SQL Server dans un contexte autogéré (hébergé sur Amazon EC2 ou sur site), il prend en charge la réplication ponctuelle et continue selon deux modes : en utilisant MS-REPLICATION (pour capturer les modifications apportées aux tables dotées de clés primaires) et MS-CDC (pour capturer les modifications apportées aux tables dépourvues de clés primaires). Toutefois, si vous utilisez Amazon Relational Database Service (Amazon RDS) comme source AWS DMS pour, seul le MS-CDC est pris en charge. AWS DMS propose une gamme de points de terminaison source et cible, prend en charge des moteurs de base de données hétérogènes et offre un contrôle précis du processus de réplication. Vous pouvez également utiliser le AWS Schema Conversion Tool (AWS SCT) avec AWS DMS pour les migrations de bases de données hétérogènes. AWS SCT automatise les modifications au niveau du schéma et produit également des rapports pour la préparation et la planification de la migration.

Vous ajoutez des bases de données source et cible en tant que points de terminaison AWS DMS, comme illustré dans le schéma suivant. Ce service met en œuvre un processus de réplication logique à l'aide de MS-REPLICATION ou de MS-CDC. Si vous avez une configuration hybride, vous pouvez la configurer AWS DMS pour une réplication continue entre une configuration sur site et AWS. Pendant le passage, la tâche de AWS DMS migration peut être arrêtée et l'application pourra se connecter à la base de données déjà synchronisée avec la base de données locale sans plus tarder. L'utilisation de AWS DMS for SQL Server en tant que source comporte quelques limites, qui sont décrites dans la AWS DMS documentation.

Envisagez d'utiliser des méthodes HA/DR natives à la AWS DMS place des méthodes HA/DR natives dans les scénarios suivants :

• Lorsque vous souhaitez économiser sur les coûts de licence. Par exemple, si vous utilisez une version avancée telle que SQL Server Enterprise uniquement pour ses options Always On, vous pouvez envisager de la configurer à la AWS DMS place, car elle peut fournir une option de réplication logique sans le coût d'une licence d'édition Enterprise.

• Lorsque vous avez des sources et des cibles hétérogènes. Les versions de SQL Server sur les nœuds principaux et de reprise après sinistre n'ont pas besoin de correspondre (dans AWS DMS certaines limites), ce qui offre une flexibilité significative.

• Pour éviter la surcharge liée à Windows, au clustering SQL Server et à la configuration et à la gestion des groupes de disponibilité distribués. AWS DMS permet une configuration simple et une gestion aisée des tâches de réplication.

• Pour les cas d'utilisation professionnels tels que le transfert en temps quasi réel (en fonction de l'instance de réplication, de la configuration réseau et du volume de données), le masquage des données, le filtrage sélectif, le mappage des schémas/tables (homogènes et hétérogènes), les évaluations préalables à la migration et le support JSON.

• Pour dupliquer, arrêter et démarrer facilement des tâches selon les besoins en fonction des numéros de séquence du journal (LSNs), des horodatages et d'options similaires.

Le schéma suivant montre une autre approche permettant de AWS DMS fournir un support de réplication. Dans cette configuration, la source est un cluster de groupes de disponibilité SQL Server Always On qui AWS DMS utilise l'option de capture des données de modification (CDC) pour répliquer en continu les données vers une cible située dans une autre AWS région. Pour des performances optimales, il est essentiel de s'assurer que l'instance de réplication est correctement dimensionnée et qu'elle reste dans la région source.

Il n'est pas nécessaire que les moteurs source et cible correspondent. Dans le diagramme, les nœuds principal et secondaire marqués comme (1) peuvent être un cluster SQL Server dans une configuration mono-AZ ou multi-AZ. La source peut également être un nœud SQL Server unique qui prend en charge MS-CDC ou MS-REPLICATION.

L'instance de base de données cible, marquée comme (2) dans le diagramme, peut être n'importe quelle version de SQL Server sur Amazon RDS EC2, Amazon ou toute autre cible hétérogène. Il n'est pas nécessaire qu'elle corresponde aux instances principale et secondaire ou qu'elle prenne en charge les groupes de disponibilité Always On. Par exemple, la source peut être un cluster de groupes de disponibilité SQL Server Always On, et la cible peut être l'édition compatible avec Amazon Aurora PostgreSQL.

Utilisation AWS Application Migration Service pour la DR

Nous vous recommandons d'utiliser le AWS Application Migration Service pour lift-and-shift les migrations vers AWS. Le service de migration d'applications réplique en permanence vos machines (y compris le système d'exploitation, la configuration de l'état du système, les bases de données, les applications et les fichiers) dans une zone de transit peu coûteuse de votre AWS compte cible et de votre région préférée. En cas de sinistre, vous pouvez utiliser le service de migration d'applications pour lancer automatiquement des milliers de machines entièrement provisionnées en quelques minutes.

Considérations supplémentaires

La liste suivante identifie les points d'étranglement possibles que vous devez prendre en compte lors de la conception d'une stratégie HA/DR.

• Bande passante, latence, complexité du réseau et connectivité dans une configuration de nœud multirégional.

• Taille des EC2 instantanés Amazon EBS ou Amazon, et temps nécessaire pour les copier à l'aide de. AWS Backup

  • Les EC2 instantanés Amazon EBS et Amazon sont stockés dans Amazon S3 à l'aide de. AWS Backup

  • Un instantané EBS n'est pas répliqué dans la région cible dans Amazon S3 tant que le cliché actuel n'est pas terminé. La durée de réplication dépend également de la taille du volume.

  • Lorsque l'instantané est terminé, la durée de copie des instantanés peut être de 15 minutes seulement pour 99,99 % des objets. Cependant, des tests approfondis sont nécessaires pour des cas d'utilisation spécifiques et des volumes importants critiques.

• Temps nécessaire pour restaurer les volumes EBS dans la zone de disponibilité et la région cibles.

• Temps nécessaire pour restaurer les EC2 images Amazon dans la zone de disponibilité et la région cibles.

• Si vous créez à partir de zéro, il faut du temps pour provisionner l'infrastructure pour l' EC2image Amazon ou pour restaurer les instantanés EBS dans la zone de disponibilité et la région cibles.

• En cas de restauration à partir de zéro, temps nécessaire pour restaurer les sauvegardes complètes, différentielles et journaux natives de SQL Server dans la zone de disponibilité et la région cibles.

• Dépendances applicatives et externes qui doivent être disponibles dans toutes les régions.

• Limitations relatives à la taille des fichiers pour les volumes et pour le téléchargement vers Amazon S3.