Installation d’un Groupe de Disponibilité avec SQL Server 2012 – Partie 5
Cet article fait partie d’une série dont vous trouverez le sommaire ici : https://blogs.technet.com/b/sql/archive/2011/09/08/installation-d-un-groupe-de-disponibilit-233-avec-denali-introduction.aspx
Test et validation du fonctionnement d’un Groupe de Disponibilité AlwaysOn
Une fois que nous avons fini de construire notre cluster Denali 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é :
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 : https://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 Denali:
· 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 : https://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.
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, nom de code Denali.
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.
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 (Anciennement Denali) 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 – nom de code Denali, vous pouvez consulter les documents de référence :
- Les livres en ligne : https://technet.microsoft.com/en-us/library/ms130214(SQL.110).aspx
- Le guide produit : https://www.microsoft.com/download/en/details.aspx?id=27069
- Le site technique sur SQL en Français : https://technet.microsoft.com/fr-fr/sqlserver