Escalar horizontalmente el nivel de BizTalk Server

Para escalar horizontalmente el nivel de BizTalk, agregue más hardware a la topología existente. Se recomienda que agregue hardware en los siguientes escenarios:

• BizTalk Server se convierte en un cuello de botella. Alguno de los problemas siguientes puede causar el cuello de botella:

• CPU: si el escenario utiliza canalizaciones, asignaciones u orquestaciones que hacen un uso intensivo de CPU, los servidores BizTalk Server no tendrán ningún espacio en cabeza adicional de CPU.

• Memoria e E/S: si los equipos existentes han alcanzado su límite máximo de memoria e E/S, la única manera de agregar recursos es agregar otro equipo físico.

• El escalamiento vertical resulta demasiado caro. Por ejemplo, piense en una topología de servidor BizTalk Server, donde la CPU ha alcanzado su capacidad máxima. Si es más barato agregar equipos con procesadores dobles adicionales, en vez de actualizar el procesador doble a un procesador cuádruple, debería entonces hacer un escalamiento horizontal del sistema.

• El escalamiento vertical no corrige el cuello de botella. Puede que el escalamiento vertical no funcione en los siguientes escenarios:

  • E/S está en el nivel máximo para el equipo de BizTalk, de modo que necesita otro equipo para escalar el E/S.

  • La memoria está en el nivel máximo para su sistema operativo. En este escenario, la única forma de escalar su sistema es agregar un equipo adicional de BizTalk a la topología.

  Es posible que en algunos escenarios desee servidores específicos para recibir, enviar mensajes y procesarlos. Cuando dispone de servidores específicos, es más fácil aislar problemas y realizar el mantenimiento en un equipo sin afectar a los otros. Puede agregar estos equipos escalando horizontalmente el nivel de BizTalk.

Cuándo no es posible escalar horizontalmente el nivel de BizTalk

• En la base de datos de cuadro de mensaje se produce el cuello de botella.

• El cuello de botella se produce en un adaptador. Por ejemplo, si utiliza el adaptador de SQL, después de aumentar el número de receptores de BizTalk, la contención de bloqueo se incrementa en la base de datos SQL de la que extrae datos el adaptador de SQL de BizTalk. Esto limita su capacidad de escalar horizontalmente el adaptador de SQL.

  La siguiente ilustración muestra un ejemplo de cómo puede escalar horizontalmente el nivel de BizTalk.

  

  Esta figura muestra una topología de BizTalk escalada horizontalmente, que evoluciona de un servidor BizTalk Server a dos servidores BizTalk Server. En la primera topología de servidor BizTalk Server, tres instancias de host comparten los recursos del equipo de BizTalk. En la segunda topología de servidor BizTalk Server, el host de transmisión se separa en un servidor diferente, con lo que se consigue un mayor rendimiento.

Consideraciones al escalar horizontalmente el nivel de BizTalk

Debe plantearse las siguientes preguntas antes de agregar otro equipo de servidor BizTalk Server:

¿Cómo configuro el sistema para el equilibrio de carga y la tolerancia a errores al escalar horizontalmente el nivel de BizTalk?

La selección de la tecnología para el equilibrio de carga y la tolerancia a errores depende del adaptador que se utiliza en el escenario. Para adaptadores de SOAP y HTTP, la manera recomendada es usar NLB. Para obtener más detalles, consulte la documentación de NLB.

¿Cómo volver a descomponer en factores las instancias de host?

No hay una regla única para determinar cómo debe volver a descomponer en factores las instancias de host al realizar un escalamiento horizontal del nivel de BizTalk. La factorización de las instancias de host depende de la complejidad del escenario. A continuación, se muestran algunos ejemplos sobre el modo de descomponer en factores las instancias de host.

Escenario 1

Una configuración de servidor BizTalk Server e instancias de host de recepción y transmisión se encuentran en el mismo equipo.

Suponga que hay un cuello de botella de CPU. Agrega otro equipo de BizTalk idéntico al grupo para realizar un escalamiento horizontal, lo que le proporciona dos formas de descomponer en factores las instancias de host.

A continuación se enumeran dos soluciones para este problema:

• Solución 1: La manera más sencilla de factorizar en este escenario es clonar la factorización de la instancia de host del primer equipo al segundo equipo. Por lo tanto, en términos de funcionalidad, el segundo equipo es una copia exacta del primero; también puede tener tanto hosts de recepción como de envío. Suponiendo que no hay ningún otro cuello de botella, puede obtener un factor de escalamiento de 2 dado que se duplican los recursos de CPU.

• Solución 2: Otra manera de factorizar las instancias de host es aislar las funciones de recepción y envío a distintos equipos. Por lo tanto, uno de los servidores BizTalk Server es exclusivo para la recepción y otro para el envío.

  Comparación de la solución 1 y la solución 2

  En la solución 1, el número de instancias de host se duplica con respecto a una configuración BTS. Esto significa que aumentará la contención de bloqueo en el servidor SQL Server. El aumento en contención de bloqueo determinará el factor de escalamiento. Si la contención de bloqueo está dentro de límites que puedan convertirla en un cuello de botella, puede obtener un factor de escalamiento de 2.

  La ventaja de la solución 2 es que solo tiene dos instancias de host, por lo que la contención de bloqueo en el servidor SQL Server debe ser menor en comparación con la solución 1. Sin embargo, el factor de escalado depende completamente de la complejidad de las instancias de host de recepción y envío. Considere los casos siguientes en la solución 2:

  Suponga que las instancias de host tanto de recepción como de transmisión son de la misma intensidad y cada una de ellas utiliza el 50 % de la CPU en la primera topología de servidor BizTalk Server. En la segunda topología de servidor BizTalk Server, se desplaza la instancia de host de transmisión a un equipo diferente y ahora tanto la recepción como la transmisión duplican los recursos. Esto debería proporcionar un factor de escalamiento de 2, suponiendo que no hay ningún otro cuello de botella. Este caso resulta mejor que la Solución 1 porque hay solamente dos instancias de host y, por lo tanto, una menor contención de bloqueo.

  Suponga que la transmisión es más intensa que la recepción y utiliza el 80 % de los recursos de la CPU en la primera topología de servidor BizTalk Server. Al mover la instancia del host de transmisión a otra máquina, solo se obtienen 20 % más recursos de CPU, por lo que el factor de escalado máximo será de 1,2. Además, el equipo con la instancia de host de recepción solo usará recursos de CPU del 20 al 30 %, por lo que la ventaja del escalado horizontal es mucho menor.

  Observe la siguiente ilustración, que tiene cuatro servidores BizTalk Server. Cada equipo es receptor y remitente, lo que le proporciona un total de cuatro instancias de host de cada tipo (recepción y transmisión).

  

  Esta topología podría no ser la mejor posible. También debería probar otras permutaciones de factorización, en función de la complejidad del escenario. Por ejemplo:

• Dedique dos ordenadores para recibir y dos para transmitir. Esto le dará el mejor escalamiento posible cuando tanto la recepción como el envío son igualmente intensivos.

• Dedique tres equipos a la recepción y uno a la transmisión si la recepción es más intensiva que la transmisión.

• Dedique un equipo a la recepción y tres a la transmisión si la transmisión es más intensiva que la recepción.

  En todos los escenarios, se recomienda que minimice el número de instancias de host de cada host para reducir la contención en la base de datos de cuadro de mensajes y para que, al mismo tiempo, la utilización de los recursos del equipo sea la máxima. La mejor permutación de factorización dependerá de la complejidad del escenario y del tipo de cuello de botella. Compruebe siempre la factorización antes de finalizar una permutación.

Consulte también

Escalar el nivel de BizTalk Server verticalmente
Escalar el nivel del servidor SQL Server verticalmente
Escalar horizontalmente el nivel de SQL Server
Hosts de recepción escalados horizontalmente
Hosts de procesamiento escalados horizontalmente
Hosts de envío escalados horizontalmente
Uso de un clúster de Windows Server para proporcionar alta disponibilidad para BizTalk Server hosts2
Bases de datos escaladas horizontalmente
Agrupación en clústeres de las bases de datos de BizTalk Server