Problema del servidor BizTalk

Question

tenemos un servidor biztalk (uno virtual (1!) ...) en nuestra empresa, y un servidor SQL donde se guardan los datos. Ahora tenemos mucho tráfico de datos. Estoy hablando de cientos de miles. Así que en realidad ni siquiera estoy seguro de si un servidor es bastante seguro, pero nuestra empresa no es tan fácil de convencer.

Ahora, recientemente tenemos muchos problemas.

Permitir que yo sitúo en detalle, así que no me falta nada:

Nuestro servidor tiene 5 aplicaciones:

• Uno con 3 orquestaciones, 12 puertos de envío, 16 ubicaciones de recepción.
• Uno con 4 orquestaciones, 32 puertos de envío, 20 ubicaciones de recepción.
• Uno con 4 orquestaciones, 24 puertos de envío, 20 ubicaciones de recepción.
• Uno con 47 orquestaciones (sí 47), 37 puertos de envío, 6 ubicaciones de recepción.
• Uno con aplicación común con un par de recursos.

Nuestros problemas han ocurrido desde que desplegamos las aplicaciones con las 47 orquestaciones. Muchas de estas orquestaciones usan formas de asignación que usan el código C# para realizar la asignación. Esto se debe a que utilizamos extensiones HL7 y esto es algo especial, por lo que al usar el código C# & xpath fue mucho más fácil hacer la asignación porque muchos de estos esquemas se parecen. El C# lee en XmlNodes recibidos a través de xpath, y devuelve XmlNode que luego se asignan nuevamente a los mensajes de biztalk. No estoy seguro de si esta podría ser la causa, pero pensé que lo mencionaría.

Los puertos de envío y recepción tienen muchos tipos diferentes: Archivo, MQSeries, SQL, MLLP, FTP. Cada uno de estos tipos tiene instancias de host diferentes para equilibrar la carga. Nuestras orquestaciones usan el host BiztalkApplication.

En este servidor también se ejecutan un par de scripts, en su mayoría scripts de carga ftp & también un script zipper, que comprime archivos cada media hora en un zip diario y elimina los archivos zip después de un mes. Usamos este zipscript en nuestros archivos de copia de seguridad (realizamos muchas copias de seguridad, las copias de seguridad también están en nuestro servidor), lo hicimos porque el servidor tenía problemas para enviar archivos a una ubicación donde había un montón (MUCHO) de archivos, entonces después los archivos se redujeron a las cremalleras, fue mejor.

Ahora los problemas que estamos teniendo recientemente son principalmente dos problemas principales:

• Nuestro problema más importante es la siguiente. Mantuvimos una ubicación de recepción con muchos mensajes en cola para probar. Después de que comenzamos esta ubicación de recepción que usa las 47 orquestaciones, las instancias de servicio en ejecución comienzan a destellar. Ok, esto es bastante normal. Digamos aproximadamente 10000, y luego detenemos la ubicación de recepción para ver cómo biztalk maneja estas 10000 instancias. Normalmente bajan bastante rápido, y algunas veces lo hace, pero después de un tiempo comienza a "acelerarse", lo que significa que simplemente dejan de procesarse y las instancias del servicio permanecen en el mismo número, por ejemplo, en 30 segundos baja de 10000 a 4000 y luego se queda en 4000 y baja muy muy muy lentamente, como 30 en 5 minutos o algo así. Esto significa que todas las demás instancias de servicio de las otras aplicaciones también están atrapadas aquí, y tampoco se procesan.

Notamos que después de reiniciar nuestras instancias de host, el número de instancia volvió a bajar rápidamente. Intentamos reiniciar selectivamente diferentes instancias de host para localizar el problema. Notamos que finalmente reiniciar la instancia de host de envío/recepción de archivos haría el truco. Así que pensamos que el envío de archivos sería el problema. Concordando que hacemos muchas copias de seguridad. Así que reemplazamos las copias de seguridad de tipo de archivo con copias de seguridad de mqseries. El mismo problema ocurrió, y lo curioso, reiniciar el host de envío/recepción de archivos aún soluciona el problema.

No se encontraron errores en el visor de eventos tampoco.

• Un segundo problema que tenemos es. Que a veces alrededor de las 6 a. M., Se detienen todas o parte de las instancias del host.

En el visor de sucesos nos dimos cuenta de los errores siguientes (estos son más de uno):

The receive location "MdnBericht SQL" with URL "SQL://ZNACDBPEG/mdnd0001/" is shutting down. Details:"The error threshold has been exceeded. The receive location is shutting down.".

The Messaging Engine failed to add a receive location "M2m Othello Export Start Bestand" with URL "\m2mservices\Othello_import$\DataFilter Start*.xml" to the adapter "FILE". Reason: "The FILE adapter cannot access the folder \m2mservices\Othello_import$\DataFilter Start. Verify this folder exists. Error: Logon failure: unknown user name or bad password. ".

The FILE adapter cannot access the folder \m2mservices\Othello_import$\DataFilter Start. Verify this folder exists. Error: Logon failure: unknown user name or bad password.

An attempt to connect to "BizTalkMsgBoxDb" SQL Server database on server "ZNACDBBTS" failed. Error: "Login failed for user ''. The user is not associated with a trusted SQL Server connection."

Se woould parece que hay una falta de la conexión en este momento y que, debido a que otros servicios también están experimentando problemas y, finalmente, se cierran.

El caso es que nuestro usuario es administrador, y es imposible que su contraseña sea incorrecta "a veces". Hemos llegado a la conclusión de que el problema podría deberse a un problema de infraestructura, pero ese no es el departamento.

Sé que es una publicación larga, pero ya no estamos seguros de qué hacer. ¿Sumaríamos otro problema al agregar otro servidor y al equilibrar la carga? ¿Hay alguna manera de medir nuestro equilibrio y saber por dónde empezar a dividir? ¿Cuáles son los números normales de carga, etc.?

Agradezco cualquier respuesta porque estos problemas están empeorando y también estamos en una fecha límite.

¡Muchas gracias por las respuestas!

Answer 1

Su problema inmediato es BizTalk throttlingfeature. Se supone que ayuda a BizTalk a sobrevivir condiciones de sobrecarga temporal. Uno de sus muchos problemas es que puede ver la aceleración de aceleración solo en el monitor de rendimiento y no en el registro de eventos.

Lo que debe hacer:

1. independiente la nueva aplicación a un host diferente que el resto de las aplicaciones. La regulación se realiza en el nivel de host. Entonces, la aplicación problemática no afectará el resto de las aplicaciones.
2. Lea acerca de cómo deshabilitar la regulación en el enlace de arriba.
3. Lo que hemos hecho es implementar un servicio externo de aceleración. Que alimenta la ubicación de recepción de BizTalk en pequeños paquetes digeribles. Es feo, pero el problema es feo.

Actualiza para comentar: Tienes suficientes instancias de host. Entonces ignora ese consejo. Puede reordenar las aplicaciones entre las instancias. Pero no hay pautas claras para hacer eso. Así que es solo arrastrando los pies y adivinando.
Acerca de la seguridad de deshabilitar la aceleración. Esta característica no tiene mucho sentido en muchos escenarios. Tienes que estudiarlo. Compruebe cuál de los parámetros de regulación está alcanzando (esto se puede ver en el monitor de rendimiento) y decida cómo cambiar los umbrales.

Answer 2

¿Cuántas instancias de host tiene?

Desde la línea:

The send and receive ports have a lot of different types: File, MQSeries, SQL, MLLP, FTP. Each of these types have a different host instances, to balance out the load. Our orchestrations use the BiztalkApplication host

Parece que usted tiene un montón - Hace poco hice una auditoría de un sistema en el que se auto BizTalk estrangulación y la cuestión era, en parte, debido a demasiados casos de acogida. Cada instancia de host coloca su propia carga en el cuadro de mensaje de BizTalk, así como mastica un mínimo de 200 mb de memoria.

Al leer su comentario, tiene 20 - esto es demasiado y sería una gran parte de sus problemas.

Una buena parte del servidor de partida sería:

• Un seguimiento específico de acogida
• Un host que contiene todos reciben los controladores para los adaptadores
• Un host que contiene todas las orquestaciones
• Un host que contiene todos los controladores de envío para adaptadores
• Un host para adaptadores que deben agruparse (como FTP y MSMQ)

También puede considerar introducir hosts "en tiempo real" y hosts por lotes, para que pueda sintonizar los hosts en tiempo real con baja latencia.

También puede tener hosts para aplicaciones específicas si se sabe que son inestables, pero en general esto no se debe hacer.

Answer 3

Ejecuto un sistema BizTalk que tiene problemas similares y puede empatizar con lo que está viendo. No sé si es lo mismo, pero pensé que compartiría mi experiencia por si acaso.

De la misma manera, el reinicio del envío/recepción parece solucionar el problema. En mi caso, encontré una correlación directa con el uso de la memoria por los procesos de host. Usé los contadores de rendimiento para ver cuándo se estrangulaba un host determinado para memoria. Al crear hosts adicionales y mover orquestaciones y puertos entre ellos, pude determinar qué conjuntos de negocios estaban causando el problema. Básicamente, en mi caso reiniciar los hosts fue el equivalente a la última "recolección de basura" para liberar memoria. Esto fue, por supuesto, hasta que llegaron suficientes casos para devorarlo nuevamente.

Me temo que no hemos resuelto el problema todavía, pero algunas cosas que encontré para aliviar el problema:

1. elevar la memoria para un proceso determinado de manera que no se produce estrangulación o que ocurra más tarde
2. Cada instancia de host, aunque es informativa, sí tiene una sobrecarga que se agrega. Intente combinar hosts que no son sus hijos problemáticos para reducir la huella de memoria.
3. hardware de lanzar en el problema, la memoria RAM es barato

4. mido el siguiente cada pocos minutos en el Monitor de rendimiento para que pueda diagnosticar dónde está el problema:

   BizTalk: MessageAgent (*) \ uso de memoria de proceso (MB)

   BizTalk: MessageAgent (*) \ Proceso umbral de uso de la memoria

   memoria \ MBytes disponibles

Algunas otras cosas para ver. Asegúrese de que las tuberías personalizadas utilicen buenas prácticas de memoria BizTalk (es decir, que no haya manipulación XML DOM escondida en algún lugar, etc.). También, teóricamente, la reducción del número de subprocesos para un host determinado debería reducir la cantidad de memoria que puede aprovechar a la vez. No parecía tener mucha suerte con este. Tal vez el estrangulamiento de BizTalk lo sobrepasó, como otros lo han mencionado, no lo sé. Además, en una nota final, si descarga los resultados perfmon a un csv, con Excel puede hacer algunos gráficos de uso de memoria bonitos. Estos pueden ser útiles para hablar con la gerencia sobre la compra de más hardware. Eso supone que su problema también se ajusta a este escenario.

Answer 4

Hemos solucionado el problema temporalmente debido a una combinación de todas sus respuestas.

Configuramos los parámetros de aceleración del uso de la memoria de proceso de algunos hosts más.

Dividimos el equilibrio de las instancias de host mejor después de analizar todo el uso de memoria de todos los hosts, gracias a los contadores de rendimiento y también con el uso de una herramienta llamada MsgBoxViewer.

Y ahora estamos tratando de obtener más memoria física & con suerte también un servidor adicional o un servidor de 64 bits.

¡Gracias por todas las respuestas!

Answer 5

Instalamos recientemente un servidor de 64 bits en clúster con nuestro servidor anterior. Gracias a esto podemos equilibrar la memoria aún mejor, lo que resolvió muchos problemas.

pesar de que el 64 bits no nos dio mucho mejoras (a excepción de un poco más de memoria) ya que no puede utilizar los 64 bits de IBM MQ de, MLLP de, tuberías, etc ... HL7

Answer 6

El otras respuestas son útiles para la optimización del rendimiento en tiempo de ejecución, pero también recomendaría un cambio de diseño.

Dice que hace mucha manipulación de mensajes en la orquestación en las formas de asignación de mensajes.

Recomendaría mover ese código a transformaciones dedicadas. Son mucho más livianos y se pueden ejecutar más rápido. Puede combinar xslt personalizado y c# en estos mapas para hacer el trabajo duro. Las orquestaciones cuestan más en desarrollo, diseño y pruebas, y mucho más en rendimiento en tiempo de ejecución.

Puede usar transformaciones para la transformación de mensajes y dejar la orquestación (lo que queda después de mover el código de asignación de mensajes) a las orquestaciones.

El beneficio adicional de usar transformaciones en lugar de orquestaciones es que son mucho más comprobables.