Évolution horizontale du niveau SQL Server
Pour chaque groupe BizTalk, vous ajoutez une base de données principale MessageBox. Toutes les bases de données MessageBox suivantes que vous ajoutez sont des bases de données secondaires. La base de données principale MessageBox gère tous les abonnements et le routage des messages. Elle permet également la publication de messages. Les bases de données secondaires MessageBox publient des messages uniquement lorsqu'elles sont configurées pour ce faire.
Ajout d'une base de données secondaire MessageBox
Il existe deux façons d'ajouter des bases de données secondaires MessageBox :
Ajoutez la base de données secondaire MessageBox sur le même serveur physique.
Procédez de la sorte si le serveur physique MessageBox existant dispose de suffisamment de ressources UC et E/S et s'il est engorgé uniquement par un conflit de verrouillage. Créez la base de données secondaire MessageBox sur des lecteurs d'E/S distincts.
Avantages :
La marge d'UC supplémentaire peut être utilisée par un autre MessageBox.
Moins de licences serveur SQL sont requises.
Le tronçon réseau est éliminé.
Ajoutez la base de données secondaire MessageBox sur un autre serveur physique.
Dans ce cas utilisez un serveur physique dédié avec sa propre E/S en tant que base de données MessageBox supplémentaire.
La figure suivante montre un scénario dans lequel le niveau SQL subit une évolution horizontale d'une base de données MessageBox vers trois bases de données MessageBox.
Quand procéder à l'évolution horizontale de la base de données MessageBox
La base de données MessageBox devient le goulot d'étranglement. Ces engorgements peuvent être notamment :
CPU Dans le cas de scénarios d’orchestration très coûteux et complexes, la base de données MessageBox consomme de lourdes ressources processeur. L'ajout d'une autre base de données MessageBox dans laquelle la publication est activée doit aider à augmenter le débit.
Contention de verrou Les scénarios complexes avec plusieurs instances d’hôte ou orchestrations ont tendance à créer une contention de verrous sur la base de données MessageBox. Là encore, l'ajout d'une autre base de données MessageBox dans laquelle la publication est activée doit aider à augmenter le débit.
L'évolution verticale ne résout pas l'engorgement. Par exemple, si la base de données principale MessageBox est liée par un conflit de verrouillage, l'évolution horizontale est la seule option possible.
L'évolution verticale est trop onéreuse. Par exemple, si la mise à niveau du serveur à quatre processeurs vers un serveur à huit processeurs est plus coûteuse que d'ajouter un autre ordinateur à quatre processeurs, l'évolution horizontale est plus intéressante.
Cas dans lesquels l'évolution horizontale du niveau SQL est impossible
En théorie, le niveau SQL doit pouvoir évoluer horizontalement tant que la base de données principale MessageBox ne devient pas le goulot d'étranglement. Pour cela, faites de la base de données principale MessageBox une base de données MessageBox n'acceptant pas la publication afin qu'elle n'effectue que le routage. Toutefois, dès que la base de données principale est engorgée par un conflit de verrouillage, vous ne pouvez plus faire évoluer horizontalement le niveau SQL.
Stratégies et recommandations en matière d'évolution horizontale
Faites évoluer la base de données principale MessageBox verticalement puis horizontalement.
Scale-out de 1 à 3 bases de données SQL MessageBox au lieu de 1 à 2. Considérez la topologie 1 serveur SQL illustrée dans la figure ci-dessus intitulée « 4 BizTalk Server, 1 SQL Server Topologie », et supposons que le serveur SQL est lié au processeur, en d’autres termes, le traitement du processeur est un goulot d’étranglement. Si vous n'ajoutez qu'une base de données MessageBox à cette topologie, la base de données principale Messagebox restera liée à l'UC et la base de données secondaire MessageBox sera sous-utilisée. Le facteur de mise à l’échelle est donc presque égal à 1. Si vous désactivez la publication sur la base de données Master MessageBox et dédiez la base de données Master MessageBox uniquement pour effectuer le routage, la base de données MessageBox secondaire effectuera la publication. Cependant, cela ne permettra pas d'augmenter le débit global dans la mesure où la base de données secondaire MessageBox devient le seul éditeur et demeure l'engorgement. Par conséquent, le meilleur moyen de procéder à une évolution horizontale dans ce scénario consiste à ajouter 2 bases de données secondaires MessageBox et à désactiver la publication sur la base de données principale MessageBox.
La base de données principale MessageBox devient à terme le goulot d'étranglement. Par conséquent, l'ordinateur physique hébergeant la base de données principale MessageBox doit être plus rapide et plus puissant.
Pour limiter l'envoi de données sur le réseau (et la surcharge DTC associée), pensez à installer plusieurs bases de données MessageBox sur le même ordinateur physique, avec des lecteurs dédiés. Vérifiez dans le même temps que l'ordinateur hébergeant ces bases de données n'est pas engorgé car les ressources sont partagées par plusieurs bases de données MessageBox.
Toutes les bases de données secondaires MessageBox doivent utiliser du matériel comparable parce que le travail est réparti de manière homogène entre les bases de données MessageBox acceptant la publication.
Puisque vous pouvez faire évoluer horizontalement des bases de données secondaires MessageBox tant que la base de données principale MessageBox n'est pas engorgée, ces bases secondaires peuvent s'exécuter sur des ordinateurs possédant des ressources d'UC inférieures à celles requises par le serveur de la base de données principale MessageBox.
Voir aussi
Évolution horizontale du niveau BizTalk Server
Montée en puissance par unité du niveau BizTalk Server
Évolution verticale du niveau serveur SQL Server
Hôtes de réception montés en charge
Hôtes de traitement montés en charge
Hôtes d’envoi montés en charge
Utilisation d’un cluster Windows Server pour fournir une haute disponibilité pour les hôtes BizTalk Server 2
Bases de données montées en charge
Mise en cluster des bases de données BizTalk Server