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 …

Publicités

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.

10 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

  3. thiang dit :

    Bonjour
    Une question
    Je suis en train de mettre en place le Always avec deux noeud,
    J’ai mis en place 3 serveurs (2 noeuds et 1DC). On sait certaines configurations exigent un compte de domaine mais je ne sait si les intallations des instances sql en font part

    • Christophe dit :

      Bonjour
      Dans le cadre d’un AG il est tout a fait possible d’affecter un compte local en tant que compte de service de chaque instance.
      Dans ce cas, il faudra alors donner la permission au compte COMPUTER$ de l’autre instance sur le point de terminaison dédié à AlwaysON.

      Sachant que vous êtes en 2016, vous pouvez également opter pour une solution sans domaine, mais vous avez toujours besoin d’un DNS qui soit commun.
      New-Cluster –Name CLUSTSQLWRK -Node SQL2K16W01,SQL2K16W02 -AdministrativeAccessPoint DNS
      L’authentification des noeuds se fait alors au travers de certificats.

  4. FlowB41 dit :

    Bonjour,

    J’ai une question toute simple, est-on encore obligé d’avoir des disques en ISCSI accessibles des deux serveurs en cluster avec « l’Always ON » de SQL 2016?
    Cdlt,

    Florian

    • Christophe dit :

      Bonjour

      N’oubliez pas qu’AlwausOn est une « marque » regroupant toutes les solutions de haute disponiblité SQL Server.
      Ceci dit, si vous pensez aus groupes de disponibilité, il n’y a rien d’obligatoire puisque la soltion est conçue pour être relativement agnostique au niveau matériel. Il est donc tout a fait possible, voire même souhaitable si on est à la recherche de la performance maximale, de profiter de disques locaux en attachement SAS ou SATA, voire mieux avec du SSD PCI NVMe.
      Et rien n’a changé depuis que les groupes de disponibilité existent. Avec SQL2012, c’était déjà le cas, du coup j’ai un peu de mal à comperndre le « encore » de votre phrase et avoir la bonne interprétation de vote question.

      Par contre, si vous pensez au FCI, le cluster de basculement, la version « historique » depuis NT4 WolfPack, effectivement il n’est pas nécéssaire de disposer de disques issus d’un SAN. Depuis Windows 2016 et la fonctionalité S2D, Storage Spaces Direct, on peut en effet batir un FCI SQL Server sur un environnement hyperconvergé à base de disques locaux.

      cdlt
      Christophe

      • FlowB41 dit :

        Merci Christophe de cette réponse complète,

        En effet je me suis mal exprimé.

        Je souhaite mettre en place deux SQL 2016 Serveur avec redondance en cas de panne.
        Mais avec la version 2012 R2 j’était obligé d’avoir un « disque partagé » c’est à dire créer un « disque virtuel » en ISCSI auxquels les deux serveurs pouvaient avoir accès pour prendre « la place » de l’autre en cas de panne.
        Mais mon hébergeur ne voulait pas mettre en place un disque ISCSI sur une de leur baie SAN (Pour que le disque virtuel soit lui aussi redondé), et je me demandais si avec ‘AlwaysOn Basic Availability Group’  » et ses nouvelles fonctionnalités de SQL 2016, je pouvais avoir une alternative.
        Mais je pense que rien n’a changé au niveau des pré-requis 🙂

      • Christophe dit :

        C’est bien ce que je pensais. Il s’agit du FCI est non pas de l’AG.
        Oui, les hosteurs ne permettent pas de disposer d’un disque partagé entre machines virtuelles.
        Donc si on souhaite utiliser le FCI il faut passer par du S2D.

        Oui le basic availability group te permettra de faire ce que tu veux. A savoit avoir de la redondance au niveau de tes bases. Et avec des disques locaux à ta VM (ou des serveurs) cela fonctionne parfaitement. Pour info c’est ce type d’architecture que je propose à mes clients pour héberger leurs bases de données.
        Le Basic Availability Group n’est que du Database Mirroring avec une couche marketing et quelque options supplémentaires…

  5. Ping : SQL Server 2016 – Groupes de disponibilité distribués | 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