Azure Pipeline托管代理：WIN-与fv-az类型MSDTC网络故障差异问询

背景概述 #

在Azure Pipeline的windows-2022微软托管代理中运行流水线时，我们启动SQL Server容器作为数据库服务器，让代理本地应用与容器化数据库进行通信。已在代理及容器中执行以下DTC网络配置命令：

Set-DtcNetworkSetting -DtcName 'Local' -AuthenticationLevel 'NoAuth' -InboundTransactionsEnabled $true -OutboundTransactionsEnabled $true -RemoteClientAccessEnabled $true -RemoteAdministrationAccessEnabled $true -XATransactionsEnabled $true -Confirm:$false

同时在代理中执行命令允许DTC通过防火墙：

Enable-NetFirewallRule -DisplayGroup "Distributed Transaction Coordinator"

但观察到两类微软托管Windows代理表现完全不同：

• 以WIN-开头的代理（如WIN-IIS1P4PRUUV）：无MSDTC错误，流水线正常执行
• 以fv-az开头的代理（如fv-az378-745）：即使配置相同，仍出现MSDTC通信错误：

The MSDTC transaction manager was unable to pull the transaction from the source transaction manager due to communication problems. Possible causes are: a firewall is present and it doesn't have an exception for the MSDTC process, the two machines cannot find each other by their NetBIOS names, or the support for network transactions is not enabled for one of the two transaction managers.

而在独立的windows-2022虚拟机中执行完全相同的配置，可正常运行。

两类代理的核心差异 #

这两类代理的底层宿主架构存在本质区别：

• WIN-开头的代理：属于经典Azure虚拟机（VM）托管的代理，基于传统的Azure VM实例构建，主机名遵循传统Windows命名规则，网络环境默认对NetBIOS解析、跨进程/容器的DTC通信支持更友好。
• fv-az开头的代理：属于Azure虚拟机规模集（VMSS）托管的代理，是微软推出的较新托管代理架构，主机名由VMSS的自动命名规则生成，底层网络隔离策略、系统初始配置与经典VM代理存在差异。

MSDTC故障的根因分析 #

MSDTC分布式事务严重依赖NetBIOS名称解析来建立跨节点（代理主机与容器）的通信，结合两类代理的差异，故障原因可归纳为两点：

1. NetBIOS名称解析异常
   虽然fv-az开头的主机名长度通常未超过NetBIOS的15字符限制，但VMSS环境下的NetBIOS名称生成逻辑与经典VM不同，可能存在名称截断、注册异常的情况，导致容器无法通过NetBIOS名称找到代理主机，进而无法建立DTC事务连接。
2. 网络策略与端口限制
   VMSS托管的代理默认采用更严格的内部网络安全策略：
   • 即使手动开启了DTC防火墙组规则，VMSS的网络安全组（NSG）或主机防火墙可能存在额外规则，拦截了DTC依赖的135端口（RPC端点映射）以及动态端口范围（默认49152-65535）的通信。
   • 经典VM代理的初始网络配置对容器与主机的内部通信限制更少，而VMSS代理的默认隔离策略会阻断这类未显式授权的跨节点通信。

验证与排查方向 #

针对fv-az开头的代理，可通过以下步骤进一步定位问题：

• 在代理主机执行nbtstat -n命令，查看当前注册的NetBIOS名称，确认其有效性；
• 在SQL Server容器内尝试ping代理主机的NetBIOS名称，验证名称解析是否正常；
• 检查代理主机的防火墙规则，确认除了DTC组规则外，是否允许135端口及DTC动态端口的入站/出站通信；
• 查看VMSS关联的NSG规则，确认是否放行容器与主机之间的DTC相关端口流量。

内容的提问来源于stack exchange，提问作者Manas