Microsoft 群集相对于 Microsoft 网络负载均衡器的优势

Question

直到最近，我一直认为 Microsoft NLB 是在操作系统/机器级别而不是应用程序级别工作。也就是说，NLB 只是监视机器上的心跳以检查机器是否处于活动状态，然后在特定节点出现故障时将其关闭。

然而，我发现评论关于服务器故障问题，说法不同。根据评论

NLB 只会将连接路由到打开的 TCP 端口。如果您的应用程序关闭了该端口，则 NLB 将不再将连接路由到该端口，直到该端口再次打开。

1. 以上内容属实吗？NLB 是否在端口级别监控应用程序？
2. 如果 (1) 的答案是“是”，那么它会同时针对服务中断和服务挂起的情况进行切换，还是仅针对其中一种情况进行切换？
3. 如果 NLB 确实做到了上述所有事情，那么使用 Clustering 又有什么意义呢？唯一的优势是，对于 Clustering 来说，您不需要复制数据。但总体而言，Clustering 是更昂贵的解决方案。
4. 对于 MS SQL Server 等标准产品以及我自己的服务，上述问题的答案会有所不同吗？还是相同？
5. 如果 NLB 不执行上述操作而仅执行 OS/机器级别的心跳，那么除了集群之外还有其他方法可以为自己的服务提供 HA 和切换吗？

Answer 1

NLB 的工作方式并非如此。NLB 端口规则决定哪些端口在 NLB 主机之间进行负载平衡。未“绑定”到 NLB 端口规则的流量不会在 NLB 主机之间进行负载平衡。NLB才不是监控与端口规则关联的端口，并在该端口关闭或特定主机上为该端口提供服务的应用程序崩溃时禁用到该主机的 NLB 群集流量。NLB 使用第 2 层“心跳”来确定群集中主机的可用性。如果主机的心跳机制失败，则所有其他主机将“聚合”（或重新聚合），从群集中移除无响应的主机，以便没有群集流量（基于端口规则）被定向到无响应的主机。NLB 严格来说是第 3 层（网络层）负载平衡机制。它不是第 7 层（应用程序层）负载平衡机制。

在 NLB 端口规则中定义的 NLB 主机上，如果应用程序挂起（例如 HTTP 或 RDP），但仍在接收 NLB 流量，即使该应用程序无法接受该流量，这完全正常。这是因为 NLB 无法感知第 3 层以上的任何内容。