[SQL Server] Présentation rapide du failover clustering

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.

Publicités

19 commentaires sur “[SQL Server] Présentation rapide du failover clustering

  1. Thomas dit :

    Bonjour M. Cherif,
    Je voudrais savoir quelle taille optimale je peux choisir pour chacune de mes 7 partitions à utiliser dans la configuration du cluster; sachant que ma base de production fait 2Go (du moins le fichier mdf); le journal, je le vide la nuit après avoir effectué une sauvegarde.

    • Bonsoir Thomas,

      Tout dépend de la volumétrie attendue à court, moyen et long-terme (oui, il s’agit avant tout d’une question de prévoyance). Sans parler de tes valeurs d’incrément, de la rétention de tes backups (BAK comme TRN), etc…

      En supposant que ta base applicative de 2 Go soit la seule à traiter (outre les bases systèmes) et que chaque noeud lui soit dédié (i.e., pas d’applications tierces, etc…), que tu souhaites garder tes backups 1 semaine sur tes serveurs, et que tu vises l’implémentation d’un quorum avec disque majoritaire dans un contexte actif/passif, je dirais pour du long-terme:
      – Bases systèmes: 20 Go.
      – MDF: 40 Go
      – LDF: 20 Go.
      – TempDB: 20 Go.
      – Backups: 20 Go.
      – Quorum: au moins 512 Mo feront largement l’affaire.
      – MSDTC: pas besoin d’une taille excessive (512 Mo est suffisant, par exemple).

      Soit une volumétrie totale de ~121 Go, ce qui laisse beaucoup de marge, et permet de voir venir sur du long-terme.

      A ajuster, cependant, en fonction des besoins.

      Juste un détail par rapport au journal de transactions: un fichier LDF ne se vide pas (à proprement parler), il se tronque. Si tu multiplies les sauvegardes transactionnelles (toutes les heures, par exemple), tu auras l’avantage, d’une part, de tronquer ton fichier LDF, et d’autre part, de disposer d’une bonne stratégie de restauration, avec un bon plan de maintenance.

      N’hésite pas à parcourir ce blog; j’en parle beaucoup (i.e., journaux de logs, fichiers de données, stockage, plans de maintenance, etc…).

      @+!

      M.

  2. Thomas dit :

    Bonsoir M. Cherif,
    j’ai commencé le test; j’ai déjà configuré le cluster sous Windows et installer le premier noeud SQL Server; mais je constate que quand le premier noeud est actif, les disques partagés ne sont pas visibles sur le second (ce qui est normal); si je fais l’installation du second noeud, le premier doit être éteint n’est ce pas? dans ce cas je ne risque pas d’écraser des fichiers du premier noeud? (puisque les disques (systeme, temp, data, log, backup) sont partagés entre les deux)

    • Bonsoir Thomas,

      Il n’est pas nécessaire d’éteindre le premier noeud SQL Server pour procéder à l’installation du second. Procède plutôt en lançant le média d’installation, et en choisissant – dans la section Installation Add node to a SQL Server failover cluster, sur le second noeud.

      Bon courage,

      M.

  3. Thomas dit :

    Bonjour M. Cherif,
    D’accord, je vais vous pouvoir finaliser d’ici demain et je ferai des tests avec mon application cliente; et je vous ferai le feed-back. A la fin de l’installation, je voudrais définir un GPO pour empêcher que des utilisateurs du domaine n’aient pas le privilège d’arrêter le services MS SQL Server sur aucun des noeuds et qu’ils ne puissent pas redéfinir un GPO pour se réapproprier les privilèges; est-ce possible?
    Merci

    • Bonsoir Thomas,

      Oui, cela est possible (GPMC, base de registre,…). Comme pour n’importe quel service, en fait, au niveau Windows.

      Par ailleurs, au niveau de SQL Server, ne pas oublier de bien définir les permissions, et surtout t’assurer qu’xp_cmdshell, par exemple, ne soit pas à la portée de tout le monde (par défaut, cette option est désactivée).

      @+!

      M.

  4. Thomas dit :

    Bonjour M. Cherif,
    J’ai fini la configuration du cluster et j’ai fait des tests de basculement; ça fonctionne; maintenant mon problème se situe au niveau de l’application cliente; car dès que j’effectue le basculement elle perd la connexion; mais je voudrais que le basculement soit transparent aux utilisateurs; y a t-il une option à définir dans la chaîne de connexion (un timeout) pour attendre que le basculement soit effectué au lieu de me générer une erreur au basculement?

  5. Thomas dit :

    Mon application cliente est un projet ADP (Microsoft Access DataBase Project) qui utilise une base SQL Server pour les données et des form Access pour le client. Je n’ai pas encore trouvé la solution pour gérer le temps de latence lors du failover; dès que le basculement est lancé, l’application perd la connexion et je suis obligé de relancer; il aurait été mieux que l’application se mette en attente de la disponibilité du serveur pour que le basculement soit transparent à l’utilisateur

  6. Thomas dit :

    Bonsoir M. Cherif; oui pour l’adresse IP; j’ai aussi essayé avec le hostname du cluster SQL Server. Pour mon parefeu j’ai désactive mais c’est pareil. En effet, il me faut modifier l’application pour prendre en compte le temps du failover; mais pour l’instant je n’ai pas encore trouvé un moyen de détecter la perte de connexion et de relancer la reconnexion;
    J’ai aussi pensé à une possibilité mais n’est pas envisageable en production; paramétrer un timer qui à chaque x seconde vérifie si l’application est connecté ou non; si pas connecté alors relancer la connexion; ça serait de l’attente active qui me boufferait trop de ressources…

  7. Thomas dit :

    Bonjour M. Cherif,
    Meilleurs voeux pour l’année 2014.
    Je voudrais savoir s’il y a une opération particulière à réaliser pour appliquer un service pack sur un cluster SQL Server? autrement quelle est la procédure pour l’application du patch sur le cluster?
    Merci d’avance

    • Bonsoir Thomas,

      Merci, je te souhaite une bonne année également.

      Concernant l’application d’un SP sur un cluster, il vaut mieux commencer par le noeud inactif. Et sitôt fini, faire de même sur le noeud actif.

      Bon courage,

      M.

      • Thomas dit :

        Bonjour M. Cherif,
        En voulant appliquer le service pack 3 sur le noeud inactif de mon cluster, j’obtiens le message d’erreur suivant après l’étape de vérification (au début de l’installation)

        [Message d’erreur]
        Il n’existe aucune instance SQL Server ou fonctionnalité partagée qui peut être mise à jour sur cet ordinateur.
        ================================================================================

  8. Thomas dit :

    Bonsoir M. Cherif
    je crois avoir trouvé la source du problème; j’avais installé une version SQL Server 2008 R2 alors que j’ai téléchargé le SP3 de SQL Server 2008 Simple; je confirme demain

  9. Thomas dit :

    Bonjour M. Cherif,
    j’ai téléchargé la bonne version du service pack mais le problème n’est toujours pas résolu; sur l’écran de choix des fonctionnalités (après les termes du contrat de licence), la case à cocher permettant de sélectionner les fonctionnalités à mettre à jour est inactive; même quand on clique sur le bouton « sélectionner tout », rien ne se passe; et quand on fait suivant, on obtient le message :
    « Il n’existe aucune instance SQL Server ou fonctionnalité partagée qui peut être mise à jour sur cet ordinateur. »

    • Bonsoir Thomas,

      Cela est normal: le SP3 n’existe pas pour SQL Server 2008 R2 (du moins, à l’heure actuelle). De plus, pour que la mise-à-jour soit effective, il faut que la ou les sources utilisées aient exactement la même version, architecture et langue que l’instance traitée. Ainsi, par exemple, un service pack issu de SQL Server 2008 ne fonctionnera pas sur une instance SQL Server 2008 R2.

      @+!

      M.

  10. Thomas dit :

    Bonjour M. Cherif;
    Merci pour l’éclaircissement; je vois; pour le service Pack 2 de 2008 R2 j’ai téléchargé la version française alors que l’instance a été installé avec la version anglaise. Je vais donc télécharger la version anglaise du service Pack 2. Merci beaucoup; voilà pourquoi j’adore ce blog qui me permet de découvrir beaucoup de choses…
    A bientôt

  11. Thomas dit :

    Bonjour M. Cherif,
    Le problème était effectivement dû à la version de mon service pack; j’ai téléchargé la bonne version (anglaise) et j’ai pu lancer l’installation de la mise à jour; mais à un moment j’ai un message d’erreur; le journal est un peu long à afficher; y a t -il un moyen pour attacher un fichier txt?
    Meilleures salutations

    • Bonsoir Thomas,

      Je n’ai pas (encore) intégré de quoi pouvoir attacher un fichier dans les commentaires.

      Sinon, concernant ton problème, que dit-il grosso-modo ? Et à quel moment tombe-t-il ?

      Tu peux toujours m’envoyer ledit fichier à: mac(dot)cherif(a)gmail(dot)com.

      @+!

      M.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s