Instances Biztalk d’équilibrage de charge réseau

Question

Quels sont quelques bons articles/ressources pour comprendre comment l'équilibrage de charge est configuré avec Biztalk --- à la fois en termes de capacités inhérentes au produit et d'utilisation de NLB (équilibrage de charge réseau avec Windows 2003 ou éditions ultérieures) ?

MODIFIER:Je suis particulièrement intéressé par l'impact du protocole d'application sur l'équilibrage de charge ?Par exemple, comment deux instances du serveur Biztalk gèrent les connexions TCP/IP lorsque l'autre partie (à laquelle Biztalk fait une demande de connexion) n'autorise pas plus d'une connexion, etc.

Answer 1

La ressource évidente est MSDN - Il y a une section intitulée Planification pour une activité élevée qui couvre la plupart des concepts et vous donnera la bonne terminologie pour ensuite rechercher d'autres ressources sur le Web.Comme pour de nombreux produits serveur Microsoft, MSDN propose également de nombreux livres blancs couvrant des scénarios BizTalk spécifiques.

La plupart des bons livres BizTalk incluent également une section sur les concepts d'équilibrage de charge (Professional BizTalk Server 2006 en propose un exemple).

Au-delà de cela, il existe plusieurs concepts clés qui pourraient vous être utiles, notamment en ce qui concerne l'utilisation de la terminologie (certaines utilisations de BizTalk peuvent être trompeuses).

L'équilibrage de charge

BizTalk Server est, de par la nature de son architecture, un équilibrage de charge.Cela signifie que si plusieurs hôtes BizTalk se connectent à une base de données MessageBox, les messages de la base de données seront répartis uniformément entre les hôtes participant au groupe BizTalk.(avec des mises en garde concernant les processus BizTalk qui ont été configurés pour s'exécuter sur chaque hôte).

Il existe également le concept de Network Load Balancing qui est Microsoft Network Load Balancing Services ou tout service équivalent.Dans BizTalk, cela s'applique au niveau Web, pour les adaptateurs de réception utilisant le protocole HTTP (par ex.l'adaptateur HTTP, l'adaptateur SOAP et les adaptateurs HTTP WCF).Cet équilibrage de charge n'est pas réellement un service BizTalk, mais plutôt une couche d'équilibrage de charge fournie au-dessus des adaptateurs hôtes isolés BizTalk pour garantir la haute disponibilité des ressources Web.Il est configuré de la même manière que n’importe quel autre service NLB.

Regroupement

Lorsque le clustering est mentionné dans BizTalk, il est utilisé pour faire référence à l'une des deux choses suivantes : le clustering au niveau de la couche SQL pour fournir une haute disponibilité et le basculement, et le clustering d'hôtes BizTalk.

Clustering SQL - il s'agit simplement (bien que ce ne soit pas simple à faire, disons simplement) de fournir un cluster de serveur SQL qui exécute les bases de données du serveur BizTalk, permettant le basculement de la base de données.Il ne s'agit pas d'une technologie spécifique à BizTalk.

Clustering d’hôtes BizTalk : dans ce cas, un hôte BizTalk Server est marqué comme étant mis en cluster lors de sa création dans BizTalk.Il s'agit d'un paramètre spécifique à BizTalk qui indique essentiellement qu'une et une seule instance de l'hôte sera exécutée à la fois et que, par extension, toutes les ressources de cet hôte n'auront également qu'une seule instance.Il est principalement destiné à être utilisé avec des adaptateurs tels que les adaptateurs FTP et MSMQ qui se comportent incorrectement lorsque plusieurs d'entre eux sont autorisés à s'exécuter en même temps.

---

Cette modification fait suite au commentaire du PO demandant plus de détails.Espérons que cela rende les choses plus claires.Si vous avez d'autres questions sur des détails précis, je peux éventuellement y répondre, mais cela épuise à peu près mon théorie connaissance de la configuration d'un environnement à haute disponibilité.Je suis avant tout un développeur et un concepteur de solutions BizTalk. Lorsqu'il s'agit de subtilités de réseau, il y a des personnes chez qui je travaille qui s'occupent des moindres détails et de la mise en œuvre de ces conceptions.

Équilibrage de charge réseau pour les adaptateurs HTTP

Le point clé que j'essayais d'exprimer ici était que l'équilibrage de la charge réseau dans le contexte de BizTalk n'est pas différent de tout autre scénario d'équilibrage de la charge réseau.

BizTalk a deux types d'hôtes, En cours et Isolé.Les hôtes In Process sont des services BizTalk individuels exécutés sur des serveurs (avec une instance d'hôte par serveur).Les hôtes isolés sont en fait des délégués à un serveur Web (IIS) qui gère tous les adaptateurs HTTP (l'adaptateur HTTP et l'adaptateur SOAP ainsi que certaines configurations pour l'adaptateur WCF).

Lorsque vous introduisez l'équilibrage de charge réseau dans un environnement BizTalk, vous l'introduisez au niveau de la couche du serveur Web, pour les adaptateurs hébergés par l'hôte isolé.

Voici la page MSDN pour le introduction à la NLB.L’un des points clés concernant le NLB est exprimé dans la page dans la citation suivante :

L'équilibrage de la charge du réseau permet à tous les ordinateurs du cluster d'être traités par le même ensemble d'adresses IP de cluster (mais conserve également leurs adresses IP uniques et dédiées existantes).

En configurant NLB, vous autorisez plusieurs serveurs hôtes isolés à gérer le trafic Internet dirigé vers une seule adresse IP dédiée.La configuration NLB confie le travail.

Clustering des gestionnaires d’adaptateurs BizTalk

Dans ma réponse ci-dessus, j'ai déclaré que certains adaptateurs BizTalk se comportaient de manière incorrecte lorsqu'ils étaient autorisés à s'exécuter dans plusieurs instances d'hôte BizTalk.Ceci est très spécifique à l'adaptateur en termes de pourquoi, donc la meilleure extension de cette réponse que je puisse donner est la citation suivante du Documentation MSDN, traitant spécifiquement de l'adaptateur FTP.

Pour la plupart des adaptateurs intégrés BizTalk, la haute disponibilité peut être réalisée en créant plusieurs gestionnaires d'adaptateurs pour fonctionner sur des instances d'hôte BizTalk sur différents serveurs Biztalk au sein d'un groupe Biztalk.Les gestionnaires de réception de l'adaptateur FTP ne doivent cependant pas être configurés pour exécuter simultanément dans plusieurs instances d'hôte BizTalk.Cette recommandation est formulée car l'adaptateur de réception FTP utilise le protocole FTP pour récupérer des fichiers du système cible et le protocole FTP ne verrouille pas les fichiers pour s'assurer que plusieurs copies du même fichier ne sont pas récupérées simultanément lors de l'exécution de plusieurs instances de l'adaptateur FTP reçoivent l'adaptateur de réception FTP .

Comme on dit, l'adaptateur FTP utilise le protocole FTP qui ne verrouille pas les fichiers.Étant donné que BizTalk est par nature un système hautement parallèle, si vous autorisez plusieurs hôtes BizTalk à héberger une instance de l'adaptateur FTP, vous vous retrouverez avec plusieurs copies du même message FTP reçues dans votre système BizTalk.Le clustering BizTalk garantit que tous les hôtes BizTalk en cluster s'exécuteront sur 1 et seulement 1 instance hôte.En plaçant votre gestionnaire de réception FTP dans un hôte cluster, vous garantissez que :

• vous aurez toujours un adaptateur FTP en cours d'exécution tant qu'un hôte BizTalk est en cours d'exécution
• vous n'aurez jamais plus d'un adaptateur FTP en cours d'exécution.

En plus vous pouvez utiliser un hôte en cluster BizTalk pour réduire la charge sur un système.Par exemple, un emplacement de réception d'un adaptateur BizTalk SQL qui a été configuré pour interroger, interrogera sur tous instances hôtes.Bien que cela ne provoque pas nécessairement plusieurs instances de message, cela pourrait entraîner une charge excessive sur le serveur SQL que vous interrogez, ou même créer des scénarios de blocage en fonction de la conception de la procédure stockée appelée. Le regroupement du gestionnaire de réception de l'adaptateur SQL peut donc être une bonne idée.