Windows Server网络负载均衡NLB配置中的亲和性设定

Windows Server网络负载均衡（NLB）的亲和性设定，本质上是在解决一个“状态”问题。当你把多台服务器通过NLB组成一个集群对外提供服务时，默认情况下客户端的请求会被平均分配到各个节点。但如果你的应用是有状态的，比如一个用户登录后，购物车信息只存在了服务器A的内存里，下一个请求却被NLB转发到了服务器B，用户就会发现购物车突然空了。亲和性就是用来确保同一个客户端在一段时间内的请求，始终被转发到同一台后端服务器上。这不是一个简单的开关，而是直接影响应用架构设计和用户体验的核心参数。

NLB提供了三种亲和性设置，在配置界面上显示为“无”“单一”和“网络”。很多管理员只是随手一选，但它们的底层行为差异巨大。

无（None）： 这是最纯粹的负载均衡模式。每个新的请求，无论是否来自同一个客户端IP或端口，NLB都会根据负载算法重新选择目标服务器。这种模式下，集群的负载分布最均匀，但代价是完全不考虑会话状态。如果你的应用是完全无状态的，比如静态图片服务器、纯API网关且认证令牌存储在客户端或共享缓存中，那么“无”是最佳选择。它能最大化利用所有节点的计算资源。

单一（Single）： 这是最常用的亲和性模式。一旦NLB将某个客户端IP的第一个请求分配给了服务器A，那么后续来自这个特定IP的所有请求，都会被强制转发到服务器A。这个绑定关系会一直持续到该客户端停止请求超过一个设定的超时时间，或者集群成员发生变更。它的核心机制是NLB驱动在底层修改了TCP/IP协议栈的哈希算法。默认情况下，NLB会对源IP和目标IP及端口进行哈希计算来决定路由。开启“单一”亲和性后，哈希计算只基于源IP，完全忽略了端口变化。这意味着同一台电脑上打开的两个浏览器，因为源IP相同，它们的请求都会被导向同一台服务器。

网络（Network）： 这个模式很多人容易和“单一”混淆，但它的粒度更粗。它基于的是客户端所在的C类子网，也就是IP地址的前三段。只要客户端来自同一个网段，比如192.168.1.x，所有请求都会被分配到同一台服务器。这个设计在早期主要为了兼容那些使用网络地址转换（NAT）代理上网的环境，因为大量用户可能共用一个公网IP出口。但现在它的应用场景已经非常狭窄，甚至可能带来严重的负载不均问题，因为一个大型企业或学校可能成千上万用户都从同一个C类地址段出来，结果全部请求都压在一台服务器上。

亲和性不是在全局开关的，它是在“端口规则”里定义的。这是配置中最容易出错的地方。在NLB管理器中，你添加的每一条规则都对应一个端口范围、协议类型以及独立的亲和性设置。这意味着你可以为同一个集群的不同服务设置完全不同的亲和性策略。

一个典型的混合场景是：集群同时提供HTTPS网站和FTP服务。对于443端口的HTTPS流量，你可能需要“单一”亲和性来维持用户登录会话。但对于21端口的FTP控制连接，由于FTP协议的特殊性，它需要动态打开数据端口，如果使用了“单一”亲和性，控制连接和数据连接可能被分配到不同节点导致传输失败。此时，FTP的端口规则就应该设置为“无”，并配合共享存储来解决文件一致性问题。这种按端口粒度的精细化控制，是高级NLB配置的核心思路。

亲和性不是永久的。NLB有一个关键的隐藏参数：会话超时时间。在“单一”和“网络”模式下，当客户端停止发送请求一段时间后，NLB会清除这个客户端的亲和性绑定记录。这个时间默认值在不同Windows Server版本中有所不同，通常是几分钟。对于需要长时间保持会话的应用，比如基于WebSocket的在线协作工具，默认超时可能导致用户在编辑文档时突然失去与后端特定节点的连接。

这个超时值无法通过图形界面修改，必须通过PowerShell或注册表调整。在PowerShell中，你可以使用以下命令查看当前集群的配置细节：

Get-NlbCluster | Format-List *

要修改会话超时时间，需要调整注册表项。路径通常位于 HKLM\System\CurrentControlSet\Services\WLBS\Parameters 下，具体键值涉及 AliveMsgTolerance 和 AliveMsgPeriod 等参数。但请注意，直接修改注册表风险较高，建议先在测试环境验证。更稳妥的方式是通过设置 ClientAffinityTimeout 参数。这个值以分钟为单位，适当延长它可以减少用户被意外切换节点的概率，但也会导致负载分布在一段时间内不够均衡。

一个常见的认知误区是认为开启了NLB亲和性，应用层的会话就不会丢失。这是错误的。NLB工作在传输层，它只负责把数据包转发到某台服务器，完全不理解HTTP Cookie或Session是什么。如果服务器A因为硬件故障宕机，NLB会检测到心跳丢失，立即将后续请求切换到服务器B。此时，即使亲和性设置还在，但目标服务器已经变了，服务器A内存里的会话数据瞬间消失。

亲和性只能解决“正常情况下的路由一致性”问题，解决不了“故障转移时的状态保持”问题。要真正实现会话级别的容错，必须在应用层做状态外置。将Session存储在Redis、Memcached这类共享缓存中，或者存入共享数据库。这样，即使NLB把用户请求切换到了服务器B，服务器B也能从共享存储中找回用户的登录状态和购物车数据。在这个架构下，NLB的亲和性设置其实可以大胆地设为“无”，从而获得最佳的负载均衡效果和资源利用率。

开启“单一”亲和性后，最典型的故障现象是集群中某台服务器的CPU或内存使用率持续高于其他节点。这通常是因为某些源IP地址产生了远超平均水平的请求量。比如，一个来自大型企业网关的IP，背后可能隐藏着几百个真实用户，但NLB只看到一个源IP，于是把所有请求都压到了一台服务器上。

诊断这个问题，需要用到NLB的日志功能。在Windows Server上，你可以通过性能监视器添加NLB相关的计数器，特别是“Client connections”和“Packets received”。同时，在每台节点上开启IIS日志并记录客户端IP地址。通过分析日志，如果发现某个IP的请求量占总请求的20%以上，且该IP的请求全部落在同一台节点上，就基本可以确定是亲和性导致的负载倾斜。解决思路不是取消亲和性，而是优化应用。例如，让客户端在首次连接时随机生成一个标识附加在URL路径或子域名上，人为增加源信息的散列维度，让NLB的哈希计算能够更均匀地分布流量。

在纯IPv6或双栈环境中，NLB的亲和性行为需要特别注意。IPv6地址空间巨大，NAT的使用场景大幅减少，每个客户端设备通常都有全局唯一的公网IPv6地址。这意味着“单一”亲和性在IPv6下会变得极其精确，几乎每个设备都会被独立绑定到一台服务器。这看似理想，但如果客户端使用了IPv6隐私扩展，它会定期更换IP地址以保护隐私。一旦客户端IP发生变化，NLB就会认为这是一个全新的客户端，从而可能将其请求分配到另一台服务器，导致原有会话丢失。

对于“网络”亲和性，在IPv6下其行为基于IPv6地址的前缀，通常是前64位。这代表一个子网，粒度依然很粗，同样面临负载不均的风险。因此，在规划IPv6部署时，如果应用依赖会话保持，必须评估客户端是否启用了隐私扩展，并相应调整亲和性策略或强化应用层状态共享机制。

在大规模集群部署中，手动通过图形界面配置亲和性既低效又容易出错。PowerShell提供了完整的NLB管理模块。以下脚本演示了如何为特定端口规则设置“单一”亲和性：

# 导入NLB模块
Import-Module NetworkLoadBalancingClusters

# 获取现有集群
$cluster = Get-NlbCluster

# 为端口443添加新规则，设置单一亲和性
$cluster | Add-NlbClusterPortRule -StartPort 443 -EndPort 443 -Protocol TCP -Affinity Single -Mode Multiple

# 如果需要修改现有规则，可以先移除再添加，或者使用Set-NlbClusterPortRule
# 查看当前所有端口规则以确认配置
Get-NlbClusterPortRule | Format-Table StartPort, EndPort, Protocol, Affinity, Mode

对于更复杂的场景，比如需要为多个端口批量设置不同亲和性，可以编写一个CSV配置文件，然后用脚本循环读取并应用。这种基础设施即代码的思路，能确保开发、测试、生产环境的NLB配置完全一致，避免因人为误操作导致的生产事故。

在Hyper-V或VMware虚拟化平台上运行NLB时，亲和性设定会遇到网络层面的额外干扰。虚拟交换机的MAC地址学习机制、端口组的安全策略都可能影响NLB的心跳和流量转发。如果虚拟机使用了动态MAC地址，或者虚拟交换机开启了MAC地址欺骗防护，NLB的多播或单播模式可能工作异常，进而导致亲和性绑定表混乱。

对于使用单播模式的NLB，虚拟交换机的MAC地址表会因为集群共享同一个虚拟MAC而频繁更新，这可能导致亲和性绑定关系在几秒内失效。解决方案是在虚拟化平台上启用“MAC地址欺骗”或“混杂模式”用于NLB流量，或者改用NLB的多播模式。在多播模式下，亲和性设定依然生效，但需要确保上游物理交换机和虚拟交换机都能正确处理多播IGMP报文。否则，亲和性虽然配置正确，但数据包根本无法到达正确的节点。

NLB的健康检测机制与亲和性之间存在微妙的联动。当一个节点被标记为不可用（例如因为心跳丢失），NLB会立即将该节点从转发列表中移除。所有原本通过亲和性绑定到该节点的客户端，其后续请求会被重新分配。这里的关键在于，重新分配后的新节点选择，依然遵循亲和性规则。如果新节点被选中，客户端IP会立即与这个新节点建立新的亲和性绑定。

这个过程对客户端来说可能表现为一次连接中断，然后重连后恢复正常。但如果故障节点恢复，重新加入集群，NLB并不会自动将之前迁移走的客户端再“归还”回去。那些客户端已经与新节点建立了绑定，会一直留在新节点上，直到会话超时或者客户端停止请求。这种设计避免了频繁的节点切换，但也意味着在节点恢复后，集群的负载分布可能会暂时不均衡。理解这一点，有助于在计划内维护时，通过手动排空节点连接来平滑过渡，而不是直接关机导致大量亲和性绑定瞬间断裂。

深入理解NLB的亲和性设定，本质上是理解无状态与有状态应用在架构上的取舍。没有一种设置是绝对正确的，它完全取决于你的应用逻辑、客户端行为以及底层网络环境。把亲和性当作一个需要根据业务指标持续调优的动态参数，而不是一次性的静态配置，才是保证Windows Server负载均衡集群长期稳定运行的关键。