Planning and Deploying Session-based Virtual Desktops

Understanding high availability for RDS

A highly available service is one that is available almost all of the time. High availability often is expressed numerically as the percentage of time that a service is available. For example, a requirement for 99.9 percent availability allows 8.75 hours of downtime per year, or approximately 40 minutes of downtime every four weeks. With 99.999 percent uptime, the allowed service downtime is reduced to only 5 minutes per year.

To achieve high availability for a service such as RDS, you need to identify single points of failure in the infrastructure and work to eliminate them. For example, if you have only one RD Session Host server, that is a single point of failure. There will be a service outage if that server has hardware problems or is taken offline for maintenance.

To make infrastructure highly available, you need to make it redundant. For example, within a server, using mirroring (RAID 1) for disks ensures that that failure of a single hard disk does not cause the server to fail. This principle also can be applied at other levels of infrastructure such as networking, network services, and data center power. To make RDS highly available, you need multiple servers for each of the RDS role services, but not all RDS role services automatically become highly available just because you add more servers running the role service. Some RDS role services require you to implement load balancing.

Understanding load balancing

Load balancing is a technology that you can use to achieve high availability and scalability primarily for stateless services. The term stateless refers to workloads that respond to each request independently from previous requests and without keeping client state. For example, when a client requests a webpage, a Web server gathers all of the necessary information from the request and then returns a generated webpage to the client. When the client requests another webpage, it might request the webpage from the same Web server or from any other identically configured Web server in a load-balancing cluster.

The servers that are part of a load balancing cluster are referred to as nodes. Each node is configured with the same software so that clients can connect with any node and obtain the intended service. For example, each node would have the same website configured.

Clients connect to a virtual IP address that is used to access all nodes in the cluster. To the clients, the virtual IP address behaves the same way that an IP address configured on a physical server would. Only one cluster node responds to each client request.

If a node in the cluster fails, the remaining nodes continue to service clients. This makes a load balancing cluster highly available. Adding nodes to the cluster increases the capacity of the cluster. Adding nodes is scaling out.

Windows Network Load Balancing

Windows Network Load Balancing (NLB) is a software solution for load balancing that is included in Windows Server operating systems. NLB creates a virtual IP address that all of the nodes in the load balancing cluster share. When a request comes in to virtual IP, the request is received by all nodes, but only one node responds. The nodes determine the appropriate node to respond based on an algorithm that they all use.

The most common reason organizations consider using NLB is the cost. Because it is included in Windows Server operating systems, it is effectively free. However, there are a few drawbacks to using NLB:

• It is not service aware NLB is capable of identifying when a server is no longer responding but not when a service is no longer responding. This means that some types of failures result in clients being directed to a nonresponsive service on a partially functional node.
• Scalability is limited NLB supports up to 32 nodes in a cluster, but performance peaks at 8 nodes.
• Network hardware configuration may be required Some network switches need additional configuration to work with NLB. This is required because multiple devices are sharing the same virtual IP address but are connected to different switch ports.

Hardware-based load balancing

Most large organizations use specialized hardware load balancers instead of using NLB. Hardware load balancers are more scalable than NLB, but they also are significantly more expensive. The least expensive hardware load balancers are about $2,000, and they can cost more than $40,000.

The configuration of a hardware load balancer varies depending on the vendor, but all of them provide the same basic functionality. The virtual IP address for the load balancing cluster is assigned to the load balancer, and the load balancer receives requests from the clients. The load balancer then forwards each request to a single node.

The load balancer is responsible for identifying failed nodes. Node failure can be identified at the node level, as NLB does, or at the service level. If service-level failure is used, the load balancer monitors the service on each node and stops sending client requests if the service stops responding.

High availability for RD Session Host servers

When an RDS deployment has a single RD Session Host server, that server becomes a single point of failure. When it fails, the failure will affect all users who are connected to it and who run RemoteApp programs on that server. You must consider the possibility of failure or the lack of RD Session Host server availability in your disaster recovery plan.

You can take several steps to improve RD Session Host availability. You can use reliable and redundant hardware from respected vendors to minimize the probability of hardware failure. You also should make sure that the network is reliable and that there are multiple network paths to an RD Session Host server. You should be aware, however, that failures are unavoidable, and no single server can always be available without downtime. For example, after you install Windows updates, computer restart is often required, which causes server downtime.

To make the RD Session Host server role highly available, you should have multiple RD Session Host servers in each collection. The RD Connection Broker role service automatically load balances connections to the RD Session Host servers. If the RD Connection Broker role service identifies that an RD Session Host server is unavailable, clients are not directed to the failed RD Session Host server. Clients are directed only to the remaining functional RD Session Host server.

As a best practice, all RD Session Host servers should have a similar hardware configuration. This ensures that all RD Session Host servers have similar performance and can handle a similar number of clients. The default configuration of load balancing for a collection, shown in Figure 8-23, is best suited for this scenario.

You can adjust the ratio of sessions allocated to an RD Session Host server by adjusting the Relative Weight value for that server. The default value for all servers is 100. When all servers have the same value, they all receive the same number of sessions. If you have one server with significantly better hardware and give that server a Relative Weight of 200, then it will receive twice as many sessions as a server with a Relative Weight of 100.

You also can set a Session Limit for each server. The default value for the Session Limit is 999,999, which effectively is unlimited. If you have determined that users experience performance issues when more than 80 clients are connected, then you can set a session limit of 80 to ensure that performance is satisfactory for all users.

To add a second RD Session Broker server to an RDS deployment, perform the following steps:

1. In Server Manager, in the navigation pane, click Remote Desktop Services.
2. On the Overview page, click Add RD Session Host Servers.
3. In the Add RD Session Host Server window, on the Select A Server page, in the Server Pool box, double-click the server you want to configure as an RD Session Host server and click Next.
4. On the Confirm Selections page, select the Restart Remote Computers As Needed check box and click Add.
5. Wait until the RD Session Host role service is installed on the server and click Close.

To add an RD Session Host server to a session collection, perform the following steps:

1. In Server Manager, in the navigation pane, click Remote Desktop Services.
2. In the navigation pane, click the session collection.
3. Scroll down to the Host Servers box, click Tasks, and click Add RD Session Host Servers.
4. In the Add Servers To Collection Wizard, on the Specify RD Session Host Servers page, double-click the RD Session Host server that you want to add to the session collection and click Next.
5. On the Confirm Selections page, click Add.
6. Wait until the task is complete and then click Close.

High availability for the RD Connection Broker role service

The RD Connection Broker role service is responsible for directing clients to an available RD Session Host server. If the RD Connection Broker role service is unavailable, then users are not able to access session-based virtual desktops. Having a single RD Connection Broker server creates a single point of failure.

To make the RD Connection Broker role service highly available, you need to have multiple RD Connection Broker servers. The RD Connection Broker role service uses a SQL Server database to track sessions that have been allocated to RD Session Host servers. For multiple RD Connection Brokers servers to work together, they need to share a single SQL Server database.

To prepare the RD Connection Broker role service for high availability, you need to do the following:

• Configure a server running Microsoft SQL Server 2008 R2 or newer. The RD Connection Broker servers must have permission to create a database on the server.
• Install the SQL Server Native Client on all RD Connection Broker servers. The RD Connection Broker servers use this to connect to the SQL database.
• Configure a static IP address on all RD Connection Broker servers. This is required to implement DNS round robin for load balancing.
• Configure a DNS round robin record for the RD Connection Broker servers. Select a name that is meaningful, such as rds.adatum.com.

When you configure the RD Connection Broker role service for high availability, its database moves from a local WID to a computer that is running SQL Server. Even when an RDS deployment has multiple RD Connection Broker servers, SQL Server still can be a single point of failure. You should make sure that SQL Server is highly available by running it in a failover cluster.

When you configure high availability for the RD Connection Broker role service, you need to provide a Database Connection String that the RD Connection Broker servers use to connect to the SQL server. The Database Connection String has the following format:

DRIVER=SQL Server Native Client 11.0;SERVER=LON-SQL.Adatum.com;Trusted_
Connection=Yes;APP=Remote Desktop Services Connection Broker;Database=RDS-DB

There are several things to note about the Database Connection String:

• A SQL native client version is specified In this example, the SQL native client version is 11.0. This is used when your SQL server is SQL Server 2012. If your SQL server is SQL Server 2008 R2, then the SQL native client version is 10.0.
• A server name is specified In this example, the server name is LON-SQL.Adatum.com. In your deployment, you should specify the name of the SQL server that will be hosting the database for the RD Connection Broker servers.
• A database name is specified In this example, the database name is RDS-DB. This is the name of the database that will be created for the RD Connection Broker servers to use. You can select an alternate name, but it should be a meaningful name to make it easy to identify.

To configure the RD Connection Broker role service for high availability, perform the following steps:

1. In Server Manager, in the navigation pane, click Remote Desktop Services.
2. On the Overview page, in the Deployment Overview area, right-click RD Connection Broker and click Configure High Availability.
3. In the Configure RD Connection Broker For High Availability Wizard, on the Before You Begin page, click Next.

4. On the Configure RD Connection Broker For High Availability page, shown in Figure 8-24, in the Database Connection String box, type the appropriate Database Connection String for your environment.

   

   Figure 8-24 Configure RD Connection Broker For High Availability Wizard, Configure RD Connection Broker For High Availability page

5. In the Folder To Store Database Files box, type the path for the database on the SQL server. The database will be created in this location. This folder must already exist.
6. In the DNS Round Robin Name box, type the name of the DNS round robin record that you created for the RD Connection Broker servers and then click Next.
7. On the Confirmation page, click Configure.
8. On the Progress page, click Close.

After you have configured high availability for the RD Connection Broker role service, the RD Connection Broker icon in the Deployment Overview area is updated with the text (High Availability Mode). Now you can add another RD Connection Broker server by right-clicking the RD Connection Broker icon and clicking Add RD Connection Broker server. The new RD Connection Broker server will use the central SQL database that you have configured.

High availability for the RD Web Access role service

RD Web Access servers are a critical part of an RDS deployment. The RD Web Access servers are responsible for providing clients with an .rdp file that contains connectivity information to collections. If RD Web Access isn’t available, then clients can’t obtain the necessary configuration information to connect to session-based virtual desktops. You should make RD Web Access servers highly available.

Load balancing is used to make RD Web Access servers highly available. You can use NLB, hardware-based load balancing, or DNS round robin. If you are using NLB or hardware-based load balancing, you’ll need to create a DNS record for the virtual IP address used by the load balancing cluster. For example, you could create a host (A) record for RDWeb.adatum.com that resolves to the virtual IP address. If you are using DNS round robin, then you need to create multiple host (A) records for RDWeb.adatum.com that resolve to the IP addresses of the RD Web Access servers.

To add an RD Web Access server, perform the following steps:

1. In Server Manager, in the navigation pane, click Remote Desktop Services.
2. On the Overview page, right-click RD Web Access and click Add RD Web Access Servers.
3. In the Add RD Web Access Servers Wizard, on the Select A Server page, double-click the server you want to configure as an RD Web Access server and click Next.
4. On the Confirmation page, click Add.
5. Wait until the installation is complete and click Close.
6. Configure your load-balancing solution with the IP address of the new RD Web Access server.

High availability for the RD Licensing role service

The effect of the RD Licensing role service for an RDS deployment varies, depending on the licensing mode that has been selected. When an RDS deployment is configured for Per User licensing, the RD Session Host servers contact an RD Licensing server each time a client connects. If an RD Licensing server isn’t available, then users can’t connect.

Per User licensing isn’t enforced by RD Licensing servers. If an RD Session Host server can contact an RD Licensing server, that is sufficient to allow a connection. You are responsible for ensuring that you are in compliance with licensing requirements, but they are not enforced.

To make an RDS deployment with Per User licensing highly available, you need to install multiple RD Licensing servers. If the first RD Licensing server is unavailable, then the second is contacted.

Allocation of RDS User CALs among the RD Licensing servers does not matter because they are not enforced. To simplify license management, you can install and activate all RDS User CALs on a single RD Licensing server.

High availability for an RDS deployment configured for Per Device licensing also requires multiple RD Licensing servers, but configuration is more complex because RDS Device CAL usage is enforced. If an RDS Device CAL isn’t available, then connectivity can be blocked. Because of this, you need to consider how CALs are allocated among the RD Licensing servers.

RDS client behavior for Per Device licensing varies, depending on the state of the client:

• First connection The first time a device connects, it is issued a temporary CAL that can be used only once. If an RD Licensing server is unavailable, the temporary CAL can’t be issued, and new devices are unable to connect. The temporary CAL can be issued by any RD Licensing server even if no RDS Device CALs are available on that server.
• Temporary license The second time a device connects, it is issued a permanent RDS Device CAL. For a device to be issued a permanent RDS Device CAL, an RD Licensing server with unallocated Per Device CALs must be available. If an RD Licensing server with unallocated Per Device CALs isn’t available, then the temporary CAL remains valid for 90 days.
• Permanent CAL Devices with a permanent CAL can connect to an RD Session Host when no RD Licensing server is available. Permanent RDS Device CALs are valid for 52 to 89 days and can’t be renewed if no RD Licensing server is available.
• Permanent CAL expired If the permanent CAL has expired and an RD Licensing server isn’t available, the connection is blocked. An RD Licensing server with unused Per Device CALs must be available to issue a new permanent CAL.

The simplest way to configure high availability for the RD Licensing role service when using Per Device licensing is to put all RDS Device CALs on a single RD Licensing server. The second RD Licensing server has no CALs installed and issues only temporary licenses. In this configuration, failure of the RD Licensing server with CALs has no effect on devices with a permanent or temporary license, which typically are the majority of devices. Devices connecting for the first time are issued a temporary license from the remaining RD Licensing server without CALs. The only clients unable to connect are devices with an expired license, which should be a small number of devices.

A slightly more complex way to configure high availability for the RD Licensing role service when using Per Device licensing is to split RDS Device CALs among RD Licensing servers. Most CALs are installed on the primary RD Licensing server, but some are installed on a secondary RD Licensing server. This configuration is better because if the primary RD Licensing server fails, then CALs can be issued by the secondary RD Licensing server, and no devices should be prevented from connecting.

Splitting CALs between two RD Licensing servers is slightly more expensive because you need to purchase additional CALs for the secondary RD Licensing server. In a large deployment of RDS, this likely is worth the additional cost to avoid outages. In a small deployment of RDS, it may not be worth the cost because very few users would be affected.

When you have multiple RD Licensing servers, it is critical that you configure the RDS deployment to use the RD Licensing server you have configured with the CALs as the primary RD Licensing server.

To configure the order of RD Licensing servers, perform the following steps:

1. In Server Manager, in the navigation pane, click Remote Desktop Services.
2. On the Overview page, in the Deployment Overview area, click Edit Deployment Properties.
3. In the Deployment Properties window, in the navigation area, click RD Licensing.
4. Select the server you want to be primary, click Move Up until it is at the top of the list, and click OK.

To add an RD Licensing server, perform the following steps:

1. In Server Manager, in the navigation pane, click Remote Desktop Services.
2. On the Overview page, in the Deployment Overview area, right-click RD Licensing and click Add RD Licensing Servers.
3. In the Add RD Licensing Servers Wizard, on the Select A Server page, double-click the server you want to configure as an RD Licensing server and click Next.
4. On the Confirmation page, click Add.
5. Wait until the installation is complete and click Close.