Introduction

1.1 Problématique et solution

Aujourd’hui, la haute disponibilité des données est un sujet incontournable pour une entreprise qui traite et stock une quantité importante d’information. Une coupure de service quelle qu’elle soit (programmée ou pas), peut engendrer des coûts importants pour une entreprise. Afin de se prémunir de cela, les entreprises qui ont fait le choix d’implémenter SQLServer2008 comme gestionnaire de base de données peuvent opter pour la mise en place d’un Failover Clustering.

1.2 Principe du Failover Clustering actif / passif

Le principe du Failover Clustering est de minimiser au maximum les interruptions de services fournis par un serveur. Composé d’un minimum de deux nœuds, le cluster permet, en cas de défaillance du nœud actif, de basculer les services vers un nœud fonctionnel de façon automatique et transparente pour les utilisateurs finaux.

L’espace de stockage étant commun, les utilisateurs y aurons toujours accès et ne déplorerons pas de pertes de données.

Le Failover Clustering est une solution qui implémente le concept de haute disponibilité ce qui bien évidement, n’est pas une solution qui a vocation à remplacer un système de sauvegarde ; Celle-ci implémente le concept dePlan de reprise d’activité (PRA). Il est donc important de considérer le Failover Clustering comme une solution complémentaire à la politique de sauvegarde.

Au fil des chapitres nous allons voir comment mettre en place cette technologie sous un environnement composé de Windows Server 2008 R2 Edition Enterprise x64 et SQL Server 2008 édition Enterprise Service Pack 1 x64 *.

* : Lors de la rédaction cet article SQL Server 2008 R2 n’était pas encore disponible.

Présentation de l’environnement

2.1 Architecture

Pour réaliser ce Labo, nous avons mis en place une architecture constituée des serveurs suivants :

Ø SRVDC01 :

– Rôle : Contrôleur de domaine hébergeant les 5 rôles FSMO*, serveur DNS

– Domaine : MSLAB.LAN

– OS : Windows Server 2003 SP2 Edition Standard x32

– Adresse IP : 192.168.1.1 (Réseau public (LAN))

Ø SRVSQL01

– Rôle : Serveur SQL (Nœud A)

– Domaine : Membre de MSLAB.LAN

– OS : Windows Server 2008 R2 Edition Enterprise x64

– Adresse IP :

· 192.168.1.2 (Réseau public (LAN))

·  192.168.2.1 (réseau privé cluster)

· 192.168.3.1 (Réseau dédié au stockage)

Ø SRVSQL02

– Rôle : Serveur SQL (Nœud B)

– Domaine : Membre de MSLAB.LAN

– OS : Windows Server 2008 R2 Edition Enterprise x64

– Adresse IP :

· 192.168.1.3 (Réseau public (LAN))

·  192.168.2.2 (réseau privé cluster)

· 192.168.3.2 (Réseau dédié au stockage)

Ø SRVSTOCK01

– Rôle : Serveur qui gère le stockage iSCSI

– Domaine : Membre de MSLAB.LAN

– OS : Windows Server 2008 R2 Edition Enterprise x64

– Adresse IP : 192.168.1.4

· 192.168.1.4 (Réseau public (LAN))

· 192.168.3.3 (Réseau dédié au stockage)

* pour une explication détaillée des rôles FSMO nous vous invitons à lire l’article suivant : /articles/win/FSMO/

2.2 Schéma de l’architecture

Pré-requis et contraintes techniques

3.1 Le fonctionnement du Clustering sous Windows Server 2008

Pour mettre en place une architecture en Failover Clustering il est important de comprendre comment fonctionne la technologie.

Le Failover Clustering est établie au niveau de la couche Windows. C’est donc à ce niveau que nous effectuerons tout le paramétrage. Une fois l’installation et la configuration finies, nous implémenteront la couche SQL.

3.2 Versioning et licences

3.2.1 Le Failover Clustering ET les éditions de Windows Server 2008 R2

Toutes les versions de Windows Server 2008 R2 ne fournissent pas les mêmes services. Le Failover Clustering n’est disponible que sur les versions Enterprise, Datacenter et Itanium.

Ci-dessous un tableau récapitulatif :

Vous pouvez retrouver le tableau dans son intégralité à l’adresse suivante :

https://www.microsoft.com/windowsserver2008/en/us/r2-differentiated-features.aspx

3.2.2 Le Failover Clustering ET les éditions de SQL Server 2008

Seules les versions listées ci-dessous supportent le Clustering :

· SQL Server 2008 Standard Edition 32/64 bits

· SQL Server 2008 Enterprise Edition 32/64 bits

· SQL Server 2008 Developer Edition 32/64 bits

 3.2.3 Nombre de nœuds possible

Le nombre de nœud possible varie selon l’édition de Windows Server 2008 R2 et de SQL Server 2008

Nombre de nœud selon l édition Windows Server 2008 R2 :

Edition Nb de nœuds max
Data Center 16
Enterprise 16
Itanium 8

Nombre de nœud selon l’édition de SQL Server 2008 :

Architecture Nb de nœuds max SQL Server 2008 Enterprise / Developer Edition Nb de nœuds max SQL Server 2008 Standard Edition
x64 16 2
x86 et Itanium 8 2

Tableau récapitulatif :

Edition de windows Server 2008 R2
Data Center Enterprise Itanium
Edition de SQL Serveur
SQL Server Enterprise/Developer Edition x64 16 16
SQL Server Enterprise /Developer Edition x86/Itanium 8 8 8
SQL Server Standard Edition x64 2 2
SQL Server Standard Edition x86/Itanium 2 2 2

3.2.4 Licences

Windows :

· Une licence / nœud.

La tarification est disponible à l’adresse suivante :

https://www.microsoft.com/windowsserver2008/en/us/pricing.aspx

SQL :

· Une licence pour le nœud actif. le nœud passif ne requiert pas de licence si le nombre de ses processeurs est inférieur ou égal à ceux du nœud actif. Si les rôles étaient inversés vous avez 30 jours pour rétablir la configuration initiale, excédé ces 30 jours il faudrait une acheter licence supplémentaire.

La tarification est disponible à l’adresse suivante :

https://www.microsoft.com/sqlserver/2008/en/us/pricing.aspx

3.3 Pré-requis

3.3.1 Matériel

Composant Configuration requise
Processeur Type de processeur :

· Minimum : AMD Opteron, AMD Athlon 64, Intel Xeon avec prise en charge Intel EM64T, Intel Pentium IV avec prise en charge EM64T

Vitesse du processeur :

· Minimum : 1,4 GHz

· Recommandé : 2,0 GHz ou plus

Mémoire RAM :

· Minimum : 1 Go

· Recommandé : 4 Go ou plus

· Maximum : 64 Go

Source :

https://msdn.microsoft.com/fr-fr/library/ms143506.aspx#EEx64

Afin de vous assurer que votre matériel est bien compatible avec Windows Server 2008 R2, vous pouvez faire une vérification à l’aide de ce portail :

https://www.windowsservercatalog.com/

3.3.2 Logiciel

Le Framework .Net est requis. Vous devrez installer la version du Framework selon votre édition Windows. En voici le détail :

· Framework.net 3.5 SP1 pour les éditions x64

· Framework.net 2.0 pour les éditions Itanium

Windows Installer 4.5 et Microsoft Data Access Components (MDAC) sont également requis mais présentent l’avantage d’être installés en natif sur le Windows Server 2008 R2.

3.3.3 Domaine

Pour permettre la réalisation d’un cluster sous Windows Server 2008 R2 un domaine doit être mise en place. Les différents nœuds doivent être membre du même domaine. Le domaine doit être basé sur Active Directory ce qui veut dire que les Domaines en NT4 devront être mise à jour avec n’importe quel domaine fonctionnel.

3.3.4 Features et Roles

Ci-dessous un tableau récapitulatif des différents rôles requis pour la mise en place du cluster

Nom Type Information
Failover Clustering Features Requis pour installer et configurer le cluster
Multipath I/O Features Non requis à moins que vous utilisiez le Multipath
Storage Manager for SANs Features Non requis, si vous avez un SAN il peut s’avérer un outil utile
.Net Framework Features Requis pour l’installation du Cluster.
Nom Type Information
Application Server Role Requis pour la mise en place de Microsoft Distributed Transaction Control (MSDTC) *
Application Server Foundation Role Services Requis pour la mise en place de Microsoft Distributed Transaction Control*
Distributed Transaction Role Services Requis pour la mise en place de Microsoft Distributed Transaction Control*
COM+ Network Access Role Services Requis si votre Firewall Windows est actif et que vous voulez installer le MSDTC. Ce service permettra de créer une règle pour ouvrir le port 135. **

* Microsoft Distributed Transaction Control n’est pas un composant requis mais il est vivement conseillé de l’installer afin de permettre une meilleure gestion des procédures stockées entre plusieurs serveurs.

**Même si votre Firewall est désactivé, il n’est pas inutile d’installer ce composant. En effet si vous décidiez de réactiver votre firewall vous auriez déjà là règle de créée.

3.3.5 Réseau

Chaque nœud du cluster devra disposer d’un minimum de deux cartes réseaux :

·

·

Vous pouvez également dédier une carte réseau pour :

·

3.3.6 Disque et Système de fichier

3.3.6.1 Type de disque

Etant donné que les disques dynamiques ne sont pas supportés, veuillez donc à sélectionner des disques Basics. Vous pouvez également convertir vos disques dynamiques en Basic. Ci-dessous un lien qui vous montre la marche à suivre.

https://technet.microsoft.com/en-us/library/cc776315(WS.10).aspx

Une fois vos disques choisis vous aurez le choix de les configurer en Master Boot Record (MBR) ou en Guid Partition Table (GTP). Voici les principales caractéristiques de ces deux modes :

MBR GPT
Taille Maximale 2To 256 To
Nombre maximum de partitions 4 128
Système de fichier supporté FAT, NTFS NTFS
Bootable Oui Oui sur des systèmes basés sur l’EFI (Extensible Firmware Interface)
Sauvegarde de la table de partition Non Oui
Comptabilité Pas de problème particulier à signaler Certains outils et OS ne reconnaissent pas les disques GPT

Présenté comme cela, les disques de grandes capacités sont largement exploitables avec le GPT, mais vous devez garder à l’esprit le temps de maintenance nécessaire sur les disques de gros volume. Si vous étiez amené à utiliser des outils tels que CHKDSK vous créerez alors une grosse indisponibilité. Pensez donc à cela lors de l’étude et optez pour un partitionnement que vous adapterez à vos besoins. Pour la réalisation de notre Labo nous utiliseront le MBR car il suffit amplement à nos besoins.

3.3.6.2 Format de fichiers

Tous les disques doivent être formatés en NTFS. Afin de gagner en performances, Il est recommandé de définir des tailles de blocks plus petits pour les disques qui hébergeront les datas, 64Ko est la valeur préconisée dans les « best practices », Les autres disques peuvent être formatés avec une taille des blocks par défaut c’est-à-dire 4096 Ko.

Préparation

Apres avoir validé la décision d’implémenter une architecture en cluster, il est important de passer par la phase préparation afin de définir la politique de nommage, l’adressage IP, les comptes d’administrations, les comptes de services ainsi que les ports à ouvrir sur le firewall de Windows.

4.1 Nommage

La mise en place d’un cluster génère automatiquement des noms en plus sur votre environnement. En voici les détails :

· 1 nom de machine / nœuds

· 1 nom de cluster

· 1 nom pour le MSDTC (Si vous choisissez de le mettre en place)

· 1 nom de serveur SQL

· 1 nom / instance SQL

· 1 nom pour l’ID de l’instance

Dans notre cas cela donne :

· 1 nom de machine pour le nœud A : SRVSQL01

· 1 nom de machine pour le nœud B : SRVSQL02

· 1 nom pour identifier le cluster sur le réseau : SRVCLUSQL01

· 1 nom pour identifier le MSDTC : SRVCLUSQL01Dtc

· 1 nom pour identifier notre serveur SQL sur le réseau : SRVLABSQL01

· 1 nom pour identifier l’instance SQL : INST01_MSLAB

· 1 nom pour l’ID de l’instance : INST01_MSLAB_ID

4.2 Adressage IP

L’adressage IP devra également être préparé. Même si cela n’est pas conseillé, il est tout fait possible de choisir un adressage dynamique. Pour la réalisation de notre Labo, nous optons pour des adresses IP statiques.

Voici le détail des adresses nécessaires:

· 1 adresse IP / nœuds pour la communication sur le réseau public (LAN)

· 1 adresse IP / nœuds pour la communication sur le réseau privé

· 1 adresse IP/ nœuds pour la communication sur le réseau iSCSI

· 1 adresse IP pour le cluster (réseau public)

· 1 adresse IP pour le MSDTC si vous choisissez de le mettre en place

· 1 adresse IP / instances SQL

Dans notre cas cela donnera :

· 1 adresse IP pour la communication du nœud A sur le réseau public : 192.168.1.2 /24

· 1 adresse IP pour la communication du nœud A sur le réseau privé : 192.168.2.1 /24

· 1 adresse IP pour la communication du nœud A sur le réseau iSCSI : 192.168.3.1 /24

· 1 adresse IP pour la communication du nœud B sur le réseau public : 192.168.1.3 /24

· 1 adresse IP pour la communication du nœud B sur le réseau privé : 192.168.2.2 /24

· 1 adresse IP pour la communication du nœud B sur le réseau iSCSI : 192.168.3.2 /24

· 1 adresse IP pour le Cluster : 192.168.1.5/24

· 1 adresse IP pour le MSDTC : 192.168.1.6/24

· 1 adresse IP pour l’instance SQL : 192.168.1.7/24

4.3 Configuration Réseau

4.3.1 Renommage des cartes réseaux

Pour un souci d’organisation nous renommons les cartes réseaux pour s’y retrouver facilement.

Nous allons dans les paramètres réseaux :

Dans le menu de gauche nous cliquons sur « change adapter settings ».

Nous sélectionnons une carte réseau et cliquons sur « Rename this connection ». Nous pouvons également utiliser la touche F2 du clavier.

Dans notre cas voici le résultat :

4.3.2 Priorité

Il est important de définir la priorité de vos réseaux. Pour ce faire nous pressons la touche ALTde notre clavier pour faire apparaître le menu. Ensuite nous cliquons sur « Advanced » puis « Advanced Settings… ».

Dans l’onglet « Adapters and Bindings », avec l’aide des flèches vertes nous définissons le Réseau Public (LAN) comme réseau prioritaire. Ensuite, suit le réseau Privé et le Stockage pour finir.

4.3.3 Désactivation de L’IPV6

Nous recommandons de désactiver l’iPv6 sur toutes les cartes réseaux actives de votre réseau si vous ne n’utilisez pas. Même non utilisé, ce protocole génère du trafic réseau. Ci-dessous une trame capturée avec Wireshark :

Désactivation du Protocol IP V6

Nous sélectionnons une carte réseau de notre nœud A, puis cliquons sur « Properties » et décochons la case correspondante à L’IPV6.

Nous reproduisons l’opération sur les autres cartes réseau du nœud.

4.3.4 DNS et NetBios

Sur la carte réseau Public, nous vérifions que la connexion s’enregistre dans le DNS. Ensuite nous activons le NetBios. Pour ce faire, nous allons donc dans les propriétés de l’IPV4.

Sur les cartes de réseaux privés et Stockagesnous décochons « Register this connection ‘s adresses in DNS » et nous sélectionnons « Disable NetBIOS over TCP/IP ».

Nous répétons les étapes 4.3.1 à 4.3.4 sur le nœud B de notre cluster. Concernant l’étape 4.3.3 pour gagner en efficacité, nous désactivons l’IPV6 sur les autres postes de notre LAN.

4.3.5 Règles firewall

Si vous utilisiez le firewall Windows il est nécessaire d’ouvrir certains ports pour le bon fonctionnement du cluster. En voici la liste :

Affectation Numéro Type Description
Analysis Services 2383 TCP Si vous mettez en place Analysis services vous devrez ouvrir ce port
Cluster Service 3343 UDP Ce port sert au service cluster qui contrôle et gère les opérations faites par le cluster
Cluster Administrator 137 UDP Port d’administration
File and Printer Sharing 139 TCP Le Quorum peut être amené à utiliser ce port s’il est configuré en Node and File Share Majority
File and Printer Sharing 445 TCP Le Quorum peut être amené à utiliser ce port s’il est configuré en Node and File Share Majority
File and Printer Sharing 138 UDP Le Quorum peut être amené à utiliser ce port s’il est configuré en Node and File Share Majority
RPC 135 TCP Ce port est utilisé par le Cluster Service, le MSDTC et SQL Server Intégration Services (ouvert par défaut si vous ajouter COM+ Access Network en role service)
SQL Server 1433 TCP Port par défaut dans un pool dynamique qu’une instance tentera d’utiliser
SQL Server Browser 1434 UDP Port utilisé par SQL Server browser

Dans notre cas le firewall est désactivé.

4.4 Disques

La création des partitions est une étape très importante. Bien entendu, elle est définie selon vos besoins. Lors de la configuration de votre SAN, pour respecter les « bests practises » vous devez définir des « Logical Unit Number (LUN*) » différents pour le Quorum, les données, les logs et les sauvegardes dans le but d’éviter les « single point of failure (SPOF)* *».

La sélection du type de Quorum est également essentielle. Pour rappel le Quorum a pour fonction de :

· Permettre d’ « authentifier » et d’ « intégrer » un nœud dans le cluster.

· Permettre d’éviter la division du cluster en plusieurs partis du cluster en cas de non communication entre les nœuds, grâce à un système de vote.

· Permettre de stocker la configuration du cluster.

Sous Windows 2008 server il existe quatre modes de fonctionnement du Quorum :

No Majority : Le Quorum est simplement placé sur un disque. Ce disque est parfois appelé « Witness Disk » (Non conseillé, pour cause de single point of failure).

Node Majority: Ce mode peut être mise en place lorsque le cluster est composé d’au moins trois nœuds et sans stockage partagé. Le cluster continuera de fonctionner, si la majorité des votants fonctionnent.

Node and Majority Disk : Valeur par défaut, C’est la combinaison entre le No Majority mode et le Node Majoity. Il est fonctionnel à partir de deux nœuds. En plus des nœuds le Quorum sera également votant.C’est ce mode que nous allons utiliser .

Node and File Share Majority : C’est le même principe que le Node and Majority disk mais au lieu d’avoir un partage sur le réseau remplace le « Witness disk ». C’est une solution envisageable en cas de géo-cluster.

* Logical Unit Number (identifiant d’unité logique) : Cela représente une unité de stockage

** Single point of failure (Point individuel de défaillance) : Point d’un système informatique dont le reste du système est dépendant, si ce point venait à être défaillant c’est tout le système qui serait impacté.

En plus du Quorum nous aurons une partition pour le MSDTC, les données, logs et sauvegarde. En voici le détail.

Pour plus d’information sur le sujet du Quorum nous vous invitons à lire cet article :

https://technet.microsoft.com/en-us/library/cc770620%28WS.10%29.aspx#BKMK_why

Vous y trouverez les informations sur le type de Quorum à mettre en place en fonction du cas de figure.

Les lettres des partitions devront être identiques sur les deux nœuds. Pour notre Labo cela donne :

· E : pour la partition du Quorum

· F : Pour la partition du MSDTC

· G : Pour la partition des data

· H : Pour la partition des logs

· I : Pour la partition des backups

4.6 Comptes

4.6.1 Compte d’administration

Afin d’installer et configurer le cluster, un compte d’administration est nécessaire. Ce compte devra bénéficier des droits pour créer des objets (ordinateurs) sur le domaine. Il est également requis que ce compte soit rajouté dans le groupe d’administrateur local de chaque nœud.

Dans notre cas nous allons créer un nouveau compte et lui attribuer les droits nécessaires. Ensuite nous allons l’ajouter dans le groupe d’administrateur du nœud A (SRVSQL01) et nœud B (SRVSQL02).

Compte :adminclusql01.

Nous nous connectons sur le contrôleur de domaine puis sélectionnons « Active Directory Users and Computers ».

Info : Nous utilisons le logiciel BGINFO pour afficher les informations sur le bureau.

Puis créons le nouveau compte.

Une fois le compte créé, nous cliquons sur « View » et « Advanced Features », cela nous permet d’accéder à plus d’option.

Nous allons donner au compte que nous venons de créer le droit de créer et de supprimer des ordinateurs. Nous cliquons sur « Computers » puis « Properties ».

Nous allons dans l’onglet « Security ».

Et ajoutons le compte que nous avons créé.

Nous allons maintenant lui attribuer les droits. Nous le sélectionnons et cliquons sur Advanced.

Nous sélectionnons le compte et cliquons sur « Edit… ».

Dans le menu déroulant nous sélectionnons « This object and all child object ». Nous cochons ensuite les cases « Create Computers Objects » et « Delete Computers Objects » puis cliquons sur « OK ».

Nous validons en cliquant sur « OK ».

De retour dans cette fenêtre on peut voir que la case « Allow » de « Spécial Permissions » est cochée. On clic sur « OK » pour validé sortir de cette fenêtre.

4.6.2 Compte de service

Nous devons créer également 2 comptes de services

que nous allons nommer :

·sqlagentsvcacc (ce compte de service sera celui de l’agent SQL)

·sqlsvcacc (ce compte de service sera celui SQL Server)

Ensuite nous créons un groupe de sécurité que nous appelonssqlsvcgrp.

Ce groupe accueillera les comptes sqlagentsvcaccet sqlsvcacc en tant que membre.

4.6.3 Configuration des comptes sur les nœuds

Les comptes adminclusql01et sqlagentsvcaccdoivent être placés dans le groupe administrateur local de chaque nœud du cluster.

Nous allons dans Server Manager puis dans la section Configuration => Local Users and Group => Groups => Administrators et ajoutons les deux comptes:

Les comptes sqlagentsvcacc et sqlsvcacc doivent bénéficier des droits

pour exécuter les actions suivantes :

· Adjust memory quotas for a process (Ajuster les quotas de mémoire pour un processus)

o Les comptes auront le droit d’ajuster la quantité de mémoire attribuée à un processus.

· Bypass traverse checking (Contourner la vérification de parcours)

o Les comptes seront autorisés à parcourir les arborescences des répertoires même si ils ne disposent pas des autorisations.

· Log on as a batch job (Ouvrir une session en tant que tâche)

o Permettra aux comptes d’ouvrir une session au moyen d’une fonction de file d’attente de tâches. Le planificateur de tâche connectera les comptes en tant qu’utilisateur de tâche et non en tant qu’utilisateur interactif.

· Log on as a service (Ouvrir une session en tant que service)

o Les comptes auront le droit d’inscrire un processus en tant que service.

· Replace a process-level token (Remplacer un jeton de niveau processus)

o Les comptes auront le droit d’appeler l’API (Aplication Programming Interface) « CreateProcessAsUser » afin de démarrer un service à partir d’un autre.

C’est dans l’optique de faciliter l’administration de cette partie que nous avons créé le groupe sqlsvcgrp

.

Sur le nœud A nous ouvrons la console « Local Security Policy ».

Une fois la console ouverte nous allons dans « Local Policies », puis « User Right Assignement » dans le menu de droite, nous retrouvons les actions que nous avons besoin d’attribuer à nos compte de services. Nous commençons par « Adjust memory quota for a process » en double cliquant dessus. Puis nous ajoutons le groupe à la liste.

Nous reproduisons la même opération pour les autres actions citées plus haut.

Pour finir nous nous connectons sur le nœud B et effectuons la même procédure.

4.7 Configuration des disques

4.7.1 Connexion des disques iSCSI

Apres avoir configuré notre SAN * (technologie iSCSI), nous devons maintenant configurer nos disques.

Nous commençons par le nœud A et lançons la console de management iSCSI.

Si c’est la première fois que vous lancez « iSCSI Initiator » un message vous demandera de démarrer le service iSCSI, vous devrez l’accepter.

* Pour la réalisation de ce Labo, nous utilisons Starwind dans sa version d’évaluation sur le serveur SRVSTOCK01. Si vous optez pour cette solution, vous trouverez des tutoriaux disponibles à l’adresse suivante : https://www.starwindsoftware.com/technical-papers

Dans l’onglet « Discovery » nous indiquons l’adresse IP et le port de notre serveur iSCSI (SRVSTOCK01) en cliquant sur « Discover Portal…».

Ensuite nous sélectionnons l’onglet « Target » pour afficher la liste des disques que nous pouvons connecter à notre nœud.

Pour connecter un disque il suffit de le sélectionner et de cliquer sur « Connect ». Attention à bien respecter l’ordre de connexion, car le numéro du disque sera attribué en fonction de l’ordre de connexion.

Lorsque nous cliquons sur « Connect » une fenêtre apparaît. Nous laissons la première case cochée afin de permettre une reconnexion automatique à chaque redémarrage.

Nous connectons tous les disques puis validons.

Nous répétons la même opération sur le nœud B.

4.7.2 Initialisation et formatage des disques

Une fois nos disques connectés, nous devons les initialiser et les formater en NTFS.

Sur le nœud A nous ouvrons Server Manager et nous sélectionnons « Disk Management ».

Nous voyons les cinq disques que nous avons connectés.

Nous cliquons sur le Disk 1 et choisissons « Initialize Disk ».

Dans le menu qui suit, nous sélectionnons tous les disques que nous avons connectés. Comme cité dans la section précédente, nous choisissons MBR en type de disque, ensuite nous validons nos choix.

Nos disques sont maintenant initialisés, nous pouvons créer nos partitions et les formater. Nous sélectionnons le « Disk 1 » qui sera notre Quorum et effectuons un clic droit dessus, puis choisissons « New Simple Volume… ».

Nous suivons ensuite le Wizard pour pouvoir créer la partition, définir une taille, une lettre, le système de fichier, la taille des blocs, un nom et exécuter le formatage.

Pour rappel nous laissons la taille des blocks par défaut sauf pour le disque qui hébergera les data ; nous lui attribuons 64 Ko à l’aide du menu déroulant.

Apres avoir créé et formaté les partitions voici le résultat :

Nous nous connectons ensuite sur le nœud B pour initialiser les disques. Le formatage n’est pas nécessaire puisque nous venons de le faire. Nous vérifions que l’ordre des disques et les lettres attribués aux partitions sont identiques au nœud A.

Installation

5.1 Ajout des Features et Roles

Nous ouvrons une session sur le nœud A avec le compte adminclusql01.

Nous allons ajouter les différents Features et Rôles nécessaire à la mise en place du cluster. Nous allons dans « Server Manager » et cliquons sur « Features » puis « Add Features » dans le menu de droite.

Dans le menu qui s’affiche, nous cliquons sur « Failover Clustering » puis cliquons sur « Next ».

Nous cliquons sur « Install »» et suivons le Wizard pour procéder à l’installation.

Une fois l’installation terminée nous procédons à l’ajout des rôles.

Dans le menu de gauche nous cliquons sur « Roles » puis sur « Add Roles » dans le menu de droite.

Une fois le Wizard initialisé nous cliquons sur « Next » pour avoir accès aux options.

Pour pouvoir installer notre MSDTC nous avons besoin d’ajouter le rôle « Application Server ».

Une fenêtre s’affiche Automatiquement nous obligeant à installer le .Net Framework pour pouvoir continuer, nous procédons donc à son installation.

Après l’installation du .NET Framework le rôle « Application Server » est coché. Nous cliquons « Next » pour poursuivre le processus d’ajout des rôles.

Une explication du rôle s’affiche, nous cliquons sur « Next » pour sélectionner les différents « roles services» que nous voulons installer.

Une fois la fenêtre des « Roles Services » affichées, nous sélectionnons « COM+ Network Access »

« Distributed Transactions » et ses différentes-sous cases. « .NET Framework 3.5.1 » est sélectionné par défaut. Nous cliquons sur « Next » pour valider.

Le processus d’installation nous demande si nous voulons mettre une authentification forte pour accéder à notre serveur. Nos besoins ne requiert pas ce type d’authentification, nous cliquons sur « Choose a certificate for SSL encryption Later » puis cliquons sur « Next ».

Un résumé de nos paramètres s’affiche, nous cliquons sur « Install » pour procéder à l’installation.

Une fois l’installation terminée, nous nous connectons sur le nœud B pour rajouter les mêmes « Roles » et « Features ».

.

5.2 Validation du cluster

Après avoir installé les « Roles » et « Features » sur nos deux serveurs, nous allons procéder à la validation de notre cluster. Durant cette phase, notre configuration matériel et logiciel sera testé. Tous les nœuds devront être actifs pour cette phase.

Pour lancer le processus de validation nous cliquons sur « Validate a Configuration ».

Le Wizard étant initialisé nous cliquons sur « Next ».

Nous indiquons les noms de nos deux nœuds qui composeront le cluster, puis cliquons sur « Next ».

En cliquant sur « Run all test » les éléments ci-dessous s’apprêtent à être testés :

· Inventory (Inventaire matériel et logiciel)

· Network : (Test sur la configuration réseau)

· Storage (Test sur les éléments lié au stockage)

· System configuration : (Test de comptabilité)

A noter que pour être supporté par Microsoft, votre Cluster devra effectuer tous les tests.

La validation est prête à être lancée. Nous cliquons sur « Next » pour l’exécuter.

A la fin de la validation, le résultat s’affiche. Les détails sont disponibles dans un rapport détaillé visible en cliquant sur « View Report… ».

Notre validation s’est bien déroulée et aucune erreur n’apparait. Il est important de noter que si nous avions eu un échec dans la validation nous n’aurions pas pu installer SQL Server 2008 en cluster. Nous aurions du trouver une solution au problème puis lancer une seconde vérification pour pouvoir procéder à l’installation de SQL.

Le rapport est consultable à l’aide du navigateur internet.

5.3 Création du cluster

Les tests de validation ont été positifs, nous pouvons installer notre cluster. Pour ce faire nous cliquons sur « Create the cluster now using the validated nodes… »

Si jamais vous aviez fermé la fenêtre, il suffit de cliquer sur « Create a Cluster », ce lien est disponible dans le menu « Failover Cluster Manager ».

Une fois le Wizard lancé nous cliquons sur « Next » pour accéder à la configuration.

Nous entrons le nom de cluster que nous avons définis dans la préparation ainsi que son adresse IP. Une fois fini, nous cliquons sur « Next ».

Le cluster est sur le point d’être installé, nous confirmons en cliquant sur « Next ».

Une fois l’installation terminée il est possible de voir le rapport en cliquant sur « View Report… ».

5.4 Post installation

 5.4.1 Etat du cluster, nœuds et disques

Notre cluster est maintenant visible dans le menu de « Failover Cluster Manager ».

Avec le menu ci-dessus nous pouvons voir que le cluster est actif sur le nœud A. Nous vérifions l’état du nœud B en affichant la liste des noeuds.

Nous vérifions également l’état de disques.

A ce stade il est tout à fait possible de changer le type et le disque du Quorum. Il suffit de cliquer sur le nom du cluster et de sélectionner l’option « More Actions… » Ensuite suivre le Wizard. Dans notre cas le cluster est sur le bon disque et le type « Node and Disk Majority » nous convient.

5.4.2 Configuration réseau

Nous allons configurer le réseau au niveau de la couche cluster. Nos trois cartes étant visibles nous allons les renommer pour une meilleure organisation et définir celles qui sont disponibles à la connexion ou non.

Cette carte réseau est celle de notre réseau public nous acceptons donc que le cluster communique sur cette carte et que les clients se connectent au cluster via cette interface.

Nous la renommons.

Nous nous faisons la même opération pour la seconde carte réseau.

Cette carte réseau correspond à notre réseau privé. Nous voulons que le cluster puisse communiquer sur cette interface mais ne voulons pas que les clients s’y connectent.

Nous la renommons en Private Network.

La dernière carte réseau correspond à notre réseau iSCSI nous la renommons et spécifions que le cluster ne peut communiquer via cette carte réseau puisqu’elle est strictement dédiée aux flux iSCSI.

5.5 Installation de MSDTC

Les opérations de Post installation du cluster étant terminées, nous pouvons installer le MSDTC. Pour ce faire, nous sélectionnons « Services et applications ».

Nous faisons un clic droit puis cliquons sur « Configure a Service or Application… ». L’option est également disponible dans le menu de droite.

Une fois Le Wizard lancé,  nous cliquons sur « Next pour accéder aux options. Ensuite, nous sélectionnons « Distributed Transaction Coordinaor (DTC) » puis cliquons sur « Next ».

Nous définissons le nom du MSDTC ainsi que son adresse IP. Nous nous référons à notre planification.

Nous choisissons le disque dédié au MSDTC. Dans notre cas cela correspond au disque 2.

Nous confirmons nos paramètres et procédons à l’installation.

Lorsque l’installation est terminée. Nous pouvons constater que notre MSDTC est en ligne sur le nœud B.

Nous choisissons de migrer la ressource sur le nœud A.

Nous confirmons la migration.

Le menu principal nous affiche maintenant que le MSDTC est disponible sur le nœud A.

5.6 Phase de vérification avant installation de la couche SQL

Avant de d’installer SQL Serveur nous allons faire quelques vérifications pour s’assurer que notre environnement est bien fonctionnel.

5.6.1 Etat général du cluster

En cliquant sur le nom de notre cluster, nous avons un résumé de l’état. Nous n’avons aucun problème remonté dans le « Cluster Events » notre cluster est bien en ligne sur le nœud A et le Quorum est bien sur le « Disk 1 ».

5.6.2 Etat du MSDTC

Notre MSDTC est bien en ligne sur le nœud A et son disque est bien le « Disk 2 ».

5.6.3 Etat des disques

Tous nos disques sont en ligne. Les « Disk 1,2 » sont respectivement attribués au Quorum et au MSDTC.

5.6.4 Etat du réseau

Tous nos réseaux sont disponibles et configurés comme nous le souhaitons

.

5.6.5 Accessibilité

Pour finir, depuis srvstock01 ou un autre poste du réseau nous effectuons un Ping pour vérifier l’accès à notre cluster ainsi que le mappage des noms.

5.7 Installation de SQL Serveur sur le nœud A

Nous allons procéder à l’installation du premier nœud. Nous avons opté pour l’option d’intégrer le Service Pack 1 intégré à l’installation. Vous pouvez faire cela en suivant la procédure disponible à l’adresse suivante :

https://blogs.msdn.com/petersad/archive/2009/02/25/sql-server-2008-creating-a-merged-slisptream-drop.aspx

Vous pouvez télécharger le service pack 1 à l’adresse suivante :

https://www.microsoft.com/downloads/details.aspx?FamilyID=66ab3dbb-bf3e-4f46-9559-ccc6a4f9dc19&displaylang=en

Après avoir exécuté le Setup nous allons dans le menu Installation et sélectionnons le « New SQL Server failover cluster installation ».

Avant de commencer le processus d’installation, une vérification de différents éléments qui pourrait affecter le bon déroulement de l’installation de SQL Serveur est faîte.

Aucun problème particulier nous est remonté nous pouvons passer à l’étape suivante en cliquant sur « OK ».

L’installation requiert une librairie de fichiers pour pouvoir continuer. Nous cliquons donc sur « Install ».

Après l’installation de la librairie, une deuxième vérification est lancée. Cette vérification teste la bonne configuration du cluster. Les «Warning » n’empêchent pas de continuer l’installation, par contre, les « Failed » empêcheront le processus de continuer. Toutefois, selon le message du « Warning » il est préférable de résoudre le problème.

Dans notre cas, nous avons un Warning qui nous indique que le nœud n’a pas accès à Internet, cela pourrait influer sur le temps d’ouverture d’un outil comme management studio. Rien de vital pour l’application nous pouvons donc passer à l’étape suivante.

Nous devons rentrer la clé de notre produit. Si vous spécifier la une free édition sachez que vous avez une période d’essai de 180 jours avant d’acquérir une licence.

Puis accepter les termes de la licence pour pouvoir accéder à l’étape suivante.

Dans cette étape, nous devons sélectionner quelles « Instances Features » et « Shared Features » nous voulons installer. Pour notre Labo, nous allons nous contenter d’une installation basique, c’est à dire le moteur SQL et quelques « Features » forts utiles.

Dans la section « Instances Features » :

Nous sélectionnons :

·Database Engine : Moteur SQL

·SQLServer Replication: Ce composant permet de copier et synchroniser la basesur différents emplacements.

·Full-Text Search: Moteur de recherche textuel qui permet de répondre aux requêtes qui interrogent les colonnes de type : char

,varchar,nchar,nvarchar,text,ntext,image,xml,varbinary based.

Nous ne sélectionnons pas :

·Analysis services : Ce composant fourni les outils pour créer et gérer des cubes multidimensionnels OLAP

(Online Analytical Processing). Il est important de noter que les « Best Practises» ne recommandent pas l’installation de « Database Engine » et « Analysis services » sur le même cluster.

·Reporting services : Ce composant permet de créer des rapports décisionnels. Il faut également noter que « Reporting services » n’est pas élément qui pourra être mis en haute disponibilité. Même si l’installation est possible vous ne bénéficierez pas du service de haute disponibilité sur ce composant.

Dans la section « Shared Features »

Nous sélectionnons :

·Client Tools Connectivity : Ce composant permet d’installer les connecteurs ODBC, DB-Library et OLEDB pour permettre une communication client server.

·Client Tools Bakwards Compatibility: Permet une compatibilité des outils de SQL Server 2008 sur des systèmes moins récents.

·Management Tools Basic: Ce composant installe l’outil de management principal (management studio)

·Management Tools Complete : Ce composant installe les outils de management des plateformes décisionnelles :Reporting Services, Analysis Services, Integration Services. Il installe également : Support for SQL Server Profiler et Database Tuning Advisor. Nous pourrions par exemple utiliser ces outils pour nous connecter sur un autre serveur SQL.

Nous ne sélectionnons pas :

·Business Intelligence Développent Studio : Outil équivalent à Visual studio mais enrichi d’objets pour pouvoir réaliser des projets décisionnels.

·Integration Services Integration : Outil d’extraction, transformation et chargement (Extract, Transform, Load. ETL)

·Client tools SDK : Kit de développement.

·SQL Server BoOKs Online : Documentation SQL. L’aide est disponible en ligne à l’adresse suivante : https://msdn.microsoft.com/en-us/library/ms130214.aspx

·SQL Client Connectivity SDK : Kit de développement pour les connecteurs.

·Microsoft Sync Framework : Plateforme de synchronisation multi-protocole.

Une fois la sélection faîte, nous pouvons cliquer sur « Next ».

Nous devons rentrer le nom de notre serveur SQL. Ce nom sera celui par lequel les clients se connecteront au serveur SQL, il faut également définir un nom pour l’instance ainsi qu’un nom pour l’ID de l’instance.

Le processus d’installation nous informe de l’espace disque requis. Nous cliquons sur « Next ».

Nous sélectionnons la ressource cluster qui vient d’être créer. Nous pouvons remarquer qu’elle porte le nom de l’ID que nous venons de créer. Nous cliquons sur « Next » pour passer à la fenêtre suivante.

Il nous faut choisir les disques qui seront attribués à notre ressource cluster SQL. Nous choisissons les disques 3, 4 et 5 qui correspondent respectivement à Data, Logs et Backup. Nous pouvons cliquer sur « Next ».

En ce référant à notre préparation nous attribuons l’adresse IP à notre serveur SQL, puis cliquons sur « Next ».

Le processus d’installation nous demande quel mécanisme de sécurité nous voulons utiliser pour installer les services de notre ressource cluster. Nous laissons la valeur définie par défaut. Le service SIDs permet d’attribuer de manière automatique certains droits à un service pour qu’il puisse accéder à certains objets sans lui spécifier un compte qui bénéficie de hauts privilèges. Après cela nous cliquons sur « Next ».

Nous indiquons les comptes de service que nous avons créés.

Pour « SQL Full-Text Filter Deamon Launcher » et « SQL Server Browser » SQL Server utilisent le compte « NT AUTHORITY\ LOCAL SERVICE ».

Nous cliquons ensuite sur l’onglet « Collation ».

L’onglet « collation » nous permets de définir quelles sont les règles qui seront appliquée pour trier et comparer les données. Les paramètres nous convenant, nous ne changeons pas la configuration et cliquons sur « Next ».

Nous devons spécifier le compte d’administration SQL. Nous optons pour « Mixed Mode ». Cela nous active le compte d’administration SQL qui a pour login « SA », nous lui attribuons un mot de passe et ajoutons également le compte adminclusql01comme administrateur SQL.

Ensuite nous cliquons sur l’onglet « Data directories » pour indiquer le chemin des différents objets.

Les data devront être dans le disque G:\ les logs dans le disque H:\ et les backups dans le disque I:\

Nous n’avons pas besoin de stocker des data non structurées de type bureautique, multimédia, etc. nous n’avons donc pas besoins d’activer et de paramétrer les options « FILESTREAM ». Nous passons à l’étape suivante en cliquant sur « Next ».

Nous choisissons de participer aux programmes d’amélioration de SQL en envoyant nos rapports d’erreurs et des informations d’usage des composants. Ceci est bien entendu optionnel. Nous cliquons ensuite sur « Next ».

Le processus lance une dernière phase avant d’afficher le résumé de nos paramètres. Notre configuration est bonne nous pouvons cliquer sur « Next ».

Un résumé de nos paramètres est affiché. Il nous reste plus qu’à les vérifier et à cliquer sur « Install ».

L’installation est en cours.

Une fois l’installation terminée, nous avons un résumé sur le déroulement de l’installation.

La dernière fenêtre du Wizard s’affiche et nous indique où les logs de l’installation sont stockés. Nous pouvons cliquer sur « Close » pour sortir du Wizard.

5.8 Installation de SQL Serveur sur le nœud B

Une fois le nœud A installé, nous pouvons ajouter le nœud B au cluster. Nous nous connectons sur le nœud B et lançons le setup. Nous allons dans la section « Installation » et cliquons sur « Add node to a SQL Server failover cluster ».

1. Comme pour l’installation du nœud A, une phase de vérification est exécutée.

2. Nous rentrons la clé de licence.

3. Nous acceptons les termes de la licence.

4. Nous installons la librairie requise par SQL

5. Une deuxième phase de vérification est lancée. Nous avons toujours le même « Warning » puisque le nœud B n’a pas d’accès à Internet. Une fois la vérification terminée nous cliquons sur « Next ».

6. Nous choisissons la ressource cluster correspondant à notre serveur SQL et cliquons sur « Next ».

7. Nous indiquons les mots de passe des comptes que nous avons renseigné lors du paramétrage du nœud A et cliquons sur « Next ».

8. Comme pour la configuration du nœud A, nous choisissons de participer au programme d’amélioration de SQL Serveur, puis cliquons sur « Next ».

9. Une dernière vérification est lancée avant d’afficher le résumé. Aucun problème nous est remonté nous cliquons sur « Next ».

10. Apres lecture du résumé nous cliquons sur « Install » pour ajoutons le nœud B au cluster.

11. L’installation se déroule.

12. L’installation est terminée. Nous constatons qu’elle s’est déroulée correctement.

13. La dernière fenêtre du « Wizard » s’affiche, le chemin des logs de l’installation est indiqué. Nous quittons le Wizard en cliquant sur Close.

5.9 Vérification de l’installation

Dans la section « Services and applications » nous pouvons voir que notre ressource est bien créée et active. Nous voyons également qu’elle est sur le nœud A et que les disques utilisés sont bien le 3,4 et 5.

Connexion à la base

6.1 Connexion sur le cluster. Nœud A actif, Nœud B passif.

Comme nous l’avons vu dans la fenêtre ci-dessus le cluster et le ressource sont actifs sur le nœud A.

Nous allons tenter une connexion à la base depuis un poste du réseau, SRVSTOCK01, nous lançons management studio et nous nous connectons avec le compte d’administration SA.

La connexion s’est bien déroulée ; nous exécutons une requête sur une table installée par défaut.

La requête s’est bien déroulée et le serveur nous affiche une réponse.

6.2 Connexion sur le cluster. Nœud B actif, Nœud A passif.

Maintenant nous allons mettre délibérément hors ligne le nœud A et faire un autre test de requête.

Les ressources ont bien basculées sur le nœud B.

Depuis SRVSTOCK01 nous tentons une nouvelle connexion.

La connexion s’est bien déroulée, et nous exécutons la requête. Le résultat est également positif.

Conclusion

Grâce au composant Failover Clustering amélioré sous Windows Server 2008, les entreprises bénéficie d’une solution efficace et fiable pour répondre à leurs besoins de haute disponibilité.

Facile à mettre en place, cette solution en cluster pourrait s’avéré un être un investissement judicieux pour les entreprises soucieuses de pérenniser leurs environnement critiques qui s’appuient sur SQL serveur.