企业官网建设流程全解析

简介：这份PDF资料面向Windows Server运维人员与系统集成工程师，聚焦Windows Server 2019自带的网络负载均衡（NLB）软负载方案，用于解决业务量增大后单台服务器负荷过重、可用性不足的问题，帮助读者掌握高可用服务器组的搭建思路与落地方法。资源包内共1个PDF文件，约2.03MB，图文并茂地记录了从NLB概念、环境要求到完整部署流程的说明，便于按章节对照实操。内容涵盖NLB集群的虚拟IP通信原理、心跳线与网络聚合的网卡规划、添加角色与功能、创建NLB群集、单播与多播模式选择，以及通过关闭故障节点验证流量重定向的模拟测试，并说明了NAS、分布式存储等存储选型建议。目前已有2227人学习，适合初涉Windows高可用架构或需要一份可参照图文文档的读者查漏补缺。

1. 两台 Windows Server 2019 如何对外只暴露一个 IP

同一网段里放两台 Windows Server 2019，各跑一个同样的 IIS 站点，业务方要求对外只给一个地址，任何一台宕机后请求要在几秒内落到另一台，还不打算为这个内网系统添置硬件设备——这类四层、同子网、节点数不超过 32 台的需求，Windows Server 2019 自带的 NLB（Network Load Balancing，网络负载均衡）就是现成答案。它工作在 TCP/UDP 这一层，靠每台节点各自计算同一套哈希来决定流量归谁，不需要中心调度器，也没有共享状态要同步。适合的人群很明确：负责内部系统接入层、跑 IIS 或自研 TCP 服务、节点都在一个 VLAN 里的运维和开发。需要按 URL、Header、Cookie 做七层分流的场景，交给 Nginx 那类七层组件更合适，NLB 不该背这个锅。安装部署本身在向导里点几下就完事，真正让人返工的是单播模式、亲和性和交换机侧那几项。

2. NLB 的等开销分发与单播、多播模式怎么选

2.1 等开销负载均衡其实是一次哈希映射

NLB 的分发逻辑和 Nginx 那种"上游健康检查 + 加权轮询"完全不是一回事。每台节点本机独立跑一份驱动，收到流量后拿客户端源地址做哈希，得到一个 0 到 255 之间的值，再按各主机的负载权重把这个区间切块；所有节点用同一套输入算同一个哈希，因此对"这个包归谁"能得出一致结论——落在自己区间就收下，落在别人区间就丢弃。节点之间不需要交换状态，也就不存在调度器单点。

权重默认所有节点相等，这就是"等开销负载均衡"这个说法的由来。它的准确含义是"按配置权重等分哈希空间"，而不是"按机器实时压力动态分配"。第一次压测的人常会愣一下：两台机器 CPU 差了百分之三十，流量却仍旧五五开，原因就在这里。哈希的输入取决于亲和性设置，这一点在第 5 章会展开，它直接决定会话能不能保持。

还有一个副作用值得提前知道：因为判定完全靠本地计算，某个节点掉线后，剩下节点会在一段时间内继续把原本属于它的那部分流量丢掉，直到心跳判断完成、集群重新收敛。收敛窗口由心跳周期和重试次数决定，不是实时切换。

2.2 单播模式为什么会把交换机 MAC 表搅乱

单播模式下，NLB 会给参与集群的网卡分配一个虚拟 MAC，前两个字节固定是 02-BF，顶掉网卡原来的物理 MAC。两台节点因此对外共用同一个 MAC。在 Windows 上跑ipconfig /all，会看到物理地址被改写成了那个虚拟地址。

麻烦出在交换机侧：同一个 MAC 从两个不同端口被学到，CAM 表要么反复刷新，要么干脆把流量泛洪出去。生产环境的直观表现是核心交换机对应端口流量异常、抓包能抓到本不该收到的包，个别依赖网卡 MAC 做授权的软件直接失效。绕开有两条路：一是让节点在二层互相看不到对方，接到不同交换机或者划进不同 VLAN，交换机就永远只从一个端口学到这个共享 MAC；二是改用多播模式。

# 查看参与集群的网卡名称与 MAC，Name 列就是创建集群时 -InterfaceName 要填的值 Get-NetAdapter -Name "Ethernet" | Select-Object Name, MacAddress, Status # 创建集群后重新执行一次，对比 MAC 是否被替换成 02-BF 开头的虚拟地址 Get-NetAdapter | Where-Object Status -eq "Up" | Select-Object Name, MacAddress

Get-NetAdapter返回的Name是网卡连接名，不是"描述"里的网卡型号，-InterfaceName参数认的是前者。网卡名带空格时用引号包住。把创建集群前后的MacAddress拉出来对比一眼，比翻文档快得多。

2.3 多播、IGMP 多播与交换机侧的配合

多播模式给集群分配一个 03-BF 开头的多播 MAC，各节点保留自己的物理 MAC，二层不再有"一个 MAC 两个端口"的冲突。代价是集群 IP 到多播 MAC 的 ARP 解析在不少三层设备上不按常规工作，需要在网关或核心交换机上手工补一条静态 ARP。厂商命令不同，Cisco 系常见写法如下，其他品牌按各自手册对应即可。

arp 192.168.10.100 03bf.0a0a.0a64 ARPA

IGMP 多播是在多播基础上再进一步：节点会发出 IGMP 加入报文，交换机据此知道这个多播 MAC 只挂在哪些端口上，于是不再向所有端口泛洪。它要求接入交换机开启 IGMP snooping，同时三层设备侧那条静态 ARP 依然不能省。多播加 IGMP 换来的是干净的转发路径，付出的是网络侧配置工作量，这在需要跨团队协作的内网里往往是最费口舌的部分。

提示：主机若是虚拟机（Hyper-V、VMware 这类平台），单播模式通常还要把虚拟交换机的安全策略调成允许混杂模式、允许伪造传输，否则虚拟交换机可能直接丢弃共享 MAC 的流量。这一步漏掉，现象就是集群建起来了但只有一台在收流量。

3. Windows Server 2019 装 NLB 与节点前置配置

3.1 用 Install-WindowsFeature 安装 NLB 功能

每台要参与集群的机器都要装，装完不需要重启。

# 在每一台 Windows Server 2019 节点上执行，安装 NLB 功能与管理工具 Install-WindowsFeature -Name NLB -IncludeManagementTools # 确认安装结果，State 应显示 Installed Get-WindowsFeature -Name NLB # 加载模块，确认相关 cmdlet 可用 Import-Module NetworkLoadBalancingClusters Get-Command -Module NetworkLoadBalancingClusters | Select-Object Name

-Name NLB是功能名，Windows Server 2019 里它同时提供内核驱动和 PowerShell 模块；-IncludeManagementTools会一并装上 nlbmgr.exe 图形管理器，不加这一项后面还得回来补。Get-Command -Module列出的结果里，New-NlbCluster、Add-NlbClusterNode、New-NlbClusterPortRule、Get-NlbCluster、Stop-NlbClusterNode 这几条是后面全程会用到的。习惯图形界面的话，服务器管理器里"添加角色和功能"一路下一步，在网络功能列表里勾选"网络负载均衡"效果相同。

不想逐台登录，可以走远程批量安装，前提是 WinRM 已放通且账号有管理员权限：

$nodes = @("nlb01", "nlb02") Invoke-Command -ComputerName $nodes -ScriptBlock { Install-WindowsFeature -Name NLB -IncludeManagementTools }

Invoke-Command的-ComputerName接受数组，一次性推送到多台。执行完把输出里的 Success、RestartNeeded 两列看一遍，Success 为 True 才算装上。

3.2 集群 IP 的 DNS 注册与同子网约束

集群 IP 是虚拟的，它不真正属于任何一块网卡，所以千万别让它被注册进 DNS。做法是在业务网卡的 IPv4 属性里进"高级"、切到"DNS"选项卡，取消勾选"在 DNS 中注册此连接的地址"。不关这一步，DNS 里那条指向集群 IP 的记录可能被解析到某个具体节点上，客户端以为在做负载均衡，实际全打到一台。

NLB 要求所有节点处于同一子网。这不是建议，是硬约束——集群 IP 在节点间共享，二层必须能互通。跨网段做负载均衡，得靠上层组件或者别的方案，NLB 本身不解决这个问题。另外要确认节点之间能互通心跳，第三方主机安全软件、终端防护策略有时会拦，遇到节点频繁进出集群先查这里。

账号方面，域环境下用同一个域账号即可；工作组环境下更省事的做法是在每台机器上建同名同密码的本地管理员，后续用 nlbmgr 远程添加节点时不会反复要凭据。

3.3 网卡规划与远程管理通道

单播模式会改写业务网卡 MAC，而 RDP、监控采集、备份这些管理动作通常也走同一张网卡，容易出现管理通道抖动甚至连不上。稳妥的规划是加一块不参与集群的网卡专门做管理。

管理网卡记得不要设默认网关，避免和业务网卡抢路由。如果节点跑在虚拟化平台上，两张虚拟网卡分别接到两张虚拟交换机上更干净，也便于把业务侧那张交换机的安全策略单独放开。

3.4 创建集群前的检查清单

这张表走一遍，后面建集群基本不会卡在莫名其妙的地方。

4. 用 nlbmgr 与 PowerShell 创建集群并加入节点

4.1 图形界面新建群集的点击路径

习惯了图形操作的话，nlbmgr.exe是最快的入口，这个可执行文件在装完管理工具后就在系统目录里，直接在运行框输入即可。

第一步，打开后右键左侧的"网络负载均衡群集"，选"新建群集"。第二步，在"新群集：主机"里填本机当前的业务 IP 和子网掩码，这一步是告诉 NLB 用哪块网卡的地址参与，填的是节点自己的真实 IP，不是集群 IP。第三步，进"新群集：群集 IP"页面，填虚拟出来的集群 IP 和掩码。第四步，进"新群集：群集参数"，这里是全书最容易选错的地方——IP 配置选"专用"还是"Internet"取决于集群 IP 是否公网可达；操作模式选单播、多播还是 IGMP 多播，按第 2 章的判断来；集群名建议和业务域名一致，方便后面建 A 记录。第五步，"新群集：端口规则"页面默认给一条"所有端口 0-65535、TCP/UDP 都管、多主机模式、单一亲和性"的规则，可以原样完成，也可以在这里先改成 80 和 443 两条，回头再细调。点"完成"，第一台节点就位。

完成后回到主界面，左侧树里能看到这个群集和它的唯一节点，右侧列出节点名、状态、主机优先级和负载权重。

4.2 PowerShell 一行一行把集群搭起来

图形界面适合做演示，真正批量部署还是得靠命令。

Import-Module NetworkLoadBalancingClusters # 1. 在第一个节点上创建集群，集群 IP 为 192.168.10.100 New-NlbCluster -InterfaceName "Ethernet" ` -ClusterPrimaryIP 192.168.10.100 ` -SubnetMask 255.255.255.0 ` -OperationMode Unicast ` -ClusterName "nlbweb" # 2. 查看集群概览，确认 ClusterPrimaryIP 与操作模式 Get-NlbCluster # 3. 查看当前节点状态，InitialHostState 应为 Started Get-NlbClusterNode -HostName "nlbweb"

-InterfaceName填Get-NetAdapter里的 Name，填错会报找不到接口。-ClusterPrimaryIP是虚拟 IP，必须是没有被别的主机占用的空闲地址，建议先在交换机或路由器上确认这个 IP 没有被 DHCP 池包含、也没有静态占用。-SubnetMask是集群 IP 所在网段的掩码。-OperationMode取 Unicast、Multicast、IgmpMulticast 三选一，对应第 2 章的三张牌，选多播系要提前把交换机侧配好，否则建完不通看不出原因。-ClusterName是集群名，用于 DNS 和管理工具里的显示。

建完立刻用Get-NlbCluster回看一遍，重点是 ClusterPrimaryIP 和 ClusterOperationMode 两项，和预期不一致就删掉重建，比在建好的集群上小修小补快：

# 需要推倒重来时，先停节点再删集群 Stop-NlbClusterNode -HostName "nlbweb" Remove-NlbCluster -HostName "nlbweb"

4.3 把第二台及后续节点拉进集群

两个方向都能加节点，按手头方便选一个。在已存在的集群节点上发起，远程把新节点拉进来：

Add-NlbClusterNode -NewNodeName "nlb02" ` -NewNodeInterface "Ethernet" ` -HostName "nlbweb" Get-NlbClusterNode -HostName "nlbweb" | Select-Object Name, State, HostPriority, LoadWeight

在新节点上执行也行，方向和上面相反，注意-HostName指向的是集群名而不是某个节点名：

Add-NlbClusterNode -InterfaceName "Ethernet" -HostName "nlbweb"

两种写法的参数集不同，拿不准就先跑Get-Help Add-NlbClusterNode -Full，把参数集看一遍再下手，比照着网上零散的例子猜要稳。图形界面里同样能加：右键群集选"连接到现有群集"输入任意节点 IP，再右键选"添加主机到群集"，填新节点名和网卡名即可。

加完后用Get-NlbClusterNode确认每台节点的 State 都是 Converged。这个状态是判断集群是否正常收敛的关键：一度出现 Pending 又变回 Converged 属正常，长时间停在 Converged 之外，先查节点间心跳通不通。

注意：32 是 NLB 的节点上限，主机优先级在集群内必须唯一，取值 1 到 32。用命令加节点时优先级会自动分配，手工调整后记得回看一眼有没有撞号。

5. 端口规则、亲和性与心跳参数的调优

5.1 端口规则的三要素：范围、协议、处理模式

端口规则决定 NLB 管哪些流量，以及这些流量怎么落到主机上，一条规则由端口范围、协议、处理模式三部分构成。

端口范围可以是一条"所有端口 0-65535"，也可以是 80 到 80 这种精确区间。图省事用全端口规则的后果是，诸如 3389、445 这类管理端口也被卷进分发逻辑，多节点环境下表现为 RDP 偶尔连到别的节点上去，排查起来很费时间。生产环境建议只放行真正需要分发的端口。

协议取 TCP、UDP 或 BOTH。Web 是 TCP，DNS 之类的服务需要 UDP，不确定就把两者都包含进来。处理模式有三种：MultipleHost 是多主机模式，所有节点按权重分担，这是绝大多数场景的选项；SingleHost 是单一主机模式，只有优先级最高的那台收流量，其余待命，适合主备而非多活；Disabled 直接丢弃该端口流量，用来把不需要暴露的端口挡掉。

# 先删掉默认的全端口规则，再按 80、443 两条精确规则建立 Get-NlbClusterPortRule -HostName "nlbweb" Remove-NlbClusterPortRule -HostName "nlbweb" -PortStart 0 -PortEnd 65535 New-NlbClusterPortRule -HostName "nlbweb" ` -PortStart 80 -PortEnd 80 ` -Protocol TCP ` -Affinity Single ` -Mode MultipleHost New-NlbClusterPortRule -HostName "nlbweb" ` -PortStart 443 -PortEnd 443 ` -Protocol TCP ` -Affinity Single ` -Mode MultipleHost

-Affinity控制粘性，-Mode控制分发方式，两个参数组合起来才是一台客户端实际会经历的行为。

5.2 亲和性单选、无、网络对会话保持的影响

亲和性是这套配置里最容易被忽略、也最容易背锅的一项，它决定同一个客户端会不会一直落到同一台主机。

Single 是默认值，同一客户端 IP 的请求始终归同一台主机处理。IIS 那种进程内 Session 的站点必须用它，否则用户刷新一下页面就掉登录态。它的边界在于客户端 IP 在会话期间必须稳定，经过 NAT 出口汇聚、手机切网这些情况，源地址一变就会被重新分配到另一台机器。

None 表示不做粘性，同一客户端的请求可能落到不同节点。它适合无状态应用，比如静态资源站点、纯 API 服务。有一点需要澄清：单个 TCP 连接内的所有报文仍然会走同一台主机，因为连接的四元组哈希一致；受影响的只是客户端发起的多个独立连接，浏览器并发请求会被打散到不同节点。

Network 是把同一个网段整体映射到一台主机，粒度更粗。它适合客户端集中在少数几个大出口网段的场景，能减少跨节点来回。改亲和性不需要重建集群，直接更新已有规则：

Set-NlbClusterPortRule -HostName "nlbweb" -PortStart 80 -PortEnd 80 -Affinity None

改完在客户端侧连续访问几次同一地址，看返回内容里的主机名是否变化。这一步是验证亲和性是否生效最直接的办法，比翻文档猜要快。

5.3 负载权重、主机优先级与心跳超时

权重决定哈希空间怎么切。两台配置差一截的机器，把强的那台权重调高，能让它多接一些。

# 让 nlb02 承担较少流量 Set-NlbClusterNode -HostName "nlbweb" -NodeName "nlb02" -LoadWeight 30 # 查看每台节点的权重与当前状态 Get-NlbClusterNode -HostName "nlbweb" | Select-Object Name, State, HostPriority, LoadWeight

权重是按比例生效的，两台机器的权重写 70 和 30 跟写 7 和 3 是一回事，没必要凑成一百。这个值调完立刻生效，不影响已有连接。

主机优先级用于 SingleHost 模式，数值 1 最高，集群内不能重复。主机初始状态有三个取值：Started 表示立即参与分发，Stopped 表示不参与，Suspended 表示暂停但保留已有连接。最后这个取值在计划维护时很有用，配合后面第 6 章的排空操作，能实现用户无感的节点下线。

心跳参数在图形界面的集群属性 →"群集参数"里改，默认周期 1000 毫秒、重试 5 次，也就是差不多 5 秒判定一台节点离线。周期调小切换更快，但网络稍有抖动就会误判，节点反复进出集群反而更不稳；调大则切换变慢。内网环境保持默认通常就够，只有在网络质量明确较差时才考虑放宽重试次数。故障切换时间等于周期乘以重试次数再加重收敛开销，这个账值得自己算一遍。

顺带说一句边界：NLB 只做接入层的流量分发，数据库这类有状态服务的双机切换是另一回事，那属于 Windows Server 故障转移集群（WSFC）要解决的问题，两者经常搭配使用，但职责完全不同，别指望 NLB 能把 SQL Server 的实例切换也一起办了。

6. 上线验证与几个真会踩的坑

6.1 用排空做一次零中断的切换验证

集群建好、规则配好之后，别直接把它当已完成。最少要做一遍下线验证：在业务低峰期把其中一台节点排空，也就是让它先停止接收新连接，等已有连接自然结束再退出集群。

# 排空 nlb02：不接受新连接，已有连接继续处理 Stop-NlbClusterNode -HostName "nlbweb" -NodeName "nlb02" -Drain # 观察状态，等它从 Draining 变为 Stopped Get-NlbClusterNode -HostName "nlbweb" | Select-Object Name, State

排空期间在客户端侧持续发起请求，正常表现是全部落到剩余节点、没有连接被重置。恢复节点用Start-NlbClusterNode -HostName "nlbweb" -NodeName "nlb02"。要是排空过程中出现大量超时，说明业务侧没有正确处理连接迁移，通常和服务自己的连接池、长连接超时设置有关，而不在 NLB 这一层。

验证分发的另一个笨办法是在每台节点返回内容里带上机器名或节点标识，从客户端反复请求，看响应是否在两个标识之间交替。配合Get-NlbClusterPortRule确认规则命中的端口范围，比对着抓包结果猜要省事。

6.2 三个高频现象与排查顺序

第二个现象最常被误判成 NLB 没生效。默认亲和性是 Single，从一个固定客户端测试，分词算法必然把它固定映射到某一台，看起来就是"只有一台在干活"。把亲和性临时改成 None，或者换一台不同来源 IP 的客户端再试，立刻就能看出区别。想看得更细，可以打开事件查看器里的 Microsoft-Windows-NLB 日志，节点收敛、心跳超时这类事件都会记在里面。

还有个容易忽略的点：如果节点上跑的是容器化的服务，比如用 Docker 安装部署好、通过端口映射暴露到宿主机的应用，NLB 按宿主机的端口分发就行，容器内部网络对它是透明的，不需要为容器单独配规则。监控侧也一样，只要业务节点上的性能计数器能采出来，用 Prometheus 加 Grafana 看每台节点的连接数和吞吐是否按权重分布，比凭感觉判断均衡效果靠谱得多。

本文还有配套的精品资源，点击获取