SQL Server Denali – “Availability Group”

Je vous avais promis un petit tutorial pour mettre en œuvre une nouvelle fonctionnalité de Denali (SQL11) : les groupes de disponibilité, ou “Availability Group”.

SQL Server 2005 SP1 (oui, bon OK c’était présent dans la RTM mais il fallait activer un tarceflag) a introduit la mise en miroir d’une base de donnée. Ce database mirroring permettait en effet d’avoir un (et un seul) réplica de la base de donnée qui pouvait suppléer la base principale en cas de panne sur le serveur. cette solution offrait ainsi la haute disponibilité, granularité base de données, sans avoir recours à du cluster, avec éventuellement basculement automatique.

Le database mirroring fonctionne soit en mode haute sécurité (toute transaction doit être validée sur le serveur principal et sur le serveur miroir avant de rendre la main au client) ou bien en mode haute performance (la “réplication” se faisant alors en mode asynchrone, mais du coup il y a possibilité de perte d’information, mais pas besoin d’attendre le commit sur le serveur en miroir pour rendre la main au client).

Il était aussi possible de créer une base de capture instantanée sur le serveur en miroir afin d’accéder aux données en lecture seule et ainsi bénéficier de la puissance d’un serveur supplémentaire (RAM, CPU, TempDB) pour faire du reporting sur des bases en lecture seule.

Malheureusement, cette technologie ne permet pas d’avoir plusieurs réplicas, ni d’”automatiser” facilement la génération de snapshot à intervalles réguliers pour bénéficier de données “à jour”.

Lors de la sortie de la CTP1 de Denali, un détail dans SSMS (qui évolue aussi pour se rapprocher encore davantage de Visual Studio) attire mon attention :

image

Hum hum, ça m’a vraiment fait penser à Exchange 2010. Une des grosses nouveauté de cette version est la notion de DAG : Database Avalability Groups. En y regardant de plus prés, cela ressemble à la réplication et à du mirroring, sauf qu’il est possible d’avoir plusieurs réplicas. Mais ça donne des idées …

Effectivement, les groupes de disponibilité dans SQL 11 permettent entre autre d’avoir jusqu’à 5 réplicas d’une base de données. Chaque réplica peut avoir un comportement propre :

  • un mode HA (High Availability) avec basculement automatique (dans un même datacenter pour avoir de la haute disponibilité),
  • mode HA avec basculement manuel (avec activation automatique en lecture seule du réplica pour un usage Reporting dans le même datacenter – ça c’est vraiment intéressent comme fonctionnalité),
  • un mode asynchrone qui permet de faire du Disaster Recovery (équivalent Log Shipping) sur un second datacenter … Bref, on entrevoit une évolution des possibilités pour mettre en œuvre des stratégies HADR.

Plus besoin d’être un expert Cluster, voire Geo-Cluster, de maitriser à la fois le database mirroring et le log shipping pour bénéficier a la fois de haute disponibilité et de disaster recovery. Une seule technologie regroupe ces concepts.

Et cerise sur le gâteau, là où la session de mise en miroir sur SQL 2005, 2008 et 2008R2 avait pour granularité la base de donnée, la technologie AlwaysON (HADR) de SQL11 permet d’englober plusieurs bases qui vont ainsi avoir le même comportement.

La version CTP1 de SQL 11 supporte seulement un seul réplica, et le mode asynchrone. Vivement les prochaines releases.

Let’s go …

Prérequis :

Cette fonctionnalité s’appuie, comme le DAG Exchange, sur le Failover Cluster de Windows 2008 et suivants. Donc il ne sera malheureusement pas possible d’implémenter les Availability Group sur une édition standard de Windows. Edition Entreprise ou Datacenter obligatoire. Il me faut 1 AD et les 2 serveurs qui vont supporter els instances SQL doivent être dans le même domaine.

Pour les deux serveurs Windows, il faut donc activer la fonctionnalité Failover Cluster :

image

Installation SQL Server :

En fait rien de particulier …. On n’installe pas nécessairement une instance virtuelle mais bel et bien une instance Stand-Alone de SQL Server :

image

Chaque instance impliquée dans le groupe de disponibilité peut être une instance en cluster, mais la technologie AlwaysON ne requiert pas d’instance virtuelle. De la même manière, cela fonctionne avec une instance par défaut ou bien un instance nommée.

Une fois les deux instances installées, il ne reste qu’a paramétrer SQL Server afin de pouvoir bénéficier de cette technologie.

Il suffit d’ouvrir SQL Server Configuration manager, et d’aller sur l’onglet SQL HADR du service SQL Server (click droit / propriétés).

image

Ah, bon, certes, tout n’est pas totalement transparent. Il va falloir créer le cluster au préalable ….

Notez qu’il n’est pas nécessaire d’avoir un disque Quorum (contrairement à ma configuration où pour d’autres besoins j’ai un cluster avec Node and Disk Majority), on peut tout a fait créer un cluster à Node Majority, ou mieux un cluster à Node Majority avec FileShare Witness (venez me voir en cours Cluster Windows 2008 pour plus d’infos ….). Pensez aussi à effectuer la validation du cluster pour vous assurer que tout va fonctionner correctement et pour bénéficier du support Microsoft en cas de problème.

Le compte pour créer le cluster doit être administrateur local des deux nœuds (DenaliCTP1 et DenaliCTP2 dans mon cas) et avoir des droits suffisent au niveau AD pour créer le compte d’ordinateur pour le cluster. Un compte “domain admin”, par exemple.

Sur un des nœuds, on ouvre la console Failover Cluster Manager et on cliques sur créer un cluster :

image

On ajoute les deux nœuds du cluster :

image

On renseigne le nom réseau du cluster ainsi que son adresse IP :

image

et on valide la création :

image

On vérifie que tout s’est bien passé lors de la création du cluster :

image

On peut à présent revenir sur le gestionnaire de configuration de SQL Server pour activer le HADR sur les deux nœuds :

image

Notez qu’il est nécessaire de redémarrer le service SQL pour que la modification soit prise en compte.

Il est maintenant possible de créer le groupe de disponibilité dans SSMS (sur DENALICTP1 dans mon cas).

Click droit sur Availability Group et ensuite New Availability Group permet de lancer un assistant de configuration.

image

image

image

Renseigner le nom du groupe de disponibilité ( ce sera le nom donné au group de ressrouce dans le Cluster).

image

Il faut ensuite sélectionner la ou les bases que l’on veut inclure dans le groupe de disponibilité. Notez que toutes les bases ne sont pas présentes. elles doivent remplir quelques critères, comme avoir été sauvegardées (backup database) et être en mode de récupération complet. On peut avoir un aperçu des pré-requis manquants sur les autres bases en sélectionnant la case à cocher en bas à gauche :

image

L’opération suivante consiste à choisir le ou les réplicas (dans cette CTP, un seul est autorisé) et si les connections clients sont autorisées :

image

image

On peut soit créer le script pour garder une trace de ce que l’on vient de faire ou bien directement terminer le wizard :

image

Pour les fans de script, voici ce que donne cette succession d’étapes :

--- YOU MUST EXECUTE THE FOLLOWING SCRIPT IN SQLCMD.
:Connect DENALICTP1

use [master]

GO

GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [CONSEILIT\sqlservice]

GO

:Connect DENALICTP2

use [master]

GO

GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [CONSEILIT\sqlservice]

GO

:Connect DENALICTP1

USE [master]

GO

CREATE AVAILABILITY GROUP [MyAvailabilityGroup]
FOR DATABASE [AdventureWorks2008], [MyTestDB]
REPLICA ON
   N'DENALICTP1' WITH
        (ENDPOINT_URL = N'TCP://DENALICTP1.conseilit.local:5022',
                SECONDARY_ROLE (ALLOW_READ = NO)),
   N'DENALICTP2' WITH
        (ENDPOINT_URL = N'TCP://DENALICTP2.conseilit.local:5022',
               SECONDARY_ROLE (ALLOW_READ = READ_CONNECTIONS_ONLY));

GO

:Connect DENALICTP2

ALTER AVAILABILITY GROUP [MyAvailabilityGroup] JOIN;

GO

Il faut a présent débuter la synchronisation des données :

image

image

Un répertoire partagé est requis, pensez à cliquer sur le bouton de test afin de valider que vous n’avez pas de problème de sécurité (droit NTFS) sur ce répertoire. Cliquez ensuite sur OK.

Une fois la synchronisation terminée, on peut vérifier que les bases sont bien présentes et accessibles sur notre seconde instance :

image

image

Sur notre base de test, créons une table et ajoutons des données :

image

celles ci sont bien présentes sur le réplica :

image

La CTP actuelle ne permet pas de faire de basculement entre les réplicas primaire et secondaires, que ce soit en mode manuel ou automatique.

Il est cependant possible d’effectuer un basculement forcé avec perte données.

ALTER AVAILABILITY GROUP MyAvailabilityGroup  FORCE_FAILOVER_ALLOW_DATA_LOSS

Et ensuite on peut reprendre la synchronisation des données :

image

image

On peut visualiser l’état de la synchronisation des données à l’aide de la requête :

SELECT DB_NAME(database_id),data_movement_state_desc, replica_database_state_desc
FROM sys.dm_hadr_database_replica_states
WHERE is_local = 1

Il est aussi possible d’effectuer la bascule via l’interface :

image

On on entrevoit les limites de cette bêta. Les prochaines CTP devraient combler ces quelques lacunes. D’autres billets devraient prochainement venir compléter cette introduction !

Bon HADR ….

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.

6 commentaires pour SQL Server Denali – “Availability Group”

  1. Ping : SQL Server Denali – Contained Databases | Christophe LAPORTE – Consultant SQL Server

  2. Christophe B. dit :

    Bonjour,

    Super, toutes ces infos.

    Il ne me reste qu’un doute. Je n’ai jamais mis en place de cluster ni Winodows et donc encore moins SQL Server.
    Dans un autre post, il est mentionné que la personne crée un « cluster with no shared storage ». Je dois avouer que je ne comprends pas bien qu’elle est la configuration minimum nécessaire pour le cluster Windows pour utiliser le HADR de Denali.
    Lien article :

    • Christophe dit :

      Le problème réside dans le vocabulaire employé. Lorsque l’on parle cluster il faut entendre cluster de basculement, car le NLB est lui aussi un cluster, mais pour la répartition de charge. Le cluster est seulement un grappe (de serveurs appellés noeuds).

      Pour un cluster de basculement, le stockage partagé fait parti des prérequis. Si tu mets une instance SQL en cluster ou bien si tu mats un partage de fichier en cluster, tes disques doivent être visibles par les différents noeuds.

      Pour les groupes de disponibilité dans Denali (tout comme le DAG Exchange 2010), tu dupliques ton infirmation, donc tu n’as plus besoin de stockage partagé.
      Et depuis Windows 2008, le vote supplémentaire pour atteindre la majorité du quorum peut être un partage de fichier sur un autre serveur. Le Disque quorum n’est donc plus une obligation, donc plus besoin obligatoirement de disque partagés sur un SAN.

      Donc la configuration minimum : 2 windows Entreprise ou datacenter. Sélectionne ensuite la feature Failover Cluster. Installe SQL11 et c’est parti …

  3. Ping : Denali – Installation d’un cluster 2 nœuds | Christophe LAPORTE – Consultant SQL Server

  4. Ping : Denali – Groupes de disponibilité | Christophe LAPORTE – Consultant SQL Server

  5. Ping : Denali – Ajout d’un nœud à un Groupes de disponibilité | 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