Groupes de disponibilité Always On

Principe

Dans de nombreux cas d’installation de serveurs, il est nécessaire de prévoir des solutions de secours en cas de panne matérielle afin d’assurer la continuité de service. De nombreuses solutions existent tant au niveau architecture que système.

Avec SQL Server, plusieurs solutions sont proposées :

La première de ces solutions se paramètre au niveau des instances SQL Server, mais du fait de la nécessité d’un stockage partagé, elle peut s’avérer d’un coût plus élevé.

Les deux autres solutions se paramètrent au niveau de chaque base de données. Celles-ci, bien que toujours présentes, sont remplacées par les groupes...

Installation du service de cluster Windows

L’architecture minimale pour installer les groupes de disponibilité de SQL Server est un contrôleur de domaine Windows et deux serveurs membres du domaine avec SQL Server installé.

Tous les serveurs SQL Server qui feront partie du cluster doivent être identiques du point de vue matériel et logiciel. Les bases de données, qui feront partie des groupes de disponibilité, étant présentes sur chaque serveur, il faut s’assurer d’avoir l’espace disque nécessaire sur chacun d’entre eux. Chacun des serveurs doit également disposer obligatoirement d’une passerelle par défaut (même si aucun accès en dehors de son réseau n’est nécessaire).

La fonctionnalité Clustering de basculement de Windows peut ensuite être installée sur chacun des serveurs SQL Server.

Ensuite, il faut créer le cluster. Pour cela, à partir de la console Gestionnaire du cluster de basculement dans les outils d’administration de Windows, il faut lancer l’assistant de création du cluster et y indiquer le nom des serveurs le constituant :

Puis valider tous les tests de configuration.

À la fin de l’assistant, si les tests sont concluants, même s’il y a des warnings, le cluster est créé. Il est quand même souhaitable...

Paramétrage de l’instance SQL Server et des bases de données

Le service de cluster installé et paramétré, il faut maintenant paramétrer SQL Server pour pouvoir l’utiliser.

La fonctionnalité de cluster de Windows étant basée sur un domaine, les comptes de service pour SQL Server devront obligatoirement être des comptes de domaine (cf. chapitre Installation et configuration - Installation de SQL Server).

Il est maintenant possible d’activer chaque instance SQL Server pour l’utilisation des groupes de disponibilité. Pour cela, dans la console Gestionnaire de configuration SQL Server, dans les Propriétés de l’instance SQL Server, il faut cocher la case Activer les groupes de disponibilité Always On.

Un redémarrage du service SQL Server est ensuite nécessaire.

Plusieurs bases de données peuvent appartenir au même groupe de disponibilité. Le fonctionnement de la mise à jour des différents nœuds du groupe est basé sur l’utilisation du journal des transactions de ces bases. C’est pourquoi celles-ci doivent absolument être en mode de récupération complet et nécessiteront donc des sauvegardes du journal des transactions régulières (cf. chapitre Sauvegarde - Mise en œuvre des sauvegardes).

Une sauvegarde complète des bases de données...

Création d’un groupe de disponibilité

La création du groupe de disponibilité peut se faire de trois façons différentes :

Cette opération étant ponctuelle, le plus simple est de l’effectuer graphiquement dans SQL Server Management Studio en ayant pris soin au préalable de se connecter sur tous les serveurs SQL concernés par l’opération :

Un nom de groupe sera demandé.

Il faut sélectionner au moins une base de données répondant aux prérequis (des bases supplémentaires peuvent être ajoutées par la suite).

Il faut sélectionner les serveurs devant faire partie du groupe (des serveurs supplémentaires peuvent être ajoutés par la suite) en indiquant s’ils feront des mises à jour synchrones ou asynchrones et s’ils participent à la bascule automatique en cas de panne d’un nœud du cluster.

Une dernière option permet d’indiquer si le réplica secondaire accepte les accès en lecture seule. Ceci nécessitera, du côté du client, d’indiquer "read only" dans la chaîne de connexion utilisée.

Dans l’onglet Préférences...

Connexion à un groupe de disponibilité

La connexion au serveur SQL Server s’effectue comme pour n’importe quel autre serveur, que ce soit via SQL Server Management Studio ou une autre application utilisant une chaîne de connexion. Il faudra juste indiquer, pour le nom du serveur, le nom DNS indiqué pendant la création du groupe de disponibilité. En effet, ne sachant pas quel nœud du cluster gère le groupe de disponibilité, l’utilisation du nom réel d’un des serveurs peut connecter l’application cliente sur un nœud secondaire et ainsi ne pas avoir accès à la base de données souhaitée en lecture/écriture.

Si le nœud principal tombe, le service de cluster de Windows bascule automatiquement un des nœuds secondaires en tant que principal. Ainsi, pour l’utilisateur, il n’y a quasiment pas d’interruption de service (si ce n’est une coupure de connexion au moment de la panne et pendant la bascule qui dure quelques secondes). Il lui suffira éventuellement de relancer l’action qu’il était en train de faire avant la venue de la panne.

Pour simplifier la gestion des droits d’accès sur les bases de données faisant partie du groupe de disponibilité, il est préférable de ne pas utiliser de compte de connexion, mais plutôt des utilisateurs...

Use LivreTSQL; 
go 
Sp_configure 'contained database authentication',1 
Reconfigure