Partage via

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

  • Article

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.

Important

Avant de déployer Groupes de disponibilité Always On, nous vous recommandons de lire les sections de cette rubrique.

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.

Fonctionnalité dépendante Correctif logiciel Lien
Reporting Services Le correctif pour .NET 3.5 SP1 ajoute une prise en charge au client SQL concernant les fonctionnalités Always On d’intention de lecture (read-intent), de lecture seule (readonly) et de basculement à plusieurs sous-réseaux (multisubnetfailover). Le correctif doit être installé sur chaque serveur de rapports Reporting Services . ARTICLE 2654347 DE LA BASE DE CONNAISSANCES : Correctif pour .NET 3.5 SP1 pour l’ajout d’une prise en charge des fonctionnalités Always On

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 :

Condition requise Lien
Vérifiez que ce système n'est pas un contrôleur de domaine. Les groupes de disponibilité ne sont pas pris en charge sur les contrôleurs de domaine.
Assurez-vous que chaque ordinateur fonctionne avec une version de Windows Server prise en charge Configuration matérielle et logicielle requise pour :
- SQL Server 2022
- SQL Server 2019
- SQL Server 2017
- SQL Server 2016
Vérifiez que chaque ordinateur est un nœud dans un cluster WSFC. Clustering de basculement Windows Server avec SQL Server
Vérifiez que le cluster WSFC contient suffisamment de nœuds pour prendre en charge vos configurations de groupe de disponibilité. Un nœud de cluster peut héberger un réplica pour un groupe de disponibilité. Le même nœud ne peut pas héberger deux réplicas du même groupe de disponibilité. Le nœud de cluster peut participer à plusieurs groupes de disponibilité, avec un réplica de chaque groupe.

Demandez à vos administrateurs de base de données le nombre de nœuds de cluster nécessaires pour prendre en charge les réplicas de disponibilité des groupes de disponibilité planifiés.

Qu’est-ce qu’un groupe de disponibilité Always On ?.

Important

Vérifiez que votre environnement est correctement configuré pour se connecter à un groupe de disponibilité. Pour de plus amples informations, consultez Prise en charge des pilotes et de la connectivité du client pour les groupes de disponibilité.

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.

  • Disposition de disque identique : chaque ordinateur sur lequel une instance de serveur héberge un réplica de disponibilité doit avoir une disposition de disque identique (avec des lettres et des tailles exactes de lecteur de disque) pour garantir que les chemins d’accès aux fichiers de base de données (mdf, ldf) sont en miroir, ce qui empêche les complications lors de l’amorçage et de la synchronisation. Passez en revue les Restrictions (bases de données de disponibilité) pour connaître les dispositions de disque qui diffèrent.

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)

Tâche Lien
Définissez la valeur de HostRecordTTL. Modifiez HostRecordTTL (à l'aide de Windows PowerShell)

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)

Contenu associé (système Windows)

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 contrôle : conditions préalables requises (instance de serveur)

Configuration requise Liens
Cet ordinateur hôte doit être un nœud WSFC. Les instances de SQL Server qui hébergent les réplicas de disponibilité d’un groupe de disponibilité donné résident sur des nœuds distincts du cluster. Un groupe de disponibilité peut temporairement chevaucher deux clusters pendant sa migration vers un autre cluster. SQL Server 2016 (13.x) introduit les groupes de disponibilité distribués. Dans un groupe de disponibilité distribué, deux groupes de disponibilité résident sur des clusters différents. Clustering de basculement Windows Server avec SQL Server

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

Groupes de disponibilité distribués
Si vous souhaitez qu'un groupe de disponibilité utilise Kerberos :

Toutes les instances de serveur qui hébergent un réplica de disponibilité pour le groupe de disponibilité doivent utiliser le même compte de service SQL Server.

L'administrateur de domaine doit inscrire manuellement un nom de principal de service (SPN) avec Active Directory sur le compte de service SQL Server pour le nom de réseau virtuel (VNN) de l'écouteur de groupe de disponibilité. Si le SPN est inscrit sur un compte différent du compte de service SQL Server, l'authentification échoue.

Pour utiliser l’authentification Kerberos pour la communication entre les points de terminaison de groupe de disponibilité, inscrivez des nom de principal de service manuellement pour les points de terminaison de mise en miroir de bases de données utilisés par le groupe de disponibilité.

Important : si vous modifiez le compte de service SQL Server, l’administrateur de domaine doit réinscrire le SPN manuellement.		 Inscrire un nom de principal du service pour les connexions Kerberos

Remarque :

Kerberos et les SPN assurent une authentification mutuelle. Le SPN est mappé au compte Windows qui démarre les services SQL Server. Si l'inscription du SPN n'est pas effectuée correctement ou échoue, la couche de sécurité Windows ne peut pas déterminer le compte associé au SPN et l'authentification Kerberos ne peut pas être utilisée.

Remarque : NTLM n'est pas soumis à cette condition.
Si vous envisagez d'utiliser une instance de cluster de basculement SQL Server pour héberger un réplica de disponibilité, assurez-vous de comprendre les restrictions relatives à l'instance de cluster de basculement et de respecter les conditions préalables requises pour cette dernière. Prérequis et restrictions concernant l’utilisation d’une instance de cluster de basculement SQL Server afin d’héberger un réplica de disponibilité (plus loin dans cet article)
Pour participer à un groupe de disponibilité, chaque instance de serveur doit exécuter la même version de SQL Server. Pour de plus amples informations, consultez la liste des éditions et des fonctionnalités prises en charge à la fin de cette section.
Toutes les instances de serveur qui hébergent des réplicas de disponibilité pour un groupe de disponibilité doivent utiliser le même classement SQL Server . Définir ou modifier le classement du serveur
Activez la fonctionnalité Groupes de disponibilité Always On sur chaque instance de serveur qui hébergera un réplica de disponibilité pour un groupe de disponibilité. Sur un ordinateur donné, vous pouvez activer autant d'instances de serveur que vous le souhaitez pour Groupes de disponibilité Always On , dans la limite du nombre pris en charge par votre installation de SQL Server . Activer ou désactiver la fonctionnalité de groupe de disponibilité Always On

Important : si vous supprimez et recréez un cluster WSFC, vous devez désactiver puis réactiver la fonctionnalité Groupes de disponibilité Always On sur chaque instance de serveur qui était activée pour les Groupes de disponibilité Always On sur le cluster d’origine.
Chaque instance de serveur nécessite un point de terminaison de mise en miroir de bases de données. Ce point de terminaison est partagé par tous les réplicas de disponibilité, ainsi que par tous les serveurs partenaires et témoins de mise en miroir de bases de données sur l'instance de serveur.

Si une instance de serveur que vous sélectionnez pour héberger un réplica de disponibilité s’exécute sous un compte d’utilisateur de domaine et n’a pas encore de point de terminaison de mise en miroir de bases de données, Utiliser l’assistant Groupe de disponibilité (SQL Server Management Studio) (ou Ajouter un réplica à votre groupe de disponibilité Always On à l’aide de l’assistant Groupe de disponibilité dans SQL Server Management) peut créer le point de terminaison et accorder l’autorisation CONNECT au compte de service de l’instance de serveur. Toutefois, si le service SQL Server s'exécute en tant que compte intégré, tel que Système local, Service local ou Service réseau, ou comme compte qui n'appartient pas au domaine, vous devez utiliser des certificats pour l'authentification du point de terminaison, et l'Assistant ne peut pas créer un point de terminaison de mise en miroir de bases de données sur l'instance de serveur. Dans ce cas, nous recommandons de créer les points de terminaison de mise en miroir de bases de données manuellement avant de lancer l'Assistant.

Note de sécurité : la sécurité du transport pour les Groupes de disponibilité Always On est la même que pour la mise en miroir de bases de données.		 Point de terminaison de mise en miroir de bases de données (SQL Server)

Sécurité du transport – mise en miroir de bases de données – Groupes de disponibilité Always On
Si des bases de données utilisant FILESTREAM sont ajoutées à un groupe de disponibilité, vérifiez que FILESTREAM est activé sur chaque instance de serveur qui hébergera un réplica de disponibilité pour le groupe de disponibilité. Activer et configurer FILESTREAM
Si des bases de données autonomes sont ajoutées à un groupe de disponibilité, vérifiez que contained database authentication (option de configuration du serveur) a la valeur 1 sur chaque instance de serveur qui héberge un réplica de disponibilité pour le groupe de disponibilité. Authentification de la base de données autonome (option de configuration de serveur)

Options de configuration du serveur (SQL Server)

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

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âche Autorisations requises
Création du point de terminaison de mise en miroir de bases de données Requiert l'autorisation CREATE ENDPOINT ou l'appartenance au rôle serveur fixe sysadmin . Requiert également l'autorisation CONTROL ON ENDPOINT. Pour plus d’informations, consultez Autorisations de point de terminaison GRANT (Transact-SQL).
Activation de Groupes de disponibilité Always On Nécessite l'appartenance au groupe Administrateur sur l'ordinateur local et le contrôle total sur le cluster WSFC.

Tâches associées (instance de serveur)

Tâche Article
Détermination de l'existence du point de terminaison de mise en miroir de bases de données sys.database_mirroring_endpoints (Transact-SQL)
Création du point de terminaison de mise en miroir de bases de données (s'il n'existe pas encore) Créer un point de terminaison de mise en miroir de bases de données pour l'authentification Windows (Transact-SQL)

Utiliser des certificats pour un point de terminaison de mise en miroir de bases de données (Transact-SQL)

Créer un point de terminaison de mise en miroir de bases de données pour un groupe de disponibilité à l’aide de PowerShell
Activation des groupes de disponibilité Activer ou désactiver la fonctionnalité de groupe de disponibilité Always On

Contenu associé (instance serveur)

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 (instances de cluster de basculement)

Remarque

Les instances de cluster de basculement (FCI) prennent également en charge les volumes partagés de cluster (CSV). Pour plus d’informations sur les volumes CSV, consultez l’article Présentation des volumes partagés de cluster dans un 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)

Configuration requise Lien
Vérifiez que chaque instance de cluster de basculement SQL Server dispose du stockage partagé requis, conformément à l'installation standard de l'instance de cluster de basculement SQL Server.

Tâches associées (FCI)

Tâche Article
Installation d’une FCI SQL Server Créer une nouvelle instance de cluster de basculement Always On (Installation)
Mise à niveau sur place de votre cluster de basculement SQL Server existant Mettre à niveau une instance de cluster de basculement
Maintenance de votre cluster de basculement SQL Server existant Ajouter ou supprimer des nœuds dans une instance de cluster de basculement (installation)

Contenu associé (FCI)

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

Dans cette section :

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.

Configuration requise Description
Si vous envisagez d'utiliser une instance de cluster de basculement SQL Server pour héberger un réplica de disponibilité, assurez-vous de comprendre les restrictions relatives à l'instance de cluster de basculement et de respecter les conditions préalables requises pour cette dernière. Conditions préalables requises et restrictions concernant l’utilisation d’une instance de cluster de basculement SQL Server afin d’héberger un réplica de disponibilité (plus haut dans cet article)

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âche Autorisations requises
Création d'un groupe de disponibilité Requiert l’appartenance au rôle serveur fixe sysadmin et l’autorisation de serveur CREATE AVAILABILITY GROUP, l’autorisation ALTER ANY AVAILABILITY GROUP ou l’autorisation CONTROL SERVER.
Modification d'un groupe de disponibilité Requiert l'autorisation ALTER AVAILABILITY GROUP sur le groupe de disponibilité, l'autorisation CONTROL AVAILABILITY GROUP, l'autorisation ALTER ANY AVAILABILITY GROUP ou l'autorisation CONTROL SERVER.

En outre, la jointure d’une base de données à un groupe de disponibilité nécessite l’appartenance au rôle de base de données fixe db_owner .
Suppression d'un groupe de disponibilité Requiert l'autorisation ALTER AVAILABILITY GROUP sur le groupe de disponibilité, l'autorisation CONTROL AVAILABILITY GROUP, l'autorisation ALTER ANY AVAILABILITY GROUP ou l'autorisation CONTROL SERVER. Pour supprimer un groupe de disponibilité qui n'est pas hébergé à l'emplacement du réplica local, vous avez besoin de l'autorisation CONTROL SERVER ou CONTROL sur ce groupe de disponibilité.

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

Tâche Article
Création d'un groupe de disponibilité Utiliser l’Assistant Groupe de disponibilité (SQL Server Management Studio)

Créer un groupe de disponibilité Always On à l’aide de Transact-SQL (T-SQL)

Créer un groupe de disponibilité Always On à l’aide de PowerShell

Spécifier l’URL de point de terminaison – Ajout ou modification d’un réplica de disponibilité
Modification du nombre de réplicas de disponibilité Ajouter un réplica secondaire à un groupe de disponibilité Always On

Joindre un réplica secondaire à un groupe de disponibilité Always On

Supprimer un réplica secondaire d'un groupe de disponibilité (SQL Server)
Création d'un écouteur de groupe de disponibilité Configurer un écouteur Always On pour un groupe de disponibilité
Annulation d'un groupe de disponibilité Supprimer un groupe de disponibilité (SQL Server)

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 :

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 :

Spécifications Lien
doit être une base de données utilisateur. Les bases de données système ne peuvent pas appartenir à un groupe de disponibilité ;
doit résider sur l'instance de SQL Server où vous créez le groupe de disponibilité et être accessible à l'instance de serveur ;
doit être une base de données en lecture/écriture. Les bases de données en lecture seule ne peuvent pas être ajoutées à un groupe de disponibilité ; sys.databases (is_read_only = 0)
doit être une base de données multi-utilisateur ; sys.databases (user_access = 0)
ne doit pas utiliser AUTO_CLOSE ; sys.databases (is_auto_close_on = 0)
doit utiliser le modèle de récupération complète ; sys.databases (recovery_model = 1)
Possédez au moins une sauvegarde complète de base de données.

Remarque : après avoir défini une base de données en mode de récupération complète, une sauvegarde complète est requise pour initialiser la séquence de journaux de récupération complète.		 Créer une sauvegarde de base de données complète
ne doit pas appartenir à un groupe de disponibilité existant ; sys.databases (group_database_id = NULL)
ne doit pas être configurée pour la mise en miroir de base de données. sys.database_mirroring (Si la base de données ne participe pas à la mise en miroir, toutes les colonnes qui utilisent le préfixe « mirroring » ont la valeur NULL.)
Avant d'ajouter une base de données qui utilise FILESTREAM à un groupe de disponibilité, vérifiez que FILESTREAM est activé sur chaque instance de serveur qui héberge ou hébergera un réplica de disponibilité pour le groupe de disponibilité. Activer et configurer FILESTREAM
Avant d'ajouter une base de données autonome à un groupe de disponibilité, vérifiez que l'option de serveur contained database authentication a la valeur 1 sur chaque instance de serveur qui héberge ou hébergera un réplica de disponibilité pour le groupe de disponibilité. Authentification de la base de données autonome (option de configuration de serveur)

Options de configuration du serveur (SQL Server)

Notes

Groupes de disponibilité Always On fonctionne avec tous les niveaux de compatibilité de base de données pris en charge.

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é)

Tâche Article
Préparation d'une base de données secondaire (manuellement) Préparer une base de données secondaire pour un groupe de disponibilité Always On
Jointure d'une base de données secondaire à un groupe de disponibilité (manuellement) Joindre une base de données secondaire à un groupe de disponibilité Always On
Modification du nombre de bases de données de disponibilité Ajouter une base de données à un groupe de disponibilité Always On

Supprimer une base de données secondaire d'un groupe de disponibilité (SQL Server)

Supprimer une base de données primaire d’un groupe de disponibilité Always On

Contenu connexe