Embed Size (px)
Citation preview
1
Article Technique – Microsoft France - Septembre 2011
La prochaine version de SQL Server, SQL Server 2012, apporte de nombreuses nouvelles fonctionnalités, l'une d'entre
elle étant la capacité à délivrer un service de haute disponibilité appelé "AlwaysOn". Derrière ce nom se cache le
rapprochement de deux technologies existantes avec SQL Server 2008 R2 : Le cluster pour les solutions de haute
disponibilité et le miroir de bases pour la réplication de données. Ces solutions, qui sont toujours disponibles avec
SQL Server 2012, mais ne permettent pas d'exploiter le matériel de secours.
AlwaysOn, solution qui vient en complément des autres technologies, apporte non seulement la capacité à répliquer
les données entre plusieurs nœuds d'un même cluster potentiellement répartis sur plusieurs subnets mais aussi la
possibilité de grouper plusieurs bases de données au sein d'un même objet qui maintiendra la cohésion du groupe
lors d'une bascule. Pour permettre de tirer le meilleur partit des ressources utilisées par une telle architecture,
AlwaysOn permet aussi d'accéder aux bases de données répliquées en lecture, par exemple pour pouvoir effectuer
des backups ou des rapports.
Dans ce document nous allons voir pas à pas comment mettre en œuvre un cluster AlwaysOn à deux nœuds.
Installation d’un groupe de disponibilité avec
SQL Server 2012 AlwaysOn (CTP3)
qsjdlkqjs
Subtitle here
2
Architecture, prérequis et création du cluster Windows
Le but de cet article est de vous guider pas à pas dans la mise en œuvre d'un cluster HADR (ou AlwaysOn) sur une
maquette. Vous pouvez adopter la même configuration ou l'adopter à votre environnement.
Le minimum requis pour monter une infrastructure "Always On" est:
Un domaine AD (sqldemo.com) qui est hébergé dans notre environnement sur le serveur SQL-DC.
Deux serveurs classiques tournant sous Windows 2008 R2 : SQL-SRV-1 et SQL-SRV-2 qui seront utilisés pour
créer le cluster HADR.
Une baie de disque partagée ou une target iSCSI n'est pas nécessaire pour installer un cluster SQL Server 2012 de
type AlwaysOn. Nous reviendrons sur ce sujet dans la configuration du cluster.
SQL-DC10.10.10.1
512 Mo
SQL-SRV-110.10.10.11
2 Go
SQL-SRV-210.10.10.12
2 Go
La configuration mémoire des machines est suffisante pour monter une maquette et doit absolument être adaptée
dans le cas d'une mise en production ou de la réalisation d'un prototype.
Prérequis logiciel
Les deux serveurs SQL-SRV-1 et SQL-SRV-2 indiqués ci-dessus doivent être membre du domaine sqldemo.com et
respecter les prérequis nécessaire à l'installation de SQL Server 2012, à savoir :
Windows Powershell 2.0 (installé par défaut avec Windows 2008 R2)
Le Framework .Net 3.51 (via le Add Features de Windows 2008 R2)
Windows Failover Clustering (via le Add Features de Windows 2008 R2)
Dans le cadre de notre maquette les serveurs tournent avec Windows 2008 R2 x64 SP1 et sont à jour en termes de
correctifs de sécurité mais Windows 2008 SP2 est aussi supporté.
3
Pour plus de détails sur les prérequis sur l'installation de SQL Server 2012, vous pouvez consulter la page suivante :
http://msdn.microsoft.com/fr-fr/library/ms143506(SQL.110).aspx
Nous allons pouvoir créer le cluster Windows qui sera utilisé comme fondation pour la construction du cluster SQL
AlwaysOn.
Création du cluster Windows
Comme nous avons installé la fonctionnalité "Failover Clustering" avec les pré-requis, nous pouvons lancer le
"Failover Cluster Manager" dans la liste des outils d'administration.
Il faut créer un cluster Windows :
Sélectionnez les serveurs membre du domaine qui seront les différents nœuds du cluster SQL Server 2012.
Donnez ensuite un nom à votre cluster et une adresse IP. Si les deux nœuds du cluster sont sur des subnets
différents, il faudra donner une adresse IP par subnet. Il est aussi possible de laisser le cluster en client DHCP si votre
configuration réseau le permet.
4
Vérifiez bien la configuration de votre cluster avant de valider la création du cluster.
L'assistant se termine mais remonte une alerte à la fin indiquant que notre cluster n'est pas viable. Avec uniquement
deux éléments pour voter en cas d'incident sur le cluster, il n'est pas possible d'atteindre une majorité de vote qui
5
permet de décider quel nœud prend la main. Nous allons voire dans le paragraphe suivant comment créer un cluster
viable.
Choix du modèle de quorum
L'assistant de création du cluster a créé un cluster ou les seuls votant possibles sont les nœuds SQL-SRV-1 et SQL-
SRV-2. Dans cette configuration, il n'est pas possible d'avoir une majorité de votant, au mieux chacun aura la moitié
des votes et aucune décision ne pourra être prise quant à la possession du cluster. Il faut donc un troisième votant,
c'est le modèle de quorum qui va nous permettre de choisir qui est ce troisième votant.
Il est alors possible de choisir le modèle de quorum souhaité. :
Dans le cas d'une configuration avec un disque partagé, l'option par défaut ("Node and Disk Majority") convient
parfaitement, en plus des deux nœuds, l'accès en lecture / écriture sur le disque partagé donne le vote manquant.
6
Dans notre maquette, sans disque partagé, nous choisissons la troisième option : "Node and File Share Majority" (si
vous avez pris l'initiative de monter un cluster à trois nœuds, restez avec le modèle "Node Majority").
Ce choix d'architecture présente les avantages suivants :
Coûts réduits
Adhérence limitée entre les serveurs et le matériel de stockage
Facilité de mise en œuvre
Capacité à supporter des clusters dispersés géographiquement
Pour plus d'informations sur les modèles de quorum, vous pouvez consulter les articles suivant de la documentation :
http://technet.microsoft.com/en-us/library/cc731739.aspx
http://msdn.microsoft.com/en-us/library/hh270280(SQL.110).aspx
http://msdn.microsoft.com/en-us/library/ff929171(SQL.110).aspx
Il reste à indiquer le partage de fichier qui servira de témoin pour le cluster.
Pour notre maquette, j'ai créé un partage (FSW) sur le contrôleur de domaine (SQL-DC).
Attention : Penser à donner les droits d'écriture sur le répertoire qui sera partagé pour les nœuds membres du
cluster. Dans le cas d'une maquette, vous pouvez simplifier l'opération en utilisant le groupe "Domain Computers".
7
Le cluster que nous venons de créer et configurer ne possède aucune ressource ni services, il peut être comparé à
une coquille vide qui servira de base à l'installation de SQL Server 2012 en mode HADR.
Nous allons pouvoir procéder à l'installation de SQL Server 2012 à proprement parler.
Installation de SQL Server sur chaque nœud
Une fois le cluster Windows configuré et vérifié, nous allons procéder à l'installation des binaires de SQL Server. Cette
opération doit être effectuée sur tous les serveurs qui seront membres du cluster AlwaysOn. Dans notre cas, il s'agit
des serveurs SQL-SRV-1 et SQL-SRV-2.
L'installation ci-dessous a été effectuée avec la CTP 3 de SQL Server 2012, les captures d'écran peuvent évoluer avec les
prochaines versions du produit.
Passons directement dans le deuxième onglet "Installation" pour lancer le setup.
Attention: Notez que c'est la première option qui est choisie ! L'installation d'un cluster SQL en mode HADR
nécessite une installation en mode standalone et non en mode cluster. La deuxième option consiste à installer un
cluster à bascule classique avec une base de données sur une baie de disque partagée.
L'assistant d'installation vérifie si les prérequis à l'installation de SQL Server 2012 sont remplis.
Avec la CTP3, vous n'avez pas besoin de clef de produit, choisissez l'option "Evaluation".
8
Acceptez le contrat de licence puis laissez le système chercher les mises à jour sur Internet.
Si vous avez accès à Internet, le système téléchargera les mises à jour automatiquement pendant le processus
d'installation.
9
Si vous n'avez pas accès à Internet, il faudra:
1. Télécharger la mise à jour depuis le catalogue Microsoft Update (KB2580208) :
http://catalog.update.microsoft.com
2. Relancer le setup de SQL Server 2012 en précisant le répertoire où trouver les mises à jour avec le paramètre
/UpdateSource=<repertoire_updates>.
Vous trouverez plus d'informations sur le lancement de dans ces deux articles :
http://blogs.msdn.com/b/petersad/archive/2011/07/13/product-update-in-sql-server-code-named-denali.aspx
http://blogs.msdn.com/b/petersad/archive/2011/07/13/provide-feedback-on-the-sql-server-code-name-denali-
product-update-feature.aspx
Nous pouvons continuer l'installation du setup de SQL :
Notez l'alerte concernant la présence du parefeu. Pensez à le reconfigurer en accord avec les recommandations
indiquées :
10
Nous pouvons maintenant passer à l'installation de SQL à proprement parler. L'option à sélectionner est "SQL Server
Feature Installation".
Dans le cas de notre maquette, nous allons choisir d'installer seulement les fonctionnalités nécessaires pour
démontrer la fonctionnalité HADR de SQL, à savoir :
Le moteur de base de données : Database Engine Services
Les outils d'administration : Management Tools
Pour le troubleshooting : Client Tools Connectivity
La sélection de fonctionnalités donne donc le résultat suivant :
11
Passez sur l'écran "Installation Rules" pour aller sur l'écran de configuration de l'instance :
Pour des raisons de simplicité de compréhension, j'ai choisi d'utiliser des instances nommées :
DENALI1 sur SQL-SRV-1
DENALI2 sur SQL-SRV-2
Vous pouvez utiliser l'instance par défaut si vous le souhaitez mais cela peut rendre l'analyse en cas de problème
plus compliquée.
Vérifiez que votre serveur possède assez d'espace disque :
12
Indiquez ensuite les comptes de service à utiliser.
Dans le but de simplifier la mise en œuvre de cette maquette, nous allons utiliser un compte de service du domaine
pour faire tourner le service serveur de SQL Server 2012. L'utilisation d'un compte du domaine sera utile lors de la
création avec l'assistant du groupe de disponibilité (Availability Group) permettant la mise en haute disponibilité d'un
groupement de bases.
Vous trouverez quelques informations supplémentaires sur ce sujet dans le paragraphe "Using the New Availability
Group Wizard" sur cette page : http://technet.microsoft.com/en-us/library/ff878176(SQL.110).aspx#SSMSProcedure
Pour des raisons de compréhension, j'ai utilisé un compte de service différent pour chaque nœud du cluster.
Lors de la configuration du moteur de base de données, pensez à bien ajouter votre compte comme administrateur.
13
Validez les étapes suivantes de la procédure d'installation jusqu'à la page "Ready to Install" :
En bas de la fenêtre le fichier .ini indiqué est un fichier qui contient une copie de la configuration établie avec
l'assistant. Il est possible de réutiliser ce fichier dans une autre installation de SQL Server 2012. Par exemple pour
l'installation du second nœud de notre cluster.
Une fois l'installation terminée, voici le résultat obtenu :
14
Il faut suivre la même procédure pour configurer SQL-SVR-2 ou plus généralement tout nœud qui ferait partie du
cluster.
Pour le moment, nous avons simplement installé SQL en mode autonome sur un serveur qui est membre d'un cluster
Windows à bascule (Windows Failover Cluster). Il faut maintenant configurer cette instance pour qu'elle supporte les
groupes de disponibilité de type AlwaysOn.
Lancer "SQL Server Configuration Manager"
Aller dans les propriétés du service "SQL Server (NOM_INSTANCE)" et cocher la case "Enable AlwaysOn Availability
Group"
Les changements effectués ne seront pris en compte qu'une fois le service redémarré.
15
Vous pouvez vérifier si la configuration a bien été prise en compte en interrogeant la propriété SERVERPROPERTY en
Transact-SQL:
Pour plus d'informations sur ce point, vous pouvez consulter l'article suivant de la documentation en ligne :
http://msdn.microsoft.com/en-us/library/ff878259(SQL.110).aspx
Il est maintenant possible de créer un groupe de disponibilité et d'y monter une ou plusieurs bases de données.
Création du Groupe de Disponibilité (Availability Group)
Qu'est-ce qu'un « Availability Group » ?
Comme nous l'avons vu en introduction, l'Availability Group permet de répondre aux besoins suivants :
La solution permet d'assurer une bascule simultanée de toutes les bases de données du groupe en cas
d'incident. Cette approche permet de répondre aux besoins de disponibilité des applications qui accèdent à
plusieurs bases de données en même temps sans avoir à mettre en œuvre des contournements complexes.
Répliquer les données sur plusieurs instances (le maximum étant 5 copies au total) tout en permettant aux
applications d'y accéder via un nom virtuel unique sans avoir besoin de solution de réplication matérielle.
Accéder aux copies répliquées en mode lecture seule pour permettre de décharger l'instance principale de la
charge générée par exemple par les sauvegardes ou les rapports.
Solution de cluster dispersé géographiquement purement à base de logiciel.
Cette solution de disponibilité peut être vue comme une combinaison des bons côtés du mirroring et du cluster à
bascule que nous connaissions avec SQL 2008 R2.
Avant de créer à proprement parler le groupe de disponibilité, il faut monter une base de données sur l'un des deux
serveurs SQL. Prenons par exemple la base de données d'exemple AdventureWorks disponible en téléchargement
pour SQL Server 2012 à cette adresse : http://msftdbprodsamples.codeplex.com/releases/view/55330
La procédure pour remonter les bases de données est disponible à cette adresse :
http://social.technet.microsoft.com/wiki/contents/articles/sql-server-samples-readme.aspx
Création du Groupe de Disponibilité
La création et configuration de l'Availability Group se fait dans SSMS (SQL Server Management Studio). Si la
fonctionnalité a bien été activée comme indiquée à l'étape précédente, le conteneur "Availability Group" apparait
dans SSMS sous le conteneur "Management".
16
Il est possible de lancer l'assistant de création d'un Availability Group (AG).
Donnez un nom au groupe de disponibilité, par exemple, dans notre cas : AdventureWorksAG et cliquez sur
Suivant.
Il est alors possible de choisir la ou les bases de données qui feront partie de l'Availability Group que nous sommes
en train de créer. Si vous choisissez plusieurs bases de données, toutes ces bases basculeront en même temps.
Pour notre maquette, nous choisirons uniquement la base "AdventureWorksDW". Vérifiez que le status indique
bien "Meets prerequisites".
17
Indiquez ensuite les instances SQL qui ont été activée pour supporter AlwaysOn qui possèderont une copie de la
base de données. Par défaut l'instance sur laquelle SSMS est connecté est ajouté à la liste des réplicas.
Ajoutez le server SQL-SRV-2 à la liste des réplicas possibles de la base AdventureWorksDW.
Note: Il faut démarrer le service "SQL Server Browser" si ce n'est déjà fait et mettre le service en démarrage
automatique pour le bon fonctionnement du cluster HADR.
18
Il est possible de modifier le mode du réplica pour passer du mode 'Automatic failover' (mode proposé par défaut)
aux modes 'High performance' (commit asynchrone et bascule forcée avec potentielle perte de données) ou 'High
safety' (bascule manuelle seulement). Nous laisserons le mode 'Automatic failover'.
Le 'Connection Mode in Secondary role' est plus intéressant. C'est ce paramètre qui autorise ou non les connexions
sur la copie de la base de données. Par exemple si vous avez une application de génération de rapport, vous pouvez
décharger l'instance primaire, utiliser ses ressources pour servir au mieux les clients et utiliser les ressources de
l'instance secondaire pour servir les fonctionnalités de reporting. Les modes autorisés sont :
Disallow connections : Aucune connexion n'est autorisée sur l'instance si elle est en mode secondaire. Par
exemple, dans le cas où la latence de réplication n'est pas permise.
Allow only read-intent connections : Seulement les applications qui indiquent dans la chaine de connexion le
mode 'read-intent' pourront se connecter à cette instance en mode secondaire.
Allow all connections : Toute application peut se connecter à l'instance, peu importe la chaine de connexion
mais seulement des opérations de lecture seront possibles sur la base.
Pour les besoins de notre maquette nous allons prendre le dernier mode : "Allow all connections".
Dans l'étape suivant nous allons renseigner le nom réseau du Groupe de Disponibilité. C'est ce nom virtuel qui sera
utilisé ensuite par les clients pour se connecter à la(les) base(s) du groupe. Ce nom est appelé un Listener.
Vous pouvez choisir l'option client DHCP dans le cas où vous avez un serveur DHCP sur le réseau. Cette option est
particulièrement intéressante dans le cas de cluster répartit sur plusieurs subnets. Lors de la bascule d'un nœud à
l'autre, le cluster prendra une IP du subnet où il se trouve.
Dans le cas où vous voudriez ajouter une IP manuellement, sélectionnez l'option "Skip". Vous ajouterez un Listener
manuellement depuis SQL Server Management Studio (SSMS) une fois le groupe de disponibilité créé.
Il est aussi possible lors de cette étape de changer le port d'écoute. Pour notre maquette, nous laisserons le port par
défaut.
19
Pour le moment la base de données est sur le serveur SQL-SRV-1. La mise en œuvre du Groupe de Disponibilité
autorise plusieurs modes pour la copie initiale des données vers SQL-SRV-2 :
SQL Server 2012 effectue la synchronisation initiale des données avec une mécanique de sauvegarde /
restauration automatisé. Cette opération nécessite l'utilisation d'un partage sur le réseau et peut ne pas être
appropriée dans le cas de manipulations de gros volumes de données.
Pour les scénarios manipulant des gros volumes de données ou dans le cas où une copie existe déjà sur la ou
les instances cible, le système laisse la main au DBA pour mettre les copies en place. Dans ce cas, le système
ne procède pas à la synchronisation initiale.
Dans le cas de notre maquette, pour des raisons de simplicité, nous allons choisir la première option. Le partage peut
être sur n'importe quel serveur sur le réseau mais il faut qu'il soit accessible par tous les nœuds du cluster pour
pouvoir procéder à la restauration des données.
20
La configuration du groupe de disponibilité est maintenant terminée. Laissez l'assistant vérifier que tout est bon.
Si vous souhaitez scripter cette opération, vous pouvez obtenir le script au moment du résumé.
Et le résultat de l'opération :
21
Il reste à vérifier que notre cluster fonctionne !
Test et validation du fonctionnement d'un Groupe de Disponibilité AlwaysOn
Une fois que nous avons fini de construire notre cluster SQL Server 2012 AlwaysOn, dans le cadre de notre maquette,
nous allons vérifier son bon fonctionnement.
Commençons par faire un état des lieux au niveau du dashboard du groupe de disponibilité dans SSMS.
Voici ce que nous voyons sur l'instance qui possède le groupe de disponibilité :
22
Le serveur SQL-SRV-1 est bien indiqué comme "primary", et SQL-SRV-2 est bien indiqué comme "Readable
Secondary". Les deux copies sont dans l'état "Synchronized".
Si on regarde le même tableau de bord en étant connecté sur SQL-SRV-2, voici ce que l'on obtient.
Ce premier indicateur est rassurant concernant l'état de santé de notre groupe de disponibilité.
Si vous préférez obtenir des informations concernant l'état de santé du groupe de disponibilité, vous pouvez utiliser
un script T-SQL disponible à cette adresse : http://msdn.microsoft.com/en-us/library/ff878305(SQL.110).aspx
Regardons maintenant si le groupe de disponibilité bascule correctement. Deux options sont possibles avec la CTP3
de SQL Server 2012:
23
Powershell
Transact-SQL
Dans les deux cas, il faut se connecter sur le nœud cible, c’est-à-dire celui qui va recevoir le groupe. En Transact-SQL
la commande est assez simple :
ALTER AVAILABILITY GROUP AdventureWorksAG FAILOVER;
Vérifiez sur le tableau de bord que le group est bien pris en main par SQL-SRV-2. Le rafraichissement du dashboard
peut prendre quelques instants alors que la bascule a déjà été effectuée.
Vous pouvez faire revenir le groupe sur le serveur SQL-SRV-1 avec une commande en Powershell. Pour cela, lancez
Powershell depuis SSMS sur SQL-SRV-1 comme ci-dessous.
Saisissez ensuite la commande suivante :
Switch-SqlAvailabilityGroup –Path SQLSERVER:\SQL\SQL-SRV-
2\DENALI2\AvailabilityGroups\AdventureWorksAG
Vous trouverez plus d'informations sur les bascules manuelles dans cette page de la documentation en ligne :
http://msdn.microsoft.com/en-us/library/hh231018(SQL.110).aspx
Le dernier point à vérifier est que les clients se connectent bien à la base pendant ces opérations. Pour cela, j'utilise
un client qui insère des lignes aléatoires dans une des tables de la base de données.
Pour le premier test la chaine de connexion pointe sur SQL-SRV-1\DENALI1, c'est l'instance qui héberge le groupe de
disponibilité que nous venons de créer.
Si je bascule le groupe vers le deuxième nœud du cluster, l'application va passer en echec comme l'indique la
capture d'écran ci-dessous.
24
Si maintenant, je change la chaine de connexion pour utiliser le nom du listener du groupe de disponibilité, à savoir
AdventureWorksAG_Listener, l'application cliente se connecter bien sur l'instance qui héberge le groupe de
disponibilité :
L'application continue à fonctionner avec une nouvelle chaine de connexion sans avoir besoin d'être reconfigurée et
bénéficie des fonctionnalités "AlwaysOn" de SQL Server 2012.
Une application de reporting indiquant un accès de type "ReadOnly" pourrait se connecter sur le nom virtuel du
groupe et serait redirigé vers le nœud secondaire et afin d'exploiter au mieux les ressources du cluster.
25
Conclusion
A travers cet article, nous avons mis en œuvre dans le cadre d'une maquette une base de données AlwaysOn en
suivant les étapes suivantes :
Création du cluster Windows et choix du quorum utilisé
Installation de SQL Server 2012 sur chacun des nœuds
Activation de la fonctionnalité AlwaysOn sur les instances SQL faisant partie du cluster
Création et configuration d'un groupe de disponibilité
Vérification du bon fonctionnement du cluster et des clients en cas de bascule
Les étapes décrites ci-dessus permettent de mettre en œuvre un cluster à des fins de test ou d'apprentissage. Dans le
cadre d'une mise en production, il est nécessaire de réfléchir à l'architecture des systèmes mis en place, de la charge
que le système devra supporter, du nombre de copies secondaires nécessaires, etc …
Si vous souhaitez en savoir plus sur SQL Server 2012, vous pouvez consulter les documents de référence :
Les livres en ligne : http://technet.microsoft.com/en-us/library/ms130214(SQL.110).aspx
Le guide produit : http://www.microsoft.com/download/en/details.aspx?id=27069
Le site technique sur SQL en Français : http://technet.microsoft.com/fr-fr/sqlserver
