Blog ENI : Toute la veille numérique !
-25€ dès 75€ sur les livres en ligne, vidéos... avec le code FUSEE25. J'en profite !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. SQL Server 2019
  3. Groupes de disponibilité Always On
Extrait - SQL Server 2019 Apprendre à administrer une base de données transactionnelle avec SQL Server Management Studio
Extraits du livre
SQL Server 2019 Apprendre à administrer une base de données transactionnelle avec SQL Server Management Studio
4 avis
Revenir à la page d'achat du livre

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 :

  • Installation de l’instance SQL Server en cluster (nécessite un stockage partagé entre les instances SQL Server pour le stockage des fichiers de bases de données).

  • Mise en miroir de bases de données : permet d’avoir une mise à jour de l’instance secondaire de manière synchrone et avec bascule automatique si trois instances SQL Server sont présentes (fonctionnalité dépréciée).

  • Log Shipping (transmission de journaux de transactions) : permet d’avoir plusieurs instances de serveurs secondaires éventuellement accessibles en lecture seule, mais uniquement avec mise à jour asynchrone.

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.

images/11ri01.PNG

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 :

images/11ri02.png

Puis valider tous les tests de configuration.

images/11ri03.png

À 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.

images/11RI11.png

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 :

  • Graphiquement avec SQL Server Management Studio, en lançant l’assistant Nouveau groupe de disponibilité :

  • Avec Transact SQL (T-SQL).

  • Avec PowerShell.

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 :

images/11ri12.png

Un nom de groupe sera demandé.

images/11ri13.png

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).

images/11ri14.png

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.

images/11ri15.png

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...

Exercice : créer un accès à une base dans un groupe de disponibilité

1. Énoncé

La base LivreTSQL va être intégrée à un groupe de disponibilité. Il faut donc la préparer pour cela et créer un compte utilisateur SQL permettant un accès complet à l’aide de l’interface graphique.

2. Corrigé

La base doit permettre l’utilisation des comptes utilisateurs sans compte de connexion. Il faut donc activer cette fonction sur le serveur et la base de données. Cette dernière doit également être en mode de récupération complet :

Use LivreTSQL; 
go 
Sp_configure 'contained database authentication',1 
Reconfigure 
images/11ri22.png

Il reste à créer le compte utilisateur de base de données de type Utilisateur SQL avec mot de passe.

images/11ri23.png

Puis il faut le rendre membre du rôle db_owner :

images/11ri24.png