我们有一个用于 BizTalk 的虚拟机和一个用于 SQL 后端的单独虚拟机。我们使用 Veeam 进行备份，这基本上会启动虚拟机的快照。当此快照在 SQL VM 上最终确定时，应用程序服务器上的 BizTalk 服务将失败。通常它们会自动重新启动，但有时这需要手动干预才能启动服务。 BizTalk 服务器上记录了以下错误。
是否有任何超时设置或配置更改允许 BizTalk 服务在快照过程中保持正常状态？
发生错误，需要终止 BizTalk 服务。最常见的原因如下：
1) 意外的内存不足错误。
或者
2) 无法连接或丢失与 BizTalk 数据库之一的连接。
该服务将在 1 分钟内关闭并自动重新启动。如果有问题的数据库仍然不可用，则将重复此循环。
错误消息：[DBNETLIB][ConnectionRead (recv()).]一般网络错误。检查您的网络文档。
错误来源：
BizTalk 主机名：BizTalkServerApplication
Windows 服务名称：BTSSvc$BizTalkServerApplication
我们在 BizTalk 2009 和 BizTalk 2013 上都遇到了相同的情况和错误，每个服务器都设置了两台应用程序服务器和一台 SQL DB 服务器。
当我们的VMware在应用程序服务器上执行快照备份的最后一步时，它会冻结应用程序服务器大约10秒，以防止其接收数据包。在 SQL Server 2008 和 2012 上，默认情况下，它会每 30 秒（30,000 毫秒）向客户端发送一次保持活动数据包。如果 SQL 服务器无法从应用程序服务器收到响应，它将每隔 1 秒（1,000 毫秒）重试 5 次保持活动请求（默认设置）。如果 SQL 仍然没有收到响应，它将终止连接，这将导致应用程序服务器上的 BizTalk 主机重置，在我们的例子中，当我们的德国制造 ERP 系统在此期间将其 EDI 文档发送到 BizTalk复位期间，传输将失败。
我们通过在数据库和应用程序服务器上运行 NetMon 来捕获该问题，等待下一条错误消息。经检查，我们看到 5 个 SQL keep-alive 数据包间隔 1 秒发送到应用程序服务器，同时应用程序服务器上根本没有收到任何数据包。乍一看，人们可能会认为它们“只是丢弃了网络数据包”，但这种情况很少见。然后，我们对虚拟机快照的时间进行了关联，现在确认每天快照每次完成时，应用程序服务器都会冻结。
作为中短期解决方法，我们通过添加注册表值 TcpMaxDataRetransmissions 并将其设置为 30（即 SQL 声明连接之前 30 秒），提高了声明连接失效之前 SQL 重试的次数（默认为 5）。客户端无响应）。这暂时为我们掩盖了问题，请自行决定使用。
我们还在研究基于代理的虚拟机快照版本，这可能会缓解服务器冻结的情况。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
