Good Morning AskPerf Nation! Our Launch Series is at Day Seventeen. There are only five more days to go! Today we’re continuing on with Remote Desktop Services, with a look at Remote Desktop Services Virtualization (or RDS-V, for short). You may also hear RDS-V referred to as Virtual Desktop Infrastructure (VDI). RDS-V provides remote desktop access to managed desktop environments hosted in Hyper-V on Windows Server 2008 R2. OK, there are way too many technical buzzwords in that last sentence, aren’t there? Simply put, in the same way that RemoteApp makes applications available to users through individual Remote Desktop Services sessions, RDS-V provides access to specific virtual machines (desktops) through a similar mechanism. So, what does it really do?
RDS-V uses the Remote Desktop Connection Broker to determine where the user is redirected. If a user is assigned and requests a personal virtual desktop, RD Connection Broker redirects the user to this virtual machine. If the VM is not turned on, RD Virtualization turns on the VM and then connects the user. If the user is connecting to a shared virtual pool, then the RD Connection Broker checks to see if the user already has a connected session in the pool. If the user has a disconnected session then they are reconnected to that VM. If the user does not have a disconnected session, a VM in the pool is dynamically assigned to the user – if one is available. A quick note here, the Hyper-V server role has to be installed on the same system that has the RD Virtualization role service installed. Let’s take a quick look at the fairly simple high-level RDS-V topology:
The different components of RDS-V are as follows:
The diagram above breaks out the different components and their functions. Let’s take a closer look at the Connection Broker’s functions:
There are some basic steps that the Connection Broker performs. If the endpoint for the request is a farm, then the Connection Broker has to check the cache of user sessions to see if there is an existing disconnected session within that particular farm. The key here is that the disconnected sessions are farm-specific. If the user does not have a session, the Connection Broker chooses the best machine or VM image within the farm. There is also some machine logic that takes place. Connection Broker calls into the type-specific VM Plug-in to carry out what is called Placement. This action involves the plug-in move the necessary VM image to the best VM Host and then return the name of that host. For VM calls specifically (as opposed to RemoteApp requests), the Connection Broker calls into the VM Host Agent to spin up the VM image. This is called Orchestration. The return value of this step is a list of IP addresses for the final machine / image to which the RDS Client should be redirected. These steps are executed each time a user connects. In addition, the Connection Broker also has a “Pool Creator”. This component coordinates the creation of VM farms by directing VM Host Agents to create farm-joined VM instances out of template VM images.
The flowchart below outlines the logic that is followed by the Connection Broker when a VM connection request is made:
OK folks – with that, we’ve reached the end of today’s post. A couple of quick things to keep in mind:
Now, I know that we didn’t do a full walkthrough on the “How To’s” for this entire process. If that’s something that you would like us to go over – let us know. And now, we really are at the end of our post. I’ll be back tomorrow with a look at Remote Desktop Services IP Virtualization. Until tomorrow …
|Share this post :||
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.