适用于:Azure Stack HCI 版本 22H2、Windows Server 2022、Windows Server 2019
如果你已经为软件定义的网络 (SDN) 设置了软件负载均衡器 (SLB),但数据路径无法通过 SLB 工作,则幕后可能有多种原因。 本文帮助你识别和排查 SDN 的 SLB 的一些常见问题。
有关 SLB 及其管理方法的概述,请参阅什么是 SDN 的软件负载均衡器 (SLB)?和管理 SDN 的软件负载均衡器。
故障排除工作流
下面是排查 SLB 问题的概要工作流:
- 检查 SLB 多路复用器 (MUX) VM 的配置状态
- 排查常见配置状态错误
- 收集 SLB 状态转储
检查 SLB 多路复用器 VM 的配置状态
必须先检查 SLB MUX VM 的配置状态。 为此,可以使用 Windows Admin Center 或 PowerShell。
按照以下步骤通过 Windows Admin Center 检查 SLB MUX 的配置状态:
排查常见配置状态错误
本部分介绍如何排查 SLB MUX VM 的配置状态不正常时的常见错误。
SLB MUX 未连接到 BGP 路由器
如果 MUX VM 无法与架顶式 (ToR) 交换机建立边界网关协议 (BGP) 对等互连,则会发生此错误。 请记住,MUX 在端口 179 上通过 BGP 对等互连到 ToR。
若要解决 MUX VM 和 BGP 路由器连接错误:
确保 MUX VM 和 ToR 交换机之间已建立连接。 如果你正在使用网络虚拟化,则对等互连应通过 Hyper-V 网络虚拟化提供商地址 (HNV PA) 网络建立。
通过在 MUX VM 上运行以下命令来检查是否已建立连接:
Netstat -anp tcp | findstr 179
如果 MUX 和 ToR 之间未建立连接,请使用
Test-NetConnection
检查是否可以从 MUX 访问 ToR。 如果 MUX 无法访问 ToR,则表示底层结构网络或 ToR 有问题。Test-NetConnection -ComputerName <ToR_IP> -Port 179
其中:
- ToR_IP 是 loadBalancerMuxes 资源的一部分。
下面是 LoadBalancerMux 资源的片段,其 ToR IP 地址为 192.168.200.1:
Get-NetworkControllerLoadBalancerMux -ConnectionUri $uri|ConvertTo-Json -Depth 10 "peerRouterConfigurations": [ { "localIPAddress": "", "routerName": "BGPGateway-64000-64001", "routerIPAddress": "192.168.200.1", "peerASN": 64001, "id": "be5850aa-4dce-4203-a9f2-f3de25eaacba" }
如果配置了多个交换机,请确保所有交换机都已与 MUX VM 对等互连。
若要进一步调试与 BGP 对等互连失败相关的问题,请在任何物理主机上运行
Test-SDNExpressBGP
脚本:Install-Module test-sdnexpressbgp Test-SDNExpressBGP -RouterIPAddress 10.10.182.3 -LocalIPAddress 10.10.182.7 -LocalASN 64628 -verbose -ComputerName sa18n22mux02 -force
其中:
RouterIPAddress
是 ToR IPLocalIPAddress
是 SLBMUX VM 的 PA IP 地址LocalASN
是 SDN SLB ASNComputerName
是 SLBMUX VM 的名称
该脚本停止 MUX VM 上的 SLBMUX 服务,尝试建立连接(结果为失败或完成),并在失败时提供更多详细信息。
无法访问虚拟服务器
你可能因网络错误或虚拟服务器上拒绝身份验证而收到此错误。 这通常表示网络控制器无法连接到 SLB MUX VM。
若要排查无法访问虚拟服务器的原因,请检查:
网络控制器和 MUX VM 之间已建立连接。 若要检查连接性,请运行以下命令:
Test-NetConnection -ComputerName <MUX IP address> -Port 8560
MUX 服务在 MUX VM 上运行。 若要进行此项检查,请从 MUX VM 上的 PowerShell 会话运行以下命令。 状态必须为“正在运行”。
Get-Service slbmux
不存在防火墙问题。 确保端口 8560 未被 MUX VM 上的防火墙阻止。 如果
Test-NetConnection
命令成功,则表示不存在防火墙问题。
证书不受信任或证书未获授权
如果 SLB MUX 提供给网络控制器的证书有问题,你可能会收到此错误。
若要识别证书,请在 MUX VM 上运行以下命令:
$cert= get-childitem "cert:\localmachine\my"| where-object {$_.Subject.ToUpper() eq "CN=$NodeFQDN".ToUpper()}
其中:
NodeFQDN
是 MUX VM 的 FQDN。
识别证书后,检查证书:
若要测试证书,请运行以下命令:
Test-Certificate $cert
确保证书受网络控制器 VM 的信任。 如果该证书是自签名证书,则所有网络控制器 VM 的根存储中必须存在相同的证书。 如果该证书由 CA 签名,则所有网络控制器 VM 的根存储中必须存在 CA 证书。 若要列出网络控制器 VM 的根存储中的所有证书,请在所有网络控制器 VM 上运行以下命令:
get-childitem "cert:\localmachine\root"
策略配置失败
此错误可能表现为下列其中一项:PolicyConfigurationFailureonHost、PolicyConfigurationFailureonMux、PolicyConfigurationFailureonVfp 或 PolicyConfigurationFailure。
如果网络控制器由于可访问性、证书问题或任何其他问题而无法将策略推送到 SLB MUX VM 或 Hyper-V 主机,就会发生此错误。
若要排查策略配置失败错误,请首先检查是否存在任何可访问性和证书问题。 请参阅前面部分中的步骤:SLB MUX 未连接到 BGP 路由器、无法访问虚拟服务器和证书不受信任或证书未获授权。
如果不存在任何可访问性和证书问题,请执行以下步骤以检查网络控制器与 SLB MUX VM 和主机上的 SLB 主机代理之间的连接:
检查网络控制器与 SLB MUX VM 之间的连接。 请记住,网络控制器(SlbManager 服务)通过端口 8560 连接到 MUX。 网络控制器启动连接。 各种虚拟 IP 地址 (VIP) 配置、源网络地址转换 (SNAT) 端口等都是通过此连接推送的。
若要检查网络控制器与 SLB MUX 之间的连接,请在 SLB MUX VM 上运行
netstat
。下面是所用命令的示例输出:
netstat -anp tcp | findstr 8560 TCP 0.0.0.0:8560 0.0.0.0:0 LISTENING TCP 100.88.79.12:8560 100.88.79.9:59977 ESTABLISHED
检查网络控制器与 SLB 主机代理之间的连接。 请记住,SLB 主机代理通过端口 8571 连接到网络控制器(SlbManager 服务)。 各种 SLB 策略都是通过此连接推送的。
若要检查网络控制器与 SLB 主机代理之间的连接,请在物理主机上运行
netstat
。下面是所用命令的示例输出:
netstat -anp tcp | findstr 8571 TCP 100.88.79.128:56258 100.88.79.9:8571 ESTABLISHED
数据路径连接问题
即使 SLB MUX VM 处于正常配置状态,也可能会出现数据路径连接问题。 这意味着 SLB 流量在中途被丢弃。 若要确定丢弃流量的位置,需要收集数据路径跟踪。 在执行此操作之前,请确保满足以下条件:
ToR 交换机可以看到播发的 VIP。 由于已经为负载均衡、入站 NAT、出站 NAT 或其组合设置了负载均衡器,因此负载均衡器 VIP 已播发给 ToR。 使用交换机 CLI 检查 VIP 是否已播发。
不得在 ToR 或任何物理防火墙上阻止 SLBM VIP。 这是在网络控制器的 LoadBalancerManager/config 资源中指定为 loadBalancerManagerIPAddress 的 IP 地址。 当入站数据包已传入并且 MUX VM 确定了要将数据包发送到的正确后端 IP 时,它会发送源 IP 地址为 MUX SLBM VIP 的数据包。 在某些情况下,可能会在 ToR 中丢弃该数据包。
SLB 运行状况探测已启动。 如果已配置 SLB 运行状况探测,请确保至少有一个后端 VM 处于活动状态,并且它能够响应运行状况探测。 还可以按本文稍后所述,通过 SLB 状态转储获取探测的状态。
后端 VM 中的防火墙未阻止流量。 确保后端 VM 中的主机防火墙未阻止传入的 SLB 流量。
SDN 网络安全组未阻止流量。 你可能直接在后端 NIC 或子网上配置了一些网络安全组。 确保网络安全组未阻止传入的 SLB 流量。
若要通过 PowerShell 检查网络安全组,请在可以向网络控制器发出 REST 命令的计算机上运行以下命令:
若要获取 NetworkInterface 资源的详细信息,请运行以下命令:
Get-NetworkControllerNetworkInterface –ConnectionUri <REST uri of Network Controller> -ResourceId <Resource ID of the backend NIC>|ConvertTo-Json –Depth 10
若要获取 VirtualNetworkSubnet 资源的详细信息,请运行以下命令:
Get-NetworkControllerVirtualNetwork –ConnectionUri <REST uri of Network Controller> -ResourceId <Resource ID of the network>|ConvertTo-Json –Depth 10
若要获取 LogicalNetworkSubnet 资源的详细信息,请运行以下命令:
Get-NetworkControllerLogicalNetwork –ConnectionUri <REST uri of Network Controller> -ResourceId <Resource ID of the network>|ConvertTo-Json –Depth 10
上述命令的输出包含一个
AccessControlList
节。 可以检查是否有任何AccessControlList
附加到这些资源。 如果有,可以运行以下命令来验证AccessControlList
的详细信息,以检查AccessControlList
是否阻止了任何 SLB 流量:Get-NetworkControllerAccessControlList –ConnectionUri <REST uri of Network Controller> - ResourceId <Resource ID of the AccessControlList>|ConvertTo-Json –Depth 10
还可以使用以下 Windows Admin Center 扩展查找所有这些信息:
- “逻辑网络”显示逻辑网络详细信息
- “虚拟网络”显示虚拟网络详细信息
- 使用“网络安全组”扩展查找 ACL 详细信息
收集 SLB 状态转储
如有必要,可以创建 SLB 状态转储并检查是否有任何错误。 此外,可与 Microsoft 共享状态转储以便进行高级故障排除。 SLB 状态转储提供有关所有 VIP 的端到端信息。 可以运行 DumpSlbRestState.ps1 脚本来收集 SLB 状态转储。 以下部分描述了可以在状态转储中检查的各种错误情况。
检查 MuxAdvertisedRoutes 是否为空或缺少受影响的 VIP
下面是 MuxAdvertisedRoutes
为空的示例。 这意味着 MUX 不会向 ToR 播发任何路由。 在这种情况下,所有 VIP 都已关闭。
"name": "MuxRoutes",
"description": "Mux Routes",
"dataRetrievalFailed": false,
"dataUnits": [
{
"value": [
"MuxAdvertisedRouteInfo: MuxId=3951dc43-4764-4c65-a4b5-35558c479ce6 MuxDipEndpoint=[172.24.47.12:8560] MuxAdvertisedRoutes=[]",
"MuxAdvertisedRouteInfo: MuxId=a150f826-6069-4da7-9771-642e80a45c8d MuxDipEndpoint=[172.24.47.13:8560] MuxAdvertisedRoutes=[]"
如果路由为空,则问题可能与 MUX-ToR 对等互连有关,或者是因为 SLBM 未推送正确的目标状态。
还有一些情况是路由仅缺少几个 VIP,导致仅与这些 VIP 连接失败。 如果是这样,问题在于 SLBM 未推送目标状态。
缓解
移动 SlbManager 服务和 ControllerService 的主要节点并重启主机代理。
若要移动 SlbManager 和 ControllerService 的主要节点,请在网络控制器 VM 上运行以下命令:
若要确定网络控制器服务模块将哪个节点用作主要节点,请运行以下命令:
Get-NetworkControllerReplica
找到 SlbManagerService 和 ControllerService 的 NodeName。 转到相应的节点并运行以下命令:
Get-Process Sdnctlr| Stop-Process and Get-Process SdnSlbm | Stop-Process
这会在不同的网络控制器 VM 上重启进程。
若要重启主机代理,请在每台物理主机上运行以下命令:
Restart-Service nchostagent --force Start-Service slbhostagent
检查 VipAddress 的编程和连接状态
此 SLB 状态转储部分提供了有关 VIP 的详细信息。 它提供了 SLBM、MUX 和主机上 VIP 的状态。 在主机下,它会转储当前属于 VIP 的所有 DIP。 确保列表与配置一致。 如果问题在于出站连接,请检查 SNAT 配置并确保 MUX 和主机之间的端口分配一致。
"name": "192.168.102.1",
"value": [
"Programming and Connectivity state for VipAddress: 192.168.102.1",
收集数据路径跟踪
如果上述方法均无法解决问题,请收集数据路径日志并将其发送给我们。
收集以下日志:
- 网络控制器数据收集日志。 有关如何收集 SDN 日志的信息,请参阅收集软件定义的网络日志。
应仅收集短时间内的以下日志。 开始记录日志,重现场景,然后停止记录日志。
MUX 跟踪。 必须在 MUX VM 上收集这些跟踪。 按照以下步骤收集跟踪:
若要开始记录日志,请运行以下命令:
netsh trace start tracefile=c:\mux.etl globallevel=5 provider=`{645b8679-5451-4c36-9857-a90e7dbf97bc`} provider=`{6C2350F8-F827-4B74-AD0C-714A92E22576`} ov=yes report=disabled
重现场景。
若要停止记录日志,请运行以下命令:
netsh trace stop
若要将 ETL 格式的跟踪文件转换为指定的格式,请运行以下命令:
netsh trace convert input=<trace file> ov=yes
SLB 主机代理跟踪。 必须在物理主机上收集这些跟踪。 按照以下步骤收集跟踪:
若要开始记录日志,请运行以下命令:
netsh trace start tracefile=c:\slbHA.etl globallevel=5 provider=`{2380c5ee-ab89-4d14-b2e6-142200cb703c`} ov=yes report=disabled
重现场景。
若要停止记录日志,请运行以下命令:
netsh trace stop
若要将 ETL 格式的跟踪文件转换为指定的格式,请运行以下命令:
netsh trace convert input=<trace file> ov=yes
VFP 跟踪。 必须在具有 MUX VM 和租户 VM 的物理主机上收集这些跟踪。 按照以下步骤收集跟踪:
若要开始记录日志,请运行以下命令:
Netsh trace start scenario=virtualization capture=yes capturetype=both tracefile=vfp.etl ov=yes report=di
重现场景。
若要停止记录日志,请运行以下命令:
netsh trace stop
若要将 ETL 格式的跟踪文件转换为指定的格式,请运行以下命令:
netsh trace convert input=<trace file> ov=yes