A RD Session Host server farm consists of two or more RD Session Host servers with the same software configuration (for example, security settings and device redirection policies) and application sets, all represented under a single farm name so that they appear to the client as a single server. Server farms are load-balanced so that the workload is distributed evenly among all farm members. Because the servers are configured the same way, it does not matter to users which server they get directed to. All servers should provide the same user experience.
When a client connects to RDSH farm, the client makes an initial connection to a particular RDSH server which redirects the client to a Remote Desktop Connection Broker (RDCB) which then brokers a connection to an individual RDSH of the farm. Initial connections can be load balanced in three main ways:
- DNS Round Robin
- Network Load Balancing
- Dedicated RDSH Redirector
DNS RR is not so clever. By creating multiple host records for each member of the farm, you distribute client connections to the farm. If however a farm member goes down, DNS will continue to hand the host record out to requesting clients despite the fact that a member server is down.
A dedicated redirector is an RD Session Host server whose sole role is to redirect initial connection requests to RDCB. To avoid asking working RD Session Host farm servers to handle incoming connections, you can dedicate a server to do this work. The only catch to using a dedicated redirector is that it represents a single point of failure.
We will configure initial connection load balancing by using load Network Load Balancing (NLB):
As you can see in the diagram above, the client makes an initial connection via the RD Web Access server to RDSH 1. This could be infact to RDSH1 or RDSH2 as these two servers will be in a NLB cluster. Either server will then redirect the connection to the RDCB. The RD Connection Broker finds the most suitable endpoint for the connection request and gets its IP address. The result is passed back to the RDSH and then back to the client. The client then connects directly to the RDSH that the RD Connection Broker has deemed most suitable.
If an RDSH server goes offline how does the RDCB know? It monitors whether the connections it redirects are successful. If redirection fails the RDCB begins pinging the suspect RDSH server and if this fails then the RDSH is removed from its database.
No comments:
Post a Comment