SQL Server 2016–AlwaysOn Basic Availability Group

Tout d’abord, un petit mea-culpa. Cela fait en effet quelques semaines que je n’ai rien posé sur ce blog. Plusieurs raisons à cela : un planning plus que chargé avec des déplacements (avec parfois plus de 11h00 d’avion), et la reprise d’activité annexes comme … les constructions en Lego !

Et suivre les 471 pages du manuel prends quelques heures. Sourire

2016-02-18 08.32.12

A cela se rajoute quelques idées folles autour d’une plateforme Windows IoT sur Raspberry PI. Avec, si tout se passe bien, quelque chose de fun à venir autour de SQL et cet ordinateur format carte de crédit. Stay Tuned.

Bref, suite à une question hier soir d’un ami, j’ai rapidement monté une plateforme Windows 2016 (CTP4) SQL Server 2016 (CTP3.3) afin de valider ce qui était mentionné dans la documentation technique des groupes de disponibilité en version basique, disponibles dans l’édition standard, en remplacement du Database Mirroring.

Le Database Mirroring étant déprécié et donc amené à disparaitre, il était temps de faire évoluer les groupes de disponibilités apparus avec SQL Server 2012, édition entreprise, qui n’étaient au final qu’une suite logique au DBM.

Puisque son remplaçant, il n’est pas étonnant de disposer des mêmes limitations que le DBM :

  • Seulement 2 réplicas
  • 1 seule base dans le groupe de disponibilité
  • Base de donne secondaire inaccessible (pas d’offload de sauvegarde, ni d’accès en lecture seule)

Rien de particulier pour l’installation du serveur SQL, reportez vous au post relatif à ce sujet.

Pour les plus pressés, une simple ligne de commande suffit :

 $HostName = Hostname
    D:\Setup.exe /ACTION=Install /FEATURES=SSMS,ADV_SSMS,SQLEngine,Replication,IS,Conn,FullText  `
                /INSTANCENAME=MSSQLSERVER `
                /SQLSVCACCOUNT="NT Service\MSSQLServer" `
                /AGTSVCACCOUNT="NT Service\SQLServerAgent" `
                /FTSVCACCOUNT="NT Service\MSSQLFDLauncher" `
                /ISSVCACCOUNT="NT Service\MsDtsServer130" `
                /TCPENABLED="1" `
                /SQLTEMPDBFILECOUNT=4  `
                /UpdateEnabled=FALSE `
                /SECURITYMODE=SQL /SAPWD="Password1" /SQLSYSADMINACCOUNTS="$Hostname\Administrator" `
                /SQLUSERDBDIR="E:\MSSQLServer\Data" `
                /SQLUSERDBLOGDIR="E:\MSSQLServer\Log" `
                /SQLTEMPDBDIR="E:\MSSQLServer\Data" `
                /SQLTEMPDBLOGDIR="E:\MSSQLServer\Log" `
                /SQLTEMPDBFILESIZE=256 `
                /SQLTEMPDBFILEGROWTH=64 `
                /SQLTEMPDBLOGFILESIZE=256 `
                /SQLTEMPDBLOGFILEGROWTH=256 `
                /HELP="False" /INDICATEPROGRESS="False" /QUIET="True" /QUIETSIMPLE="False" `
                /X86="False" /ENU="True" /ERRORREPORTING="False" /SQMREPORTING="False" `
                /SQLSVCINSTANTFILEINIT=TRUE `
                /IACCEPTSQLSERVERLICENSETERMS 

Pour un serveur de production, les tailles de fichiers et emplacements seraient à revoir, tout comme le paramètre SYSADMINACCOUNTS.

Installons donc 2 serveurs, activons les fonctionnalités dotnetfx et cluster. Installons les instances, activation de la case à cocher magique pour activer les Availability Groups.

  image

Créons une base vide, son contenu n’a finalement que très peu d’importance. Une sauvegarde complète de la base est toujours nécessaire, même si vous choisissez de confier au wizard l’initialisation de la base sur le réplica secondaire.

C’est ensuite que les écrans de création d’une BAG (Basic Availability Group) diffèrent légèrement de ce que nous connaissions jusqu’alors, avec la possibilité d’opter pour un groupe de disponibilité basique. Notez également, que les transactions distribuées seront (enfin !) supportées.

image

image

Il est toujours possible de définir des réplicas synchrone ou asynchrone, avec basculement manuel ou automatique. ais, clairement, le wizard ne propose pas la possibilité de rendre un réplica secondaire accessible en lecture seule.

image

Tout comme la sélection des options de sauvegarde est grisée. Seul le backup priori est accessible, mais gageons qu’il s’agit d’un oubli dans la CTP, mais qui dons tous les cas, n’a pas d’effet.

image

Dernier point, il n’est pas possible de créer de listener depuis l’assistant.

image

Ensuite, pas de changements notoires.

image

Les fans de script T-SQL ne seront pas dépaysés :

image

Et donc, questions de Philippe : dans la doc il n’est pas fait mention du support du listener. Par contre, nous venons de voir qu’il n’était pas possible de le créer au début du processus. Qu’en est-il si on essaie de la rajouter manuellement ?

L’écran reste accessible

image

Mais le message surs de la validation est clair :

image

La doc en ligne ne dit rien un message dans SQL nous informe que c’est non supporté.

Hum hum

Etant donné que la mécanique sous jacente des groupes de disponibilité repose sur le WSFC, voyons voir s’il est possible de créer un client access point (@IP et nom DNS) directement dans le groupe de ressource dans la console de gestion du cluster.

imageimageimageimage

Le wizard se termine bien. Par défaut, l’adresse IP set en DHCP, je corrige pour passer en statique (non obligatoire mais je n’ai pas de serveur DHC sur ce réseau).

image

Ensuite, Bring Online des ressources et tout est fonctionnel

image

La question est : est-ce que cela fonctionne en tant que point d’accès pour SQL Server ?

La réponse est : OUI  Sourire

image

Le failover du groupe de disponibilité se passe également bien

image

image

image

Le client SQL point bien vers le nouveau serveur primaire.

Donc, oui, cela fonctionne. Le “Listener” peut être créé et est parfaitement fonctionnel. Listener est à mettre en guillemets car au final on ne peut le considérer que comme un alias DNS, mais qui va suivra automatiquement la base sur le réplica actif. Bien entendu, il perd la fonctionnalité de routing list qui de toute manière est inutile puisque il n’y a pas de lecture possible sur la base secondaire.

Enjoy BAG …

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 SQL Server 2016–AlwaysOn Basic Availability Group

  1. Oromy dit :

    Bonjour,
    Je me pose une question, on ne peux pas avoir un AlwaysOn Availability Group sur une instance déjà en AlwaysOn Failover Cluster.
    Idem avec AlwaysOn « Basic » Availability Group?

    • Christophe dit :

      Bonjour

      Oui, il est possible de cumuler FCI et AGs. Quelques point spécifiques à respecter quand même comme des timeout à modifier et l’on préfère que les réplicas soient supportés par des instances virtuelles qui ne doivent pas cohabiter sur un même nœud.

      Je n’ai pas testé avec le BAG, mais à première vue je ne vois pas de contre indication.

      Quelle serait la raison d’un tel choix, cette configuration est relativement atypique.

  2. Ping : Controler le Database Mirroring au travers d’un cluster Windows | 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