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 de disponibilité qui vont cumuler les avantages des deux précédentes sans les inconvénients (en édition Entreprise uniquement) :

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 de vérifier la liste des warnings pour en corriger un maximum (par exemple, si vos serveurs ne sont reliés que par un seul réseau, il y aura un warning indiquant un point potentiel de défaillance).

Un nom DNS ainsi qu’une adresse IP, qui seront enregistrés sur le serveur DNS, vous seront demandés :

Ils serviront à se connecter à la console de gestion du service de cluster à des fins d’administration de celui-ci :...

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.

L’onglet Points de terminaison indique le nom DNS et le port (5022 par défaut) utilisé pour la communication entre les serveurs du groupe de disponibilité. Il faudra donc ouvrir ce port au niveau du pare-feu local de Windows.

Dans l’onglet Préférences de sauvegarde, il est possible d’indiquer les préférences de serveur pour les opérations de sauvegarde. Ainsi, celles-ci pourront se faire sur une instance secondaire, ce qui diminuera la charge pour l’instance...

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 de bases de données SQL avec mot de passe ou utilisateur Windows (cf. chapitre Gestion de la sécurité des accès - Gestion des utilisateurs de base de données). Ainsi, que la base de données soit gérée par l’un ou l’autre des nœuds du cluster, son fonctionnement est identique et il n’y a pas à dupliquer de compte de connexion d’un serveur à l’autre. Par contre, n’utilisant...

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