Déploiements multi-AZ pour Amazon RDS for Microsoft SQL Server - Amazon Relational Database Service

Déploiements multi-AZ pour Amazon RDS for Microsoft SQL Server

Les déploiements Multi-AZ améliorent la disponibilité, la durabilité des donnés et la tolérance aux pannes pour les instances de bases de données. En cas de maintenance planifiée de la base de données ou d'interruption imprévue du service, Amazon RDS bascule automatiquement vers l'instance de base de données secondaire à jour. Cette fonctionnalité permet aux opérations de la base de données de reprendre rapidement sans intervention manuelle. Les instances principales et de secours utilisent le même point de terminaison, l'adresse réseau physique de celui-ci étant transférée vers le réplica secondaire dans le cadre du processus de basculement. Vous n'avez pas à reconfigurer votre application lorsqu'un basculement se produit.

Amazon RDS prend en charge les déploiements Multi-AZ pour Microsoft SQL Server en utilisant une mise en miroir de bases de données (DBM) SQL Server ou des groupes de disponibilité (AG) AlwaysOn. Amazon RDS surveille et maintient l'état de votre déploiement Multi-AZ. En cas de survenue de problèmes, RDS répare automatiquement les instances de bases de données non saines, rétablit la synchronisation et démarre le basculement. Le basculement n'a lieu que si les instances de secours et principales sont parfaitement synchronisées. Vous ne devez rien gérer.

Lorsque vous configurez le déploiement Multi-AZ de SQL Server, RDS configure automatiquement toutes les bases de données sur l'instance pour utiliser une mise en miroir de bases de données ou des groupes de disponibilité Always On. Amazon RDS gère les instances de base de données principale, témoin et de secours pour vous. Dans la mesure où la configuration est automatique, RDS sélectionne la mise en miroir ou les groupes de disponibilité Always On en fonction de la version de SQL Server déployée.

Amazon RDS prend en charge les déploiements Multi-AZ avec les groupes de disponibilité Always On pour les éditions et les versions de SQL Server suivantes :

  • SQL Server 2019 :

    • Standard Edition 15.00.4073.23 et versions ultérieures

    • Enterprise Edition

  • SQL Server 2017 :

    • Standard Edition 14.00.3401.7 et versions ultérieures

    • Enterprise Edition 14.00.3049.1 et versions ultérieures

  • SQL Server 2016: Enterprise Edition version 13.00.5216.0 et supérieure

Amazon RDS prend en charge les déploiements Multi-AZ avec la mise en miroir (DBM) pour les versions et éditions suivantes de SQL Server, à l'exception des versions précédemment indiquées :

  • SQL Server 2019 : Standard Edition version 15.00.4043.16

  • SQL Server 2017 : Standard Edition et Enterprise Edition

  • SQL Server 2016 : Standard Edition et Enterprise Edition

  • SQL Server 2014 : Standard Edition et Enterprise Edition

  • SQL Server 2012 : Standard Edition et Enterprise Edition

Vous pouvez utiliser la requête SQL suivante pour déterminer si votre instance de base de données SQL Server est mono-AZ, multi-AZ avec DBM ou multi-AZ avec groupes de disponibilité Always On :

SELECT CASE WHEN dm.mirroring_state_desc IS NOT NULL THEN 'Multi-AZ (Mirroring)' WHEN dhdrs.group_database_id IS NOT NULL THEN 'Multi-AZ (AlwaysOn)' ELSE 'Single-AZ' END 'high_availability' FROM sys.databases sd LEFT JOIN sys.database_mirroring dm ON sd.database_id = dm.database_id LEFT JOIN sys.dm_hadr_database_replica_states dhdrs ON sd.database_id = dhdrs.database_id AND dhdrs.is_local = 1 WHERE DB_NAME(sd.database_id) = 'rdsadmin';

La sortie est semblable à la suivante :

high_availability Multi-AZ (AlwaysOn)

Ajout d'un déploiement multi-AZ à une instance de base de données Microsoft SQL Server

Lorsque vous créez une nouvelle instance de base de données SQL Server à l'aide d'AWS Management Console, vous pouvez ajouter un déploiement multi-AZ avec mise en miroir ou groupes de disponibilité Always On. Pour ce faire, définissez Déploiement multi-AZ sur Oui (Mise en miroir/Always On). Pour plus d'informations, consultez Création d'une instance de base de données Amazon RDS.

Lorsque vous modifiez une instance de base de données SQL Server à l'aide de l'AWS Management Console, vous pouvez ajouter le Multi-AZ avec une mise en miroir de bases de données (DBM) ou des groupes de disponibilité Always On (AG) en choisissant Yes (Mirroring / Always On) (Oui (Mise en miroir / Toujours actif) dans Multi-AZ deployment (Déploiement Multi-AZ) sur la page Modify DB Instance (Modifier l'instance de base de données). Pour plus d'informations, consultez Modification d'une instance de base de données Amazon RDS.

Note

Si votre instance de base de données exécute la mise en miroir de bases de données (et non les groupes de disponibilité Always On), vous devrez peut-être désactiver l'optimisation en mémoire avant d'ajouter un déploiement multi-AZ. Désactivez l'optimisation en mémoire avec la mise en miroir de bases de données avant d'ajouter un déploiement multi-AZ si votre instance de base de données exécute SQL Server 2014, 2016 ou 2017 Enterprise Edition et que l'optimisation en mémoire est activée.

Si votre instance de base de données exécute des groupes de disponibilité, cette étape n'est pas obligatoire.

Notes, limitations et recommandations concernant le déploiement multi-AZ de Microsoft SQL Server

Voici quelques limitations lorsque vous travaillez avec des déploiements multi-AZ pour les instances de bases de données RDS for Microsoft SQL Server :

  • Le Multi-AZ entre régions n'est pas pris en charge.

  • Vous ne pouvez pas configurer l'instance de base de données secondaire pour accepter l'activité de lecture de base de données.

  • Le déploiement multi-AZ avec les groupes de disponibilité Always On prend en charge l'optimisation en mémoire.

  • Le déploiement multi-AZ avec les groupes de disponibilité Always On ne prend pas en charge l'authentification Kerberos pour l'écouteur du groupe de disponibilité. En effet, l'écouteur ne possède pas de nom de principal de service (SPN).

  • Vous ne pouvez pas renommer une base de données sur une instance de base de données SQL Server située dans un déploiement multi-AZ SQL Server. Si vous devez renommer une base de données sur une telle instance, vous devez d'abord désactiver le déploiement multi-AZ pour l'instance de base de données, puis renommer la base de données. Réactivez ensuite le déploiement multi-AZ pour l'instance de base de données.

  • Vous pouvez uniquement restaurer des instances de base de données multi-AZ sauvegardées en utilisant le modèle de récupération « Full ».

  • Les déploiements multi-AZ ont une limite de 100 tâches SQL Server Agent.

    Si une limite plus élevée est nécessaire, demandez une augmentation en contactant le AWS Support. Ouvrez la page du Centre AWS Support, connectez-vous si nécessaire, puis choisissez Create case (Créer une demande de support). Sélectionnez Service Limit increase (Augmentation des limites de service). Remplissez et envoyez le formulaire.

Voici quelques notes sur l'utilisation des déploiements multi-AZ pour les instances de bases de données RDS for Microsoft SQL Server :

  • Amazon RDS expose le point de terminaison de l'écouteur des groupes de disponibilité Always On. Le point de terminaison est visible dans la console et est renvoyé par l'API DescribeDBInstances en tant qu'entrée dans le champ des points de terminaison.

  • Amazon RDS prend en charge les basculements à plusieurs sous-réseaux du groupe de disponibilité.

  • Pour utiliser les déploiements multi-AZ SQL Server avec une instance de base de données SQL Server dans un VPC, créez d'abord un groupe de sous-réseaux de base de données comportant des sous-réseaux dans au moins deux zones de disponibilité distinctes. Affectez ensuite le groupe de sous-réseaux de base de données au réplica principal de l'instance de base de données SQL Server.

  • Quand une instance de base de données est transformée en déploiement multi-AZ, pendant la modification, son état est modifying (modification). Amazon RDS crée l'instance de secours et effectue une sauvegarde de l'instance de base de données principale. Une fois le processus terminé, le statut de l'instance de base de données principale devient disponible.

  • Les déploiements Multi-AZ maintiennent toutes les bases de données sur le même nœud. Si une base de données sur l'hôte principal bascule, toutes vos bases de données SQL Server basculent en tant qu'unité atomique vers votre hôte de secours. Amazon RDS approvisionne un nouvel hôte sain et remplace l'hôte non sain.

  • Le Multi-AZ avec DBM ou AG prend en charge un réplica de secours unique.

  • Les utilisateurs, les ID de connexion et les autorisations sont automatiquement répliqués pour vous sur l'instance secondaire. Vous n'avez pas besoin de les recréer. Les rôles de serveur définis par l'utilisateur (une fonction de SQL Server 2012) sont uniquement répliqués dans les instances multi-AZ pour les instances de groupes de disponibilité Always On.

  • Dans les déploiements Multi-AZ, les tâches de l'agent SQL Server sont répliquées de l'hôte principal vers l'hôte secondaire lorsque la fonction de réplication des tâches est activée. Pour plus d'informations, consultez Activation de la réplication des tâches de l'agent SQL Server.

  • Il est possible que vous observiez des temps de latence élevés par rapport à un déploiement d'instance de base de données standard (dans une zone de disponibilité unique) en raison de la réplication synchrone des données.

  • Les délais de basculement sont affectés par le temps nécessaire à la réalisation du processus de récupération. Le délai de basculement est allongé pour les transactions de volume important.

  • Dans les déploiements multi-AZ SQL Server, le redémarrage avec basculement redémarre uniquement l'instance de base de données principale. Après le basculement, l'instance de base de données principale devient la nouvelle instance de base de données secondaire. Les paramètres peuvent ne pas être mis à jour pour les instances multi-AZ. Pour le redémarrage sans basculement, les instances de base de données principale et secondaire redémarrent, et les paramètres sont mis à jour après le redémarrage. Si l'instance de base de données ne répond pas, nous vous recommandons de procéder à un redémarrage sans basculement.

Voici quelques recommandations sur l'utilisation des déploiements multi-AZ pour les instances de bases de données RDS for Microsoft SQL Server :

  • Pour les bases de données utilisées en production ou préproduction, nous vous recommandons les options suivantes :

    • Déploiements multi-AZ pour une haute disponibilité

    • IOPS provisionnés pour des performances rapides et cohérentes

    • « Mémoire optimisée » plutôt que « Usage général »

  • Vous ne pouvez pas sélectionner la zone de disponibilité (AZ) pour l'instance secondaire. Tenez-en compte lorsque vous déployez les hôtes d'application. Votre base de données peut basculer vers une autre zone de disponibilité et les hôtes d'application peuvent ne pas se trouver dans la même zone de disponibilité que la base de données. C'est pourquoi nous vous recommandons d'équilibrer vos hôtes d'application sur toutes les zones de disponibilité (AZ) de la région AWS concernée.

  • Pour optimiser les performances, n'activez pas la mise en miroir ou les groupes de disponibilité Always On pendant une opération de chargement d'un volume important de données. Pour optimiser la vitesse de chargement de vos données, terminez le chargement des données avant de convertir votre instance de base de données en déploiement multi-AZ.

  • Les applications qui ont accès aux bases de données SQL Server doit disposer d'une gestion des exceptions qui identifie les erreurs de connexion. L'exemple de code suivant illustre un bloc try/catch qui identifie une erreur de communication. Dans cet exemple, l'instruction break quitte la boucle while si la connexion réussit, mais relance jusqu'à 10 tentatives si une exception est déclenchée.

    int RetryMaxAttempts = 10; int RetryIntervalPeriodInSeconds = 1; int iRetryCount = 0; while (iRetryCount < RetryMaxAttempts) { using (SqlConnection connection = new SqlConnection(DatabaseConnString)) { using (SqlCommand command = connection.CreateCommand()) { command.CommandText = "INSERT INTO SOME_TABLE VALUES ('SomeValue');"; try { connection.Open(); command.ExecuteNonQuery(); break; } catch (Exception ex) { Logger(ex.Message); iRetryCount++; } finally { connection.Close(); } } } Thread.Sleep(RetryIntervalPeriodInSeconds * 1000); }
  • N'utilisez pas la commande Set Partner Off lorsque vous travaillez avec des instances multi-AZ. Par exemple, n'effectuez pas les opérations suivantes :

    --Don't do this ALTER DATABASE db1 SET PARTNER off
  • Ne définissez pas le mode de récupération sur simple. Par exemple, n'effectuez pas les opérations suivantes :

    --Don't do this ALTER DATABASE db1 SET RECOVERY simple
  • N'utilisez pas le paramètre DEFAULT_DATABASE lors de la création de nouveaux ID de connexion sur des instances de bases de données multi-AZ car ces paramètres ne peuvent pas être appliqués au miroir de secours. Par exemple, n'effectuez pas les opérations suivantes :

    --Don't do this CREATE LOGIN [test_dba] WITH PASSWORD=foo, DEFAULT_DATABASE=[db2]

    En outre, n'effectuez pas les opérations suivantes :

    --Don't do this ALTER LOGIN [test_dba] SET DEFAULT_DATABASE=[db3]

Détermination de l'emplacement du réplica secondaire

Vous pouvez déterminer l'emplacement du réplica secondaire à l'aide d AWS Management Console. Vous devez connaître l'emplacement du réplica secondaire si vous configurez votre instance de base de données principale dans un VPC.


				Secondary AZ (zone de disponibilité pour réplica secondaire)

Vous pouvez également consulter la zone de disponibilité du réplica secondaire à l'aide de la commande describe-db-instances de l'AWS CLI ou de l'opération d’API RDS DescribeDBInstances. Le résultat indique la zone de disponibilité secondaire où se situe le miroir de secours.

Migration de la mise en miroir de bases de données (DBM) vers les groupes de disponibilité AlwaysOn

Dans la version 14.00.3049.1 de Microsoft SQL Server Enterprise Edition, les groupes de disponibilité Always On sont activés par défaut.

Pour migrer de la mise en miroir de bases de données vers les groupes de disponibilité, commencez par vérifier votre version. Lorsque vous utilisez une instance de base de données de version antérieure à 13.00.5216.0, modifiez l'instance pour la faire passer à la version 13.00.5216.0 ou une version ultérieure. Lorsque vous utilisez une instance de base de données de version antérieure à 14.00.3049.1, modifiez-la pour la faire passer à la version 14.00.3049.1 ou une version ultérieure.

Si vous souhaitez mettre à niveau une instance de base de données en miroir afin d'utiliser des groupes de disponibilité, exécutez d'abord la mise à niveau, modifiez l'instance pour supprimer le multi-AZ, puis modifiez-la à nouveau afin d'ajouter le multi-AZ. Cette opération convertit votre instance en vue de l'utilisation des groupes de disponibilité Always On.