简介这份图文教程面向Windows Server运维人员与网络初学者系统讲解Windows Server 2019自带的网络负载均衡NLB软负载方案帮助解决业务量大、单点故障导致服务中断的问题提升服务器集群的高可用性与稳定性。资源包为1个PDF文件大小约2.03MB内容以图文并茂的方式编排涵盖NLB概念与环境要求、安装前准备、安装角色和功能、创建NLB群集及模拟测试等完整章节并配有双服务器、多网卡与心跳线的实际案例环境说明。读者可据此掌握从系统优化、网络聚合配置到群集参数设置、故障转移验证的全流程操作理解单播与多播模式、心跳机制等关键知识点并参考NAS、分布式存储等存储选型建议。目前已有2227人学习下载适合需要快速上手NLB部署与排错的中高级运维人员对照实践。1. 为什么单机 IIS 扛不住 200 并发NLB 到底解决了什么某公司内部一套基于 IIS 的审批系统工作日早上九点前后集中登录单台 Windows Server 2019 上 CPU 直接冲到 95%页面响应从 300ms 涨到 4s 以上。运维第一反应是加内存、换 SSD结果发现瓶颈根本不在磁盘而在单机 Web 工作进程的请求队列。这时候才想到 Windows Server 2019 自带的负载均衡NLB——注意它不是装个软件就完事而是要把两台以上服务器组成一个集群对外只暴露一个虚拟 IP请求按算法分发到各节点。NLB 解决的是「入口层的流量分摊」和「节点故障时的自动摘除」它工作在 TCP/IP 层对 IIS、FTP、甚至自定义 TCP 服务都透明。适合谁适合那些不想引入额外硬件负载设备、又需要基本高可用和横向扩展的中小规模内网服务。但它的边界也很清楚不做应用层健康检查、不感知 HTTP 会话所以会话保持和状态同步得自己处理。这篇就把从零搭建到踩坑的完整路径讲透。2. 装 NLB 之前必须想清楚的三个选型问题2.1 单播还是多播交换机 MAC 表会告诉你答案NLB 集群有两种模式单播和多播。单播模式下集群里所有节点共用同一个 MAC 地址交换机的 MAC 地址表会把该 MAC 映射到多个端口形成「MAC 泛洪」。如果交换机不支持这种泛洪或者做了端口安全限制就会出现部分客户端访问不通的玄学问题。多播模式则给集群分配一个多播 MAC同时保留各节点原 MAC对交换机更友好但需要交换机支持 IGMP 多播且部分路由器会丢弃多播源地址的 ARP 响应。我一般这样选如果集群节点接在同一台可管理交换机上且交换机没有开端口安全优先单播配置最简单如果跨交换机或云环境多播更稳。判断方法很简单配好单播后从不同网段 ping 集群 IP如果时通时不通基本就是 MAC 泛洪被限制了。2.2 端口规则决定「哪些流量进集群」NLB 的端口规则Port Rules是核心配置它决定集群监听哪些端口、用什么协议、如何分发。默认规则是 0-65535 全部端口筛选模式为「多个主机」相似性为「无」。这意味着所有 TCP/UDP 流量都按节点负载分发且同一客户端的连续请求可能落到不同节点。对于 IIS 场景通常只需要开放 80 和 443。如果应用依赖会话状态相似性要设成「单一」或「网络」让同一客户端 IP 始终落到同一节点。但「单一」相似性会牺牲负载均衡效果节点少的时候可能倾斜严重。常见做法是要么在应用层做会话共享如 Redis 存 Session要么用「网络」相似性按 C 类网段分发平衡效果和会话粘性。2.3 集群操作模式单播下的「聚合」与「IGMP 多播」在 NLB 管理器里配置集群时还有一个「集群操作模式」选项单播模式下可选「聚合」或「IGMP 多播」。聚合模式就是前面说的共用 MACIGMP 多播则是单播基础上加入 IGMP 多播组让交换机知道把多播流量转发到哪些端口。如果交换机支持 IGMP Snooping选 IGMP 多播能减少泛洪如果不支持选聚合反而更直接。这里有个血泪经验某次在虚拟化环境里配单播聚合两台虚拟机在同一台宿主机上结果集群 IP 完全不通。原因是虚拟交换机对 MAC 泛洪的处理和物理交换机不同最后改成多播模式才恢复。所以虚拟化环境优先多播物理机环境看交换机能力。3. 两台 Server 2019 组 NLB 集群的完整操作步骤3.1 前置准备网卡、IP 与防火墙每台节点需要至少两块网卡推荐一块用于集群通信心跳一块用于对外服务。如果只有一块网卡NLB 会在同一网卡上同时处理集群流量和主机流量可能影响性能但实验环境可以接受。假设两台节点节点主机 IP集群虚拟 IP用途NODE1192.168.10.11192.168.10.100IIS NLBNODE2192.168.10.12192.168.10.100IIS NLB先在两台机器上关闭防火墙对 80/443 的拦截或者直接放行。命令如下# 放行 HTTP 和 HTTPS 入站规则 New-NetFirewallRule -DisplayName Allow HTTP -Direction Inbound -Protocol TCP -LocalPort 80 -Action Allow New-NetFirewallRule -DisplayName Allow HTTPS -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow逻辑说明NLB 集群本身不处理防火墙流量到达节点后仍由 Windows 防火墙过滤。如果防火墙拦截了 80 端口客户端会看到集群 IP 不通但节点主机 IP 可能正常容易误判为 NLB 故障。参数上-LocalPort指定端口-Action Allow表示放行。3.2 安装 NLB 功能图形界面与 PowerShell 两条路图形界面路径服务器管理器 → 添加角色和功能 → 功能 → 勾选「网络负载均衡」。PowerShell 更直接# 在 NODE1 和 NODE2 上分别执行 Install-WindowsFeature -Name NLB -IncludeManagementTools安装完成后不需要重启但 NLB 管理器需要从「开始菜单 → Windows 管理工具 → 网络负载均衡管理器」打开。注意NLB 是 Windows 功能不是角色所以不会出现在「角色」列表里新手容易在角色里找不到而翻车。3.3 创建集群并添加节点关键参数逐项拆解在 NODE1 上打开 NLB 管理器右键「网络负载均衡集群」→「新建集群」。依次填写集群 IP192.168.10.100子网掩码255.255.255.0集群操作模式先选「多播」虚拟化环境更稳完整 Internet 名称可留空内网不需要接着进入「集群 IP 地址」页面添加 192.168.10.100。端口规则页面默认规则可以删掉新建一条端口范围80 到 80协议TCP筛选模式多个主机相似性无启用勾选再建一条 443 的规则参数相同。完成后右键集群 →「添加主机」把 NODE2 的 IP 填进去连接后选择要加入的网卡点击「下一步」直到完成。这里有个细节添加主机时NLB 会检查节点上是否已安装 NLB 功能如果 NODE2 没装会直接报错。所以务必先在两台机器上都执行安装命令。3.4 验证集群状态从 ping 到实际请求分发集群建好后在 NLB 管理器里应该看到两个节点都是「已聚合」状态。验证步骤# 在任意客户端上 ping 集群 IP ping 192.168.10.100 # 用 curl 连续请求 10 次观察返回的节点标识 for ($i1; $i -le 10; $i) { (Invoke-WebRequest -Uri http://192.168.10.100 -UseBasicParsing).Headers[X-Node] }为了区分请求落到哪台节点可以在两台 IIS 的默认页面上分别写「NODE1」和「NODE2」。如果 10 次请求里两个节点都出现了说明分发生效。如果全部落到同一台检查端口规则的相似性是否设成了「单一」或者另一台节点的 IIS 是否没启动。4. 会话丢失、节点假死、MAC 泛洪NLB 避坑清单4.1 现象用户登录后刷新页面就退出登录原因NLB 默认「无相似性」分发同一用户的连续请求被分到不同节点而 ASP.NET Session 默认存在单机内存里换节点就丢。解决要么在端口规则里把相似性改成「单一」让同一源 IP 固定落到一个节点要么在应用层改用 Redis 或 SQL Server 存 Session。前者配置简单但负载可能倾斜后者更彻底但需要改代码。我一般推荐后者因为相似性「单一」在 NAT 环境下会把大量用户当成同一 IP。4.2 现象集群 IP 能 ping 通但 HTTP 请求超时原因常见于单播模式下的交换机 MAC 泛洪被限制或者节点上的 IIS 没有绑定集群 IP。检查方法在节点上执行netstat -ano | findstr :80看监听地址是 0.0.0.0 还是具体 IP。如果 IIS 只绑定了主机 IP集群 IP 的请求到达后会被拒绝。解决在 IIS 管理器里编辑绑定把 IP 地址改成「全部未分配」或者手动加上集群 IP。4.3 现象一台节点宕机后所有请求仍然超时原因NLB 默认没有启用「故障转移」的快速检测或者端口规则里没有勾选「启用故障转移」。另外如果节点是断电而非服务停止NLB 需要几秒到几十秒才能感知。解决在端口规则的高级设置里把「故障转移」周期调短比如 3 秒。但注意调太短会导致网络抖动时误摘除节点。我一般设 5 秒兼顾灵敏和稳定。4.4 现象NLB 管理器里节点显示「已聚合」但实际不处理请求原因节点的 NLB 服务没有真正绑定到网卡或者网卡被禁用后重新启用NLB 绑定丢失。解决在 NLB 管理器里右键节点 →「控制主机」→「启动」如果启动失败检查网卡属性里「网络负载均衡」勾选框是否还在。虚拟化环境里迁移虚拟机后这个勾选经常丢失需要重新勾上。4.5 现象集群 IP 和主机 IP 冲突导致网络中断原因配置集群 IP 时误把某台节点的主机 IP 填成了集群 IP或者集群 IP 和现有设备冲突。解决配置前先用ping确认集群 IP 未被占用配置后如果发现节点失联通过带外管理或控制台改回。这个坑一旦踩了远程桌面直接断只能本地操作所以配置前务必确认 IP 空闲。5. 用 PowerShell 批量管理 NLB 与健康检查脚本5.1 用 NLB 模块命令替代图形界面Windows Server 2019 自带NetworkLoadBalancingClusters模块可以脚本化管理。常用命令# 查看集群状态 Get-NlbCluster -HostName NODE1 # 查看节点状态 Get-NlbClusterNode -HostName NODE1 # 查看端口规则 Get-NlbClusterPortRule -HostName NODE1 # 停止某节点接收新请求排空 Stop-NlbClusterNode -HostName NODE1 -NodeName NODE2 -Drain-Drain参数表示排空节点不再接收新连接但已建立的连接继续处理适合滚动维护。参数说明-HostName指定任意集群节点的主机名或 IP-NodeName指定要操作的目标节点。这些命令在批量运维时比图形界面快得多比如每月补丁日自动排空节点、打补丁、再恢复。5.2 写一个每 30 秒检查节点健康的脚本NLB 自身不做应用层健康检查如果 IIS 进程假死但 NLB 服务正常流量仍会打到故障节点。可以写一个 PowerShell 脚本定时请求本地 IIS失败时自动停止 NLB 服务让集群摘除该节点# health-check.ps1 $url http://localhost/health.aspx # 一个返回 200 的轻量页面 $maxFail 3 $failCount 0 while ($true) { try { $resp Invoke-WebRequest -Uri $url -TimeoutSec 5 -UseBasicParsing if ($resp.StatusCode -eq 200) { $failCount 0 } else { $failCount } } catch { $failCount } if ($failCount -ge $maxFail) { # 停止 NLB 服务集群自动摘除本节点 Stop-Service -Name WLBS -Force Write-EventLog -LogName Application -Source NLB-Health -EventId 1001 -EntryType Error -Message IIS 健康检查失败已停止 NLB 服务 break } Start-Sleep -Seconds 30 }逻辑说明脚本每 30 秒请求一次本地健康页面连续 3 次失败就停止WLBS服务NLB 的 Windows 服务名。服务停止后集群会在几秒内将该节点标记为不活动流量转到其他节点。参数上$maxFail控制容错次数-TimeoutSec 5防止请求挂起。这个脚本需要注册为计划任务或 Windows 服务开机自启。5.3 用事件日志追踪 NLB 的「黑匣子」NLB 的日志默认写在 Windows 事件日志的「系统」和「应用程序」里事件源是WLBS。常见事件 ID事件 ID含义处理建议1021节点加入集群正常1022节点离开集群检查是否手动排空或故障1023集群配置变更确认变更来源1024端口规则冲突检查规则是否重叠如果集群行为异常先看事件日志里有没有 1022 和 1024。有一次遇到节点反复加入离开最后发现是心跳网卡和对外网卡配在同一网段心跳包被广播风暴淹没。把心跳网卡换到独立网段后恢复。这个坑在只有一块网卡的实验环境里不会出现但生产环境双网卡时很容易忽略。5.4 一个容易被忽略的细节ARP 响应与客户端缓存NLB 集群 IP 的 ARP 响应由当前「主节点」负责如果主节点切换部分客户端可能缓存了旧 MAC导致短暂不通。Windows 客户端的 ARP 缓存默认 2 分钟Linux 更长。如果切换后长时间不通可以在客户端执行arp -d清除缓存。生产环境里建议把 NLB 集群 IP 和主机 IP 放在同一子网减少 ARP 跨网段问题。我自己的习惯是每次改完 NLB 配置先在一台客户端上arp -d再测试避免被缓存误导。这个习惯帮我省过好几次「以为配置错了其实是缓存没刷新」的后悔药。希望帮到你。本文还有配套的精品资源点击获取
