Cluster de basculement et groupes de disponibilité AlwaysOn (SQL Server)

Les groupes de disponibilité Always On, la solution de haute disponibilité et de reprise après sinistre introduite dans SQL Server 2014, requièrent le clustering de basculement de Windows Server (WSFC). En outre, bien que les groupes Always On de disponibilité ne dépendent pas d'un cluster de basculement SQL Server, vous pouvez utiliser une instance de cluster de basculement (FCI) pour héberger un réplica de disponibilité pour un groupe de disponibilité. Il est important de connaître le rôle de chaque technologie de clustering et de connaître les considérations nécessaires lorsque vous concevez votre environnement de groupes de disponibilité Always On.

Clustering de basculement de serveur Windows et groupes de disponibilité

Le déploiement de groupes de disponibilité Always On nécessite un cluster WSFC (Windows Server Failover Clustering). Pour être activé pour les groupes de disponibilité Always On, une instance de SQL Server doit résider sur un nœud WSFC, et le cluster et le nœud WSFC doivent être en ligne. En outre, chaque réplica de disponibilité d’un groupe de disponibilité donné doit résider sur un nœud différent 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.

Les groupes de disponibilité Always On s’appuient sur le cluster WSFC (Clustering de basculement Windows) pour surveiller et gérer les rôles actuels des réplicas de disponibilité appartenant à un groupe de disponibilité donné et déterminer comment un événement de basculement affecte les réplicas de disponibilité. Un groupe de ressources WSFC est créé pour chaque groupe de disponibilité que vous créez. Le cluster WSFC surveille ce groupe de ressources pour évaluer l’intégrité du réplica principal.

Le quorum pour les groupes de disponibilité Always On est déterminé par tous les nœuds du cluster WSFC, indépendamment du fait qu'un nœud donné héberge ou non des réplicas de disponibilité. Contrairement à la mise en miroir de bases de données, il n’existe aucun rôle témoin dans les groupes de disponibilité Always On.

La santé globale d’un cluster WSFC est déterminée par les votes du quorum des nœuds du cluster. Si le cluster WSFC est hors connexion en raison d’un sinistre non planifié ou en raison d’une défaillance matérielle ou de communication persistante, une intervention administrative manuelle est requise. Un administrateur de cluster Windows Server ou WSFC devra forcer un quorum, puis ramener les nœuds de cluster survivants en ligne dans une configuration sans tolérance de panne.

Pour plus d’informations sur l’exécution de SQL Server sur des nœuds de clustering de basculement Windows Server (WSFC) et sur le quorum WSFC, consultez Le clustering de basculement Windows Server (WSFC) avec SQL Server.

Migration entre clusters des groupes de disponibilité AlwaysOn pour la mise à niveau du système d’exploitation

À compter de SQL Server 2012 SP1, les groupes de disponibilité Always On prennent en charge la migration inter-clusters de groupes de disponibilité pour les déploiements vers un nouveau cluster WSFC (Windows Server Failover Clustering). Une migration entre clusters déplace un groupe de disponibilité ou un lot de groupes de disponibilité vers le nouveau cluster WSFC de destination avec un temps d’arrêt minimal. Le processus de migration entre clusters vous permet de maintenir vos contrats de niveau de service (SLA) lors de la mise à niveau vers un cluster Windows Server 2012. SQL Server 2012 SP1 (ou version ultérieure) doit être installé et activé pour AlwaysOn sur le cluster WSFC de destination. La réussite d’une migration entre clusters dépend de la planification et de la préparation approfondies du cluster WSFC de destination.

Pour plus d’informations, consultez Migration entre clusters des groupes de disponibilité AlwaysOn pour la mise à niveau du système d’exploitation.

SQL Server Instances de cluster de basculement et groupes de disponibilité

Vous pouvez configurer une deuxième couche de basculement au niveau de l’instance de serveur en implémentant le clustering de basculement SQL Server avec le cluster WSFC. Un réplica de disponibilité peut être hébergé par une instance autonome de SQL Server ou par une instance de cluster de basculement. Un seul partenaire FCI peut héberger un réplica pour un groupe de disponibilité donné. Lorsqu'un réplica de disponibilité s'exécute sur une FCI, la liste des propriétaires possibles pour le groupe de disponibilité contiendra uniquement le nœud FCI actif.

Les groupes de disponibilité Always On ne dépendent d’aucune forme de stockage partagé. Toutefois, si vous utilisez une instance de cluster de basculement SQL Server pour héberger un ou plusieurs réplicas de disponibilité, chacune de ces instances de cluster de basculement requiert un stockage partagé conformément à l'installation standard de l'instance de cluster de basculement SQL Server.

Pour plus d’informations sur les prérequis supplémentaires, consultez la section « Conditions préalables et restrictions relatives à l’utilisation d’une instance de cluster de basculement SQL Server (FCI) pour héberger un réplica de disponibilité » des Prérequis, Restrictions, et Recommandations pour les Groupes de Disponibilité AlwaysOn (SQL Server).

Comparaison des instances de cluster de basculement et des groupes de disponibilité

Quel que soit le nombre de nœuds de l'instance de cluster de basculement, celle-ci ne peut héberger qu'un seul réplica dans un groupe de disponibilité. Le tableau suivant décrit les distinctions de concepts entre les nœuds d'une instance de cluster de basculement et les réplicas dans un groupe de disponibilité.

*Alors que les réplicas secondaires synchrones dans un groupe de disponibilité s’exécutent toujours sur leurs instances SQL Server respectives, les nœuds secondaires dans une instance de cluster de basculement n’ont pas démarré leurs instances SQL Server respectives et sont donc inaccessibles en lecture. Dans une instance de cluster de basculement, un nœud secondaire démarre son instance de SQL Server uniquement lorsque la propriété du groupe de ressources lui est transférée lors d'un basculement de l'instance de cluster de basculement. Toutefois, sur le nœud actif de l'instance de cluster de basculement, lorsqu'une base de données hébergée par l'instance de cluster de basculement appartient à un groupe de disponibilité, si le réplica de disponibilité local s'exécute comme réplica secondaire accessible en lecture, la base de données est accessible en lecture.

**Les paramètres de stratégie de basculement du groupe de disponibilité s’appliquent à tous les réplicas, qu’il soit hébergé dans une instance autonome ou une instance de cluster de basculement.

Considérations relatives à l'hébergement d'un réplica de disponibilité sur une instance de cluster de disponibilité

Les instances de cluster de basculement (FCI) SQL Server 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 ne peut être configuré que pour un basculement manuel.

Vous devrez peut-être configurer un cluster WSFC (Clustering de basculement Windows Server) pour inclure des disques partagés qui ne sont pas disponibles sur tous les nœuds. Par exemple, considérez un cluster WSFC sur deux centres de données avec trois nœuds. Deux des nœuds hébergent une instance de clustering de basculement SQL Server dans le centre de données principal et ont accès aux mêmes disques partagés. Le troisième nœud héberge une instance autonome de SQL Server dans un centre de données différent et n'a pas accès aux disques partagés du centre de données principal. Cette configuration de cluster WSFC prend en charge le déploiement d’un groupe de disponibilité si l’instance FCI héberge le réplica principal et que l’instance autonome héberge le réplica secondaire.

Lorsque vous choisissez une instance de cluster de basculement pour l'hébergement d'un réplica de disponibilité pour un groupe de disponibilité donné, vérifiez qu'un basculement de l'instance de cluster de basculement ne peut pas provoquer de tentative d'hébergement, par un seul nœud WSFC, de deux réplicas de disponibilité pour le même groupe de disponibilité.

L'exemple de scénario suivant montre en quoi cette configuration risque de provoquer des problèmes :

Marcel configure deux clusters WSFC avec deux nœuds, NODE01 et NODE02. Il installe une instance de cluster de basculement SQL Server , fciInstance1, sur NODE01 et NODE02 , où NODE01 est le propriétaire actuel de fciInstance1.
Sur NODE02, Marcel installe une autre instance de SQL Server, Instance3, qui est une instance autonome.
On NODE01, Marcel active fciInstance1 pour les groupes de disponibilité Always On. Sur NODE02, il active les groupes de disponibilité Always On pour Instance3. Il configure ensuite un groupe de disponibilité pour lequel fciInstance1 héberge le réplica principal et Instance3 héberge le réplica secondaire.
À un moment donné, fciInstance1 devient indisponible sur NODE01, et le cluster WSFC provoque un basculement de fciInstance1 vers NODE02. Une fois le basculement effectué, l'instance fciInstance1 est compatible avec les groupes de disponibilité Always On et fonctionne sous le rôle principal sur NODE02. Toutefois, Instance3 réside maintenant sur le même nœud WSFC que fciInstance1. Cela enfreint la contrainte des Groupes de Disponibilité Always On.
Pour corriger le problème que ce scénario présente, l’instance autonome, Instance3doit résider sur un autre nœud du même cluster WSFC que NODE01 et NODE02.

Pour plus d'informations sur le clustering de basculement de SQL Server, consultez AlwaysOn Failover Cluster Instances (SQL Server).

Restrictions d'utilisation du Gestionnaire du cluster de basculement WSFC avec des groupes de disponibilité

N'utilisez pas le Gestionnaire du cluster de basculement pour manipuler des groupes de disponibilité, par exemple :

• N'ajoutez pas ou ne supprimez pas de ressources dans le service cluster (groupe de ressources) du groupe de disponibilité.

• Ne modifiez pas les propriétés du groupe de disponibilité, telles que les propriétaires possibles et par défaut. Ces propriétés sont définies automatiquement par le groupe de disponibilité.

• N'utilisez pas le Gestionnaire du cluster de basculement pour déplacer des groupes de disponibilité vers différents nœuds ou faire basculer des groupes de disponibilité. Le Gestionnaire du cluster de basculement n'a pas connaissance de l'état de synchronisation des réplicas de disponibilité, et cela peut provoquer temps morts étendus. Vous devez utiliser Transact-SQL ou SQL Server Management Studio.

Contenu associé

• Blogs :

  Configurer le clustering de basculement Windows pour SQL Server (groupe de disponibilité ou instance de cluster de basculement) avec une sécurité limitée

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

  Blogs des ingénieurs du Service clientèle et du Support technique de SQL Server

• Livres blancs :

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

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

  Livres blancs de Microsoft pour SQL Server 2012

  Livres blancs de l'équipe de consultants clients de SQL Server

Voir aussi

Vue d’ensemble des groupes de disponibilité AlwaysOn (SQL Server)Activer et désactiver des groupes de disponibilité AlwaysOn (SQL Server)Surveiller les groupes de disponibilité (Transact-SQL)
Instances de cluster de basculement AlwaysOn (SQL Server)