在虚拟机快照期间，BizTalk与SQL的连接问题 [英] BizTalk connectivity issue to SQL during VM snapshot

问题描述

我们有一个用于BizTalk的VM和一个用于SQL后端的单独的VM。我们使用Veeam进行备份，这基本上启动了VM的快照。在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服务器没有收到App服务器返回的响应，它会间隔1秒(1000ms)发送5次重试(默认设置)的Keep-Alive请求。如果SQL仍然没有收到响应，它将终止连接，这将导致应用服务器上的BizTalk主机重置，在我们的例子中，当我们的德国制造的ERP系统在重置期间将其EDI文档发送到BizTalk时，传输将失败。

我们通过在数据库和应用程序服务器上运行NetMon，等待下一条错误消息来捕获该问题。经过检查，我们看到五个SQL Keep-Alive包被间隔1秒发送到App服务器，同时应用服务器上根本没有收到任何包。乍一看，人们可能会认为它们是"只是丢弃了网络数据包"，但事实并非如此。然后，我们将其与VM快照的时间关联起来，现在确认每天快照每次完成时，应用程序服务器都会冻结。

作为一种中短期解决办法，我们通过添加注册表值TcpMaxDataRetransments并将其设置为30(因此，在SQL声明客户端无响应之前30秒)，提高了在宣布连接失效之前的SQL重试次数(默认情况下为5次)。这暂时掩盖了我们的问题，您可以自行决定是否使用。

我们还在考虑基于代理的VM快照版本，这可能会缓解冻结服务器的情况。

这篇关于在虚拟机快照期间，BizTalk与SQL的连接问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！