[TUTO] – SQL Server 2016 : Configurer un cluster SQL Server Always ON avec 2 noeuds

22
4418
1 Star2 Stars3 Stars4 Stars5 Stars (4 votes, moyenne: 4,50 sur 5)
Loading...

Nous verrons dans ce billet comment installer et configurer un cluster SQL Server Always On avec 2 noeuds sous Microsoft Windows Server 2016.

Cas pratique :

  • 1 serveur MS Windows Server 2016 (Noeud 1) + Failover Clustering + SQL Server 2016 Enterprise
  • 1 serveur MS Windows Server 2016 (Noeud 2) + Failover Clustering + SQL Server 2016 Enterprise

 

Prérequisites

Quelques prérequis sont nécessaire au déploiement d’un cluster SQL Server 2016 AlwaysON.

  •  Installation standard de Windows Server 2016.
  •  Les serveurs devront se trouver dans le même sous réseau.
  • Depuis chaque noeud Windows Server 2016 qui formera le cluster Always ON, installez les features windows suivantes :
    • .NET Framework 3.5 Features
    • Failover Clustering

 

 

Configuration du rôle Windows « Failover Cluster »

 

Création du cluster Windows

Lancez la console « Failover Cluster Manager ».

 

En haut à gauche, cliquez droit sur « Failover Cluster Manager » puis sur « Create Cluster… »

 

Cliquez sur « Next ».

 

Ajoutez les 2 serveurs que vous avez installé puis cliquez sur « Next ».

 

Sélectionnez le second choix puis cliquez sur « Next ».

 

Saisissez le nom de votre future cluster dans le champ « Cluster Name » puis renseignez sa future adresse IP.

Cliquez enfin sur « Next ».

 

Vérifiez que la case « Add all eligible storage to the cluster » soit bien décochée puis cliquez sur « Next ».

 

Cliquez sur « Finish ».

 

 

Configuration du Quorum « File Share Witness »

Dans ce cas pratique, nous sommes dans une situation d’un cluster à 2 nœuds, ce qui veut dire que nous allons devoir configurer un quorum afin de pouvoir déterminer le nœud qui portera le cluster en tant que master. Plusieurs types de quorum sont possibles, nous utiliserons le mode « File Share Witness ».

Voici le concept :

Understanding Quorum in a Failover Cluster

 

Cliquez droit sur le votre cluster puis dans « More Actions », sélectionnez « Configure Cluster Quorum Settings… »

 

Cliquez sur « Next ».

 

Sélectionnez « Advanced quorum configuration ».

 

Vérifiez que la case « All Nodes » soit bien cochée puis cliquez sur « Next ».

 

Sélectionnez « Configure a file share witness » puis cliquez sur « Next ».

 

Renseignez le partage réseau qui permettra de stocker le fichier puis cliquez sur « Next ».

  • Un partage depuis un serveur (autre que les noeuds de votre cluster)
  • Un partage depuis un NAS
  • Un partage depuis un DFS
  • Etc…

 

Cliquez sur « Next ».

 

 

Cliquez enfin sur « Finish ».

 

Vérification du cluster

 

 

Installation de SQL Server 2016

 

Note : Cette installation devra être effectuée à l’identique sur chaque serveur du cluster

 

Lancez l’installation de SQL server 2016 via l’ISO.

/!\ N’oubliez pas que la fonctionnalité Always ON (FULL) n’est disponible qu’avec SQL Server Enterprise /!\

 

Dans la rubrique « Installation », cliquez sur « New SQL Server stand-alone installation or add features to an existing installation ».

 

Cliquez sur « Next ».

 

Cochez « I accept the license terms » puis cliquez sur « Next ».

 

Cliquez sur « Next ».

 

Dans notre cas, nous n’utiliserons que le moteur SQL Database Engine Services pour monter notre cluster Always ON. En fonction de vos besoins, vous n’êtes évidemment pas obligé de suivre à la lettre les features cochées ci-dessous.

L’installation du moteur SQL sera effectuée sur la partition système C:\.

Cliquez sur « Next » pour continuer.

 

Laissez l’instance par défaut « MSSQLSERVER » puis cliquez sur « Next ».

 

Vous devez ici spécifier les comptes de service, il existe plusieurs écoles :

  • Laisser les comptes de service système (non recommandé)
  • Dédier un compte de service AD par service

Exemple :

Service SQL Server Agent : DOMAINE\CompteServiceSQLAgent (Profitez en pour passer le startup type sur automatic)

Service Database Engine : DOMAINE\CompteServiceSQLDatabaseEngine

Sélectionnez l’onglet « Collation » pour continuer ou bien cliquez sur « Next » si vous souhaitez laisser la collation SQL par défaut.

 

De nouveau, en fonction des besoins, choisissez la collation qui vous sera le plus utile.

  • Pour la france : FRENCH_CI_AS
  • Pour le reste (multilingues) : SQL_Latin1_General_CP1_CI_AS

Quelques principes sur les collations SQL : https://msdn.microsoft.com/fr-fr/library/ms144260(v=sql.105).aspx

 

Je vous conseil ici de cochez la case « Mixed Mode », ce qui vous permettra de vous connecter sur votre serveur SQL via 2 méthodes :

  • Windows Authentication mode : Avec un compte de votre domaine Active Directory
  • Mixed Mode : Avec un compte local à SQL

N’oubliez pas également de renseignez un ou plusieurs administrateurs du serveur SQL. Cliquez sur l’onglet « Data Directories » pour continuer.

 

Ici, nous spécifierons les partitions sur lesquelles seront stockées les données ainsi que les logs. Je mets les données sur la partition D:\ et les logs sur la partition L:\.

Cliquez sur l’onglet « TempDB » pour continuer.

 

Modifiez la partition des logs de la TempDB puis cliquez sur l’onglet « FILESTREAM ».

 

Ne cochez pas la case puis cliquez sur « Next ».

Pour approfondir vos connaissance sur la technologie Filestream, c’est par ici : https://msdn.microsoft.com/fr-fr/library/gg471497.aspx

 

Cliquez sur « Install » pour lancer l’installation.

 

 

 

Configuration du cluster SQL Server 2016 Always ON

 

Activation de la fonction AlwaysOn High Availability

 

Note : Il faut effectuer cette étape sur l’ensemble des serveurs faisant partie du cluster

 

La fonction AlwaysOn est par défaut désactiver. Pour y remédier, ouvrez la console « SQL Server Configuration Manager », sélectionnez « SQL Server Services » puis double cliquez sur « SQL Server (MSSQLSERVER) ».

 

Cliquez sur l’onglet « AlwaysOn High Availability ». Vous devriez voir apparaître dans le champ « Windows failover cluster name », le nom de votre cluster Failover Cluster créé au début de ce billet.

Cochez la case « Enable AlwaysOn Availability Groups » puis cliquez sur « OK ». Vous devrez redémarrer le service de l’instance SQL pour que le paramètre soit bien pris en compte.

 

Ajout d’un « Availability Group »

 

Note : Il faut effectuer cette action sur le serveur qui sera noeud primaire

 

Ouvrez la console « Microsoft SQL Server Management Studio », cliquez droit sur « AlwaysOn High Availability » puis sur « New Availability Group Wizard… »

 

Cliquez sur « next ».

 

Renseignez le nom de l’availability group puis cliquez sur « Next ».

 

Note : Créez rapidement une base « test » sur le serveur SQL et faites un backup de celle-ci une fois. (Il s’agit d’un prérequis pour créer votre availbility group).

Sélectionnez la base puis cliquez sur « Next ».

 

Cliquez sur « Add Replca.. » pour ajouter le deuxième serveur en tant que secondary.

Cliquez sur « Listener » pour continuer.

 

Le Listener permettra de contacter votre cluster Always On.

Cochez la case « Create an availibility group listener » puis renseignez les différentes informations :

  • Listenez DNS Name : J’utilise comme nom de listener le même nom que l’availability group (beaucoup moins de confusion 🙂 )
  • Port : 1434
  • Network Mode : Static IP puis saisissez une IP dans le même subnet que votre cluster

Cliquez sur « Next » pour continuer.

 

Cochez la case « Full » puis renseignez un partage réseau.

Celui-ci sera utiliser pour faire la toute première synchronisation de votre Availability Group, il ne le sera plus par la suite. Cliquez sur « Next ».

 

Check, Ready, Cliquez sur « Next ».

 

Cliquez sur « Finish » pour lancer la création du Groupe.

 

Lorsque tout se passe bien…

 

Voici le résultat de toutes nos configurations, nous retrouvons bien :

  • Notre « Availability Groups »
  • Nos 2 serveurs, l’un « Primary », l’autre « Secondary »
  • Notre base de test protégée par le groupe de disponibilité
  • Le Listeners

 

22 Commentaires

  1. Bonjour

    Super tuto tres clair que j’ai suivis a la lettre.

    Je rencontre le soucis suivant:
    2 machines windows 2016 a jour (fraichement instalée)
    2 sql entreprise 2016 avec sp1

    Aucune erreur durant les différents paramétrage mais quand je crée le groupe de disponibilité quand management studio applique les réglages ça coince a la dernière étape attachement de xxx… ca tourne en rond et j’ai beau le laisser plus d’une heure j’ai aucune erreur qui s’affiche et ca continu a tourner quand je regarde sur mon serveur sql replica j’ai bien ma bdd qui est en restauration mais ca va pas plus loin.
    une idée de ce qu’il peux se passer? ou voir les logs de ce qu’il se passe?
    quand je regarde dans le tableau de bord de disponibilité je vois bien que le serveur secondaire est marqué comme sans syncronisation.
    quand je fais une validation de mon cluster failover windows tous les test son reussi sauf 2-3 mais qui concerne que les cartes réseaux (1 seule carte non redondé)
    Au secours 🙂

    Loic

    • apres maintes recherche je me repond a moi meme
      il faut dans sql serveur executer les requetes suivantes
      et remplacer
      * domain\mirrorservername par le domaine\nom du serveur secondaire
      * domain\principalservername par le domaine\nom du serveur principal
      ensuite tout fonctionne normalement

      Principal server

      use [master]
      GO
      CREATE LOGIN [domain\mirrorservername$] FROM WINDOWS
      GO
      GRANT CONNECT ON ENDPOINT::[Mirroring] TO [domain\mirrorservername$]
      GO

      Mirror Server

      use [master]
      GO
      CREATE LOGIN [domain\principalservername$] FROM WINDOWS
      GO
      GRANT CONNECT ON ENDPOINT::[Mirroring] TO [domain\principalservername$]
      GO

  2. Bonjour,
    Je suis en train de créer mon 1er cluster pour SQL, j’utilise dans mon cas 2014, mais il y a peu de différence et je rencontre un problème lors du patchage SP1 en SP2 de l’instance secondaire.
    J’ai suivi votre tutoriel sans problème jusqu’au moment ou j’ai tenté d’upgrader ma version d’SQL Server 2014 Enterprise SP1 en SP2 de la seconde instance.

    Erreur rencontré :

    Overall summary:
    Final result: The patch installer has failed to update the following instance: S4BCL02ACC. To determine the reason for failure, review the log files.
    Exit code (Decimal): -2061893565
    Start time: 2018-05-09 18:33:02
    End time: 2018-05-09 18:35:06
    Requested action: Patch

    Et maintenant l’instance secondaire ne démarre plus alors qu’à l’installation (SP1) tout c’était bien passé !
    J’ai redémarré le serveur + Réessayé d’installé le patch sans succès.

    Savez vous comment régler ce problème car normalement en « Stand-alone » j’ai aucun problème pour faire ces patchs.

    Merci par avance pour votre réponse.

    PS : Est il possible de vous envoyer des « Capture d’écran » et des logs ?

    JALL

    • Hello.
      Vous pouvez essayer de sortir le serveur qui pose problème de l’AG. Une fois retiré, mettez le à jour comme une instance SQL en mode standalone puis réintégrez le à l’AG.
      Je n’ai jamais rencontré ce soucis d’upgrade même dans le cadre d’un cluster AlwaysON.

      A+
      Jérémy

      • Bonjour,
        Merci pour votre réponse.
        J’ai été induit en erreur par le message renvoyé par SQL, ainsi que les logs, le problème en fait était qu’une partie des disques se sont désactivés (cela pour la 2éme fois avec le serveur secondaire), j’ai pu faire les upgrades.

        Merci encore pour votre aide !

        JALL

    • Bonjour,

      Vous parlez de la création de l’Always ON ?
      Si oui, il vous suffit de le faire depuis le primaire uniquement. Le secondaire est ajouté pendant le wizard ou bien par la suite sans problème.

      Jérémy

      • Pardon, je n’ai pas été suffisamment précis, une base de données dispose de connexion avec des droits bien spécifiques, lorsqu’elle est mise en HA doit on créer la connexion sur le second serveur, attribuer les droits sur la base ???

        merci

        • Ok je vois.
          1. Configuration des droits sur l’instance primaire
          2. Ajouter le login au niveau de l’instance secondaire
          3. La synchronisation de la base prend en compte automatiquement le mapping des droits.

          Vous pouvez également utiliser cette procédure stockée pour copier les droits d’une instance à une autre, c’est beaucoup plus propre.

          Jérémy

        • J’ai testé sur une base déjà répliquée, ca n’a pas fonctionné.
          Ca doit être au moment de la mise en miroir que les droits doivent être répliqués non ?

        • Les droits ne se répliquent pas quand une base est ajoutée à un groupe AlwaysON, il faut ajouter les comptes à la main au niveau sécurité sur chaque noeud du cluster AlwaysON. Par contre le mapping des comptes (soit des droits) lui est stocké dans chaque base et est donc répliqué en même temps que celle-ci par l’AG.

  3. Bonjour,

    J’ai un petit problème lors du déroulement de votre (très bon) tutoriel.
    A la dernière étape  » joining « … » to availibility group « … » « , le délai est très long et la tâche échoue.

    Pouvez-vous m’aider à résoudre ce problème ?

    Merci

    RO

      • Bonjour,

        J’obtiens ce message d’erreur :

        TITRE : Microsoft SQL Server Management Studio
        ——————————

        Impossible de joindre la base de données « siteNatation » au groupe de disponibilité « HAclusterBascul » sur le réplica de disponibilité « IISSQLSERVER2 ». (Microsoft.SqlServer.Management.HadrModel)

        Pour obtenir de l’aide, cliquez sur : http://go.microsoft.com/fwlink?ProdName=Microsoft SQL Server&ProdVer=14.0.17199.0 ((SSMS_Rel).171004-0254)&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&LinkId=20476

        ——————————
        INFORMATIONS SUPPLÉMENTAIRES :

        Une exception s’est produite lors de l’exécution d’un lot ou d’une instruction Transact-SQL. (Microsoft.SqlServer.ConnectionInfo)

        ——————————

        La connexion au réplica principal n’est pas active. Impossible de traiter la commande. (Microsoft SQL Server, Erreur : 35250)

        Pour obtenir de l’aide, cliquez sur : http://go.microsoft.com/fwlink?ProdName=Microsoft SQL Server&ProdVer=13.00.4001&EvtSrc=MSSQLServer&EvtID=35250&LinkId=20476

        ——————————
        BOUTONS :

        OK
        ——————————

        Avez-vous déjà rencontré ce problème ? Savez-vous comment le résoudre ?
        Je vais chercher de mon côté en parallèle.

        Merci d’avance 🙂

        RO

        • Bonjour,

          Alors non effectivement, je n’ai jamais rencontré ce problème.
          Vous pouvez m’en dire un peu plus sur l’infra que vous avez monté ? Il n’y a pas eu de problème lors de la création du cluster failover et de l’AG ? Pouvez-vous tester une bascule de noeud pour tester la bonne santé de votre cluster AlwaysOn ?

          Jérémy

      • Bonjour,

        Je suis actuellement étudiant en infrastructures et réseaux. Je cherche à monter un Cluster SQL Server Always ON pour accueillir les bases de données des étudiants développeur.

        Vous aviez raison. Mon Cluster Failover était en erreur critique car les deux serveurs n’avaient pas les mêmes données de Cluster (erreur ID 1561) : sûrement à cause des mises à jour qui n’étaient pas identiques sur les deux machines virtuelles.

        Le problème est maintenant résolu. Les tests de basculement sont fonctionnels.

        Merci encore pour votre aide et votre tutoriel facile à comprendre 🙂

        RO

      • Pensez-vous que, sur les deux mêmes noeuds de Cluster Failover, on puisse faire un Cluster IIS en plus du Cluster SQL Server Always ON ?

        Merci de votre réponse,

        RO

        • Tout est possible, il suffit de configurer à l’identique vos sites IIS sur les 2 serveurs et d’utiliser un équipement réseau pour le balancing (F5, pfsense, etc..).

          Jérémy

LAISSER UN COMMENTAIRE

Please enter your comment!
Please enter your name here