Les bases de données BizTalk

Une installation BizTalk se décompose en deux types de serveurs : les serveurs BizTalk eux-mêmes sur lesquels s’exécutent les traitements (Réception, émission de messages et orchestration) et le(s) serveur(s) de bases de données.

Ce dernier joue un rôle très important :

• Il stocke la configuration des applications BizTalk.
• Il conserve les informations de suivi de l’activité.
• Il stocke les messages et l’état des orchestrations en cours d’exécution.

Ce dernier point est particulièrement important à comprendre pour la mise en œuvre d’un environnement BizTalk hautement disponible. En effet, dès qu’un message est reçu, celui-ci est stocké dans la base de données. De même, dès qu’une orchestration a effectué une action non réversible l’état de celle-ci est stocké. Ce mécanisme permet la reprise des traitements sur n’importe quels serveurs BizTalk. On dit que les serveurs BizTalk sont « sans état » (stateless en anglais).

En cas de défaillance du serveur de bases de données, BizTalk cesse de fonctionner. Il est donc important de réduire les temps de reprise sur ce type de défaillance. Sur SQL Server (qui est le moteur de bases de données utilisé par BizTalk), il existe plusieurs solutions mais toutes ne peuvent être utilisées dans une solution BizTalk.
En effet, le mirroring de bases de données ne peut être utilisé, car BizTalk s’appuie sur des transactions distribuées. La deuxième technique ne pouvant être utilisée est la réplication.

Il reste deux techniques utilisables avec BizTalk :

• Le cluster de basculement.
• Le Log Shipping BizTalk (rejeu des sauvegardes sur un serveur SQL).

Les avantages du cluster de basculement sont :

• Le basculement automatique (ou manuel si nécessaire).
• Le temps d’indisponibilité relativement faible (ordre de grandeur : minute).
• La possibilité de rajouter / enlever des nœuds (et donc d’effectuer des opérations de maintenances).

A son désavantage, on peut néanmoins citer la nécessité d’une baie de stockage dédiée ou d’un SAN. Le Log Shipping, quant à lui, est plus à réserver dans le cadre de la mise en place d’un plan de reprise d’activité. En effet il permet, simplement, de déporter sur un site distant le serveur de backup. A noter également que la reprise n’est pas automatique et que l’on aura potentiellement une perte de données correspondant à l’intervalle entre deux sauvegardes (15 minutes par défaut).

D’autres solutions peuvent être envisagées mais ne sont pas spécifiques à SQL Server. Par exemple, le « Boot » depuis le SAN (cette solution permet de remplacer facilement le serveur défectueux).