Évolution horizontale du niveau BizTalk Server

Pour faire évoluer horizontalement le niveau BizTalk, ajoutez du matériel à la topologie existante. Il est recommandé d'ajouter du matériel dans les scénarios suivants :

• BizTalk Server devient un goulot d'étranglement qui peut avoir pour origine un des problèmes suivants :

• UC : si le scénario utilise des pipelines, des mappages ou des orchestrations qui sollicitent beaucoup l'UC, les serveurs BizTalk Server n'auront pas de marge au niveau de l'UC.

• Mémoire et E/S : si les ordinateurs existants ont atteint leur limite maximale en mémoire et en E/S, la seule façon d’ajouter des ressources est d’ajouter un autre ordinateur physique.

• L'évolution verticale est une solution trop onéreuse. Prenons, par exemple, la topologie à un serveur BizTalk dans laquelle l'unité centrale BizTalk a atteint sa capacité maximale. S'il revient moins cher d'ajouter des ordinateurs à processeurs doubles supplémentaires que de mettre à niveau le processeur double et d'installer un processeur quadruple, vous devriez, à la place, faire évoluer horizontalement votre système.

• L'évolution verticale ne résout pas le goulot d'étranglement. Elle ne fonctionne pas dans les scénarios suivants :

  • Les E/S sont au niveau maximal sur l'ordinateur BizTalk ; il vous faut donc un autre ordinateur pour les monter en charge.

  • La mémoire est au niveau maximal pour le système d'exploitation. Dans ce scénario, le seul moyen de monter en charge le système consiste à ajouter un ordinateur BizTalk supplémentaire à la topologie.

  Dans certains scénarios, vous pouvez utiliser des serveurs dédiés pour recevoir des messages, en envoyer et les traiter. Si vous utilisez des serveurs dédiés, il est plus facile d'isoler les problèmes et d'effectuer les opérations de maintenance sur un ordinateur sans atteindre les performances des autres. Vous pouvez ajouter ces ordinateurs en faisant évoluer horizontalement le niveau BizTalk.

Cas dans lesquels l'évolution horizontale du niveau BizTalk est impossible

• La base de données MessageBox est le goulot d'étranglement.

• Un adaptateur devient le goulot d'étranglement. Par exemple, si vous utilisez l'adaptateur SQL, quand vous augmentez le nombre de récepteurs BizTalk, les conflits de verrouillage augmentent sur la base de données SQL d'où l'adaptateur BizTalk SQL extrait des données. Cela limite vos possibilités d'évolution horizontale par unité de cet adaptateur.

  La figure suivante illustre comment vous pouvez faire évoluer horizontalement le niveau BizTalk.

  

  Elle présente une topologie BizTalk ayant fait l'objet d'une évolution horizontale d'un serveur BizTalk à deux serveurs BizTalk. Dans la topologie à un serveur, trois instances de l'hôte partagent les ressources de l'ordinateur BizTalk. Dans la topologie à deux serveurs, l'hôte de transmission est installé sur un serveur différent qui atteint un débit supérieur.

Considérations à prendre en compte lors de l'évolution horizontale du niveau BizTalk

Avant d'ajouter un autre ordinateur BizTalk, observez les recommandations suivantes :

Comment configure-t-on le système pour l'équilibrage de la charge et la tolérance de pannes lorsque le niveau BizTalk fait l'objet d'une évolution horizontale ?

Le choix d'une technologie d'équilibrage de la charge et de tolérance de pannes dépend de l'adaptateur utilisé dans le scénario. Avec des adaptateurs SOAP et HTTP, il est conseillé d'utiliser la technologie d'équilibrage de la charge réseau (NLB). Pour plus d'informations, reportez-vous à votre documentation NLB.

Comment refactorise-t-on les instances de l'hôte ?

Aucune règle n'indique comment vous devez refactoriser les instances de l'hôte lorsque vous faites évoluer horizontalement le niveau BizTalk. La factorisation des instances de l'hôte dépend de la complexité du scénario. Les exemples suivants illustrent la factorisation des instances de l'hôte.

Scénario 1

Configuration à un serveur BizTalk ; les instances de réception et de transmission de l'hôte sont sur le même ordinateur.

Supposons qu'il y ait un goulot d'étranglement au niveau de l'unité centrale. Vous ajoutez un autre ordinateur BizTalk identique au groupe pour effectuer l'évolution horizontale qui vous donne deux moyens de factoriser les instances de l'hôte.

Voici deux solutions à ce problème :

• Solution 1 : Le moyen le plus simple de factoriser dans ce scénario consiste à cloner l’instance d’un ordinateur hôte à un deuxième ordinateur. Ce second ordinateur devient alors une copie exacte du premier en terme de fonctionnalités ; il peut aussi avoir des hôtes de réception et d'envoi. Supposons qu'il y ait un autre goulot d'étranglement ; vous pouvez obtenir un facteur d'échelle de 2 lorsque les ressources de l'unité centrale sont doublées.

• Solution 2 : une autre façon de factoriser les instances d’hôte consiste à isoler les fonctions de réception et d’envoi sur différents ordinateurs. Ainsi, un des serveurs BizTalk est dédié à la réception et l'autre à l'envoi.

  Comparaison de la solution 1 et de la solution 2

  Dans la solution 1, le nombre d'instances de l'hôte est doublé par rapport à la configuration à un serveur. Cela signifie que les conflits de verrouillage sur le serveur SQL Server vont augmenter. L'ampleur de l'augmentation des conflits de verrouillage détermine le facteur d'échelle. Si elle reste dans les limites acceptables sans qu'il y ait de goulot d'étranglement, vous obtenez un facteur d'échelle de 2.

  L’avantage de la solution 2 étant que vous n’avez que deux instances d’hôte, la contention de verrouillage sur le serveur SQL doit être inférieure à la solution 1. Toutefois, le facteur de mise à l’échelle dépend entièrement de la complexité des instances d’hôte de réception et d’envoi. Vous devez prendre en compte les points ci-après dans la solution 2 :

  Supposons que les instances de réception et de transmission de l'hôte réalisent des performances égales et qu'elles utilisent chacune 50 % de l'unité centrale dans la topologie à un serveur BizTalk. Dans la topologie à deux serveurs, vous installez l'instance de transmission de l'hôte sur un serveur différent de sorte que les instances de réception et de transmission obtiennent toutes deux le double des ressources. Vous devez obtenir un facteur d'échelle de 2 étant donné qu'il n'y a pas d'autre goulot d'étranglement. Cette solution est meilleure que la première parce qu'il n'y a que deux instances de l'hôte et partant, moins de conflits de verrouillage.

  Supposons que l'instance de transmission soit beaucoup plus performante que celle de réception et qu'elle utilise 80 % des ressources de l'unité centrale dans la topologie à un serveur BizTalk. En déplaçant l’hôte de transmission instance vers un autre ordinateur, vous n’obtenez que 20 % de ressources processeur en plus, de sorte que le facteur de mise à l’échelle maximal sera de 1,2. De plus, l’ordinateur avec l’hôte de réception instance n’utilisera que 20 à 30 % de ressources processeur, de sorte que l’avantage de la montée en charge est beaucoup moins élevé.

  Prenons la figure suivante qui présente une topologie à quatre serveurs BizTalk : Chaque ordinateur est à la fois récepteur et expéditeur, ce qui vous donne un total de quatre instances d’hôte de chaque type (réception et transmission).

  

  Cette topologie n'est sans doute pas la meilleure. Vous devez aussi tester d'autres changements de facteurs selon la complexité du scénario. Par exemple :

• Dédiez deux ordinateurs pour recevoir et deux pour transmettre. Vous obtenez ainsi une montée en charge optimale lorsque les instances de réception et d'envoi réalisent des performances égales.

• Dédiez trois ordinateurs à la réception et un à la transmission si l'instance de réception est plus performante que celle de transmission.

• Dédiez un ordinateur à la réception et trois à la transmission si l'instance de transmission est plus performante que celle de réception.

  Dans tous les cas, il est conseillé de limiter le nombre d'instances de chaque hôte de sorte à réduire les conflits de verrouillage dans la base de données MessageBox et à exploiter pleinement les ressources de l'ordinateur. La meilleure combinaison de facteurs dépend de la complexité du scénario et du type de goulot d'étranglement. Veillez toujours à tester votre facteur avant de finaliser un changement.

Voir aussi

Montée en puissance par unité du niveau BizTalk Server
Évolution verticale du niveau serveur SQL Server
Évolution horizontale du niveau 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