le broker est ses points d’entrée

Voici une petite série sur le Service Broker, tant cela se justifie en vertu de la facilité d'utilisation de cette composante dans SQL Server. Certes SQL Server 2008 y a ajouté une petite composante « graphique » dans Management Studio et un outil de diagnostic, mais je défie quiconque de le configurer correctement du premier coup.

Le Service Broker est arrivé avec SQL Server 2005 et offre la capacité à SQL Server de réaliser des traitements asynchrone. Grosso Modo on empile les tâches dans une file d'attente (Queue), pour que celles-ci soient traité par une autre tâche. Celle-ci est généralement une procédure stockée écrite à cette fin qui va dépiler automatiquement (l'appel est automatique, le boulot c'est à vous de l'écrire) les enregistrements déposés dans cette file d'attente.

En interne SQL Server utilise le Service Broker, pour entre autres : le Database Mail, les Events Notifications, les Query Notification, etc. En termes de client utilisant cette technologie, citons en un gros : MySpace.

Les End Points sont les point d'entrée extérieur du serveur de base de données. La création d'un Endpoint revient à ouvrir un port TCP accessibles par une application ou un autre serveur de base de données.

La requête suivante me donne la liste disponible sur ma machine :

select * from sys.endpoints

La liste qui suit :

Certaines précaution sont à prendre pour l'ouverture d'un port :

• Vérifiez que ce port n'est pas utilisé (netstat -a).
• Autorisez le Firewall (local ou du réseau) à laisser l'accès à ce port si nécessaire.

Pourquoi créer un Endpoint pour le Service Broker ? C'est le seul moyen qui va permettre à ce composant de communiquer avec d'autres serveurs. Par autre serveurs j'entends d'autres instances de SQL Server. Ces instances peuvent être sur la même machine, dans le même domaine ou tout autres machines distante et non joignable sur le même réseau que le vôtre. De ceci dépendra la manière de sécuriser le port ouvert pour le Service Broker. Attention par contre à sa configuration car il ne peut y en avoir qu'un seul de ce type par instance !

Voici la syntaxe de base pour créer ce point d'entrée :

CREATE ENDPOINT [edp_Service_Broker]
AUTHORIZATION sa
STATE = STARTED
AS TCP (LISTENER_PORT = 1234, LISTENER_IP = ALL)
FOR SERVICE_BROKER

(

...

)

Le port TCP est à renseigner à la place de 1234 dans le script. Les options possible à la place des (…) sont :

• AUTHENTICATION
  • WINDOWS KERBEROS, authentification à base de tickets Kerberos possible depuis les domaines Windows 2000. Nécessite un domaine et d'avoir procédé à la configuration Kerberos pour le service et le port que vous souhaitez ouvrir (ici 1234). Cette méthode offre le meilleur en termes de sécurité mais nécessite une configuration plus importante en pré-requis.
  • WINDOWS NTLM, authentification Windows de "base", fonctionne même hors domaine, avec toutefois quelques limitations de sécurité.
  • WINDOWS NEGOTIATE, laisse les serveurs décider quel est le mode approprié d'authentification pour les connexion aux Endpoints.
  • CERTIFICATE, fournis une authentification base sur TLS, chaque Endpoint disposant d'un certificat pour d'authentifier sur celui du second serveur. (Pour plus d'informations sur la manière de la configurer http://support.microsoft.com/kb/915852 )
• ENCRYPTION
  • SUPPORTED ALGORITHM AES RC4,
  • DISABLED
  • REQUIRED
• MESSAGE_FORWARDING
  • DISABLED
  • ENABLED

Par exemple, pour un port TCP écoutant sur le ports 1234 et utilisant une authentification via Windows NTLM ou KERBEROS, le cryptage de la connexion est autorisé et sera au choix AES, RC4 ou rien suivant le point de connexion distant :

CREATE ENDPOINT [edp_Service_Broker]
AUTHORIZATION sa
STATE = STARTED
AS TCP (LISTENER_PORT = 1234, LISTENER_IP = ALL)
FOR SERVICE_BROKER

(

AUTHENTICATION = WINDOWS NEGOTIATE,
ENCRYPTION = SUPPORTED ALGORITHM AES RC4,
MESSAGE_FORWARDING = DISABLED

)

Après cette étape de création des Enpoints reste à autoriser les connexions entre les serveurs.

GRANT CONNECT ON ENDPOINT::edp_Service_Broker TO [srv_login];

Le nom du Endpoint est facile à renseigner, mais quand est-il de la valeur de srv_login ?

• public : C'est la méthode du paresseux on autorise toute connexion, quelque soir le compte souhaitant s'authentifier, cette méthode n'a d'intérêt que si vous êtes sur un réseau local et maitriser la sécurité de celui-ci.
• Compte de Service du serveur SQL distant, si vous avez un compte du domaine comme compte de service sur la machine distante
• Compte de la machine distante, si le compte de service distant est Network Service
• Login SQL propriétaire du certificat distant, en cas de configuration de la sécurité via TLS et les certificats.

Avant d'autoriser la connexion à un login x ou y, assurez-vous que celui-ci a bien été créer, aucun privilège n'est nécessaire pour ce Login, ni aucuns droits dans une quelconque base de données. Exception faite de l'authentification par certificat ou il faudra créer un utilisateur dans master et y importer un certificat.

Une fois le point d'entrée créer avec succès ces lignes devrait figurer dans le journal d'erreur de SQL Server :

The Service Broker protocol transport is now listening for connections.

Server is listening on [ 'any' 1234].

Dans la prochaine série, nous créons les bases du dialogue du Service Broker.

Bon dialogue…