Resource Aggregation and Load Balancing in StoreFront 3.6 1

Storefront 3.6 brings a few important new features to the table. One of the three new features in the list is the ability to load balance non-identical sites or farms. Prior to version 3.6, all farms should have been publishing identical resources with load balancing enabled. This post will look at how the resource aggregation works and how enumeration takes place, as well as how to configure load balancing and resource aggregation.

Delivery Controller, or Delivery Controller?

One common hang up people have when they’re first exposed to store configuration is the definition of sites or farms, which happen to have the unfortunate label of “Delivery Controller”. These “Delivery Controller” entities are actually a definition of one or more Delivery Controller or XML Broker (for 6.5) and is largely analogous to the farm definition from web interface.

Figure 1 Delivery Controller definition. This refers to one or more delivery controllers within a site. Multiple are recommended for high availability.

Once you’ve defined all your sites, you can then commence with the user-to-farm mapping. This process can map user groups to a specific “Delivery Controller” definition. The reason for this is you are able to then map users to a specific site by default, for example, for geographic purposes to ensure their session is fast. In this example, we’ll distribute users equally between the two sites.

Figure 2 The “Name” of the Delivery controller is an arbitrary text label. Do not place spaces or periods in this name. The name must match between each Storefront group you are load balancing across.

Configuring Resource Aggregation

Define all sites you wish to aggregate. At this point, if you were to log into Storefront, you would see resources from each site. In order to aggregate, the resource names need to match on each end. However, if you logged in, you would see duplicates – for example – “Notepad” and “Notepad (1)”. Now we need to aggregate! Click “Configure” under “User Mapping and Multi-Site Aggregation Configuration”.

Figure 3 Mapping users to controllers is the first step

Figure 4 Specify the groups you wish to map to controllers. You may choose, for example, to map “Seattle” users to Site1 and “New York” users to Site2.

Figure 5 In our example, we are building multiple pods within a large datacenter, so we will map all users to both sites.

Once the users have been mapped to controllers, we can then specify the resource aggregation settings. It is important to be aware of the resource aggregation settings you choose, as they will affect application enumeration time which can appear as a delay to the user. If the sites are identical (same applications/desktops are published on both), select the checkbox that they are identical in order to speed up enumeration. If non-identical resources are published, there can be a delay due to the fact that Storefront must contact each individual site and gather up resources. If “Load Balancing” is not selected, the sites will be used in a first-in-list order. The load balancing will apply a round robin approach (site1, site2, site1, site2 etc) for each Storefront server. While potentially a small point, be aware that your distribution may not be exactly 50/50 depending on your Storefront load balancing settings.

Figure 6 Check the boxes for each site to aggregate then click “Aggregate”. Verify they appear in the upper “Aggregated” section.

When specific users are mapped to controllers, you would only select a single site in the GUI. This will create multiple “equivalent farm sets” in the web.config for the store, as shown below:

In this instance, if you want to provide failover to a backup site, you must manually edit the web.config of the store and insert the backup farm into the backupFarmRefs section, as shown below:

In this configuration, members of the Seattle group will only see resources from the Seattle farm. However, if Seattle goes down, they will then see resources from the New York farm, so they can continue to work.

Propagate changes to the storefront group and repeat the same settings on any other Storefront groups that may be load balancing in alternate sites. Additionally, if you are using multiple Storefront groups, you will likely want to configure subscription synchronization in order to provide a consistent view of the user apps that are subscribed.

It is worth noting you are still able to edit the configuration manually. Before doing this ensure all consoles are closed and open the web.config. You can add backup farms (used in the event that the primary farms you defined through the GUI are down). For more information, see the Storefront documentation. Additionally, review the information in this post for some more “lessons learned” when using aggregation groups.

Conclusion

With that, you’ve dramatically increased your resiliency of your 7.x deployment as you will be far less susceptible to total service loss in the event of a database outage or other problem with your brokers/database! Storefront is an incredibly powerful platform for resource delivery and Citrix has put significant effort into making it the premiere choice for organizations to delivery Citrix resources to their end users.