Denali – Groupe de disponibilité

Début janvier 2011, lors de la partition de la première CTP de Denali (SQL11), j’avais écrit un billet concernant la mise en place de groupes de disponibilité, ou “availability groups”. La CTP1 ne permettait pas d’aller au delà de deux réplicas (un primaire et un secondaire), et était limité au mode synchrone.

Ce tutorial présente les grandes lignes de l’installation d’un cluster 4 nœuds avec groupe de disponibilité. Ce que l’on retrouve sous l’appellation “AlwaysOn SQL Server Availability Groups”. Pour plus d’informations, n’hésitez pas à me contacter.

La notion de AlwaysOn reprend les thématiques de haute disponibilité, avec les groupes de disponibilité et de cluster de basculement.

La sortie de la CTP3 se rapproche enfin des fonctionnalités promises, à savoir :

  • 1 réplica primaire
  • 4 réplicas secondaires
  • Sur ces 5 réplicas, deux au maximum sont en mode basculement automatique (le primaire et un seul secondaire)
  • Sur ces 5 réplicas, trois seulement peuvent être en mode synchrone ( le primaire et deux secondaires).

La liste des failover modes est disponible ici.

Commençons par installer 4 serveurs, et créons un cluster, au sens Windows Failover Cluster. Il n’y a pas nécessité de posséder un stockage partagé pour les groupes de disponibilité. Le quorum pour le failover cluster sera assuré par un FileShare Witness.

image_thumb2image_thumb3image_thumb4image_thumb5imageimageimageimageimageimageimageimageimageimageimageimage

Les Warnings sont simplement dus au fait que l’assistant n’a pas trouvé de disques partagé pour constituer un disque quorum. Sachant qu’il y a 4 nœuds, 1 vote par nœud, il faut donc un vote supplémentaire pour avoir la majorité. Ce vote va être assuré par un répertoire partagé, ou FileShare Witness.

imageimageimageimageimageimage

Je ne vais pas revenir ici sur l’installation des instances SQL qui ne diffère en rien de l’installation d’une instance “classique”. Je vous renvoie donc à l’article qui traite de l’installation de SQL Server Denali.

Sur chaque nœud du cluster, il faut à présent activer la fonctionnalité AlwaysOn High Availability (précédemment SQL HADR) :

imageimageimage

Ensuite, afin de pouvoir ajouter plus de deux réplicas, il faut activer le flag 9532.

imageimage

image

Pour que ces options soient prises en compte, il faut redémarrer le service SQL (sur chaque nœud).

Il est possible de vérifier que l’option a bien été prise en compte en ouvrant le fichier errorlog

image

Il est temps de créer un groupe de disponibilité (les bases doivent être en mode de récupération complet et avoir été sauvegardées).

imageimageimageimageimageimageimageimageimageimage

image

image

Dans cette CTP, le point d’accès client est enfin créé par l’assistant, ce qui va faciliter la vie des DBA qui n’ont pas forcément les compétences cluster. Ce point d’accès (un nom DNS et une adresse IP) permet d’accéder aux bases du groupe de disponibilité quelle que soit le nœud hébergeant le réplica primaire. Les bases sont toujours accessibles à la même adresse IP (virtuelle).

Ainsi, on évite des problèmes éventuels de logiciels dont on ne pourrait pas modifier la chaines de connexion pour ajouter un FAILOVER_PARTNER comme dans le database mirroring.

Pour ceux qui avaient été confronté au problème, lorsqu’une base en miroir basculait sur l’instance secondaires, si cette base faisait l’objet d’un serveur liée, celui ci devenait inopérant, même si un alias DNS était créé. SQL Server gardait en cache l’instance principale.

Vous pouvez tester le failover automatique es stoppant l’instance primaire ou bien en faisant un basculement manuel. Il faut alors se connecter sur l’instance que l’on souhaite voir devenir réplica primaire et cliquer sur Fail Over.

image

D’autres options sont accessibles via script uniquement afin de gérer plus finement les conditions de basculement. Je détaillerais cela dans un prochain billet.

Pourquoi utiliser les groupes de disponibilité ?

Probablement parce que cela permet de combiner les avantages du cluster, du database mirroring et de la réplication … Et plus encore.

Dans cet exemple, Denali1 et Denali2 sont des réplicas synchrones avec basculement automatique, ce qui fournit de la haute disponibilité. Denali3 est lui aussi synchrone, on pourrait tout a fait imaginer brancher des requêtes de reporting sur cette instance et dédier le réplica asynchrone pour les sauvegardes … Oui oui, tous les réplicas secondaires peuvent être accessibles en lecture seule, en permanence sans avoir a créer de database snapshot. On peut même imaginer réaliser les backups full sur un réplica secondaire synchrone et tous els backup log sur le réplica primaire … Cela fonctionnerais aussi …

Je pense que je reviendrais sur de tels scénarios plus tard … A suivre.

A propos Christophe

Consultant SQL Server Formateur certifié Microsoft MVP SQL Server MCM SQL Server 2008
Cet article, publié dans SQL Server, est tagué , , , , . Ajoutez ce permalien à vos favoris.

3 commentaires pour Denali – Groupe de disponibilité

  1. Ping : Denali – Ajout d’un nœud à un Groupes de disponibilité | Christophe LAPORTE – Consultant SQL Server

  2. Ping : Denali – plusieurs groupes de disponibilité | Christophe LAPORTE – Consultant SQL Server

  3. Ping : Groupes de disponibilité et disaster recovery | Christophe LAPORTE – Consultant SQL Server

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s