SQL Saturday à Paris 2013 le 14 septembre 2013

Mis en avant

C’est fait les SQL Saturdays arrivent en France ! Cet évènement se déroulera le samedi 14 septembre 2013 entre 10H et 17H à Paris au sein du campus des écoles informatiques bien connus EPITA et EPITECH. Celui-ci sera axé de 3 pôles spécifiques :

  • Business Intelligence
  • Administration de bases de données
  • Etudiant

 

SQLSAT251_web_thumb1

 

Cet évènement aura la particularité d’accueillir des speakers anglophones tels que Jen Stirrup, Allan Mitchell ou Hugo Kornelis (donc préparer votre anglais) mais aussi et en grande majorité des speakers français comme Jean-Pierre Riehl, Christophe Laporte, Phillipe Geiger, Patrick Guimonet et d’autres . Je vous laisse découvrir leurs noms sur le site dédié à l’évènement. Pour le planning c’est par ici.

J’aurai l’opportunité de lancer les hostilités pour le track pour DBA avec une session sur les traces SQL vs les évènements étendus. Ce sera également l’occasion de pouvoir partager nos différentes expériences entre jeunes et moins jeunes Sourire

A noter que cet évènement a été à l’initiative du GUSS

 

guss

 

Rien de tel pour préparer sa rentrée Sourire 

 

David BARBARIN (Mikedavem)
MVP SQL Server

Considération sur les listeners associées aux groupes de disponibilités avec SQL Server 2012 AlwaysOn

Mis en avant

Lorsqu’on crée un groupe de disponibilité avec SQL Server et AlwaysOn on l’associe par la suite à un listener. Lorsque ce dernier est créé plusieurs objets lui sont associées :

  • Un objet d’ordinateur dans l’annuaire active directory
  • Une entrée DNS de type A
  • Une ressource cluster associée à au groupe de ressource créé et qui représente le groupe de disponibilité

 

Dans l’exemple suivante un groupe de disponibilité nommé AdventureWorks2 a été créé. Le listener associé s’appelle LST_ADVW2

 

alwayson_aag_lst

 

icon_arrow Les différents objets associés

 

L’objet d’ordinateur dans l’annuaire :

alwayson_ad_object

 

… l’enregistrement DNS :

alwayson_dns_record

 

… Le groupe de ressource lié au groupe de disponibilité :

alwayson_cluster_resource

 

… et les ressources qui le composent :

alwayson_cluster_resource2

 

Jetons un coup d’Å“il aux dépendances existantes entre les ressources du groupe de ressource AdventureWorksGrp2 :

alwayson_cluster_dependencies

 

Ici on vient bien les dépendances existantes : le groupe de disponibilité AdventureWorksGrp2 dépend de la ressource "nom réseau" qui représente notre listener (LST_ADVW2) qui elle même dépend de la ressource "Adresse IP" qui vous l’aurez devinez, correspond à l’adresse IP de notre listener.

 

icon_arrow Port d’écoute du listener

Est-ce qu’un listener doit écouter sur le même port que les réplicas du groupe disponibilité ?  Est-ce possible ? C’est une question qui s’est posé rapidement dans mon cas lorsqu’il a fallu installer des réplicas n’écoutant pas sur le port qui n’écoutaient pas sur le port par défaut (1433). On peut même aller à l’extrême et prendre le cas où chaque réplica écoute sur un port différent. Dans ce cas quel port dois-je paramétrer pour mon listener ? Un listener peut tout à fait écouter sur un port différent que les réplicas. Le choix du numéro de port dépend évidement de vos besoins, contraintes de sécurité etc …  Prenons un exemple avec 2 réplicas qui écoutent sur 2 ports différents (1499 et 1500) et un listener qui écoute sur le port 1433.

 

[AlwaysOn Instance]

Cette configuration fonctionne parfaitement. Par curiosité on peut voir ce que cela donne sur une trace réseau via NetMon par exemple.

alwayson_netmon0

On peut voir ici une connexion depuis SQL Server Management Studio vers le listener lst_advw.insentia.lab (IP virtuelle : 192.168.0.61)

 

Dans notre cas le listener écoute sur le port 1433 et la connexion est automatiquement redirigée vers le réplica concerné en toute transparence. Au niveau de la chaine de connexion l’impact est minime : le nom du listener remplace tout simple le nom de l’instance SQL Server. Cependant que se passe-t-il maintenant si nous changeons le port d’écoute du listener vers un port non standard ? En réalité les choses se compliquent un peu et il existe plusieurs cas :

  • On spécifie le numéro de port directement dans la chaine de connexion
  • On a la possibilité d’utiliser le format suivant : [nom listener]\[nom instance] sous certaines conditions :
    • On utilise des instances nommées qui portent le même nom pour l’ensemble des réplicas
    • Le service SQL Browser est démarré et opérationnel sur l’ensemble des réplicas pour effectuer la résolution de nom de l’instance vers le numéro de port adéquat.

icon_arrow Cas de la redirection vers un réplica secondaire en lecture seule

AlwaysOn nous fournit la possibilité d’être redirigé vers un réplica secondaire en lecture seule en se connectant via le listener à condition que les règles de redirection  aient été définies (routes et priorités). Dans ce cas une trace NetMon nous révèle la chose suivante :

alwayson_netmon1

 

On peut constater ici qu’après la phase d’authentification la connexion de SQL Server Management Studio initialement effectuée vers le listener lst_advw.insentia.lab (port 1433) est redirigé vers le réplica secondaire en lecture seule REPLICA2 (port 1498)

 

icon_arrow Kerberos, SPN et redirection vers un réplica secondaire en lecture seule

La documentation en ligne Microsoft stipule que pour utiliser Kerberos dans une architecture AlwaysOn il faut ajouter les SPN correspondants à nos listeners. Cependant je n’ai pas trouvé dans la documentation le cas où le listener effectuait une redirection d’une connexion en lecture seule vers un réplica secondaire en lecture seule. Dans ce cas ajouter les SPN pour les listeners ne suffit pas et l’on doit également ajouter les réplicas secondaires en lecture seule.

Voici une trace netmon d’une tentative de connexion en erreur à un réplica secondaire avec Kerberos :

alwayson_spn_netmon

 

On peut voir ici 2 requêtes TGS depuis ma station cliente (192.168.0.100) vers mon contrôleur de domaine (192.168.0.1) :

  • TGS request vers le service MSSQLSvc/lst_advw.insentia.lab (port 1433) : listener
  • TGS request vers le service MSSQLSvc/replica2.insentia.lab (port 1498) : réplica secondaire en lecture seule

Le contrôleur de domaine répond avec une erreur pour la deuxième demande car il n’y a pas de SPN paramétré pour REPLICA2 dans mon cas (KDC_ERR_S_PRINCIPAL_UNKNOW)

 

icon_arrow Listeners vs alias (DNS / SQL) ?

Une question intéressante surtout lorsqu’on a l’habitude de lier le point de connexion des applications via un alias DNS ou SQL par exemple. Ainsi lorsqu’on change de serveur de bases de données avec un nouveau nom, il suffit d’utiliser de modifier l’alias en conséquence. Le changement est donc relativement transparent pour les applications. Avec SQL Server AlwaysOn, lorsqu’un un listener est créé nous avons vu qu’une entrée DNS est également effectuée. De plus on a la possibilité d’associer plusieurs listeners à un seul groupe de disponibilité ce qui peut tout à fait remplacer les alias. Bien entendu chaque méthode présente des avantages mais aussi des inconvénients. Goden Yao (Program Manager , SQL Server Engine High Availability)  a écrit un billet intéressant à ce sujet.

 

Bon paramétrage de listeners !!

 

David BARBARIN (Mikedavem)
MVP SQL Server