Partager via

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

S’applique à :SQL Server sur Windows

Groupes de disponibilité Always On, la solution haute disponibilité et de récupération d'urgence introduite dans SQL Server 2012 (11.x), requiert le Clustering de basculement Windows Server (WSFC). En outre, bien que les groupes de disponibilité Always On ne dépendent pas du clustering de basculement SQL Server, vous pouvez utiliser une instance de clustering de basculement (FCI) pour héberger une réplique de disponibilité dans 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.

Notes

Pour plus d’informations sur les concepts des groupes de disponibilité Always On, consultez Qu’est-ce qu’un groupe de disponibilité Always On ?

Clustering de basculement Windows Server et groupes de disponibilité

Le déploiement de Groupes de disponibilité Always On exige un cluster de basculement Windows Server (cluster WSFC). Pour que Groupes de disponibilité Always On soit activé, 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. De plus, 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.

Groupes de disponibilité Always On s’appuie sur le cluster WSFC pour superviser et gérer les rôles actuels des réplicas de disponibilité qui appartiennent à un groupe de disponibilité donné et pour déterminer de quelle manière 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 supervise ce groupe de ressources pour évaluer l’intégrité du réplica principal.

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

L’intégrité globale d’un cluster WSFC est déterminée par les votes d’un quorum de nœuds du cluster. Si le cluster WSFC est mis hors connexion en raison d’un problème grave non planifié, ou en raison d’un problème de matériel ou de communication persistant, une intervention administrative manuelle est nécessaire. Un administrateur Windows Server ou de cluster WSFC doit forcer un quorum et remettre les nœuds de cluster survivants en ligne dans une configuration sans tolérance de panne.

Important

Les clés de Registre Groupes de disponibilité Always On sont des sous-clés du cluster WSFC. 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 SQL Server qui hébergeait un réplica de disponibilité sur le cluster WSFC d’origine.

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

Instances de cluster de basculement SQL Server (FCIs) et groupes de disponibilité

Vous pouvez configurer une deuxième couche de basculement au niveau de l’instance serveur en implémentant SQL Server et FCI avec le WSFC. Une instance autonome de SQL Server ou une instance FCI peut héberger un réplica de disponibilité. 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 Conditions préalables, restrictions et recommandations pour les groupes de disponibilité Always On (SQL Server).

Comparaison des instances de basculement en cluster 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é.

Nœuds dans une instance de cluster de basculement Réplicas dans un groupe de disponibilité
Utilise WSFC Oui Oui
Niveau de protection Instance Base de données
Type de stockage Partagé Non partagé

Bien que les réplicas d’un groupe de disponibilité ne partagent pas de stockage, un réplica hébergé par une instance de cluster de basculement utilise une solution de stockage partagé, comme l'exige cette instance de cluster de basculement. La solution de stockage est partagée uniquement par les nœuds de l'instance de cluster de basculement et pas entre les réplicas du groupe de disponibilité.
Solutions de stockage attachement direct, SAN, points de montage, SMB Dépend du type de nœud
Bases de données secondaires accessibles en lecture Non* Oui
Paramètres de stratégie de basculement applicables Quorum WSFC

Spécifique à l'instance de cluster de basculement

Paramètres du groupe de disponibilité**		 Quorum WSFC

Paramètres de groupe de disponibilité
Ressources basculées Serveur, instance et base de données Base de données uniquement

*Alors que les réplicas secondaires synchrones d’un groupe de disponibilité sont toujours en cours d’exécution sur leurs instances SQL Server respectives, les nœuds secondaires d’une instance FCI n’ont pas démarré leurs instances SQL Server respectives et ne sont donc pas lisibles. 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 FCI actif, quand une base de données hébergée par FCI fait partie d'un groupe de disponibilité, la base de données est lisible si le réplique de disponibilité locale fonctionne en tant que réplique secondaire lisible.

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

Considérations relatives à l’hébergement d’une réplique de disponibilité sur une instance de cluster de basculement

Important

Si vous envisagez d’héberger une réplique de disponibilité sur une instance de cluster de basculement SQL Server (FCI), assurez-vous que les nœuds hôtes Windows Server 2008 répondent aux conditions préalables et restrictions Always On applicables aux instances de cluster de basculement (FCI). Pour plus d’informations, consultez Prérequis, restrictions et suggestions pour les groupes de disponibilité Always On (SQL Server).

Les instances de cluster de basculement SQL Server (FCI) ne prennent pas en charge le basculement automatique par les groupes de disponibilité ; par conséquent, tout réplica de disponibilité qu’héberge un FCI ne peut être configuré que pour un basculement manuel.

Vous devrez peut-être configurer un cluster WSFC pour inclure des disques partagés qui ne sont pas disponibles sur tous les nœuds. Prenons par exemple un cluster WSFC réparti entre deux centres de données comportant trois nœuds. Deux des nœuds hébergent une instance de cluster de basculement SQL Server (FCI) dans le centre de données principal et ont accès aux mêmes disques de stockage partagés. Le troisième nœud héberge une instance autonome de SQL Server dans un autre centre de données et n’a pas accès aux disques partagés à partir du centre de données principal. Cette configuration WSFC prend en charge le déploiement d’un groupe de disponibilité si l’instance FCI héberge le réplica principal et l’instance autonome héberge le réplica secondaire.

Lorsque vous choisissez une instance FCI pour héberger un réplica de disponibilité pour un groupe de disponibilité donné, assurez-vous qu’un basculement FCI ne puisse potentiellement entraîner un seul nœud WSFC à tenter d’héberger 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 :

  • Vous configurez un cluster WSFC avec deux nœuds, NODE01 et NODE02.
  • Vous installez une instance de cluster de basculement SQL Server, fciInstance1, sur NODE01 et NODE02 où NODE01 est le propriétaire actuel de fciInstance1.
  • Sur NODE02, vous installez une autre instance de SQL Server, Instance3qui est une instance autonome.
  • Sur NODE01, vous activez fciInstance1 pour les groupes de disponibilité Always On. Sur NODE02, vous activez Instance3 pour les groupes de disponibilité Always On. Ensuite, vous configurez 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 WSFC provoque un basculement de fciInstance1 vers NODE02. Après le basculement, fciInstance1 est une instance activée pour Groupes de disponibilité Always Onqui s'exécute sous le rôle principal sur NODE02. Toutefois, Instance3 réside maintenant sur le même nœud WSFC que fciInstance1. Cela viole la contrainte 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 dans le même cluster WSFC que NODE01 et NODE02.

Pour plus d’informations sur les instances de cluster de basculement Always On SQL Server, consultez Instances de Cluster de Basculement Always On (SQL Server).

Restrictions sur l’utilisation du Gestionnaire WSFC avec des groupes de disponibilité

N’utilisez pas le Failover Cluster Manager (Gestionnaire du cluster de basculement) pour gérer des groupes de disponibilité. Par exemple:

  • N’ajoutez pas ou supprimez des ressources dans le service cluster (groupe de ressources) pour le groupe de disponibilité.

  • Ne modifiez pas les propriétés du groupe de disponibilité, telles que les propriétaires possibles et les propriétaires préférés. 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 les groupes de disponibilité vers différents nœuds ou pour procéder à un basculement de ces groupes. Le Gestionnaire du cluster de basculement n'a pas connaissance de l'état de synchronisation des réplicas de disponibilité, ce qui peut entraîner un temps d'arrêt prolongé. Vous devez utiliser Transact-SQL ou SQL Server Management Studio.

Avertissement

L’utilisation du Gestionnaire du cluster de basculement pour déplacer une instance de cluster de basculement hébergeant un groupe de disponibilité vers un nœud qui héberge déjà un réplica du même groupe de disponibilité peut entraîner la perte du réplica du groupe de disponibilité, ce qui l’empêche d’être mis en ligne sur le nœud cible. Un seul nœud d’un cluster de basculement ne peut pas héberger plus d'une réplique pour le même groupe de disponibilité. Pour plus d’informations sur la façon dont cela se produit et comment récupérer, consultez le blog Réplique supprimée de manière inattendue dans le groupe de disponibilité.

Contenu connexe

  • Last updated on