Ce billet présente rapidement une des solutions de haute-disponibilité de SQL Server : le failover clustering (cluster à basculement).    

Qu’est-ce que le failover clustering ?

Un failover cluster est une solution de haute-disponibilité Windows faisant travailler un groupe d’ordinateurs (ou nœuds) indépendants ensemble de façon à pouvoir assurer la disponibilité permanente des applications et services.

Prenons l’exemple d’un cluster à 2 nœuds, il y a donc 2 machines qui peuvent exécuter une instance SQL Server. Seul un nœud à la fois peut exécuter cette instance, et en cas de défaillance de cette machine ou de l’instance, un autre nœud va reprendre l’instance qui s’est arrêtée et cela de manière automatique (on parle d’automatic failover).

Les ressources d’un cluster sont gérées par ce qu’on appelle un quorum qui est une sorte d’arbitre. Il s’agit en fait d’un fichier qui stocke, met à jour et publie des informations sur le cluster à l’ensemble des nœuds. Son rôle est de permettre :

  • L’authentification et l’intégration d’un nœud au sein du cluster.
  • D’éviter la division du cluster en sous-clusters en cas de problèmes de communication grâce à un système de vote.
  • De stocker les informations de configuration du cluster.

Il existe 4 types de quorum :

  • No Majority : stockage du quorum sur un disque appelé Witness Disk. Type de quorum a éviter car n’empêche pas le single point of failure (SPOF).
  • Node Majority : idéal lorsque le cluster est constitué d’au moins 3 nœuds et n’utilise pas le stockage partagé. Le fonctionnement du cluster dépendra du fonctionnement de la majorité des votants fonctionnent.
  • Node and Majority Disk (mode par défaut, et recommandé, dans la majorité des scénarii d’utilisation, par Microsoft) : c’est la combinaison entre le No Majority mode et le Node Majority. Il est fonctionnel à partir de 2 nœuds. En plus des nœuds le quorum sera également dans la liste des votants.
  • Node and File Share Majority : ce type de fonctionnement du quorum suit le même principe que le Node and Majority Disk, à la différence qu’il remplace le Witness disk au lieu d’avoir un partage sur le réseau. Solution plus envisageable dans le cas du géoclustering.

Une instance de failover cluster contient :

  • Un ensemble composé d’un ou de plusieurs disques dans un groupe de clusters Microsoft Cluster Server (MSCS), également appelé groupe de ressources où chaque groupe de ressources peut contenir au plus une instance de SQL Server ;
  • un nom réseau.
  • une ou plusieurs adresses IP.
  • Un moteur OLTP ou OLAP… Et ses outils (réplication, FTS,…).

A quelle occasion doit-on (peut-on) utiliser SQL Server en mode failover cluster ? Généralement, tout dépend de la spécification des besoins, mais surtout du niveau de tolérance à la perte de données. Ainsi, si aucune perte de donnée n’est acceptée, le failover cluster intervient comme étant la meilleure solution à adopter.

Prérequis généraux

Pour l’installation en failover clustering voici les informations essentielles à retenir:

  • SQL Server 2008 (R2) Enterprise (16 nœuds maximum) ou Standard Edition (2 nœuds maximum). L’édition Developer (16 nœuds maximum) supporte également le failover clustering.
  • 2 serveurs (nœuds) Enterprise (16 nœuds maximum)
    ou Itanium (8 nœuds maximum) ou Datacenter (16 nœuds maximum, et à partir de Windows Server 2008) sont à installer.
  • 2 cartes réseaux : une carte publique (avec IP classique) pour raccorder chaque nœud du cluster et une carte privée (ou HA) qui raccorde chaque nœud entre eux via un (V)LAN dédié et un mode d’adressage privé et distinct (et sans configuration du gateway et du DNS).
  • Prévoir également une adresse IP pour MSDTC.
  • Idéalement disposer d’au moins 5 (LUNs) partitions (bases systèmes, données, logs, sauvegardes et tempDB) + 2 (quorum, MSDTC) sur un SAN.
  • Les disques doivent être de type basique et non dynamiques (ces derniers n’étant pas supportés).
  • Pour chaque nœud (2), deux comptes de service de type domain account doivent être préalablement créés sous Active Directory
  • Des comptes de service AD sont également à prévoir : un pour le moteur SQL et, si possible (sinon affecter celui du moteur), un autre pour le SQL Agent.
Notons qu’à partir de Windows Server 2008, contrairement à Windows Server 2003, la mise-en-place d’un cluster Windows avec des disques en SCSI-2 n’est plus possible. Il faut donc que le SAN présente des LUNs en réservation SCSI-3.
Vous pouvez d’ailleurs jeter un coup d’œil à la checklist des éléments à respecter avant toute installation de SQL Server 2008 (R2) en failover cluster : http://msdn.microsoft.com/en-us/library/ms189910(v=sql.100).aspx.

Pour aller plus loin…

Pour la mise-en-place d’un failover cluster, vous pouvez, par exemple, jeter un coup d’œil ici.

Share This