SQL Server permet l’installation de plusieurs moteurs de bases de données sur un même système d’exploitation. Le terme consacré pour décrire ces moteurs installés est “instance”.

Cet article a pour objet de voir les bonnes pratiques pour se connecter à une instance SQL Server dans un contexte d’entreprise, et plus précisément dans le cas où l’on a un pare-feu à traverser.

Pour rappel, un système d’exploitation Windows peut héberger un certain nombre d’instances SQL Server (la limite est par exemple à 50 instances SQL Server 2012). Ces instances peuvent être de versions SQL différentes (simple variation de quelques hotfix ou services packs, ou bien même potentiellement avec numéro de version majeure différent), ou bien avoir des propriétés différentes (classement, droits d’accès, …). D’une manière générale, on peut considérer que ce sont plusieurs moteurs de bases de données totalement indépendants. A noter que cet article se limitera à parler du moteur de bases de données relationnelles, et n’abordera volontairement pas les autres briques SQL Server supportant la notion d’instance (notamment SSRS et SSAS).

Toutes ces instances ont un nom, permettant de les identifier sur le système. Il peut toutefois y en avoir une (et une seule au maximum) qui n’a pas de nom particulier défini. Elle est dite instance par défaut, et porte en fait le nom MSSQLSERVER.

Du point de vue des échanges avec l’extérieur, ces instances SQL Server sont en général paramétrées pour répondre aux sollicitations extérieures sur la base de communications établies par TCI/IP. Chaque instance répondra sur un port TCP qui lui sera propre.

La définition par défaut de ce port est la suivante :

– pour l’instance par défaut, port TCP 1433

– pour les autres instances (c’est-à-dire les instances nommées), le port TCP est par défaut attribué de manière dynamique au lancement de l’instance.

Le paramétrage indiqué ci-dessus est celui en place par défaut, mais il est tout à fait configurable via l’outil de configuration SQL Server (et nous verrons plus bas dans cet article pourquoi modifier cette configuration par défaut). Pour définir le port de réponse d’une instance, il faut aller dans le réglage des paramètres réseau de l’instance, et demander les propriétés associées au protocole TCP/IP.

On peut choisir soit une attribution dynamique du port, soit un port fixe.

Dans le cas d’une architecture technique classique d’entreprise, il est assez fréquent que les serveurs SQL soient protégés par un pare-feu (et soient par exemple interrogés par des serveurs Web placés en DMZ). Afin de configurer correctement les pare-feu, il conviendra donc ici de fixer l’ensemble des ports d’écoute des instances, pour ouvrir au minimum le pare-feu.

Lorsqu’une application se connecte à une instance SQL, elle le fait via l’utilisation d’une chaîne de connexion précisant les différents paramètres d’accès. Parmi ces paramètres, l’identification de l’instance peut se faire de plusieurs manières :

– pour une instance par défaut, le nom du serveur est suffisant

– pour une instance nommée, on peut directement spécifier le numéro de port. Par exemple, pour une instance répondant sur le port 33111 sur le serveur MonServeur, l’identification est : MonServeur,3311

– pour une instance nommée, on peut aussi spécifier son nom. Par exemple, si l’on veut se connecter à l’instance nommée Instance1 sur le serveur MonServeur, alors on peut indiquer MonServeur\Instance1. Dans ce cas, le système a besoin de convertir ce nom en numéro de port, et va pour cela interroger le service SQL Browser sur le serveur (si toutefois celui-ci est démarrer). Ce service répondra sur le port UDP 1434 et permettra donc d’effectuer cette conversion du nom d’instance en numéro de port. Cette méthode est la seule possible lorsque les numéros de ports sont attribués de manière dynamique, mais dans le contexte d’une architecture avec pare-feu, elle oblige à laisser ouvert un port de plus (UPD 1434).

Il m’est assez souvent arrivé de voir des utilisateurs préciser à la fois le nom d’instance et le numéro de port dans leur chaîne de connexion. Que se passe-t-il alors, surtout si les informations fournies ne sont pas cohérentes ? Et bien la règle est tout simplement celle du moindre effort : pourquoi s’embêter à demander le numéro de port correspondant à un nom d’instance si un numéro de port nous est déjà donné ? Par exemple, si on paramètre une instance Instance1 pour répondre sur le port 3311 et une instance Instance2 pour répondre sur le port 33222, alors la chaîne de connexion MonServeur\Instance1,33222 nous connectera sur l’instance Instance2.

En résumé, la solution préconisée consiste à :

– fixer pour chaque instance un numéro de port fixe (et en profiter pour mettre pour l’instance par défaut une valeur différente de 1433)

– désactiver le service SQL Browser

– toujours utiliser une chaîne de connexion sous la forme NomServer,Port

Même si ce mode de connexion n’est pas nécessairement “User-Friendly”, étant donné qu’un nom d’instance est fait pour être parlant, il est préférable d’avoir une configuration efficace plutôt qu’une configuration jolie …