Mise à l'échelle des hôtes de réception

Lorsqu’un hôte contient un élément de réception, tel qu’un emplacement de réception ou un pipeline, il agit comme une limite de sécurité, et le décodage et le déchiffrement des messages se produisent dans un pipeline au sein de l’hôte. Pour que les hôtes de réception soient dotés d'une disponibilité élevée, vous devez avoir installé deux machines BizTalk Server ou plus, exécutant une instance de chacun des hôtes de réception. En effectuant un scale-out des hôtes de réception, vous pouvez garantir la disponibilité des déploiements BizTalk Server qui nécessitent beaucoup de messagerie. Bien que son traitement des orchestrations soit minimal, ce modèle de déploiement permet d'acheminer de nombreux messages de types différents de manière rapide et fiable.

Vous pouvez encore améliorer la sécurité et l'évolutivité au sein de votre environnement en séparant l'hôte de réception des hôtes chargés du traitement des orchestrations et de l'envoi des messages, car il est alors possible de sécuriser et de déployer chaque hôte indépendamment des autres. Par exemple, vous pouvez attribuer deux ordinateurs supplémentaires (instances de l'hôte) à l'hôte de réception sans pour autant en ajouter aux hôtes de traitement ou d'envoi.

Hôtes de réception multiples

La figure suivante montre un déploiement BizTalk Server qui fournit une haute disponibilité pour l’hôte de réception en ayant deux ordinateurs qui exécutent des instances de l’hôte de réception. Remarquez que les hôtes de traitement et d'envoi représentés ici ne sont pas des hôtes hautement disponibles.

Dans les cas de déploiement à grande échelle, dans des scénarios de partenariats commerciaux multiples ou d'utilisation de protocoles différents, vous avez la possibilité de répartir la fonction de réception entre plusieurs hôtes. Vous pouvez par exemple créer un hôte de réception des messages pour chaque adaptateur ou des hôtes distincts pour la réception des messages provenant de partenaires différents. Lorsque vous mettez en place plusieurs hôtes de réception, vous pouvez créer des limites de sécurité et faciliter la gestion et l'évolutivité de votre environnement sans que ce dernier puisse bénéficier pour autant d'une disponibilité élevée.

Pour obtenir un environnement à haute disponibilité, vous devez créer deux instances de l'hôte (ou plus) pour chaque hôte de réception créé. Vous pouvez par exemple créer trois hôtes de réception différents (A, B et C) afin de recevoir des messages de trois sociétés distinctes. Pour faire en sorte que tous ces hôtes bénéficient d'une disponibilité élevée, vous devez ensuite créer des instances d'hôte sur deux ordinateurs ou plus pour chaque hôte. Vous pouvez disposer des instances de chaque hôte sur un seul ordinateur sans perdre pour autant les fonctionnalités de limite de sécurité, de gestion ou d'évolutivité.

Le schéma suivant représente un environnement BizTalk Server hautement disponible à trois ordinateurs où des hôtes sont uniquement utilisés pour la réception de messages provenant de différentes sociétés.

Pour fournir une haute disponibilité dans cette configuration, chaque ordinateur exécute trois instances hôtes : une instance pour chacune des trois entreprises. Les instances de l'hôte de chaque société contiennent les emplacements de réception et les pipelines permettant la communication avec ces sociétés. Lors de tâches classiques, si les opérations de déploiement nécessaires ont été effectuées pour les adaptateurs de réception (ex. : configuration de l'équilibrage de charge réseau pour HTTP), la charge des messages est répartie entre les trois instances de chaque hôte. Si l'exécution d'une instance de l'hôte échoue sur un ordinateur, les instances de l'hôte exécutées sur les deux autres ordinateurs constituent une redondance permettant de conserver une disponibilité de service.

Mise à l'échelle des adaptateurs de réception de BizTalk Server

Outre les instances de l'hôte, le processus de mise à l'échelle et d'installation de la haute disponibilité pour les hôtes de réception dépend également des adaptateurs que vous implémentez dans votre déploiement. Chaque adaptateur possède des caractéristiques de protocole particulières qui rendent la planification et le déploiement différents à chaque fois. Toutefois, BizTalk Server vous permet d’appliquer la même solution de haute disponibilité pour toutes les cartes, principalement par le biais d’ordinateurs supplémentaires et d’instances hôtes.

Selon le protocole utilisé, certains adaptateurs de réception nécessitent un mécanisme supplémentaire pour la distribution des messages entrants sur plusieurs ordinateurs afin de fournir une disponibilité élevée. Par exemple, BizTalk Server solutions qui utilisent l’adaptateur HTTP ou SOAP (également appelé adaptateur de services Web) nécessitent un équilibreur de charge tel que l’équilibrage de charge réseau (NLB) pour distribuer la charge de travail de réception. Le tableau suivant récapitule les instructions de haute disponibilité pour les cartes les plus courantes dans BizTalk Server.

Adaptateur HTTP

L’adaptateur de réception HTTP dans BizTalk Server est une extension ISAPI (internet Server API) (BTSHTTPReceive.dll) qui s’exécute en tant que instance hôte sur chaque ordinateur hôte de réception. Lorsqu'un partenaire envoie un message à BizTalk Server par le biais du protocole HTTP, ce message arrive en général à une adresse URL spécifique, sur un ordinateur BizTalk Server où sont installés les services IIS (Internet Information Services). Dans BizTalk Server, créez une instance de l'hôte et un emplacement de réception abonné à cette URL. Lorsque des messages parviennent à cette URL, BizTalk Server les extrait et les stocke dans la base de données MessageBox.

BizTalk Server fournit une haute disponibilité pour l’adaptateur de réception HTTP en vous permettant de créer plusieurs instances hôtes du même hôte de réception. Ces instances d'hôte doivent être abonnées à une URL, cette dernière pouvant être une adresse IP mise en cluster et partagée si vous utilisez l'équilibrage de la charge réseau afin de répartir les messages entrants entre plusieurs hôtes de réception. L'ensemble de ces hôtes gère l'adresse IP virtuelle du cluster si bien que, si l'un des membres du cluster est défaillant, les autres peuvent continuer le service.

Adaptateur SOAP (Adaptateur de services Web)

Contrairement à l'adaptateur de réception HTTP, l'adaptateur de services Web ne comprend pas d'extension ISAPI. Il reçoit les messages par l'intermédiaire d'une URL préalablement indiquée dans l'Assistant Publication de services Web BizTalk. Ce dernier exporte un service Web et crée un répertoire virtuel servant d'emplacement de réception.

Pour assurer la haute disponibilité à l'adaptateur de services Web, utilisez plusieurs ordinateurs pour l'hôte de réception et servez-vous de l'équilibrage de la charge réseau afin d'obtenir une répartition des messages entrants. Lorsqu'un client envoie un message à BizTalk Server par l'intermédiaire de l'adaptateur de services, le service d'équilibrage de la charge dirige le message vers l'un des hôtes de réception et l'instance de l'hôte concernée stocke le message dans la base de données MessageBox.

Adaptateur FILE

L'adaptateur de réception File extrait les messages d'un dossier ou d'un chemin d'accès UNC. Beaucoup de sociétés utilisent cet adaptateur en lieu et place de scénarios interentreprises (B2B), car les deux parties doivent disposer d'autorisations d'accès au chemin et parce que les sociétés ne partagent généralement pas leur système de fichiers. Configurez le gestionnaire de réception File de sorte qu'il soit abonné au chemin d'accès et que BizTalk Server puisse ensuite récupérer les messages à leur arrivée dans l'emplacement de réception.

BizTalk Server fournit une haute disponibilité pour l’adaptateur de réception de fichiers en vous permettant de créer des instances hôtes sur plusieurs ordinateurs hôtes qui s’abonnent au même chemin UNC. Si l'une des instances s'exécutant sur un ordinateur hôte rencontre des problèmes ou est défaillante, la même instance s'exécutant sur un autre ordinateur hôte est capable de récupérer le message et de le stocker dans la base de données MessageBox.

adaptateur FTP

L'adaptateur de réception FTP ne doit pas être configuré de façon à être exécuté sur plusieurs hôtes, car il utilise le protocole FTP pour extraire les fichiers du système cible. Or, ce protocole ne comportant aucune capacité de verrouillage, il ne peut garantir que plusieurs copies d'un même fichier ne soient pas récupérées en même temps lors de l'exécution de plusieurs instances de l'adaptateur de réception FTP. L'adaptateur FTP doit être configuré uniquement pour être exécuté sur un hôte BizTalk en cluster. Pour plus d’informations, consultez Considérations relatives à l’exécution de gestionnaires d’adaptateurs au sein d’un hôte cluster.

Adaptateur POP3

L'adaptateur de réception POP3 peut être configuré de façon à fonctionner sur plusieurs hôtes, sauf si le serveur POP3 à partir duquel l'adaptateur lit les données permet plusieurs connexions simultanées à une même boîte aux lettres. Pour obtenir un adaptateur hautement disponible lorsque le serveur POP3 auquel il se connecte permet ces connexions simultanées, il est nécessaire de configurer le gestionnaire de réception de l'adaptateur POP3 de façon qu'il puisse être exécuté sur une instance d'hôte BizTalk mise en cluster. Pour plus d’informations, consultez Considérations relatives à l’exécution de gestionnaires d’adaptateurs au sein d’un hôte cluster.

Adaptateur MSMQ

Pour obtenir une haute disponibilité, exécutez l’adaptateur de réception MSMQ dans un hôte BizTalk en cluster Windows qui se trouve dans le même groupe de clusters que la ressource MSMQ en cluster. Pour plus d’informations, consultez Considérations relatives à l’exécution de gestionnaires d’adaptateurs au sein d’un hôte cluster.

Si l’emplacement de réception MSMQ reçoit uniquement des files d’attente MSMQ sur un serveur MSMQ distant, la haute disponibilité peut être obtenue en exécutant l’hôte de réception MSMQ sur plusieurs ordinateurs BizTalk du groupe BizTalk. Pour fournir une haute disponibilité pour MSMQ, vous devez vous assurer que le serveur MSMQ distant utilise des clustering de basculement dans Windows. Si vous utilisez des files d’attente transactionnelles, le serveur MSMQ distant doit exécuter MSMQ 4.0 (Windows Server 2008) ou une version ultérieure.

Adaptateur MQSeries

L’adaptateur Microsoft BizTalk pour MQSeries sert de pont entre les serveurs BizTalk Server et IBM MQSeries. Pour obtenir une solution hautement disponible avec cet adaptateur, vous devez disposer de plusieurs instances de l'hôte exécutant l'adaptateur, utiliser des gestionnaires de file d'attente mis en cluster dans MQSeries pour Windows et mettre en cluster MQSeries Server pour Windows. Pour plus d'informations sur la mise en cluster du gestionnaire de file d'attente et celle de MQSeries Server, reportez-vous à la documentation d'IBM WebSphere MQ. Pour plus d'informations sur la haute disponibilité pour l'adaptateur MQSeries, reportez-vous à la rubrique « High Availability » (Haute disponibilité) dans l'aide de l'adaptateur Microsoft BizTalk pour MQSeries.

Adaptateur Windows SharePoint Services

L'adaptateur Windows SharePoint Services extrait les messages provenant de SharePoint en appelant le service Web de Windows SharePoint Services installé par BizTalk sur la machine exécutant SharePoint. L'adaptateur utilise un mécanisme de vérification afin de s'assurer que des instances d'hôte différentes ne traiteront pas le même message. Cela permet à l’adaptateur de réception d’effectuer un scale-out en ajoutant d’autres instances d’hôte. BizTalk Server offre une haute disponibilité pour l’adaptateur de réception SharePoint en vous permettant d’exécuter les mêmes emplacements de réception sur plusieurs instances hôtes qui s’abonnent à la même URL HTTP pointant vers une installation nLB SharePoint.

Adaptateur WCF-NetTcp

La charge de la liaison NetTcpBinding peut être équilibrée à l'aide des techniques d'équilibrage de la charge au niveau de la couche IP. Toutefois, la liaison NetTcpBinding regroupe les connexions TCP par défaut pour réduire la latence de connexion. Il s'agit d'une optimisation qui interfère avec le mécanisme de base d'équilibrage de charge. La valeur de configuration principale pour l'optimisation de la liaison NetTcpBinding correspond au délai d'expiration du bail, qui fait partie des paramètres du pool de connexions. Le regroupement de connexions provoque l'association des connexions clientes à des serveurs spécifiques dans la batterie. Au fur et à mesure que la durée de vie de ces connexions augmente (facteur contrôlé par le paramètre de délai de bail), la distribution de la charge sur les divers serveurs dans la batterie est déséquilibrée. En conséquence, le temps d'appel moyen augmente. Aussi, lorsque vous utilisez NetTcpBinding dans les scénarios avec équilibrage de charge, pensez à réduire le délai d'expiration du bail par défaut. Un délai de bail de 30 secondes est un point de départ raisonnable pour les scénarios à charge équilibrée, bien que la valeur optimale dépende de l'application. Pour plus d'informations sur le délai d'expiration de bail du canal et les autres quotas de transport, consultez la section Quotas de transport.

Voir aussi

Configuration de la haute disponibilité pour des hôtes BizTalk