Horizon Cloud on Microsoft Azure–Technical Walkthrough (Part 5)

Author: Peter Brown

Based in Palo Alto, Peter Brown is a director of R&D for VMware EUC and leads development for VMware Horizon Cloud Service.

Share This Post On

Creating an RDS Farms for Application and Desktop Sessions

In part 4 of this blog series, I walked through the steps to create a Published Image, which could be used to create RDS Farms or VDI Desktops. In part 5 of this blog series, I am going to walk you through the process of creating, managing and using RDS Farms for both Application and Desktop sessions.

As a quick reminder, an RDS Farm is a collection of servers (one or more) whereby multiple users can share each server concurrently. RDS Farms can be used to deliver both seamless Applications (i.e. just an application such as Microsoft Excel), or a whole Desktop to end users.

Let’s dive right in!

Creating a Farm

In order to create a Farm, you need a Published Image that has the RDS Role enabled (and therefore needs to be running Server 2012r2 or Server 2016 OS). If you need help in generating such an image, please refer back to my previous blog post.

Now that you have your image, click on Inventory -> Farms and click New:

Give the farm a name, select the node on which you want to create the Farm, and select if you want the Farm to be used for Applications or Desktops. (We keep these use cases separate since the typical load a desktop session puts on a server will be very different to just an Application use case. By keeping Application Farms separate to Desktop Farms, we make it much easier for the administrator to appropriately scale out the Farms to meet their user demands for performance.

Now select the Image you wish to use, and select the Server Size. Currently, Horizon Cloud Service supports D2v2, D3v2, D4v2, D5v2 VM sizes as well as NV6 for GPU backed workloads. The bigger the server then the greater number of users you can place on that server (or, the more performance (CPU/Memory) you plan to give each user.

For guidelines on how many users you should put on a single RDS server of each size, see the white paper here. Currently, it’s not possible to change the number of users per server after the farm has been created. You also chose the minimum and the maximum number of servers in the Farm. This is a feature specific to Horizon Cloud Service on Azure, whereby due to compute costing per minute of usage, it is often desirable to ensure that servers are powered off (and deallocated) when not being used so that you only pay for the storage charge. Many customers have a regular working week (for example Monday to Friday), and whilst some usage may occur on weekends, it will usually not be to the same level as during the week. During such times, unused servers can be automatically powered off. If you set the minimum servers to one, then it means there will always be one server running, but this can expand to a maximum of ‘max servers’ as the user demand dictates. Note that it is also possible to set the minimum servers to zero! However, if a user tries to log in when the minimum servers equal zero, then they will have to wait around 10 minutes for the session to connect, since the server needs to power on, and for Windows and the service to start functioning.

Some additional advanced properties are available too if required, but for now, let’s move to the next screen:

On this part of the wizard, you first configure the Rolling Maintenance settings. Rolling Maintenance is specific to RDS Farms, whereby periodically the servers in the farm are either restarted or rebuilt in order to clear down any memory leaks or to rebuild into a pristine state. The options in this section allow you to vary whether this operation happens on a schedule (time of day/week) or based on the number of sessions a server has handled (e.g. after 1,000 sessions). You can also choose if the server should be restarted or rebuilt. The concurrent Quiescing servers value selects how many of the servers in the Farm can be restarted/rebuilt at the same time. If you make the number bigger then there will be less capacity available to serve your user demand (at the selected time), but, the Farm maintenance operation will complete sooner.

The Power Management section allows you to select between Optimized Performance, Balanced or Optimized Power. These values select how aggressively new servers are powered on when users start to use the servers. Optimized Performance means that servers are powered on earlier, to improve the performance of users logging in at the expense of running more servers sooner. Optimized Power means that the servers are left powered down for longer, thus saving cost. Balanced, means that it sits somewhere in between.

Timeout handling allows you to set timeout values and decide whether sessions are disconnected or logged off after a set period of time. Note that servers in a Farm can only be powered down once all sessions in a Farm have been logged off.

Scrolling further down the form, you will find the new Schedule Power Management options.

This allows you to override the ‘Minimum’ number of servers value that you defined above with a new value at a specific time of day/day of the week. For example, you could set a default of MinServers = 0, however, from 8 am to 6 pm you could set MinServers = 10 (note, min servers cannot exceed the maximum servers in a farm). This will guarantee servers are powered on and ready between 8 am and 6 pm, and will power down outside of these times (once all users have logged off).

Multiple schedule overrides can be configured as required. If a schedule override is not covering a specific time/day, then the default values as configured above will apply.

The next screen presents a summary, click Submit when you are happy with the Farm configuration;

The farm grid will now show the new Farm, and you will see some activity showing that the farm is being created. Depending on how many servers you requested will vary how long it takes to create (specifically, the maximum number of servers are created and complete first boot, and then all but the minimum number of servers are powered down to save costs). For a small farm of a few servers, this typically takes 15 to 20minutes.

If you click on the farm, then you will see a summary page showing the farm details, and if required in the future you can use this page to edit specific values (for example adjust the Power Management settings).

Clicking on the Servers tab shows you the status of the servers in the farm (creating, powered on/off etc);

Configure Application Catalog

Once the farm has been fully created, for an Application farm, the next step is to configure the applications from within the Farm that you want to make available to end users. If you are creating a Desktop Farm, then you can skip this section.

Click Inventory -> Applications and click New:

You then can choose between Automatic and Manual. Normally, Automatic will be the best choice, but sometimes there may be some apps that you need to remote that cannot be automatically detected.

You can populate the Application Catalog using a mix of both automatic and manually generated application definitions.

For the purpose of this blog, let’s go with the Auto-Scan approach; Select the node and the farm for which you want to auto-scan for applications:

Then, after a few moments a grid will be displayed showing the applications that are auto-detected on the Farm;

You can multi-select the apps that you want to make available, and click Next.

Attributes page allows you to rename how the application is presented to end users, as well as providing any custom start-up command line options to be used when invoking the app.

In the example above, I just left all values at their default values. Click next, review the summary and click Submit.

The Application Catalog will now show the apps available in all of your farms.

Repeat this process as many times as required to configure all apps from RDS farms that you wish to remote.

Create Assignments

Next, let’s create an Application or Desktop assignment. Click Assign and select New:

Next, select whether you want to create a Desktop or Application assignment. Of course, you can come back later and create more of these! The process for both is very simple. For now, let’s proceed with an Application assignment:

First, select the node on which you want the assignment, give it a name so you can reference it at a later date, and click Next.

Second, select the applications from that node that you wish to put into the assignment. Note that you can have applications from more than one farm (although all the farms must be on the same node). Once all the apps you want to assign are selected in this assignment, click Next.

Finally, select the users and/or user groups you wish to be entitled to this assignment.

Click, Next, review the summary, and click Submit.

The new assignment will now show on the Assignments page:

Desktop assignments are almost identical – you select a Farm and assign to users.

Repeat this for any other desktop assignments or application assignments you want to create. Users can be entitled to multiple assignments, so you can create a layered approach; for example, an app assignment for ‘All Users,’ and then separate assignments for job role specific functions – e.g. ‘Engineering Apps.’ An engineer logging in would see all of their engineering apps, along with all of the ‘general all user’s apps.’

This blog walked you through the creation of RDS Farms and Assignments for both Desktops and Applications. In the next blog in the series, I will walk through the end-user experience accessing the system using the Horizon Client and Browser-based access.

If you have any questions and comments, please visit our community site, as we’d love to hear from you.

468 ad