BizTalk服务器问题

Question

我们公司有一个biztalk服务器(一个虚拟的(1!)...)和一个保存数据的sql server.现在我们有很多数据流量.我说的是成千上万.所以我实际上不确定一台服务器是否相当安全,但我们的公司并不那么容易说服.

最近我们遇到了很多问题.

请允许我详细说明,所以我没有遗漏任何东西:

我们的服务器有5个应用:

• 一个有3个编排,12个发送端口,16个接收位置.
• 一个有4个业务流程,32个发送端口,20个接收位置.
• 一个有4个编排,24个发送端口,20个接收位置.
• 一个有47个(是47个)编排,37个发送端口,6个接收位置.
• 一个具有几个资源的常见应用程序.

自从我们使用47个业务流程部署应用程序以来,我们遇到了问题.很多这些编排使用赋值形状,使用c#代码进行映射.这是因为我们使用HL7扩展,这是一种特殊的,所以通过使用c#code和xpath,映射更容易,因为很多这些模式看起来很相似.c#读入通过xpath接收的XmlNodes,并返回XmlNode,然后再将其分配给biztalk消息.我不确定这可能是原因,但我想我会提到它.

发送和接收端口有许多不同的类型:文件,MQSeries,SQL,MLLP,FTP.每种类型都有不同的主机实例,以平衡负载.我们的业务流程使用BiztalkApplication主机.

在这个服务器上还运行了几个脚本,主要是ftp上传脚本和拉链脚本,每天拉链文件每半小时压缩一次,并在一个月后删除zip文件.我们在备份文件上使用这个zipscript(我们备份很多,备份也在我们的服务器上),我们这样做是因为服务器在将文件发送到有很多(很多)文件的位置时出现问题,所以之后文件减少到拉链它变得更好.

现在我们最近遇到的问题主要是两个主要问题:

• 我们最重要的问题如下.我们在队列中保留了一个包含大量消息的接收位置以进行测试.在我们启动这个使用47个业务流程的接收位置之后,正在运行的服务实例开始转向天空.好的,这很正常.假设大约10000,然后我们停止接收位置以查看biztalk如何处理这10000个实例.通常情况下它们会很快下降,有时会发生故障,但过了一段时间它会开始"节流",这意味着它们只是停止处理并且服务实例保持相同的数字,例如在30秒内它从10000下降到4000,然后它保持在4000并且非常非常缓慢地降低,例如在5分钟或者30分钟内降低30.所以这意味着,其他应用程序的所有其他服务实例也都停留在这里,并且它们也没有被处理.

我们注意到在重新启动主机实例后,实例编号再次快速下降.因此,我们尝试有选择地重新启动不同的主机实例以找到问题.我们注意到最终重新启动文件发送/接收主机实例就可以了.所以我们认为文件发送会成为问题.结合我们做了很多备份.所以我们用mqseries备份替换了文件类型备份.发生同样的问题,有趣的是,重新启动文件发送/接收主机仍然可以解决问题.

在事件查看器中也找不到任何错误.

• 我们遇到的第二个问题是.有时在早上6点左右,全部或部分主机实例正在停止.

在事件查看器中,我们注意到以下错误(这些错误不止一个):

具有URL"SQL:// ZNACDBPEG/mdnd0001 /"的接收位置"MdnBericht SQL"正在关闭.详细信息:"已超出错误阈值.接收位置正在关闭.".

消息传递引擎无法将具有URL"\ m2mservices\Othello_import $\DataFilter Start*.xml"的接收位置"M2m Othello Export Start Bestand"添加到适配器"FILE".原因:"FILE适配器无法访问文件夹\ m2mservices\Othello_import $\DataFilter Start.验证此文件夹是否存在.错误:登录失败:未知用户名或密码错误."

FILE适配器无法访问文件夹\ m2mservices\Othello_import $\DataFilter Start.确认此文件夹存在.错误:登录失败:未知的用户名或密码错误.

尝试连接到服务器"ZNACDBBTS"上的"BizTalkMsgBoxDb"SQL Server数据库失败.错误:"用户登录失败".用户未与受信任的SQL Server连接关联.

似乎此时登录失败,因此其他服务也遇到问题,最终它们被关闭.

问题是,我们的用户是管理员,并且"有时"密码错误是不可能的.我们已经确认问题可能是由于基础设施问题,但这不是真正的部门.

我知道这是一个很长的帖子,但我们不确定该怎么做.添加另一台服务器并平衡负载会解决我们的问题吗？有没有办法确保我们的平衡,并知道从哪里开始拆分？什么是正常的负载等？

我感谢任何答案,因为这些问题越来越严重,我们也处于最后期限.

非常感谢您的回复!

Answer 1

您当前的问题是BizTalk 限制 功能.它应该帮助BizTalk在临时过载条件下生存.其中的一个问题是,您只能在性能监视器中看到限制启动,而不是在事件日志中.

你应该做什么:

1. 将新应用程序分离到与其他应用程序不同的主机.限制在主机级别完成.因此,有问题的应用程序不会影响其余的应用程序.
2. 阅读有关如何在上面的链接中禁用限制的内容.
3. 我们所做的是实施外部限制服务.这将BizTalk接收位置提供给易消化的小包.它很难看,但问题很难看.

更新评论:您有足够的主机实例.所以忽略这个建议.您可以在实例之间重新排序应用程序.但是没有明确的指导方针可以做到这一点.所以它只是在洗牌和猜测.
关于禁用限制的安全性.在许多情况下,此功能没有多大意义.你必须要研究它.检查您正在击中哪个限制参数(这可以在性能监视器中看到)并确定如何更改阈值.