Conditions préalables requises, restrictions et recommandations pour les groupes de disponibilité Always On

S’applique à :SQL Server

Cette rubrique décrit les considérations relatives au déploiement de Groupes de disponibilité Always On, notamment les prérequis, les restrictions et les recommandations concernant les ordinateurs hôtes, les clusters de basculement Windows Server (WSFC), les instances de serveur et les groupes de disponibilité. Pour chacun de ces composants, les considérations relatives à la sécurité et les autorisations requises (le cas échéant) sont indiquées.

Correctifs logiciels .NET prenant en charge les groupes de disponibilité

Selon les fonctionnalités et composants SQL Server que vous allez utiliser avec les groupes de disponibilité Always On, vous pourrez éventuellement avoir besoin d'installer des correctifs logiciels .NET supplémentaires identifiés dans le tableau suivant. Ces derniers peuvent être installés dans n'importe quel ordre.

Liste de contrôle : conditions requises (système Windows)

Pour prendre en charge la fonctionnalité Groupes de disponibilité Always On , vérifiez que chaque ordinateur devant participer à un ou plusieurs groupes de disponibilité respecte les conditions requises fondamentales suivantes :

Recommandations pour les ordinateurs qui hébergent des réplicas de disponibilité (système Windows)

• Systèmes comparables : pour un groupe de disponibilité donné, tous les réplicas de disponibilité doivent s'exécuter sur des systèmes comparables qui peuvent gérer des charges de travail identiques.

• Cartes réseau dédiées : pour un niveau de performance optimale, utilisez une carte d'interface réseau dédiée à Groupes de disponibilité Always On.

• Espace disque suffisant : chaque nœud WSFC sur lequel une instance de serveur héberge un réplica de disponibilité doit posséder l'espace disque suffisant pour toutes les bases de données du groupe de disponibilité. Gardez à l'esprit qu'à mesure que le volume des bases de données primaires croît, le volume des bases de données secondaires correspondantes augmente aussi.

Autorisations (système Windows)

Pour administrer un cluster WSFC, l'utilisateur doit être administrateur système sur chaque nœud de cluster.

Pour plus d’informations sur le compte d’administration du cluster, consultez Annexe A : Configuration requise pour le cluster de basculement.

Tâches associées (système Windows)

Modifiez HostRecordTTL (à l'aide de PowerShell)

1. Ouvrez la fenêtre PowerShell via Exécuter en tant qu’administrateur.

2. Importez le module FailoverClusters.

3. Utilisez l’applet de commande Get-ClusterResource pour rechercher la ressource de nom de réseau, puis utilisez l’applet de commande Set-ClusterParameter pour définir la valeur de HostRecordTTL , comme suit :

   Get-ClusterResource "<NetworkResourceName>" | Set-ClusterParameter HostRecordTTL <TimeInSeconds>

   L'exemple PowerShell suivant définit HostRecordTTL sur 300 secondes pour une ressource de nom réseau nommée SQL Network Name (SQL35).

   Import-Module FailoverClusters
   
   $nameResource = "SQL Network Name (SQL35)"
   Get-ClusterResource $nameResource | Set-ClusterParameter HostRecordTTL 300
   

   Conseil

   Chaque fois que vous ouvrez une nouvelle fenêtre PowerShell, vous devez importer le module FailoverClusters .

Contenu associé (PowerShell)

• Clustering and High-Availability (Clustering et haute disponibilité) (Blog de l’équipe de clustering de basculement et d’équilibrage de la charge réseau)

• Mise en route de Windows PowerShell sur un cluster de basculement

• Commandes de ressource de cluster et applets de commande Windows PowerShell équivalentes

Contenu associé (système Windows)

• Configurer les paramètres DNS dans un cluster de basculement multisite

• Enregistrement DNS avec ressource de nom réseau

Conditions préalables requises et restrictions pour une instance de SQL Server

Chaque groupe de disponibilité requiert un jeu de partenaires de basculement, appelés réplicas de disponibilité, qui sont hébergés par les instances de SQL Server. Une instance de serveur donnée peut être une instance autonome ou une instance de cluster de basculement (FCI) SQL Server.

Dans cette section :

• Liste de vérification : Prérequis
• Utilisation de threads par les groupes de disponibilité
• autorisations
• Tâches associées
• Contenu connexe

Liste de contrôle : conditions préalables requises (instance de serveur)

Pour obtenir la liste des fonctionnalités prises en charge par les éditions de SQL Server dans Windows, consultez :

• Éditions et fonctionnalités prises en charge de SQL Server 2022
• Éditions et fonctionnalités prises en charge de SQL Server 2019
• Éditions et fonctionnalités prises en charge de SQL Server 2017
• Éditions et fonctionnalités prises en charge de SQL Server 2016

Utilisation de threads par les groupes de disponibilité

Groupes de disponibilité Always On pose les conditions suivantes pour les threads de travail :

• Sur une instance SQL Serverinactive, Groupes de disponibilité Always On n'utilise aucun thread.

• Le nombre maximal de threads utilisés par les groupes de disponibilité est le paramètre configuré pour le nombre maximal de threads serveur («max worker threads») moins 40.

• Les réplicas de disponibilité hébergés sur une instance de serveur donnée partagent un pool de threads unique dans SQL Server 2019 (15.x) et versions antérieures.

  Les threads sont partagés à la demande, comme suit :

  • En général, il existe 3 à 10 threads partagés, mais ce nombre peut augmenter en fonction de la charge de travail du réplica principal.

  • Si un thread donné est inactif pendant un certain temps, il est remis à disposition dans le pool de threads SQL Server à usage général. Normalement, un thread inactif est libéré après environ 15 secondes d'inactivité. Toutefois, selon la dernière activité, un thread inactif peut être conservé plus longtemps.

  • Une instance de SQL Server utilise jusqu’à 100 threads de restauration par progression parallèle pour les réplicas secondaires. Chaque base de données utilise jusqu’à la moitié du nombre total de cœurs de processeur, mais pas plus de 16 threads par base de données. Si le nombre total de threads requis pour une seule instance est supérieur à 100, SQL Server utilise un thread redo unique pour chaque base de données restante. Les threads de restauration par progression en série sont libérés après 15 secondes d’inactivité environ.

• En outre, les groupes de disponibilité utilisent des threads non partagés, comme suit :

  • Chaque réplica principal utilise 1 thread de capture du journal pour chaque base de données principale. En outre, il utilise un thread d'envoi du journal pour chaque base de données secondaire. Les threads d'envoi du journal sont libérés après environ 15 secondes d'inactivité.

  • Une sauvegarde sur un réplica secondaire contient un thread sur le réplica principal pour la durée de l'opération de sauvegarde.

• SQL Server 2022 (16.x) a introduit le pool de threads de restauration automatique parallèle, qui est un pool de threads au niveau de l’instance partagé avec toutes les bases de données qui sont soumises à une restauration. Avec ce pool, le même ensemble de threads peut traiter les enregistrements de journaux pour différentes bases de données en même temps (en parallèle). Dans SQL Server 2019 (15.x) et versions antérieures, le nombre de threads disponibles pour la restauration est limité à 100.

• SQL Server 2019 (15.x) a introduit une restauration par progression parallèle pour les bases de données de groupe de disponibilité à mémoire optimisée. Dans SQL Server 2016 (13.x) et SQL Server 2017 (14.x), les tables basées sur disque n’utilisent pas l’opération de restauration par progression parallèle si une base de données dans un groupe de disponibilité est également optimisée en mémoire.

Pour plus d’informations, consultez Always On - HADRON Learning Series: Worker Pool Usage for HADRON Enabled Databases (blog des ingénieurs SQL Server CSS).

Autorisations (instance de serveur)

Tâches associées (instance de serveur)

Contenu associé (instance serveur)

• Always On - HADRON Learning Series: Worker Pool Usage for HADRON Enabled Databases

Recommandations relatives à la connectivité réseau

Nous vous recommandons vivement d'utiliser les mêmes liaisons réseau pour les communications entre les nœuds de cluster WSFC et les communications entre les réplicas de disponibilité. L'utilisation de liaisons réseau distinctes peut provoquer des comportements inattendus en cas d'échec de certaines liaisons (et ce, même de façon intermittente).

Par exemple, pour qu'un groupe de disponibilité prenne en charge le basculement automatique, le réplica secondaire qui est le partenaire de basculement automatique doit être dans un état SYNCHRONIZED. Si la liaison réseau à ce réplica secondaire échoue (et ce, même de façon intermittente), le réplica passe à l'état UNSYNCHRONIZED et ne peut pas se resynchroniser tant que la liaison n'est pas restaurée. Si le cluster WSFC demande un basculement automatique alors que le réplica secondaire n'est pas synchronisé, le basculement automatique n'a pas lieu.

Prise en charge de la connectivité client

Pour plus d’informations sur la prise en charge des groupes de disponibilité Always On pour la connectivité du client, consultez Prise en charge de la connectivité du pilote et du client pour les groupes de disponibilité.

Conditions préalables requises et restrictions pour l'utilisation d'une instance de cluster de basculement (FCI) SQL Server afin d'héberger un réplica de disponibilité

Dans cette section :

• Restrictions
• Liste de vérification : Prérequis
• Tâches associées
• Contenu connexe

Restrictions (instances de cluster de basculement)

• Les nœuds de cluster d'une instance de cluster de basculement peuvent héberger un seul réplica pour un groupe de disponibilité donné : si vous ajoutez un réplica de disponibilité sur une instance de cluster de basculement, les nœuds de cluster WSFC qui sont des propriétaires d'instance de cluster de basculement potentiels ne peuvent pas héberger un autre réplica pour le même groupe de disponibilité. Pour éviter de possibles conflits, il est recommandé de configurer les propriétaires possibles pour l’instance de cluster de basculement. Cela empêche qu’un cluster WSFC tente d’héberger deux réplicas de disponibilité d’un même groupe de disponibilité.

  Par ailleurs, chacun des autres réplicas doit être hébergé par une instance de SQL Server résidant sur un autre nœud du même cluster WSFC. La seule exception survient lors de la migration vers un autre cluster : un groupe de disponibilité peut temporairement chevaucher deux clusters.

  Avertissement

  Le fait d’utiliser le Gestionnaire du cluster de basculement pour déplacer une FCI hébergeant un groupe de disponibilité vers un nœud qui héberge déjà un réplica du même groupe de disponibilité, pourrait entraîner la perte du réplica du groupe de disponibilité, l’empêchant ainsi d’être en ligne sur le nœud cible. Un même nœud d’un cluster de basculement ne peut pas héberger plusieurs réplicas du même groupe de disponibilité. Pour plus d’informations à ce sujet et sur la récupération, consultez le blog Replica nunexpectedly dropped in availability group (Replica annulé de manière inattendue dans un groupe de disponibilité).

• Les instances de cluster de basculement ne prennent pas en charge le basculement automatique par les groupes de disponibilité : les instances de cluster de basculement ne prennent pas en charge le basculement automatique par les groupes de disponibilité ; par conséquent, tout réplica de disponibilité hébergé par une instance de cluster de basculement peut uniquement être configuré pour le basculement manuel.

• Modification du nom réseau d’une instance de cluster de basculement : si vous devez modifier le nom réseau d’une instance de cluster de basculement qui héberge un réplica de disponibilité, vous devez supprimer le réplica de son groupe de disponibilité, puis l’ajouter de nouveau au groupe de disponibilité. Étant donné que vous ne pouvez pas supprimer le réplica principal, si vous renommez une instance de cluster de basculement qui héberge le réplica principal, vous devez basculer vers un réplica secondaire, puis supprimer le réplica principal précédent avant de l'ajouter à nouveau. L'attribution d'un nouveau nom à une instance de cluster de basculement modifie l'URL de son point de terminaison de mise en miroir de bases de données. Lorsque vous ajoutez le réplica, veillez à spécifier l'URL du point de terminaison actuel.

Liste de vérification : Conditions préalables (instances de cluster de basculement)

Tâches associées (FCI)

Contenu associé (FCI)

• Clustering de basculement et groupes de disponibilité Always On (SQL Server)

• Guide de l’architecture Always On : Création d’une solution haute disponibilité et de récupération d’urgence en utilisant des instances de cluster de basculement et des groupes de disponibilité

Conditions préalables requises et restrictions pour les groupes de disponibilité

Dans cette section :

• Restrictions
• Configuration requise
• Sécurité
• Tâches associées

Restrictions (groupes de disponibilité)

• Les réplicas de disponibilité doivent être hébergés par différents nœuds d'un cluster WSFC : pour un groupe de disponibilité donné, les réplicas de disponibilité doivent être hébergés par des instances de serveur qui s'exécutent sur différents nœuds du même cluster WSFC. La seule exception survient lors de la migration vers un autre cluster : un groupe de disponibilité peut temporairement chevaucher deux clusters.

  Notes

  Les ordinateurs virtuels situés sur le même ordinateur physique peuvent chacun héberger un réplica de disponibilité pour le même groupe de disponibilité, étant donné que chaque ordinateur virtuel agit en tant qu'ordinateur distinct.

• Nom de groupe de disponibilité unique : chaque nom de groupe de disponibilité doit être unique sur le cluster WSFC. La longueur maximale d'un nom de groupe de disponibilité est de 128 caractères.

• Réplicas de disponibilité : chaque groupe de disponibilité prend en charge un réplica principal et jusqu'à huit réplicas secondaires. Tous les réplicas peuvent s’exécuter en mode de validation asynchrone, ou au plus cinq d’entre eux peuvent s’exécuter en mode de validation synchrone (un réplica principal avec deux réplicas secondaires synchrones). Chaque réplica doit avoir un nom de serveur unique à la fois dans Windows et dans SQL Server. Les noms de serveur entre Windows et SQL Server doivent correspondre.

• Nombre maximal de groupes de disponibilité et de bases de données de disponibilité par ordinateur : Le nombre réel de bases de données et les groupes de disponibilité que vous pouvez placer sur un ordinateur (virtuel ou physique) dépendent du matériel et de la charge de travail, mais il n'existe aucune limite imposée. Microsoft a testé jusqu’à 10 groupes de disponibilité et 100 bases de données par machine physique, mais il ne s’agit pas d’une limite contraignante. Selon la spécification matérielle du serveur et de la charge de travail, il peut être possible de placer plus de bases de données et de groupes de disponibilité sur une instance SQL Server. Les signes d’un système surchargé incluent, notamment, l’épuisement des threads de travail, des temps de réponse longs pour les vues système et les vues de gestion dynamique des groupes de disponibilité et/ou des vidages de système de répartiteur bloqués. Veillez à tester soigneusement votre environnement avec une charge de travail semblable à celle de production pour vous assurer qu'il peut gérer la capacité de pointe conformément au contrat de niveau de service de l'application. Lorsque vous choisissez les contrats de niveau de service, assurez-vous de prendre en compte la charge en conditions d'échec ainsi que les temps de réponse attendus.

• N’utilisez pas le Gestionnaire du cluster de basculement pour manipuler les groupes de disponibilité. L’état d’une FCI SQL Server est partagé entre SQL Server et le cluster de basculement du serveur Windows (WSFC), avec SQL Server conservant des informations d’état plus détaillées sur les instances que ce dont le cluster s’occupe. Le modèle de gestion est que SQL Server doit piloter les transactions et est chargé de conserver la vue de l’état du cluster synchronisée avec la vue de l’état de SQL Server. Si l’état du cluster est changé en dehors de SQL Server, il est possible que l’état soit désynchronisé entre le cluster de basculement Windows et SQL Server, ce qui pourrait entraîner un comportement imprévisible.

  Par exemple :

  • Ne modifiez pas les propriétés du groupe de disponibilité, telles que les propriétaires possibles.

  • N'utilisez pas le gestionnaire du cluster de basculement pour basculer des groupes de disponibilité. Vous devez utiliser Transact-SQL ou SQL Server Management Studio.

• N’ajoutez pas de ressources ou ne modifiez pas des dépendances associées au rôle de groupe de disponibilité. Nous vous déconseillons de placer toutes les ressources supplémentaires (notamment les ressources utilisateur ou tierces) dans le rôle de groupe de disponibilité ou de modifier les dépendances de rôle, car ces changements peuvent avoir un impact négatif sur les performances de basculement.

Conditions préalables requises (groupes de disponibilité)

Lors de la création ou de la reconfiguration d'un groupe de disponibilité, veillez à respecter les conditions préalables requises suivantes.

Sécurité (groupes de disponibilité)

• La sécurité est héritée du cluster WSFC. Le clustering de basculement Windows Server fournit deux niveaux de sécurité utilisateur avec la granularité de l’ensemble du cluster :

  • Accès en lecture seule

  • Contrôle total

    Groupes de disponibilité Always On nécessite un contrôle total, et l’activation de Groupes de disponibilité Always On sur une instance de SQL Server lui donne le contrôle total du cluster (par le biais du SID du service).

    Vous ne pouvez pas ajouter ou supprimer directement la sécurité d'une instance de serveur dans le Gestionnaire du cluster. Pour gérer les sessions de sécurité de cluster, utilisez le Gestionnaire de configuration SQL Server ou le WMI équivalent de SQL Server.

• Chaque instance de SQL Server doit disposer des autorisations d'accès au Registre, cluster, etc.

• Nous vous recommandons d'utiliser le chiffrement pour les connexions entre des instances de serveur qui hébergent des réplicas de disponibilité Groupes de disponibilité Always On .

Autorisations (groupes de disponibilité)

Tâches associées (groupes de disponibilité)

Conditions préalables requises et restrictions pour les bases de données de disponibilité

Pour pouvoir être ajoutée à un groupe de disponibilité, une base de données doit respecter les Conditions préalables requises et restrictions suivantes.

Dans cette section :

• Configuration requise
• Restrictions
• Recommandations pour les ordinateurs qui hébergent des réplicas de disponibilité (système Windows)
• autorisations
• Tâches associées

Liste de contrôle : conditions préalables requises (bases de données de disponibilité)

Pour pouvoir être ajoutée à un groupe de disponibilité, une base de données :

Restrictions (bases de données de disponibilité)

• Si le chemin d'accès du fichier (notamment la lettre de lecteur) d'une base de données secondaire diffère du chemin d'accès de la base de données primaire correspondante, les restrictions suivantes s'appliquent :

  • Assistant Nouveau groupe de disponibilité/Assistant Ajouter une base de données au groupe de disponibilité : l’option Complète n’est pas prise en charge dans la page Sélectionner la synchronisation de données initiale (page des assistants Groupes de disponibilité Always On),

  • RESTORE WITH MOVE : pour créer les bases de données secondaires, les fichiers de base de données doivent avoir l’état RESTORED WITH MOVE sur chaque instance de SQL Server qui héberge un réplica secondaire.

  • Incidence sur les opérations d’ajout de fichier : une opération d’ajout de fichier ultérieure sur le réplica principal peut échouer sur les bases de données secondaires. Cet échec peut entraîner l'interruption des bases de données secondaires. Par voie de conséquence, les réplicas secondaires passent à l'état NOT SYNCHRONIZING.

    Notes

    Pour plus d’informations sur la marche à suivre en cas d’échec d’une opération d’ajout de fichier, consultez Résoudre une opération d’ajout de fichier ayant échoué (Groupes de disponibilité Always On).

• Vous ne pouvez pas supprimer une base de données qui appartient à un groupe de service.

Suivi des bases de données protégées par le chiffrement transparent des données

Si vous utilisez le chiffrement transparent des données (TDE), le certificat ou la clé asymétrique pour la création et le déchiffrement d'autres clés doit être identique sur chaque instance de serveur qui héberge un réplica de disponibilité pour le groupe de disponibilité. Pour plus d’informations, consultez Déplacer une base de données protégée par le chiffrement transparent des données vers un autre serveur SQL Server.

Autorisations (bases de données de disponibilité)

Nécessite l'autorisation ALTER sur la base de données.

Tâches associées (bases de données de disponibilité)

Contenu connexe

• Guide de solutions Microsoft SQL Server Always On pour la haute disponibilité et la récupération d’urgence
• Blog de l’équipe SQL Server Always On : Blog officiel de l’équipe SQL Server Always On
• Always On - HADRON Learning Series: Worker Pool Usage for HADRON Enabled Databases
• Qu’est-ce qu’un groupe de disponibilité Always On ?
• Clustering de basculement et groupes de disponibilité Always On (SQL Server)
• Prise en charge des pilotes et de la connectivité cliente pour les groupes de disponibilité