none
WINDOWS Server2008R2 NLB 單播 問題 RRS feed

  • 问题

  • 我有兩臺 2008R2 的終端服務器,是通過 NLB 單播的方式,來實現負載均衡的。

    我的使用者都是通過RDP 方式連接到 終端服務器來作業。

    現在我發現,當我的使用者連接數量越多,我的終端服務器上 訪問其他服務器的網絡延時越嚴重。

    差不多 達到每台服務器的數量有 40 個 終端連接數量的時候,

    終端服務器 ping 其他服務器 的網絡延遲都達到了 300ms。

    我在網上看到,有人說是 NLB 的 單播會對網絡造成影響,

    所以我想問問,是需要將我的NLB   單播方式 改為  多播 嗎?

    謝謝  

    2012年7月23日 5:47

答案

  • 单播 
    在单播模式下,NLB服务会重新对每个节点中启用NLB的网卡分配MAC地址(此MAC地址称为群集MAC地址),并且所有的NLB节点均使用相同的MAC地址(均使用群集MAC地址),同时NLB会修改所有发送的数据包中的源MAC地址,这样就导致交换机不能将此群集MAC地址绑定在某个端口上。 

    工作在单播模式下的NLB可以在所有网络环境下正常运行(兼容性最好),但是由于它的工作特性,具有以下两个限制:

    1.由于NLB所使用的群集MAC地址没有绑定在某个具体的交换机端口上,所以所有的NLB通讯均通过在交换机的所有端口上广播进行,
      而不管此端口是否连接了NLB节点,这造成了额外的网络流量负担; 

    2.由于所有的NLB节点具有相同的MAC地址,NLB节点之间不能通过自己原有的专用IP地址进行通讯。 (例如我们见得最多的就是节点之间就无法ping通)


    多播 

    在多播模式下,NLB不会修改NLB节点启用NLB的网络适配器的MAC地址,而是为它再分配一个二层多播MAC地址专用于NLB的通讯(此MAC地址称为群集MAC地址),这样NLB节点之间可以通过自己原有的专用IP地址进行通讯。但是在多播模式中,NLB节点发送的针对群集IP地址/MAC地址ARP请求的ARP回复会将群集IP地址映射到多播MAC地址,而许多路由器或者交换机(例如,港湾和思科的某些产品)会拒绝这一行为。如何解决呢?方法是手工在路由器或交换机上添加静态映射,将群集IP地址映射到群集的多播MAC地址

    在IT的路上,You'll never walk alone

    2012年7月23日 7:18
  • 的确要看一下交换机的CPU,内存使用率.
    2012年8月6日 6:01

全部回复

  • 我在網上看到,有人說是 NLB 的 單播會對網絡造成影響


    请问这是微软官方的说法吗?如果不是,请不要轻信。
    2012年7月23日 6:04
  • 单播 
    在单播模式下,NLB服务会重新对每个节点中启用NLB的网卡分配MAC地址(此MAC地址称为群集MAC地址),并且所有的NLB节点均使用相同的MAC地址(均使用群集MAC地址),同时NLB会修改所有发送的数据包中的源MAC地址,这样就导致交换机不能将此群集MAC地址绑定在某个端口上。 

    工作在单播模式下的NLB可以在所有网络环境下正常运行(兼容性最好),但是由于它的工作特性,具有以下两个限制:

    1.由于NLB所使用的群集MAC地址没有绑定在某个具体的交换机端口上,所以所有的NLB通讯均通过在交换机的所有端口上广播进行,
      而不管此端口是否连接了NLB节点,这造成了额外的网络流量负担; 

    2.由于所有的NLB节点具有相同的MAC地址,NLB节点之间不能通过自己原有的专用IP地址进行通讯。 (例如我们见得最多的就是节点之间就无法ping通)


    多播 

    在多播模式下,NLB不会修改NLB节点启用NLB的网络适配器的MAC地址,而是为它再分配一个二层多播MAC地址专用于NLB的通讯(此MAC地址称为群集MAC地址),这样NLB节点之间可以通过自己原有的专用IP地址进行通讯。但是在多播模式中,NLB节点发送的针对群集IP地址/MAC地址ARP请求的ARP回复会将群集IP地址映射到多播MAC地址,而许多路由器或者交换机(例如,港湾和思科的某些产品)会拒绝这一行为。如何解决呢?方法是手工在路由器或交换机上添加静态映射,将群集IP地址映射到群集的多播MAC地址

    在IT的路上,You'll never walk alone

    2012年7月23日 7:18
  • 謝謝,請問 以我的 描述的應用, 我是更適合 NLB 的單播,還是NLB 的多播呢?
    2012年7月24日 3:42
  • 建议采用多播~

    在IT的路上,You'll never walk alone

    2012年7月24日 3:46
  • 尝试是可以的,但这个尝试的理由,只是纯理论的所谓“单播效率低”吗?至少应该也从网络设备那头确认一下是不是吞吐超负荷了吧
    2012年7月24日 3:55
  • 改成 多播了,問題 還是存在,這下不知道怎麼回事了。

    2012年7月31日 3:52
  • 改成 多播了,問題 還是存在,這下不知道怎麼回事了。


    先找到确切瓶颈,再想办法解决,别盲目乱改乱猜。。。
    2012年8月1日 3:48
  • 謝謝你的多次回覆,

    可是我真不知道問題的瓶頸在哪兒?

    因為從實際情況來看,服務器的CPU 不高,沒有超過 20%,內存高一點,達到 80%左右,網卡也是很低,平均 5%都不到。

    而且是,只要我一拷貝較大問題 到其他服務器,那個網絡延遲就 立即增大很多。

    2012年8月2日 8:27
  • 的确要看一下交换机的CPU,内存使用率.
    2012年8月6日 6:01