Exporter (0) Imprimer
Développer tout
Cet article a fait l'objet d'une traduction manuelle. Déplacez votre pointeur sur les phrases de l'article pour voir la version originale de ce texte. Informations supplémentaires.
Traduction
Source

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

État de la rubrique : certaines informations de cette rubrique constituent une documentation préliminaire et peuvent faire l'objet de modifications dans les versions à venir. Ces informations préliminaires décrivent les nouvelles fonctionnalités ou les modifications apportées à des fonctionnalités existantes de Microsoft SQL Server 2014.

Groupes de disponibilité AlwaysOn, la solution haute disponibilité et de récupération d'urgence introduite dans SQL Server 2014, requiert le Clustering de basculement Windows Server (WSFC). En outre, bien que Groupes de disponibilité AlwaysOn ne dépende pas du Clustering de basculement SQL Server, vous pouvez utiliser une instance de clustering de basculement 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, ainsi que les observations nécessaires lorsque vous concevez votre environnement Groupes de disponibilité AlwaysOn.

Remarque Remarque

Pour plus d'informations sur les concepts Groupes de disponibilité AlwaysOn, consultez Vue d'ensemble des groupes de disponibilité AlwaysOn (SQL Server).

Dans cette rubrique :

Le déploiement de Groupes de disponibilité AlwaysOn requiert un cluster WSFC (clustering de basculement Windows Server). Pour que Groupes de disponibilité AlwaysOn soit activén 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é AlwaysOn s'appuie sur le cluster WSFC (clustering de basculement Windows Server) pour surveiller 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 surveille ce groupe de ressources pour évaluer l'intégrité du réplica principal.

Le quorum pour Groupes de disponibilité AlwaysOn 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é AlwaysOn.

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 Important

Les clés de Registre Groupes de disponibilité AlwaysOn 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é AlwaysOn 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 de clustering de basculement Windows Server (WSFC) et sur le quorum WSFC, consultez Clustering de basculement Windows Server (WSFC) avec SQL Server.

Icône de flèche utilisée avec le lien Retour en haut [Haut de la page]

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

Depuis SQL Server 2012 SP1, Groupes de disponibilité AlwaysOn prend en charge la migration entre clusters de groupes de disponibilité pour les déploiements dans un nouveau cluster de clustering de basculement Windows Server (WSFC). 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 mort minimal. Le processus de migration entre clusters permet de conserver les contrats de niveau de service (SLA) lors de la mise à niveau vers un cluster Windows Server 2012. SQL Server 2012 SP1 (ou une 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 du cluster WSFC de destination.

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

Vous pouvez configurer une deuxième couche de basculement au niveau de l'instance 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.

Groupes de disponibilité AlwaysOn ne dépend 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 la configuration supplémentaire requise, consultez la section « 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é » de Conditions préalables requises, 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é.

Nœuds dans une instance de cluster de basculement

Réplicas dans un groupe de disponibilité

Utilise le cluster WSFC

Oui

Oui

Niveau de protection

Instance

Base de données

Type de stockage

Partagés

Non partagé1

Solutions de stockage

attachement direct, SAN, points de montage, SMB

Dépend du type de nœud

Secondaires accessibles en lecture

Non2

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

  • Quorum WSFC

  • Paramètres du groupe de disponibilité

Ressources basculées

Serveur, instance et base de données

Base de données uniquement

1 Même si les réplicas dans un groupe de disponibilité ne partagent pas le stockage, un réplica hébergé par une instance de cluster de basculement utilise une solution de stockage partagé conforme aux exigences de 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é.

2 Alors que les réplicas secondaires synchrones dans un groupe de disponibilité s'exécutent toujours sur leurs instances respectives de SQL Server, les nœuds secondaires dans une instance de cluster de basculement n'ont pas démarré leurs instances respectives de SQL Server et sont par conséquent 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.

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

Remarque Remarque

Pour plus d'informations sur le nombre de nœuds dans le clustering de basculement et les groupes de disponibilité AlwaysOn dans les différentes éditions de SQL Server, consultez Fonctionnalités prises en charge par les éditions de SQL Server 2012 (http://go.microsoft.com/fwlink/?linkid=232473).

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

Important Important

Si vous envisagez d'héberger un réplica de disponibilité sur une instance de cluster de basculement SQL Server, assurez-vous que les nœuds hôtes Windows Server 2008 respectent les conditions préalables requises et les restrictions AlwaysOn applicables aux instances de cluster de basculement. Pour plus d'informations, consultez Conditions préalables requises, restrictions et recommandations pour les groupes de disponibilité AlwaysOn (SQL Server).

SQL ServerLes instances de cluster de basculement (FCI) 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) de manière à inclure les 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 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 de cluster de basculement héberge le réplica principal et 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 un cluster 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.
Sur NODE01, Marcel active fciInstance1 pour Groupes de disponibilité AlwaysOn. Sur NODE02, il active Instance3 pour Groupes de disponibilité AlwaysOn. 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 certain stade, fciInstance1 devient indisponible sur NODE01, et le cluster WSFC provoque un basculement de fciInstance1 vers NODE02. Après le basculement, fciInstance1 est une instance activée pour Groupes de disponibilité AlwaysOn qui 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é AlwaysOn.

Pour résoudre le problème présenté par ce scénario, l'instance autonome, Instance3, doit résider sur un autre nœud dans le même cluster WSFC que NODE01 et NODE02.

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

Icône de flèche utilisée avec le lien Retour en haut [Haut de la page]

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.

Icône de flèche utilisée avec le lien Retour en haut [Haut]

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.

Ajouts de la communauté

AJOUTER
Afficher:
© 2014 Microsoft