locked
NLB not behaving as expected RRS feed

  • Question

  • Three Windows 2008 R2 servers configured exactly alike, each with two NICs, Remote Desktop Session Host installed, NLB feature added.

    Node1 cluster IP 192.168.1.31 host priority1

    Node2 cluster IP 192.168.1.32 host priority2

    Node3 cluster IP 192.168.1.33 host priority3

    Cluster setup at 192.168.1.40 with all three nodes added, converged and working.  Port rules: ClusterIP 192.168.1.40; port range 0-65535; UDP and TCP; Filtering mode Multiple Host and Single and they are all equal weighting (essentially a default setup for now).

    DNS entries:

    CNAME: rds.domain.local = nlb.domain.local

    A Record: nlb.domain.local = 192.168.1.40

    Using Remote Desktop Connection i connect to rds.domain.local.  It only ever connects to Node1.  It doesn't appear to be load balancing anything.

    Any thoughts?


    Thanks

    Tuesday, March 5, 2013 3:47 PM

Answers

  • Ok I'm bothered by this issue.  The recommendation above is to NOT install nlb on the servers, which is contrary to everything I understood about setting up a network load balanced server farm.  It implies that the connection broker is doing your load balancing, which it is for INITIAL connections or REconnections, but it does nothing for a network failure, which is exactly where NLB comes into play.

    Regardless the initial question was regarding why I was consistently only attaching to one node.  I did some more extensive testing and discovered why.  DNS caching.   Plain and simple.

    • Marked as answer by Willmeister Wednesday, March 13, 2013 3:36 PM
    Wednesday, March 13, 2013 3:36 PM

All replies

  • Hi,

    Thanks for your post.

    In Windows Server 2008 R2, it’s recommend to deployment RDS farm for load balance. Make sure there are dedicated server install RD session host role which act as farm member. Please note that all servers in a farm are meant to be effectively identical, so they can interchange with each other. Do not install other roles on the RD Session Host server. We do not need to install NLB feature on servers. For the RD connection broker, the component should run on a separate server. This type of installation enabled to take any terminal server offline for maintenance or upgrade purposes without affecting the availability of the farm. However, the TS session broker hardware requirement is very light. So we can install it on a less capable server, or the role could be combined with other roles in the organization.

    For more detailed information, please check the following article.

    Remote Desktop Session Host Farm Design

    http://technet.microsoft.com/en-us/library/gg749904(v=ws.10).aspx

    Checklist: Create a Load-Balanced RD Session Host Server Farm by Using RD Connection Broker

    http://technet.microsoft.com/en-us/library/cc753891.aspx

    Best Regards,

    Aiden


    Aiden Cao
    TechNet Community Support


    • Edited by Aiden_Cao Wednesday, March 6, 2013 3:05 AM
    • Marked as answer by Aiden_Cao Wednesday, March 13, 2013 9:04 AM
    • Unmarked as answer by Willmeister Thursday, March 14, 2013 1:57 PM
    Wednesday, March 6, 2013 3:04 AM
  • It would appear http://technet.microsoft.com/en-us/library/cc771300(v=ws.10).aspx/ contradicts those docs.  Also DNS round robin isn't an option for any part of the load balancing.  Thanks.
    Wednesday, March 6, 2013 9:34 AM
  • Ok I'm bothered by this issue.  The recommendation above is to NOT install nlb on the servers, which is contrary to everything I understood about setting up a network load balanced server farm.  It implies that the connection broker is doing your load balancing, which it is for INITIAL connections or REconnections, but it does nothing for a network failure, which is exactly where NLB comes into play.

    Regardless the initial question was regarding why I was consistently only attaching to one node.  I did some more extensive testing and discovered why.  DNS caching.   Plain and simple.

    • Marked as answer by Willmeister Wednesday, March 13, 2013 3:36 PM
    Wednesday, March 13, 2013 3:36 PM
  • Im going to add to this prior to opening another discussion.  There are a LOT of docs out there on this subject.  Too many.  I'm basing my design on this, mentioned above http://technet.microsoft.com/en-us/library/cc771300(v=ws.10).aspx/ 

    According to this doc:

    NLB distributes traffic across several servers by using the TCP/IP networking protocol. You can use NLB with a terminal server farm to scale the performance of a single terminal server by distributing sessions across multiple servers.

    So i have NLB setup and it works great by itself, and the key here, i can pull the network cable on a node to simulate an outage and another node picks up the connection.  This is an absolute bottom line must have.  So i need NLB.

    But sometimes a disconnected session is not reconnected and a new session is opened on another server.  From my understanding this is where the Broker comes into play, and i tested it by itself taking NLB off the servers, and it worked beautifully by itself.  However if I lose a node in the farm those sessions are gone.  Unacceptable.

    So why is the advice to use a Remote Desktop Connection Broker and set up a farm (without NLB) when there's no failover capabilities?

    And the reason i ask may not be so obvious, but I want the benefits of both.  I want my NLB failover capabilities but with a Broker on the front end, and so far I have not been able to successfully deploy this.  It would appear the two don't work together...but that contradicts MS documentation.

    Thursday, March 14, 2013 2:09 PM