Microsoft群集优于Microsoftnetworking负载平衡器

直到最近,我还是假定Microsoft NLB在操作系统/机器级别而不是应用级别上工作。 即,NLB只监视机器上的心跳,以检查机器是否处于活动状态,然后closures特定节点(如果它断开)。

但是,我发现这个评论在服务器故障问题上有所不同。 根据评论

NLB只是将连接路由到打开的TCP端口。 如果您的应用程序closures了端口,则NLB将不再将其连接路由到该端口,直到该端口再次打开。

  1. 以上是真的吗? NLB是否在端口级别监视应用程序?
  2. 如果(1)的答案是“是”,那么它是否会切换服务停止以及服务挂起的情况,还是仅针对其中的一种情况?
  3. 如果NLB确实做了以上所有的事情,那么使用Clustering有什么用呢? 唯一的好处是对于集群,你不需要复制的数据。 但总体集群将是更昂贵的解决scheme。
  4. 对于像MS SQL Server这样的标准产品,对于我自己的服务,上述问题的答案是不同的,还是相同?
  5. 如果NLB不这样做,只是操作系统/机器级别的心跳,那么有没有其他的方式,而不是群集为我自己的服务提供高可用性和切换?

这不是NLB的工作原理。 NLB端口规则确定哪些端口/端口在NLB主机之间进行负载平衡。 未绑定到NLB端口规则的stream量不在NLB主机之间进行负载平衡。 NLB 不会监视与端口规则关联的端口/端口,并禁止在该端口/端口/端口closures时向该主机发送NLB群集stream量,或者在特定主机上的那些端口/端口上提供服务的应用程序崩溃。 NLB使用第2层“心跳”来确定群集中主机的可用性。 如果主机失败了心跳机制,则所有其他主机将“聚合”(或重新聚合)从集群中移除无响应的主机,使得没有集群通信(基于端口规则)被引导到非响应主机响应主机。 NLB严格是第3层(networking层)负载平衡机制。 它不是第7层(应用层)负载平衡机制。

在NLB端口规则中定义的NLB主机(如HTTP或RDP)上挂起应用程序仍然正在接收NLB通信,这是非常正常的,即使应用程序不能接受该通信。 这是因为NLB没有意识到第三层以上的任何东西。