Conditions préalables requises, restrictions et recommandations pour les groupes de disponibilité AlwaysOn (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 pour les ordinateurs hôtes, les clusters WSFC (Clustering de basculement Windows Server), 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 qui prennent en charge les groupes de disponibilité AlwaysOn

Selon les composants et fonctionnalités SQL Server 2014 que vous utiliserez avec les groupes de disponibilité Always On, vous devrez peut-être 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 logiciel pour .NET 3.5 SP1 ajoute la prise en charge des fonctionnalités SQL Client pour AlwaysOn de l’intention en lecture, en lecture seule et multisubnetfailover. Le correctif doit être installé sur chaque serveur de rapports Reporting Services .	Kb 2654347 : Correctif logiciel pour .NET 3.5 SP1 afin d’ajouter la prise en charge des fonctionnalités AlwaysOn

Exigences et recommandations système de Windows

Liste de vérification des conditions requises (système Windows)

Pour prendre en charge la fonctionnalité Groupes de disponibilité Always On, assurez-vous que chaque ordinateur qui doit participer à un ou plusieurs groupes de disponibilité répond aux exigences 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.
	Vérifiez que chaque ordinateur exécute soit x86 (non-WOW64), soit x64 Windows Server 2008 ou versions ultérieures.	WOW64 (Windows 32 bits sur Windows 64 bits) ne prend pas en charge les groupes de disponibilité Always On.
	Vérifiez que chaque ordinateur est un nœud d'un cluster WSFC (clustering de basculement Windows Server).	Clustering de basculement Windows Server (WSFC) avec SQL Server
	Vérifiez que le cluster WSFC contient suffisamment de nœuds pour prendre en charge les groupes de disponibilité que vous avez configurés.	Un nœud WSFC ne peut héberger qu'un seul réplica de disponibilité pour un groupe de disponibilité donné. Sur un nœud WSFC donné, une ou plusieurs instances de SQL Server peuvent héberger des réplicas de disponibilité pour de nombreux groupes de disponibilité. Demandez à vos administrateurs de base de données combien de nœuds WSFC sont requis pour prendre en charge les réplicas de disponibilité des groupes de disponibilité planifiés. Vue d’ensemble des groupes de disponibilité AlwaysOn (SQL Server).
	Vérifiez que tous les correctifs logiciels Windows applicables ont été installés sur chaque nœud du cluster WSFC.	** Important ** Un certain nombre de correctifs logiciels sont requis ou recommandés pour les nœuds d’un cluster WSFC sur lequel les groupes de disponibilité Always On sont déployés. Pour plus d'informations, consultez Correctifs logiciels Windows qui prennent en charge les groupes de disponibilité AlwaysOn (système Windows), plus loin dans cette section.

Correctifs logiciels Windows prenant en charge les groupes de disponibilité AlwaysOn (système Windows)

Selon la topologie de votre cluster, plusieurs correctifs logiciels Windows Server 2008 Service Pack 2 (SP2) ou Windows Server 2008 R2 supplémentaires peuvent s’appliquer pour prendre en charge les groupes de disponibilité Always On. Le tableau suivant identifie ces correctifs. Ces derniers peuvent être installés dans n'importe quel ordre.

	S'applique à Windows 2008 SP2	S'applique à Windows 2008 R2 SP1	Fourni avec Windows 2012	Pour prendre en charge...	Correctif logiciel	Lien
	Oui	Oui	Oui	Configuration d’un quorum WSFC optimal	Sur chaque nœud WSFC, assurez-vous que le correctif logiciel décrit dans l'article 2494036 de la base de connaissances est installé. Ce correctif logiciel prend en charge la configuration du quorum optimal avec les cibles de basculement non automatique. Cette fonctionnalité améliore les clusters multisites en vous permettant de sélectionner les nœuds votants.	Article 2494036 de la base de connaissances : Un correctif est disponible pour vous permettre de configurer un nœud de cluster qui n'a pas de voix de quorum dans Windows Server 2008 et Windows Server 2008 R2 Pour plus d’informations sur le vote de quorum, consultez Les modes de quorum WSFC et la configuration de vote (SQL Server)
	Oui	Oui	Oui	Utilisation plus efficace de la bande passante réseau	Sur chaque nœud WSFC, assurez-vous que le correctif logiciel décrit dans l'article 2616514 de la base de connaissances est installé. Sans ce correctif, le service de cluster envoie des notifications de registre inutiles à des nœuds de cluster. Ce comportement limite la bande passante réseau, qui est un problème sérieux pour les groupes de disponibilité Always On.	Article 2616514 de la base de connaissances : Le service de cluster envoie des notifications de changement de clé de Registre inutiles entre les nœuds de cluster dans Windows Server 2008 ou Windows Server 2008 R2
		Oui	Non applicable	Test de stockage VPD sur les disques qui ne sont pas disponibles pour tous les nœuds WSFC	Si un nœud WSFC exécute Windows Server 2008 R2 Service Pack 1 (SP1) et que le test de stockage Valider les données VPD (Vital Product Data) du périphérique SCSI échoue suite à une exécution incorrecte sur des disques qui sont en ligne et ne sont pas accessibles à tous les nœuds du cluster WSFC, installez le correctif décrit dans l'article KB 2531907 de la Base de connaissances. Ce correctif logiciel élimine les avertissements ou erreurs incorrects dans le rapport de validation lorsque les disques sont en ligne.	Article 2531907 de la base de connaissances : Le test Valider les données VPD (Vital Product Data) du périphérique SCSI échoue après l'installation de Windows Server 2008 R2 SP1
		Oui	Oui	Basculement plus rapide vers des réplicas locaux	Si un nœud WSFC exécute Windows Server 2008 R2 Service Pack 1 (SP1), vérifiez que le correctif logiciel décrit dans l'article 2687741 de la base de connaissances est installé. Ce correctif logiciel améliore les performances du basculement des groupes de disponibilité Always On vers des réplicas locaux.	Article 2687741 de la base de connaissances : Un correctif logiciel qui améliore les performances de la fonctionnalité « Groupe de disponibilité AlwaysOn » dans SQL Server 2012 est disponible pour Windows Server 2008 R2
	Oui	Oui	Oui	Instances de cluster de basculement asymétriques	Si une instance de cluster de basculement (FCI) est activée pour les groupes de disponibilité Always On, installez le correctif logiciel Windows Server 2008 976097. Ce correctif logiciel permet au composant logiciel enfichable MMC (Failover Cluster Management Console) de prendre en charge les disques partagés de stockage asymétriques disponibles uniquement sur certains des nœuds WSFC.	Article 976097 de la base de connaissances : Correctif logiciel pour l'ajout du stockage asymétrique au composant logiciel enfichable MMC de gestion du cluster de basculement pour un cluster de basculement exécutant Windows Server 2008 ou Windows Server 2008 R2 Guide d’architecture AlwaysOn : Création d’une solution de haute disponibilité et de récupération d’urgence à l’aide d’instances de cluster de basculement et de groupes de disponibilité
	Oui	Oui	Non applicable	Sécurité du protocole Internet (IPsec)	Si votre environnement utilise des connexions IPsec, vous pouvez constater un long délai (environ deux ou trois minutes) lorsqu'un ordinateur client rétablit la connexion IPsec à un nom de réseau virtuel (dans ce contexte, pour se connecter à l'écouteur de groupe de disponibilité). Si vous utilisez des connexions IPsec, nous vous recommandons d'examiner les scénarios spécifiques détaillés dans l'article KB 980915 de la Base de connaissances.	Article 980915 de la base de connaissances : Un long délai se produit lorsque vous vous reconnectez à une connexion IPSec à partir d'un ordinateur qui exécute Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7 ou Windows Server 2008 R2
	Oui	Oui	Oui	IPv6	Si vous utilisez IPv6, nous vous recommandons d'examiner les scénarios spécifiques détaillés dans l'article 2578103 ou 2578113 de la base de connaissances, selon votre système d'exploitation Windows Server. Si votre topologie Windows Server utilise IPv6 (Internet Protocol version 6), il faut environ 30 secondes au service de cluster WSFC pour basculer vers l'adresse IP IPv6. De ce fait, les clients doivent attendre environ 30 secondes pour se reconnecter à l'adresse IP IPv6.	Article 2578103 de la base de connaissances (Windows Server 2008) : Il faut environ 30 secondes au service de cluster pour basculer des adresses IP IPv6 dans Windows Server 2008 Kb 2578113 (Windows Server 2008 R2) : Windows Server 2008 R2 : Le service de cluster prend environ 30 secondes pour basculer les adresses IP IPv6 dans Windows Server 2008 R2
	Oui	Oui	Oui	Aucun routeur entre le cluster et le serveur d’applications	S'il n'existe aucun routeur entre le cluster de basculement et le serveur d'applications, le service de cluster bascule lentement les ressources liées au réseau. Cela retarde les reconnexions du client après le basculement du groupe de disponibilité. En l'absence d'un routeur, nous vous recommandons d'examiner les scénarios spécifiques détaillés dans l'article KB 2582281 et d'installer le correctif logiciel, si cela s'applique à votre environnement.	Article 2582281 de la base de connaissances : Ralentissez l'opération de basculement s'il n'existe aucun routeur entre le cluster et un serveur d'applications

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 des performances optimales, utilisez une carte réseau dédiée (carte d’interface réseau) pour les 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 Windows 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 réseau, puis utilisez l'applet de commande Set-ClusterParameter pour définir la valeur HostRecordTTL, comme suit :

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

   L'exemple PowerShell suivant définit HostRecordTTL à 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 ClusterParameter HostRecordTTL 300  
   

   Conseil

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

Contenu connexe (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 connexe (système Windows)

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

• Enregistrement DNS avec ressource de nom réseau

• Clustering multis sites de basculement Windows 2008 R2

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 SQL Serverinstance de cluster de basculement (FCI).

Liste de vérification : Conditions préalables requises (instance de serveur)

	Configuration requise	Liens
	L'ordinateur hôte doit se trouver sur un nœud WSFC (clustering de basculement Windows Server). Les instances de SQL Server qui hébergent des réplicas de disponibilité pour un groupe de disponibilité donné doivent résider sur des nœuds distincts d’un seul cluster WSFC. La seule exception survient lors de la migration vers un autre cluster WSFC : un groupe de disponibilité peut temporairement chevaucher deux clusters.	Clustering de basculement Windows Server (WSFC) avec SQL Server Clustering de basculement et groupes de disponibilité AlwaysOn (SQL Server)
	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. ** Important ** si vous modifiez le compte de service SQL Server, l’administrateur de domaine devra réinscrire le SPN manuellement.	Inscrire un nom de principal du service pour les connexions Kerberos Brève explication : 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.	Restrictions et conditions préalables requises pour l’utilisation d’une instance de cluster de basculement SQL Server afin d’héberger un réplica de disponibilité (plus loin dans cette rubrique)
	Chaque instance de serveur doit exécuter la Êdition Entreprise de SQL Server 2014.	Fonctionnalités prises en charge par les éditions de SQL Server 2014
	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 n’importe quel groupe de disponibilité. Sur un ordinateur donné, vous pouvez activer autant d’instances de serveur pour les groupes de disponibilité Always On que votre installation de SQL Server prend en charge.	Activer et désactiver des groupes de disponibilité AlwaysOn (SQL Server) ** Important ** Si vous supprimez et recréez un cluster WSFC, vous devez désactiver et réactiver la fonctionnalité Groupes de disponibilité Always On sur chaque instance de serveur activée pour les groupes de disponibilité Always On sur le cluster WSFC d’origine.
	Chaque instance de serveur nécessite un point de terminaison de mise en miroir de bases de données. Notez que 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, l’ Assistant Nouveau groupe de disponibilité (ou l’ Assistant Ajouter un réplica au groupe de disponibilité) 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 identique à celle de 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 pour la mise en miroir de bases de données et les groupes de disponibilité AlwaysOn (SQL Server)
	Si des bases de données utilisant FILESTREAM doivent être 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 doivent être ajoutées à 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é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)

Utilisation de threads par les groupes de disponibilité

Les groupes de disponibilité Always On ont les exigences suivantes pour les threads de travail :

• Sur une instance inactive de SQL Server, les groupes de disponibilité Always On utilisent 0 threads.

• 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 spécifique partagent le même pool de threads.

  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.

• 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é.

  • Les réplicas secondaires utilisent un thread de restauration par progression pour chaque base de données secondaire. Les threads de restauration par progression 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.

Pour plus d’informations, consultez AlwaysON - HADRON Learning Series : Worker Pool Usage for HADRON Enabled Databases (un blog CSS SQL Server Engineers).

Autorisations (instance de serveur)

Tâches associées (instance de serveur)

Contenu connexe (instance serveur)

• AlwaysON - Série d’apprentissage HADRON : Utilisation du pool de workers pour les bases de données compatibles HADRON

Recommandations relatives à la connectivité réseau

Nous vous recommandons fortement d'utiliser les mêmes liaisons réseau pour les communications entre les membres du 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 faon 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 La connectivité du client AlwaysOn (SQL Server).

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

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

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

• 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. Notez que 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
	Avant d'utiliser une instance de cluster de basculement pour héberger un réplica de disponibilité, vérifiez que votre administrateur système a installé le correctif logiciel Windows Server 2008 décrit dans l'article KB 976097 de la Base de connaissances. Ce correctif logiciel permet au composant logiciel enfichable MMC (Failover Cluster Management Console) de prendre en charge les disques partagés de stockage asymétriques disponibles uniquement sur certains des nœuds WSFC.	Article 976097 de la base de connaissances : Correctif logiciel pour l'ajout du stockage asymétrique au composant logiciel enfichable MMC de gestion du cluster de basculement pour un cluster de basculement exécutant Windows Server 2008 ou Windows Server 2008 R2
	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 (instances de cluster de basculement)

Contenu connexe (instances de cluster de basculement)

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

• Guide d’architecture AlwaysOn : Création d’une solution de haute disponibilité et de récupération d’urgence à l’aide d’instances de cluster de basculement et de groupes de disponibilité

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

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 WSFC : un groupe de disponibilité peut temporairement chevaucher deux clusters.

  Remarque

  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 trois d'entre eux peuvent s'exécuter en mode de validation synchrone (un réplica principal et deux réplicas secondaires synchrones).

• 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 largement testé des systèmes comportant 10 100 groupes de disponibilité et 100 bases de données par ordinateur physique. 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 AlwaysOn 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 des groupes de disponibilité :

  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.

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 pour l’utilisation d’une instance de cluster de basculement SQL Server afin d’héberger un réplica de disponibilité (plus haut dans cette rubrique)

Sécurité (groupes de disponibilité)

• La sécurité est héritée du cluster WSFC (clustering de basculement Windows Server). WSFC fournit deux niveaux de sécurité utilisateur en fonction de la granularité des API de cluster entières :

  • Accès en lecture seule

  • Contrôle total

    Les groupes de disponibilité Always On ont besoin d’un contrôle total et l’activation des groupes de disponibilité Always On sur une instance de SQL Server lui donne un contrôle total du cluster WSFC (via le SID de service).

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

• Chaque instance de SQL Server doit disposer des autorisations nécessaires pour accéder au Registre, au cluster et au soforth.

• Nous vous recommandons d’utiliser le chiffrement pour les connexions entre les instances de serveur qui hébergent des réplicas de disponibilité des 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.

Liste de vérification : 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)
	Utilisez le mode de récupération complète (également appelé 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 complète de base de données (SQL Server)
	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)

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

  • 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.

    Remarque

    Pour plus d’informations sur la réponse à une opération de fichier publicitaire ayant échoué, consultez Résoudre les problèmes liés à une opération de complément ayant échoué (groupes de disponibilité AlwaysOn).

• 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 associé

• Guide des solutions AlwaysOn de Microsoft SQL Server pour la haute disponibilité et la récupération d’urgence

• Blog de l’équipe SQL Server AlwaysOn : Blog officiel de l’équipe SQL Server AlwaysOn

• AlwaysON - Série d’apprentissage HADRON : Utilisation du pool de workers pour les bases de données compatibles HADRON

Voir aussi

Vue d’ensemble des groupes de disponibilité AlwaysOn (SQL Server)
Clustering de basculement et groupes de disponibilité AlwaysOn (SQL Server)
Connectivité du client AlwaysOn (SQL Server)