简介这是一份面向企业IT运维与系统管理员的中文技术资料围绕Windows Server 2019自带的网络负载均衡NLB软负载方案展开适合需要搭建高可用服务器集群、规避单点故障的初中级运维人员参考。文档从NLB概念与适用边界讲起明确负载场景中不宜部署数据库、存储推荐以NAS或分布式存储为主而SAN适用性有限并交代双服务器、多网卡、心跳线及网络聚合等环境要求进而给出安装角色与功能、创建NLB群集、设置群集操作模式与心跳参数、模拟故障测试的完整图文流程可对照案例中的物理IP、心跳IP与虚拟IP配置逐步落地。资源包共1个文件为PDF格式大小约2.03MB正文配有操作截图按目录分章便于快速定位角色安装、群集创建与测试环节。该资料已有2227人学习下载可作为部署Windows NLB并验证负载分发效果时的实操参照。1. 两台 IIS 扛不住的时候我为什么选了 Windows 自带的 NLB去年帮一家做医疗影像的客户做内网系统迁移两台 Windows Server 2019 上跑 IIS 的 PACS 查询前端白天门诊高峰一开单台机器的连接数直接顶到八千,CPU 没满但 TCP 队列堆积,页面响应从 200ms 涨到 3 秒。他们问我上 Nginx 还是上 F5,我的答案是先用 Windows Server 2019 自带的网络负载均衡Network Load BalanceNLB。理由很朴素:这个场景是典型的四层分发,流量模型简单,没有复杂的 URI 路由和会话保持策略,而 NLB 是操作系统角色,装完就能用,不需要多维护一套中间件和它的高可用。NLB 把两台服务器聚合成一个群集,对外只暴露一个虚拟 IP,客户端根本不知道背后有几台机器。任意一台物理机宕掉,流量会在几百毫秒内被其他节点接管,这是它最核心的价值——用系统自带能力换来业务连续性,而不是靠运维半夜爬起来重启。适合谁:手里有 2 到 32 台 Windows Server、跑 IIS/SMB/RDP 这类四层服务、又不想引入额外负载组件的团队。不适合谁:需要按 URL 做七层分发、要求会话强一致、或者要部署数据库的场景——NLB 在这几块是短板,后面会讲清楚边界在哪。2. NLB 群集架构与网卡心跳设计先把架构立住,后面敲命令才不会晕。NLB 的本质是在每台成员服务器上跑一个驱动级的过滤模块,它在网卡和 TCP/IP 协议栈之间拦截流量,只有被分配到本节点的数据包才会往上传。也就是说,群集不是一台独立设备,而是每台机器都在受理同一批请求,只是各拿各的那份。2.1 群集 IP、优先级与 MAC 的关系群集对外有一个虚拟 IP,这里规划成192.168.1.100,它是所有客户端访问的入口。每台成员机还有自己的物理 IP,案例里是192.168.1.8和192.168.1.9。客户端发往.100的包,靠 ARP 解析出一个 MAC 地址,这个 MAC 由群集操作模式决定是映射到某一台还是虚拟出新的。优先级决定了谁当主节点:优先级 1 的机器在群集启动时先承担默认流量,并在主机状态表里拥有更高权重。常见做法是把两台服务器的物理 IP 和群集 IP 放在同一个业务网段,再单独划一个网段给心跳。原文里业务网段是192.168.1.0/24,心跳用了10.10.10.0/24,10.10.10.1和10.10.10.2互指。心跳线的作用不是传业务数据,而是节点之间交换健康状态和群集一致性信息。如果心跳和业务混在同一块网卡上,业务一拥塞,心跳包也跟着延迟,严重的会被误判成节点故障,触发不必要的切换。这就是为什么要求心跳线和物理地址不同网段、走不同物理链路。2.2 三块网卡的角色拆分案例里每台服务器配了 3 块网卡,这是比较稳妥的划分方式:网卡用途数量服务器 CVNET1服务器 CVNET2说明业务通信(聚合)2Teaming192.168.1.8Teaming192.168.1.9承载客户端访问与群集流量心跳1HB10.10.10.1HB10.10.10.2仅节点间状态探测群集虚拟 IP0(逻辑)192.168.1.100同左对外统一入口两块业务网卡做 NIC Teaming 聚合,不只是堆带宽,更关键的是冗余——单块网卡或单根网线挂了,聚合组里的备用链路顶上,不会直接掉节点。心跳单独走第三块卡,和业务彻底物理隔离。如果服务器只有两块网卡,那就一块业务一块心跳,业务侧没有冗余,这一点要提前和业务方说清楚。2.3 存储与服务的选型边界原文提了一句不适合部署数据库,这话值得展开。NLB 是四层分发,它无法感知 TCP 会话之后的业务状态,也没有共享存储来保证数据一致。两台机器各自跑各自的关系型数据库,NLB 轮着转发写请求,数据必然冲突。所以数据库要么单独放一台,要么用 SQL Server 自己的 Always On 方案。存储方面,NAS、分布式存储、统一存储都能配,因为它们提供的是共享文件访问层;SAN 在纯 NLB 场景里性价比不高,除非已经有现成的 SAN 架构顺手复用。选型时问自己一句:这个服务是不是无状态、可复制?IIS 静态页、文件共享、RDP 网关都算;数据库、需要写本地临时文件的任务就不算。3. 在 Windows Server 2019 上装 NLB 角色与建群集概念铺完,开始动手。整段流程分两步:先在两台机器上各自装 NLB 功能,然后只在其中一台用图形管理器建群集,第二台再加入进来。3.1 用 PowerShell 批量安装网络负载平衡功能图形界面点点点适合单台,生产环境两台以上我一般用 PowerShell,不容易漏步骤:# 在 CVNET1 和 CVNET2 上分别执行 # -IncludeManagementTools 会一并装上网络负载平衡管理器图形工具 Install-WindowsFeature -Name NLB -IncludeManagementTools -Restart:$false # 装完验证状态,State 应为 Installed,ExitCode 应为 Success Get-WindowsFeature -Name NLB | Select-Object Name, DisplayName, Installed # 检查服务是否就绪,正常应返回 Running Get-Service -Name nlb | Select-Object Name, Status, StartTypeInstall-WindowsFeature的-Name NLB指定角色内部标识,别写成显示名网络负载平衡。-Restart:$false表示不强制重启,但系统可能仍提示需要重启,Get-WindowsFeature里ExitCode若显示SuccessRestartRequired就得安排重启窗口。图形路径对应的是原文步骤:服务器管理器 → 管理 → 添加角色和功能 → 功能列表里勾网络负载平衡。两台机器装完要确认Get-Service nlb都是 Running,一台没起来后面加群集必然报错。3.2 建群集时那几个必填参数的取值打开网络负载平衡管理器,右键网络负载平衡群集→新建群集。以下参数按案例环境填:# 等价的命令行建群集方式,便于脚本化重建 # 在 CVNET1 上执行,先建群集再接第二台 New-NlbCluster -InterfaceName Teaming -ClusterPrimaryIP 192.168.1.100 -SubnetMask 255.255.255.0 -OperationMode Multicast -ClusterName CVNET-NLB -HostName CVNET1 -InterfaceName Teaming # 把第二台按优先级 2 加入 Add-NlbClusterNode -InterfaceName Teaming -NewNodeName CVNET2 -NewNodeInterfaceName Teaming -HostPriority 2逐项说清楚:-ClusterPrimaryIP 192.168.1.100:群集虚拟 IP,必须是同网段内没被占用的地址,建群集前 ping 一下确认不通,避免 IP 冲突。-InterfaceName Teaming:绑定哪块网卡承载群集流量,要用业务聚合网卡,别误选心跳卡。-OperationMode Multicast:群集操作模式。单播会把所有节点的物理 MAC 改写成同一个虚拟 MAC,交换机的端口 MAC 表会反复抖动,业务量大时容易拥塞,不推荐;多播保留物理 MAC 不变,虚拟出一个二层结构对外通信,通用性最好;IGMP 多播依赖交换机支持 IGMP 侦听,对网络设备要求更高,环境受控时可用。-HostPriority:优先级。第一台填 1,第二台填 2,数字越小优先级越高。后期可以在管理器里右键节点改,不必重建群集。提示:依次序建群集时,只要在一台机器上操作,第二台会被自动纳入。原文里在任意 1 台服务器上创建即可就是这个意思,没必要两台都点一遍新建。图形流程对应原文:新建群集 → 主机处填192.168.1.8点连接 → 选中该 IP → 优先级填 1 → 添加虚拟 IP192.168.1.100→ 操作模式选多播 → 完成。接着右键虚拟 IP → 添加主机到群集 → 填192.168.1.9→ 优先级填 2 → 完成。建完在管理器里能看到两个节点状态都显示已聚合。3.3 验证群集是否真的生效装完不等于能用,按这几步确认:# 查看群集整体状态 Get-NlbCluster | Select-Object ClusterName, ClusterIPAddress, OperationMode, Status # 查看节点清单,确认两台都在且状态为 Converged Get-NlbClusterNode | Select-Object Name, HostPriority, State # 从客户端 ping 虚拟 IP,通才算对外可用 ping 192.168.1.100 -n 4State为Converged表示节点已就绪并完成群集收敛;如果是Pending或Draining,通常是心跳不通或网卡选错。客户端访问虚拟 IP 得到响应后,再故意在某一台上执行Stop-Service nlb,观察另一台是否能继续响应——这一步是控场测试,别在生产高峰期做。4. 心跳断连、交换机 ARP 表与双机故障切换排错群集建起来容易,跑稳难。NLB 现场出问题,八成集中在心跳、ARP 和切换判定这三块。4.1 心跳不通导致节点被误判心跳线的两个 IP 必须能互相 ping 通,这是最基础的一条:# 在 CVNET1 上测到 CVNET2 心跳地址 ping 10.10.10.2 -n 10 # 看网卡绑定和状态,确认心跳卡是独立的一块 Get-NetAdapter | Select-Object Name, Status, LinkSpeed, MacAddress Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLength如果心跳 ping 不通,先看是不是防火墙拦了 ICMP 回显,再确认两块心跳网卡是不是被误加入了业务 Teaming 组。心跳不通时,NLB 会认为对端失联,可能导致两台都以为自己是主节点、或者频繁切换。判断依据是Get-NlbClusterNode的State反复在Converged和Pending之间跳。4.2 多播模式下交换机侧要做的配合选多播后,群集虚拟 IP 会映射到一个03-BF-开头的虚拟 MAC(多播标志位)。有些接入层交换机对多播 MAC 的学习和转发支持不好,表现为虚拟 IP 能 ping 通但业务端口连不上。常见做法是在交换机端口上把这两个业务口划到同一个 VLAN,并确认没有开启会丢弃未知多播的端口安全策略。如果排到这一步还没解决,退一步改用单播模式验证:单播下虚拟 MAC 会覆盖物理 MAC,能通说明是交换机多播处理的问题,而不是 NLB 本身没配对。4.3 用事件日志和端口规则定位切换异常NLB 的切换和状态变化会记进系统日志,排错时盯着这几个来源:# 拉取最近 50 条 NLB 相关事件 Get-WinEvent -LogName System -MaxEvents 50 | Where-Object { $_.ProviderName -like *NLB* -or $_.Message -like *负载平衡* } | Select-Object TimeCreated, Id, LevelDisplayName, Message常见事件里有成员已加入群集成员主机已收敛群集已失去与成员的连接,对照时间点看是哪台先断的。端口规则也是高频坑:默认规则是所有端口,如果业务只走 80/443,就新建一条覆盖80-443的规则并设亲和性——单机亲和性会把同一客户端固定到同一节点,适合有会话状态的服务;无亲和性则纯轮询。规则建反了会出现业务时通时不通,但群集状态显示正常的情况。注意:改端口规则后要让群集重新收敛再测,别改完立刻压测,否则会把收敛过程中的抖动误判成配置错误。5. 带宽权重分配与命令行快速重建群集最后聊两个实战里省时间的技巧。一个是吞吐不均时怎么调,一个是环境崩了怎么快速拉起来。5.1 用 HostPriority 和负载权重调配比默认情况下 NLB 按轮询分发,但两台机器配置不一样时,轮询就浪费了强的那台。主机优先级影响的是群集启动时的默认承载,真正调流量配比要用端口规则的负载权重:# 查看当前端口规则 Get-NlbClusterPortRule -InterfaceName Teaming | Format-List # 新建一条覆盖 80/443 的规则,并调整节点权重 Add-NlbClusterPortRule -InterfaceName Teaming -StartPort 80 -EndPort 443 -Protocol Tcp -Mode MultipleHost -Affinity None # 给两台节点设不同的负载权重(1-100),数值越大分到的连接越多 Set-NlbClusterNode -InterfaceName Teaming -HostName CVNET1 -LoadWeight 60 Set-NlbClusterNode -InterfaceName Teaming -HostName CVNET2 -LoadWeight 40-LoadWeight取值 1 到 100,上面把 6:4 的流量分给配置不等或角色不同的两台机器。-Affinity None表示不绑会话,适合无状态的前端;若服务依赖登录态,改成Single并把会话超时和业务超时对齐。调完用Get-NlbClusterNode看LoadWeight是否生效,再看看两端连接数是否接近设定比例。5.2 从零到可用的一键重建脚本环境迁移或演练时,把建群集过程脚本化,比翻图形界面快得多:# rebuild-nlb.ps1 —— 在两台节点上分别执行,第一台建、第二台加 param([string]$Role primary) Install-WindowsFeature -Name NLB -IncludeManagementTools | Out-Null if ($Role -eq primary) { New-NlbCluster -InterfaceName Teaming -ClusterPrimaryIP 192.168.1.100 -SubnetMask 255.255.255.0 -OperationMode Multicast -ClusterName CVNET-NLB -HostName $env:COMPUTERNAME -InterfaceName Teaming } else { Add-NlbClusterNode -InterfaceName Teaming -NewNodeName $env:COMPUTERNAME -NewNodeInterfaceName Teaming -HostPriority 2 } # 收敛后打印节点状态,确认都为 Converged Start-Sleep -Seconds 10 Get-NlbClusterNode | Select-Object Name, HostPriority, State这个脚本把角色拆成参数,同一份文件放两台机器上跑,主节点传-Role primary,第二台默认加入。Start-Sleep那 10 秒是给群集收敛留时间,秒数视环境调大调小,收敛期间不要急着验证业务。每次改完配置,记住验证顺序:先 ping 虚拟 IP,再看Get-NlbClusterNode状态,最后才是业务层访问——顺序反了,分不清是网络问题还是应用问题。本文还有配套的精品资源点击获取 Windows Server 2019 NLB 双机群集配置与故障切换排错
简介这是一份面向企业IT运维与系统管理员的中文技术资料围绕Windows Server 2019自带的网络负载均衡NLB软负载方案展开适合需要搭建高可用服务器集群、规避单点故障的初中级运维人员参考。文档从NLB概念与适用边界讲起明确负载场景中不宜部署数据库、存储推荐以NAS或分布式存储为主而SAN适用性有限并交代双服务器、多网卡、心跳线及网络聚合等环境要求进而给出安装角色与功能、创建NLB群集、设置群集操作模式与心跳参数、模拟故障测试的完整图文流程可对照案例中的物理IP、心跳IP与虚拟IP配置逐步落地。资源包共1个文件为PDF格式大小约2.03MB正文配有操作截图按目录分章便于快速定位角色安装、群集创建与测试环节。该资料已有2227人学习下载可作为部署Windows NLB并验证负载分发效果时的实操参照。1. 两台 IIS 扛不住的时候我为什么选了 Windows 自带的 NLB去年帮一家做医疗影像的客户做内网系统迁移两台 Windows Server 2019 上跑 IIS 的 PACS 查询前端白天门诊高峰一开单台机器的连接数直接顶到八千,CPU 没满但 TCP 队列堆积,页面响应从 200ms 涨到 3 秒。他们问我上 Nginx 还是上 F5,我的答案是先用 Windows Server 2019 自带的网络负载均衡Network Load BalanceNLB。理由很朴素:这个场景是典型的四层分发,流量模型简单,没有复杂的 URI 路由和会话保持策略,而 NLB 是操作系统角色,装完就能用,不需要多维护一套中间件和它的高可用。NLB 把两台服务器聚合成一个群集,对外只暴露一个虚拟 IP,客户端根本不知道背后有几台机器。任意一台物理机宕掉,流量会在几百毫秒内被其他节点接管,这是它最核心的价值——用系统自带能力换来业务连续性,而不是靠运维半夜爬起来重启。适合谁:手里有 2 到 32 台 Windows Server、跑 IIS/SMB/RDP 这类四层服务、又不想引入额外负载组件的团队。不适合谁:需要按 URL 做七层分发、要求会话强一致、或者要部署数据库的场景——NLB 在这几块是短板,后面会讲清楚边界在哪。2. NLB 群集架构与网卡心跳设计先把架构立住,后面敲命令才不会晕。NLB 的本质是在每台成员服务器上跑一个驱动级的过滤模块,它在网卡和 TCP/IP 协议栈之间拦截流量,只有被分配到本节点的数据包才会往上传。也就是说,群集不是一台独立设备,而是每台机器都在受理同一批请求,只是各拿各的那份。2.1 群集 IP、优先级与 MAC 的关系群集对外有一个虚拟 IP,这里规划成192.168.1.100,它是所有客户端访问的入口。每台成员机还有自己的物理 IP,案例里是192.168.1.8和192.168.1.9。客户端发往.100的包,靠 ARP 解析出一个 MAC 地址,这个 MAC 由群集操作模式决定是映射到某一台还是虚拟出新的。优先级决定了谁当主节点:优先级 1 的机器在群集启动时先承担默认流量,并在主机状态表里拥有更高权重。常见做法是把两台服务器的物理 IP 和群集 IP 放在同一个业务网段,再单独划一个网段给心跳。原文里业务网段是192.168.1.0/24,心跳用了10.10.10.0/24,10.10.10.1和10.10.10.2互指。心跳线的作用不是传业务数据,而是节点之间交换健康状态和群集一致性信息。如果心跳和业务混在同一块网卡上,业务一拥塞,心跳包也跟着延迟,严重的会被误判成节点故障,触发不必要的切换。这就是为什么要求心跳线和物理地址不同网段、走不同物理链路。2.2 三块网卡的角色拆分案例里每台服务器配了 3 块网卡,这是比较稳妥的划分方式:网卡用途数量服务器 CVNET1服务器 CVNET2说明业务通信(聚合)2Teaming192.168.1.8Teaming192.168.1.9承载客户端访问与群集流量心跳1HB10.10.10.1HB10.10.10.2仅节点间状态探测群集虚拟 IP0(逻辑)192.168.1.100同左对外统一入口两块业务网卡做 NIC Teaming 聚合,不只是堆带宽,更关键的是冗余——单块网卡或单根网线挂了,聚合组里的备用链路顶上,不会直接掉节点。心跳单独走第三块卡,和业务彻底物理隔离。如果服务器只有两块网卡,那就一块业务一块心跳,业务侧没有冗余,这一点要提前和业务方说清楚。2.3 存储与服务的选型边界原文提了一句不适合部署数据库,这话值得展开。NLB 是四层分发,它无法感知 TCP 会话之后的业务状态,也没有共享存储来保证数据一致。两台机器各自跑各自的关系型数据库,NLB 轮着转发写请求,数据必然冲突。所以数据库要么单独放一台,要么用 SQL Server 自己的 Always On 方案。存储方面,NAS、分布式存储、统一存储都能配,因为它们提供的是共享文件访问层;SAN 在纯 NLB 场景里性价比不高,除非已经有现成的 SAN 架构顺手复用。选型时问自己一句:这个服务是不是无状态、可复制?IIS 静态页、文件共享、RDP 网关都算;数据库、需要写本地临时文件的任务就不算。3. 在 Windows Server 2019 上装 NLB 角色与建群集概念铺完,开始动手。整段流程分两步:先在两台机器上各自装 NLB 功能,然后只在其中一台用图形管理器建群集,第二台再加入进来。3.1 用 PowerShell 批量安装网络负载平衡功能图形界面点点点适合单台,生产环境两台以上我一般用 PowerShell,不容易漏步骤:# 在 CVNET1 和 CVNET2 上分别执行 # -IncludeManagementTools 会一并装上网络负载平衡管理器图形工具 Install-WindowsFeature -Name NLB -IncludeManagementTools -Restart:$false # 装完验证状态,State 应为 Installed,ExitCode 应为 Success Get-WindowsFeature -Name NLB | Select-Object Name, DisplayName, Installed # 检查服务是否就绪,正常应返回 Running Get-Service -Name nlb | Select-Object Name, Status, StartTypeInstall-WindowsFeature的-Name NLB指定角色内部标识,别写成显示名网络负载平衡。-Restart:$false表示不强制重启,但系统可能仍提示需要重启,Get-WindowsFeature里ExitCode若显示SuccessRestartRequired就得安排重启窗口。图形路径对应的是原文步骤:服务器管理器 → 管理 → 添加角色和功能 → 功能列表里勾网络负载平衡。两台机器装完要确认Get-Service nlb都是 Running,一台没起来后面加群集必然报错。3.2 建群集时那几个必填参数的取值打开网络负载平衡管理器,右键网络负载平衡群集→新建群集。以下参数按案例环境填:# 等价的命令行建群集方式,便于脚本化重建 # 在 CVNET1 上执行,先建群集再接第二台 New-NlbCluster -InterfaceName Teaming -ClusterPrimaryIP 192.168.1.100 -SubnetMask 255.255.255.0 -OperationMode Multicast -ClusterName CVNET-NLB -HostName CVNET1 -InterfaceName Teaming # 把第二台按优先级 2 加入 Add-NlbClusterNode -InterfaceName Teaming -NewNodeName CVNET2 -NewNodeInterfaceName Teaming -HostPriority 2逐项说清楚:-ClusterPrimaryIP 192.168.1.100:群集虚拟 IP,必须是同网段内没被占用的地址,建群集前 ping 一下确认不通,避免 IP 冲突。-InterfaceName Teaming:绑定哪块网卡承载群集流量,要用业务聚合网卡,别误选心跳卡。-OperationMode Multicast:群集操作模式。单播会把所有节点的物理 MAC 改写成同一个虚拟 MAC,交换机的端口 MAC 表会反复抖动,业务量大时容易拥塞,不推荐;多播保留物理 MAC 不变,虚拟出一个二层结构对外通信,通用性最好;IGMP 多播依赖交换机支持 IGMP 侦听,对网络设备要求更高,环境受控时可用。-HostPriority:优先级。第一台填 1,第二台填 2,数字越小优先级越高。后期可以在管理器里右键节点改,不必重建群集。提示:依次序建群集时,只要在一台机器上操作,第二台会被自动纳入。原文里在任意 1 台服务器上创建即可就是这个意思,没必要两台都点一遍新建。图形流程对应原文:新建群集 → 主机处填192.168.1.8点连接 → 选中该 IP → 优先级填 1 → 添加虚拟 IP192.168.1.100→ 操作模式选多播 → 完成。接着右键虚拟 IP → 添加主机到群集 → 填192.168.1.9→ 优先级填 2 → 完成。建完在管理器里能看到两个节点状态都显示已聚合。3.3 验证群集是否真的生效装完不等于能用,按这几步确认:# 查看群集整体状态 Get-NlbCluster | Select-Object ClusterName, ClusterIPAddress, OperationMode, Status # 查看节点清单,确认两台都在且状态为 Converged Get-NlbClusterNode | Select-Object Name, HostPriority, State # 从客户端 ping 虚拟 IP,通才算对外可用 ping 192.168.1.100 -n 4State为Converged表示节点已就绪并完成群集收敛;如果是Pending或Draining,通常是心跳不通或网卡选错。客户端访问虚拟 IP 得到响应后,再故意在某一台上执行Stop-Service nlb,观察另一台是否能继续响应——这一步是控场测试,别在生产高峰期做。4. 心跳断连、交换机 ARP 表与双机故障切换排错群集建起来容易,跑稳难。NLB 现场出问题,八成集中在心跳、ARP 和切换判定这三块。4.1 心跳不通导致节点被误判心跳线的两个 IP 必须能互相 ping 通,这是最基础的一条:# 在 CVNET1 上测到 CVNET2 心跳地址 ping 10.10.10.2 -n 10 # 看网卡绑定和状态,确认心跳卡是独立的一块 Get-NetAdapter | Select-Object Name, Status, LinkSpeed, MacAddress Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLength如果心跳 ping 不通,先看是不是防火墙拦了 ICMP 回显,再确认两块心跳网卡是不是被误加入了业务 Teaming 组。心跳不通时,NLB 会认为对端失联,可能导致两台都以为自己是主节点、或者频繁切换。判断依据是Get-NlbClusterNode的State反复在Converged和Pending之间跳。4.2 多播模式下交换机侧要做的配合选多播后,群集虚拟 IP 会映射到一个03-BF-开头的虚拟 MAC(多播标志位)。有些接入层交换机对多播 MAC 的学习和转发支持不好,表现为虚拟 IP 能 ping 通但业务端口连不上。常见做法是在交换机端口上把这两个业务口划到同一个 VLAN,并确认没有开启会丢弃未知多播的端口安全策略。如果排到这一步还没解决,退一步改用单播模式验证:单播下虚拟 MAC 会覆盖物理 MAC,能通说明是交换机多播处理的问题,而不是 NLB 本身没配对。4.3 用事件日志和端口规则定位切换异常NLB 的切换和状态变化会记进系统日志,排错时盯着这几个来源:# 拉取最近 50 条 NLB 相关事件 Get-WinEvent -LogName System -MaxEvents 50 | Where-Object { $_.ProviderName -like *NLB* -or $_.Message -like *负载平衡* } | Select-Object TimeCreated, Id, LevelDisplayName, Message常见事件里有成员已加入群集成员主机已收敛群集已失去与成员的连接,对照时间点看是哪台先断的。端口规则也是高频坑:默认规则是所有端口,如果业务只走 80/443,就新建一条覆盖80-443的规则并设亲和性——单机亲和性会把同一客户端固定到同一节点,适合有会话状态的服务;无亲和性则纯轮询。规则建反了会出现业务时通时不通,但群集状态显示正常的情况。注意:改端口规则后要让群集重新收敛再测,别改完立刻压测,否则会把收敛过程中的抖动误判成配置错误。5. 带宽权重分配与命令行快速重建群集最后聊两个实战里省时间的技巧。一个是吞吐不均时怎么调,一个是环境崩了怎么快速拉起来。5.1 用 HostPriority 和负载权重调配比默认情况下 NLB 按轮询分发,但两台机器配置不一样时,轮询就浪费了强的那台。主机优先级影响的是群集启动时的默认承载,真正调流量配比要用端口规则的负载权重:# 查看当前端口规则 Get-NlbClusterPortRule -InterfaceName Teaming | Format-List # 新建一条覆盖 80/443 的规则,并调整节点权重 Add-NlbClusterPortRule -InterfaceName Teaming -StartPort 80 -EndPort 443 -Protocol Tcp -Mode MultipleHost -Affinity None # 给两台节点设不同的负载权重(1-100),数值越大分到的连接越多 Set-NlbClusterNode -InterfaceName Teaming -HostName CVNET1 -LoadWeight 60 Set-NlbClusterNode -InterfaceName Teaming -HostName CVNET2 -LoadWeight 40-LoadWeight取值 1 到 100,上面把 6:4 的流量分给配置不等或角色不同的两台机器。-Affinity None表示不绑会话,适合无状态的前端;若服务依赖登录态,改成Single并把会话超时和业务超时对齐。调完用Get-NlbClusterNode看LoadWeight是否生效,再看看两端连接数是否接近设定比例。5.2 从零到可用的一键重建脚本环境迁移或演练时,把建群集过程脚本化,比翻图形界面快得多:# rebuild-nlb.ps1 —— 在两台节点上分别执行,第一台建、第二台加 param([string]$Role primary) Install-WindowsFeature -Name NLB -IncludeManagementTools | Out-Null if ($Role -eq primary) { New-NlbCluster -InterfaceName Teaming -ClusterPrimaryIP 192.168.1.100 -SubnetMask 255.255.255.0 -OperationMode Multicast -ClusterName CVNET-NLB -HostName $env:COMPUTERNAME -InterfaceName Teaming } else { Add-NlbClusterNode -InterfaceName Teaming -NewNodeName $env:COMPUTERNAME -NewNodeInterfaceName Teaming -HostPriority 2 } # 收敛后打印节点状态,确认都为 Converged Start-Sleep -Seconds 10 Get-NlbClusterNode | Select-Object Name, HostPriority, State这个脚本把角色拆成参数,同一份文件放两台机器上跑,主节点传-Role primary,第二台默认加入。Start-Sleep那 10 秒是给群集收敛留时间,秒数视环境调大调小,收敛期间不要急着验证业务。每次改完配置,记住验证顺序:先 ping 虚拟 IP,再看Get-NlbClusterNode状态,最后才是业务层访问——顺序反了,分不清是网络问题还是应用问题。本文还有配套的精品资源点击获取