Instances de cluster de basculement Always On (SQL Server)

S'applique à :SQL Server

Les instances de cluster de basculement automatique Always On de SQL Server utilisent le clustering de basculement de Windows Server (WSFC) pour assurer une haute disponibilité locale. Une instance de cluster de basculement (instance FCI) est redondante au niveau de l’instance de serveur. Une instance FCI est une instance unique de SQL Server installée sur des nœuds de cluster Windows Server et, éventuellement, sur plusieurs sous-réseaux. Sur le réseau, une instance de cluster de basculement (FCI) apparaît comme une instance de SQL Server s'exécutant sur un seul ordinateur, mais elle assure le basculement d'un nœud WSFC vers un autre si le nœud actif devient indisponible.

Une instance FCI peut tirer parti des groupes de disponibilité Always On pour fournir la récupération d’urgence à distance au niveau de la base de données. Pour plus d’informations, consultez le clustering de basculement et les groupes de disponibilité Always On (SQL Server).

Les instances de cluster de basculement SQL Server prennent en charge les Espaces de stockage direct pour les ressources de stockage du cluster, introduits dans l’édition Datacenter de Windows Server 2016. Pour plus d’informations, consultez Espaces de stockage direct dans Windows Server.

Les instances de cluster de basculement prennent également en charge les volumes partagés de cluster (CSV). Pour plus d’informations, consultez Présentation des volumes partagés de cluster dans un cluster de basculement.

Remarque

SQL Server 2025 (17.x) introduit la prise en charge de l’application de connexions strictes à votre instance de cluster de basculement.

Avantages des instances de cluster de basculement automatique

En cas de défaillance matérielle ou logicielle du serveur, les applications ou les clients qui se connectent au serveur subissent un temps d’arrêt. Les nœuds redondants protègent la disponibilité de l’instance SQL Server lorsqu’il s’agit d’une instance FCI au lieu d’une instance autonome. Un seul des nœuds du FCI détient le groupe de ressources WSFC à un moment donné. Si une défaillance se produit (par exemple, défaillance matérielle, défaillance du système d’exploitation, échec d’application ou de service) ou pendant une mise à niveau planifiée, le cluster déplace la propriété du groupe de ressources vers un autre nœud WSFC. Ce processus est transparent pour le client ou l’application se connectant à SQL Server. Le processus réduit le temps d’arrêt rencontré par l’application ou les clients lors d’une défaillance. Voici quelques principaux avantages qu’offrent les instances de cluster de basculement de SQL Server :

  • Protection au niveau de l'instance par redondance.

  • Basculement automatique en cas de défaillance (défaillances matérielles, défaillances du système d’exploitation ou défaillances d’application et de service).

    Important

    Dans un groupe de disponibilité, le basculement automatique d’une instance de cluster de basculement vers d’autres nœuds au sein du groupe de disponibilité n’est pas pris en charge. Par conséquent, les FCI et les nœuds autonomes ne doivent pas être couplés au sein d’un groupe de disponibilité si le basculement automatique est un composant important de votre solution de haute disponibilité. Toutefois, ce couplage peut être réalisé pour votre solution de reprise après sinistre.

  • Prise en charge d’un large éventail de solutions de stockage, notamment les disques de cluster WSFC (iSCSI, Fibre Channel, et ainsi de suite) et les partages de fichiers SMB (Server Message Block).

  • Récupération d’urgence via une instance FCI multi-sous-réseau ou exécution d’une base de données hébergée par FCI à l’intérieur d’un groupe de disponibilité. Avec la prise en charge de plusieurs sous-réseaux dans SQL Server 2012 (11.x), une instance FCI multi-sous-réseau ne nécessite pas de réseau local virtuel. Cette prise en charge augmente la facilité de gestion et la sécurité d’une instance FCI multi-sous-réseau.

  • Absence de reconfiguration des applications et des clients pendant les basculements.

  • Stratégie flexible de basculement pour des événements de déclenchement précis lors des basculements automatiques.

  • Basculements fiables grâce à une détection périodique et détaillée de l’état de santé au moyen de connexions dédiées et persistantes.

  • Configurabilité et prévisibilité du temps de basculement grâce à des points de contrôle indirects en arrière-plan.

  • Utilisation des ressources limitée au cours des basculements.

Recommandations

Dans un environnement de production, utilisez des adresses IP statiques conjointement avec l’adresse IP virtuelle d’une instance de cluster de basculement.

N’utilisez pas DHCP dans un environnement de production. En cas de temps d’arrêt, si le bail IP DHCP expire, un délai supplémentaire est nécessaire pour réinscrire la nouvelle adresse IP DHCP associée au nom DNS.

Vue d’ensemble de l’instance de cluster de basculement

Une instance FCI s'exécute dans un groupe de ressources WSFC avec un ou plusieurs nœuds WSFC. Au démarrage de l’instance FCI, l’un des nœuds suppose la propriété du groupe de ressources et met son instance SQL Server en ligne. Les ressources détenues par ce nœud sont les suivantes :

  • Nom du réseau
  • Adresse IP
  • Disques partagés
  • service du moteur de base de données SQL Server
  • SQL Server Service Agent
  • Le service SQL Server Analysis Services, s’il est installé
  • Une ressource de partage de fichiers, si la fonctionnalité FILESTREAM est installée

À un moment donné, seul le propriétaire du groupe de ressources (et aucun autre nœud de l'instance FCI) exécute ses services SQL Server respectifs dans le groupe de ressources. Lorsqu’un basculement se produit, qu’il s’agisse d’un basculement automatique ou d’un basculement planifié, la séquence d’événements suivante se produit :

  1. Sauf en cas de défaillance du système ou du matériel, toutes les pages de modifications dans le cache de tampons sont écrites sur le disque.

  2. Tous les services SQL Server respectifs du groupe de ressources sont arrêtés sur le nœud actif.

  3. La propriété du groupe de ressources est transférée à un autre nœud dans le FCI.

  4. Le nouveau propriétaire du groupe de ressources démarre ses services SQL Server .

  5. Les demandes de connexion d’application cliente sont automatiquement dirigées vers le nouveau nœud actif à l’aide du même nom de réseau virtuel.

Le FCI est en ligne tant que son cluster WSFC sous-jacent est dans un bon état de quorum. (La majorité des nœuds du WSFC constituant le quorum sont disponibles comme cibles de basculement automatique.) Lorsque le cluster WSFC perd son quorum, que ce soit en raison d’une défaillance matérielle, logicielle ou réseau, ou d’une configuration incorrecte du quorum, l’ensemble du cluster WSFC, ainsi que la FCI, est mis hors ligne. Une intervention manuelle est alors requise dans ce scénario de basculement non planifié afin de rétablir le quorum dans les nœuds disponibles restants et de remettre le cluster WSFC et l'instance FCI en ligne. Pour plus d’informations, consultez les modes de quorum WSFC et la configuration de vote (SQL Server).

Durée de basculement prévisible

Selon le moment où votre instance SQL Server a effectué pour la dernière fois une opération de checkpoint, le cache de mémoire tampon peut contenir un nombre important de pages modifiées. Par conséquent, les basculements durent aussi longtemps que nécessaire pour écrire les pages de modifications restantes sur le disque, opération qui peut provoquer une durée de basculement longue et imprévisible. À compter de SQL Server 2012 (11.x), l’instance de cluster de basculement peut utiliser des points de contrôle indirects pour limiter le nombre de pages sales conservées dans le cache de mémoire tampon. Bien que cela consomme davantage de ressources sous des charges de travail régulières, cela rend le temps de basculement plus prévisible et plus configurable. Cela est utile lorsque le contrat de niveau de service de votre organisation spécifie l’objectif de délai de récupération (RTO) pour votre solution de haute disponibilité. Pour plus d’informations, consultez points de contrôle indirects.

Surveillance fiable de l’état et politique de basculement flexible

Une fois l’instance FCI démarrée, le service WSFC surveille à la fois l’intégrité du cluster WSFC sous-jacent et l’intégrité de l’instance SQL Server. À compter de SQL Server 2012 (11.x), le service WSFC utilise une connexion dédiée pour interroger l’instance SQL Server active pour obtenir des diagnostics de composants détaillés via une procédure stockée système. Il existe trois implications résultantes :

  • La connexion dédiée à l'instance SQL Server permet d'interroger de manière fiable le diagnostic de composant à tout moment, même lorsque l'instance FCI est soumise à une charge importante. Cette fonctionnalité permet de faire la distinction entre un système qui est en charge importante et un système qui a des conditions d’échec, empêchant ainsi les problèmes tels que les faux basculements.

  • Les diagnostics détaillés des composants permettent de configurer une stratégie de basculement plus flexible, où vous pouvez choisir les conditions de défaillance qui déclenchent le basculement.

  • Les diagnostics détaillés des composants facilitent également un meilleur dépannage a posteriori des basculements automatiques. Les informations de diagnostic sont stockées dans des fichiers journaux situés au même emplacement que les journaux d’erreurs de SQL Server. Vous pouvez les charger dans la Visionneuse de fichiers journaux pour examiner les états des composants ayant précédé le basculement afin de déterminer ce qui l’a provoqué.

Pour plus d’informations, consultez la stratégie de basculement pour les instances de cluster avec basculement.

Configurer le chiffrement TLS 1.3

SQL Server 2025 (17.x) introduit la prise en charge de TDS 8.0 , qui permet d’appliquer le chiffrement TLS 1.3 pour la communication entre le cluster de basculement Windows Server et vos instances de cluster de basculement.

Pour commencer, consultez Connexion avec un chiffrement strict.

Remarque

L’installation de l’instance de cluster de basculement SQL Server 2025 (17.x) échoue si TLS 1.2 est désactivé sur l’ordinateur.

Éléments d'une instance de cluster de basculement

Une instance FCI se compose d’un ensemble de serveurs physiques (nœuds) qui contiennent une configuration matérielle similaire et également une configuration logicielle identique qui inclut la version du système d’exploitation et le niveau de correctif, ainsi que la version de SQL Server, le niveau de correctif, les composants et le nom de l’instance. Une configuration logicielle identique est nécessaire afin de garantir que la FCI soit pleinement opérationnelle lors du basculement entre les nœuds.

Groupe de ressources WSFC

Une instance SQL Server FCI s'exécute dans un groupe de ressources WSFC. Chaque nœud du groupe de ressources conserve une copie synchronisée des paramètres de configuration et des clés de Registre mises en point de contrôle afin de garantir le fonctionnement complet de l’instance de cluster de basculement après un basculement. Un seul des nœuds du cluster possède le groupe de ressources à la fois (le nœud actif). Le service WSFC gère le cluster de serveurs, la configuration du quorum, la stratégie de basculement et les opérations de basculement, ainsi que le nom réseau virtuel et les adresses IP virtuelles de l’instance de cluster de basculement (FCI). En cas de défaillance (défaillances matérielles, défaillances du système d’exploitation ou défaillances d’application et de service) ou d’une mise à niveau planifiée, la propriété du groupe de ressources est déplacée vers un autre nœud de l’instance de cluster de basculement. Le nombre de nœuds pris en charge dans un groupe de ressources WSFC dépend de votre édition SQL Server. De plus, le même cluster WSFC peut exécuter plusieurs instances FCI (plusieurs groupes de ressources), selon la capacité du matériel, notamment le processeur, la mémoire et le nombre de disques.

Fichiers binaires SQL Server

Les fichiers binaires du produit sont installés localement sur chaque nœud de l’instance de cluster de basculement (FCI), selon un processus similaire à celui des installations autonomes de SQL Server. Toutefois, au démarrage, les services ne sont pas démarrés automatiquement, mais gérés par WSFC.

Stockage

Contrairement à un groupe de disponibilité, une instance de cluster de disponibilité doit utiliser un stockage partagé entre tous les nœuds de l’instance de cluster de disponibilité pour le stockage de base de données et de journal. Le stockage partagé peut être sous la forme de disques de cluster WSFC, de disques sur un san, des espaces de stockage direct ou des partages de fichiers sur un SMB. Par conséquent, tous les nœuds du FCI ont la même visibilité sur les données de l’instance chaque fois qu’un basculement se produit. Cela signifie toutefois que le stockage partagé peut constituer un point de défaillance unique et que l’instance de cluster de basculement (FCI) dépend de la solution de stockage sous-jacente pour garantir la protection des données.

Nom du réseau

Le nom du réseau virtuel de la FCI offre un point de connexion unifié pour la FCI. Ce point de connexion unifié permet aux applications de se connecter au nom du réseau virtuel sans avoir à connaître le nœud actif. Lorsqu’un basculement se produit, le nom du réseau virtuel est enregistré sur le nouveau nœud actif après son démarrage. Ce processus est transparent pour le client ou l’application qui se connecte à SQL Server et réduit le temps d’arrêt de l’application ou des clients lors d’un échec.

La capture d’écran suivante montre le nom réseau de l’instance de cluster de basculement dans le Gestionnaire du cluster de basculement :

Capture d’écran du nom du réseau FCI dans le Gestionnaire du cluster de basculement.

Adresses IP virtuelles

Dans le cas d'une instance FCI à plusieurs sous-réseaux, une adresse IP virtuelle est affectée à chaque sous-réseau au sein de l'instance FCI. Pendant un basculement, le nom du réseau virtuel sur le serveur DNS est mis à jour pour pointer vers l’adresse IP virtuelle du sous-réseau respectif. Les applications et les clients peuvent ensuite se connecter au FCI en utilisant le même nom de réseau virtuel après un basculement entre plusieurs sous-réseaux.

Concepts et tâches de basculement de SQL Server

Concepts et tâches Article
Décrit le mécanisme de détection de pannes et la stratégie flexible de basculement. Stratégie de basculement pour les instances de cluster de basculement
Décrit les concepts relatifs à l’administration et à la maintenance de FCI. Administration et maintenance de l’instance de cluster de basculement
Décrit la configuration et les concepts de plusieurs sous-réseaux. Clustering multi-sous-réseau SQL Server

Configuration de l’instance de cluster de basculement SQL Server prise en charge sur WSFC

Les instances de cluster de basculement SQL Server basées sur un WSFC sont prises en charge dans les produits suivants :

  • Windows Server 2012
  • Windows Server 2012 R2
  • Éditions Standard et Datacenter de Windows Server 2016
  • Éditions Standard et Datacenter de Windows Server 2019
  • Éditions Standard et Datacenter de Windows Server 2022

Windows Server fournit deux types de services de clustering :

Seules les solutions de cluster de serveur peuvent être utilisées avec SQL Server pour la haute disponibilité si un nœud est perdu ou si un problème existe avec une instance de SQL Server. L’équilibrage de charge réseau peut être utilisé dans certains cas avec des installations SQL Server en lecture seule.

Chaque instance de cluster de basculement SQL Server nécessite les éléments suivants :

  • Groupe de clusters dédié qui a des lettres de lecteur de disque attribuées de manière unique.
  • Au moins une adresse IP unique.
  • Noms d’instance et de serveur virtuel uniques au sein du domaine.

Prise en charge des solutions de clusterisation non-Microsoft

SQL Server est développé et testé avec le clustering de serveurs Microsoft. Si vous utilisez un produit de clustering non-Microsoft, votre contact de support principal pour les problèmes d’installation, de performances ou de comportement de cluster doit être le fournisseur de solutions. Microsoft fournit une prise en charge commercialement raisonnable des installations de cluster non-Microsoft, similaire à la prise en charge des déploiements SQL Server autonomes.

Nombre de nœuds pris en charge

Pour plus d’informations sur le nombre maximal de nœuds pris en charge pour les instances de cluster de basculement Always On, consultez :

Système d’exploitation pris en charge

Pour plus d’informations sur les systèmes d’exploitation pris en charge pour le clustering de basculement de SQL Server, consultez Vérifiez votre système d’exploitation avant d’installer le clustering de basculement.

Lecteurs montés

L’utilisation de lecteurs montés n’est pas prise en charge sur les clusters qui incluent une installation de SQL Server. Pour plus d’informations, consultez la prise en charge de SQL Server pour les volumes montés.

Volumes partagés de cluster (CSV)

SQL Server 2012 (11.x) et les versions antérieures ne prennent pas en charge l’utilisation de CSV pour SQL Server dans un cluster de basculement.

Pour plus d’informations sur l’utilisation de CSV avec SQL Server 2014 (12.x) ou des versions ultérieures, consultez les ressources suivantes :

Restrictions relatives au contrôleur de domaine

Les instances de cluster de basculement SQL Server ne sont pas prises en charge sur des nœuds d’une instance de cluster de basculement configurés en tant que contrôleurs de domaine.

Considérations relatives à la migration de domaine

SQL Server 2005 (9.x) et versions ultérieures ne peuvent pas être migrés vers un nouveau domaine. Vous devez désinstaller et réinstaller les composants du cluster de basculement. Pour plus d’informations, consultez Déplacer un cluster Windows Server d’un domaine vers un autre.

Avant de désinstaller SQL Server, vous devez effectuer les étapes suivantes :

  • Définissez SQL Server pour utiliser la sécurité en mode mixte ou ajoutez de nouveaux comptes de domaine aux connexions SQL Server.

  • Renommez le DATA dossier qui contient des bases de données système afin qu’il puisse être échangé après la nouvelle installation pour réduire les temps d’arrêt.

  • Ne supprimez pas les fichiers de support SQL Server, SQL Server Native Client, Integration Services ou les composants de station de travail, sauf si vous régénérez l’intégralité du nœud.

Avertissement

Si des erreurs se produisent pendant le processus de désinstallation, vous devrez peut-être régénérer le nœud pour réinstaller SQL Server.