Hosts de recepción escalados
Cuando un host contiene un elemento de recepción, como una canalización o una ubicación de recepción, actúa como un límite de seguridad y la descodificación y descifrado de mensajes tiene lugar en una canalización del host. Para lograr que la disponibilidad de los hosts de recepción sea muy alta, debe disponer de dos o más equipos con BizTalk Server que ejecuten instancias de cada host de recepción. Al escalar horizontalmente los hosts receptores, puede garantizar la disponibilidad de BizTalk Server implementaciones que consumen muchos mensajes. Si bien estas implementaciones llevan a cabo un procesamiento mínimo de orquestación, pueden enrutar muchos mensajes de varios tipos a gran velocidad y con gran confiabilidad.
Puede mejorar la seguridad y escalabilidad del entorno separando el host de recepción de los hosts que procesan orquestaciones y envían mensajes, porque puede proteger y escalar cada host de forma independiente de otros hosts. Por ejemplo, puede agregar dos equipos (instancias de host) al host de recepción sin agregar ningún equipo a los hosts de procesamiento o envío.
Varios hosts para recibir mensajes
En la ilustración siguiente se muestra una implementación de BizTalk Server que proporciona alta disponibilidad para el host receptor teniendo dos equipos que ejecutan instancias del host receptor. Tenga en cuenta que, en esta ilustración, los hosts de procesamiento y envío no tienen una alta disponibilidad.
Para implementaciones de gran tamaño, escenarios con varios asociados comerciales y escenarios en los que se utilizan diferentes protocolos, puede repartir la funcionalidad de recepción entre varios hosts de recepción. Por ejemplo, puede crear un host para recibir mensajes para cada adaptador, o diferentes hosts para recibir mensajes de asociados diferentes. Cuando se crean varios hosts de recepción, se pueden crear límites de seguridad y facilitar el uso y la escalabilidad del entorno; sin embargo, no se logra una alta disponibilidad del entorno.
Para lograr una alta disponibilidad del entorno, debe crear dos o más instancias de host para cada host de recepción que cree. Por ejemplo, puede crear tres hosts de recepción diferentes (A, B y C) para recibir mensajes de tres compañías diferentes. Para lograr que estos hosts tengan una alta disponibilidad, debe crear instancias de host de cada uno de los hosts en dos o más equipos. Tenga en cuenta que puede tener instancias de cada host en un equipo sin perder el límite de seguridad, la facilidad de uso o la escalabilidad.
La siguiente ilustración muestra un entorno BizTalk Server de tres equipos y una alta disponibilidad con hosts dedicados a recibir mensajes de diferentes compañías.
Para proporcionar alta disponibilidad en esta configuración, cada equipo ejecuta tres instancias de host: una instancia para cada una de las tres empresas. Las instancias de host de cada compañía contienen las canalizaciones y ubicaciones de recepción para comunicarse con esa compañía. Durante un funcionamiento normal, siempre que se haya realizado el trabajo necesario para escalar los adaptadores de recepción (por ejemplo, si configura el equilibrio de carga de red para HTTP), la carga de mensajería se distribuye entre las tres instancias de cada host. Si una instancia de host en un equipo da error, las instancias de host que se ejecutan en los otros dos equipos proporcionan redundancia y mantienen la disponibilidad del servicio.
Escala de adaptadores de recepción de BizTalk Server
Además de las instancias de host, el proceso de escalar y proporcionar alta disponibilidad a los hosts de recepción depende también de los adaptadores específicos que implemente. Cada adaptador tiene características específicas del protocolo que hacen que el planeamiento y la implementación sean diferentes en cada caso. Sin embargo, BizTalk Server le permite aplicar la misma solución de alta disponibilidad para todos los adaptadores, principalmente a través de equipos adicionales y instancias de host.
Dependiendo del protocolo específico que se utilice, algunos adaptadores de recepción requieren un mecanismo adicional para distribuir los mensajes entrantes entre varios equipos host con el fin de proporcionar una alta disponibilidad. Por ejemplo, BizTalk Server soluciones que usan el adaptador HTTP o SOAP (también conocido como adaptador de servicios web) requieren un equilibrador de carga, como equilibrio de carga de red (NLB) para distribuir la carga de trabajo receptora. En la tabla siguiente se resumen las directrices de alta disponibilidad para los adaptadores más comunes de BizTalk Server.
| Adapter (Adaptador) | Directrices para obtener una alta disponibilidad |
|---|---|
| HTTP | Agregar varios equipos al host de recepción y configurar NLB para distribuir los mensajes entrantes entre los diferentes equipos host. |
| SOAP | Agregar varios equipos al host de recepción y configurar NLB para distribuir los mensajes entrantes entre los diferentes equipos host. |
| Archivo | Agregar varios equipos al host de recepción con la ubicación de recepción en cada equipo host haciendo referencia a la misma carpeta de archivos o ruta de acceso UNC (Convención de nomenclatura universal). Para lograr una solución de alta disponibilidad completa, debe asegurarse de que la ubicación de archivos a la que hace referencia la ruta de acceso UNC tenga una alta disponibilidad (o que sea al menos confiable). |
| FTP | Configurar el adaptador de recepción FTP para ejecutarlo en un host de BizTalk agrupado. Para obtener más información, consulte Consideraciones para ejecutar controladores de adaptador dentro de un host en clúster. |
| POP3 | Configurar el adaptador de recepción POP3 para ejecutarlo en un host de BizTalk agrupado. Para obtener más información, consulte Consideraciones para ejecutar controladores de adaptador dentro de un host en clúster. |
| MSMQ | Configure el adaptador de recepción de MSMQ para que se ejecute en un host de BizTalk en clúster de Windows. Para obtener más información, consulte Consideraciones para ejecutar controladores de adaptador dentro de un host en clúster. Si las ubicaciones de recepción de MSMQ usan colas en un servidor MSMQ remoto, no es necesario agrupar el host de BizTalk. En este escenario, ejecute el host de recepción de MSMQ en varios equipos de BizTalk del grupo. |
| MQSeries | Agregar varios equipos al host de recepción para este adaptador, utilizar administradores de cola agrupados en MQSeries para Windows y agrupar el servidor MQSeries Server para Windows. |
| Windows SharePoint Services | Agregar varios equipos al host de recepción y configurar NLB para distribuir los mensajes entrantes entre los diferentes equipos host. |
| - WCF-NetTcp - WCF-Custom |
Agregar varios equipos al host de recepción y configurar NLB para distribuir los mensajes entrantes entre estos equipos host. O bien Clúster que usó el host mediante el controlador de recepción del adaptador. |
| - WCF-NetNamedPipe - WCF-BasicHttp - WCF-WSHttp - WCF-CustomIsolated |
Agregar varios equipos al host de recepción y configurar NLB para distribuir los mensajes entrantes entre estos equipos host. |
| WCF-NetMsmq | Clúster que usó el host mediante el controlador de recepción del adaptador. |
Adaptador de HTTP
El adaptador de recepción HTTP en BizTalk Server es una extensión de LA API de Internet Server (ISAPI) (BTSHTTPReceive.dll) que se ejecuta como una instancia de host en cada equipo host de recepción. Cuando un asociado envía un mensaje a BizTalk Server utilizando el protocolo HTTP, el mensaje suele llegar a una dirección URL específica en el equipo con BizTalk Server que tiene instalado Internet Information Services (IIS). Cree una instancia de host en BizTalk Server con una ubicación de recepción suscrita a esta dirección URL. Cuando llegan los mensajes a la dirección URL, BizTalk Server los recupera y los envía a la base de datos de cuadro de mensajes.
BizTalk Server proporciona alta disponibilidad para el adaptador de recepción HTTP, ya que permite crear varias instancias de host del mismo host de recepción. Estas instancias de host están suscritas a una dirección URL específica que puede ser una dirección IP de clúster compartida si utiliza NLB para distribuir los mensajes entrantes entre varios hosts de recepción. Estos hosts sirven a la dirección IP virtual del clúster, de manera que, si da error un miembro del clúster, los demás pueden continuar sirviendo a esta dirección IP.
Adaptador de SOAP (adaptador de servicios web)
A diferencia del adaptador de recepción HTTP, el adaptador de recepción para servicios Web no implica una extensión ISAPI. Recibe los mensajes entrantes a través de una dirección URL que especifique utilizando el Asistente para publicación de servicios Web de BizTalk. Este asistente exporta un servicio Web y crea un directorio virtual que funciona como ubicación de recepción.
Para proporcionar una alta disponibilidad al adaptador de servicios Web, agregue varios equipos al host de recepción y utilice NLB para distribuir los mensajes entrantes. Cuando un cliente envía un mensaje a BizTalk Server a través del adaptador de servicios Web, NLB mantiene el equilibrio de carga enviando el mensaje a uno de los hosts de recepción y la instancia de host correspondiente que se ejecuta en el host envía el mensaje a la base de datos de cuadro de mensajes.
adaptador de archivo
El adaptador de recepción de archivo recupera los mensajes de una carpeta de archivos o una ruta de acceso UNC. Este adaptador se utiliza con frecuencia dentro de compañías en lugar de escenarios de empresa a empresa, porque ambas partes requieren permisos para la ruta y las compañías no suelen compartir los sistemas de archivos. Debe configurar el controlador de recepción de archivos para suscribirlo a la ruta de acceso de forma que BizTalk Server recupere el mensaje cuando llega a la ubicación de recepción.
BizTalk Server proporciona alta disponibilidad para el adaptador de recepción de archivos, ya que permite crear instancias de host en varios equipos host que se suscriben a la misma ruta de acceso UNC. Si una instancia de host que se ejecute en un equipo host encuentra errores, la misma instancia de host que se ejecute en otro equipo host puede recuperar el mensaje y enviarlo a la base de datos de cuadro de mensajes.
Adaptador de FTP
El adaptador de recepción FTP no debe estar configurado para ejecutarse en varios hosts, porque este adaptador utiliza el protocolo FTP para recuperar archivos del sistema de destino y este protocolo no tiene ninguna noción de bloqueo de archivos para garantizar que no se recuperan varias copias del mismo archivo simultáneamente cuando se ejecutan varias instancias del adaptador de recepción FTP. Este adaptador debe configurarse para ejecutarlo en un host de BizTalk agrupado. Para obtener más información, consulte Consideraciones para ejecutar controladores de adaptador dentro de un host en clúster.
Adaptador de POP3
El adaptador de recepción POP3 se puede configurar para ejecutarlo en varios hosts a menos que el servidor POP3 del que lee el adaptador permita varias conexiones concurrentes al mismo buzón. Si el servidor POP3 al que está conectado el adaptador de POP3 permite varias conexiones concurrentes a los buzones, la alta disponibilidad del adaptador de POP3 se logra configurando los controladores de recepción del adaptador de POP3 para ejecutarlos en una instancia de host de BizTalk que se haya agrupado. Para obtener más información, consulte Consideraciones para ejecutar controladores de adaptador dentro de un host en clúster.
Adaptador de MSMQ
Para lograr una alta disponibilidad, ejecute el adaptador de recepción de MSMQ en un host de BizTalk en clúster de Windows que se encuentra en el mismo grupo de clústeres que el recurso MSMQ agrupado. Para obtener más información, consulte Consideraciones para ejecutar controladores de adaptador dentro de un host en clúster.
Si la ubicación de recepción de MSMQ solo recibe de las colas de MSMQ en un servidor MSMQ remoto, la alta disponibilidad se puede lograr ejecutando el host de recepción de MSMQ en varios equipos de BizTalk del grupo de BizTalk. Para proporcionar alta disponibilidad para MSMQ, debe asegurarse de que el servidor MSMQ remoto usa la agrupación en clústeres de conmutación por error en Windows. Si usa colas transaccionales, el servidor MSMQ remoto debe ejecutar MSMQ 4.0 (Windows Server 2008) o superior.
Adaptador de MQSeries
El adaptador de Microsoft BizTalk para MQSeries actúa como un puente entre BizTalk Server y los servidores IBM MQSeries. Para proporcionar una solución de alta disponibilidad cuando utilice este adaptador, debe tener varias instancias del host que ejecuta el adaptador de MQSeries, utilizar administradores de cola agrupados en MQSeries para Windows y agrupar el servidor MQSeries Server para Windows. Para obtener más información acerca de la agrupación en clúster del administrador de cola y del servidor MQSeries Server, consulte la documentación de IBM WebSphere MQ. Para obtener más información sobre cómo lograr alta disponibilidad para el adaptador de MQSeries, consulte "Alta disponibilidad" en la Ayuda del adaptador de Microsoft BizTalk para MQSeries.
Adaptador de Windows SharePoint Services
El adaptador de Windows SharePoint Services recupera mensajes de SharePoint llamando al servicio Web de Windows SharePoint Services instalado por BizTalk en el equipo con SharePoint. El adaptador utiliza un mecanismo de desprotección para garantizar que varias instancias de host no procesarán el mismo mensaje. Esto permite que el adaptador de recepción se escale horizontalmente agregando más instancias de host. BizTalk Server proporciona alta disponibilidad para el adaptador de recepción de SharePoint, ya que permite ejecutar las mismas ubicaciones de recepción en varias instancias de host que se suscriben a la misma dirección URL HTTP que apunta a una instalación NLB de SharePoint.
Adaptador de WCF-NetTcp
Se puede equilibrar la carga de NetTcpBinding mediante técnicas de equilibrio de carga de capa IP. Sin embargo, NetTcpBinding agrupa conexiones TCP de forma predeterminada para reducir la latencia de la conexión. Ésta es una optimización que interfiere con el mecanismo básico del equilibrio de carga. El valor de configuración principal para optimizar NetTcpBinding es el tiempo de espera de conexión, que forma parte de la configuración del grupo de conexión. La agrupación de conexiones produce conexiones de cliente que se asociarán a servidores concretos dentro de la granja. Como la duración de esas conexiones aumenta (un factor controlado por el valor de tiempo de espera de la concesión), la distribución de carga en varios servidores de la granja pasa a estar sin equilibrar. Como resultado, aumentará el tiempo medio de la llamada. Por lo tanto, cuando se usa NetTcpBinding en escenarios con la carga equilibrada, considere la posibilidad de reducir el tiempo de espera de concesión predeterminado usado por el enlace. Un tiempo de espera de concesión de 30 segundos es un punto de inicio razonable para los escenarios con carga equilibrada, aunque el valor óptimo depende de la aplicación. Para obtener más información sobre el tiempo de espera de concesión de canal y otras cuotas de transporte, consulte las cuotas de transporte.