Using load-balanced App-V Servers within a Citrix Virtual Apps and Desktops deployment has been a hot topic for a while and something that the dev team gets asked for advice about on a regular basis. In this article I intend to clearly lay out all of the possible options for load-balancing your App-V Servers, the pros and cons of each approach, along with details about what is and is not currently possible to achieve.
This article applies only if you are using what is known as the Dual Admin deployment method. I.e. with Microsoft App-V Management and Publishing Servers. If you are using the Single Admin deployment method with App-V packages being delivered with Citrix Virtual Apps and Desktops directly from a network share then it does not apply.
There are 3 basic approaches you can take to the solution, in order of increasing sophistication…
- Configure Citrix Studio via the PowerShell API
- Set up a DNS Round-Robin
- Set up a Citrix ADC or other true load-balancing solution
Studio and PowerShell
When configuring your Microsoft App-V Management Server infrastructure, you can associate many individual Publishing Servers to each Management Server.
Studio however deals with things a bit differently and registers individual Management & Publishing Server pairs. When you publish an application in Citrix Virtual Apps chosen from the Management Server, information about the associated Publishing Server is sent to the VDA. The Studio UI will allow you to add and manage only a single Management & Publishing Server pair, but you can use Studio’s PowerShell API to add up to 4 more additional pairs. Having done this, Studio will then discover apps from all the configured Management Servers and allow you to pick and choose apps from a particular server at publishing time. The total limit of these configurations that studio will allow was set to 5 because this is also the maximum number of Publishing Servers that the Microsoft App-V client on the VDA will allow.
Why would you do it?
It will allow you to publish apps to individual delivery groups ensuring that you either spread the publishing load around between different groups accessing different serves or ensuring that the Publishing Server is geographically close to the machines in the catalog serving the delivery group. What it will not do is actively balance the load on any one individual server. It is entirely up to the admin to make the best decisions on this.
How to do it
First off add you’re management and publishing server details through the Studio UI
Studio will then query the Packages contained on the server and display them with some information about where they are discovered from in the details pane.
The ‘Source Name’ field here is not terribly helpful. but a value of ‘1’ indicates that it is the record that was added by the Studio UI.
If we open up a PowerShell window on the DDC we can interrogate the BrokerMachineConfiguration that has been created for more detailed information
Add-PsSnapin citrix.*
Get-BrokerMachineConfiguration -ConfigurationSlotUid (Get-BrokerConfigurationSlot -Name AppV).Uid
To add a second Publishing Server we need to format a ‘policy blob’ with the server’s details and apply it to a new BrokerMachineConfiguration of the correct type with PowerShell code similar to this
$slot = Get-BrokerConfigurationSlot -Name AppV
$blob = New-CtxAppVServer -ManagementServer http://AppVSrv1.london.local -PublishingServer http://AppVPub2.london.local:8001
New-BrokerMachineConfiguration -ConfigurationSlotUid $slot.uid -Description "Publishing Server 2" -LeafName "Pub2" -Policy $blob
Now if we restart studio we will see that the package is publishable from more than one source
And when it comes to adding apps to a delivery group we can choose which server configuration will be used in the publishing
Bearing in mind of course that depending on how you want to set it up, additional Publshing Servers may all be referencing the same or different Management Servers and therefore have a different set of packages and apps available from them.
DNS Round Robin
Possibly the easiest way to get some load-balancing in your App-V and Citrix Virtual Apps deployment is to set up some DNS Round-Robin. This way you can set up a single Management/Publishing Server reference in studio and have DNS automatically assign a different physical server to each VDA in turn as requests are made. What it says on the tin basically. This of course is a load-spreading rather than load-balancing solution because once an individual host has been assigned a particular IP for the DNS record it will continue to use it until the record is flushed, regardless of the actual load on that server.
How to do it
On the DNS server open up the DNS Manager console Start-> Run -> dnsmgmt.msc
Find the node for the forward lookup zones and select your domain. Right click and select New Host (A or AAAA)…
Enter something that is sensible to you for the alias name (I have used AppVPubRR) and the IP Address of one of the physical servers the alias refers to
Repeat this process for each of your physical servers keeping the alias name the same each time.
To test that it is working open a command prompt on one of your VDAs and ping the aliased machine name and note the IP address returning the ping request.
Flush the DNS cache ( > ipconfig /flushdns) and ping it again. Note that the IP address returning the ping has changed. Repeat this process until you are satisfied that all of the aliases are working correctly.
Now when we go to Citrix Studio we can enter the alias name into the Management and Publishing Server address boxes
Notice that the location reference in the package details still points to the physical server’s FQDN even though we entered the server alias in the Studio settings. This is because in order to communicate with the Management Server’s remote PowerShell API we need the FQDN of one of the Management servers behind the alias. We do this by performing a reverse lookup on the IP address returned by DNS for the alias and finding its ‘real’ FQDN. This brings me to the very important point about load-balancing Management Servers below…
Load Balancing Management Servers
If you are load balancing your Management Servers, it is up to you to make sure that those servers have an identical configuration. Because Studio will discover packages and apps from the server that is returned by the alias, if the actual server that ends up serving the packages to the Publishing Server and therefore ultimately the VDA doesn’t have the same set of packages, with the same access permissions, Connection Group definitions etc. All bets are off! If the Publishing Server that gets registered to the VDA is being served by a Management Server that does not contain the package in the launch request, then launches will fail with massages stating that the publishing Server sync failed. Ensuring that your Management Servers are configured identically is out of the scope of this article.
Actually the same is true for the Publishing Server load-balancing. Here is some load-balancing configuration best practices
- Only load-balance Management Servers that have mirrored databases or are in some other way guaranteed to have an identical configuration
- Only load-balance Publishing Servers behind a single alias that are either being served by same physical Management Server or Management Servers that are identical as above
- If you need different Management Servers (serving different packages) each with a load-balanced set of Publishing Servers, you can use a combination of the additional BrokerMachineConfigurations for each Management Server referencing a load-balanced alias with the Publishing Server details
Using Citrix ADC (or another true load-balancing solution)
Up until now the techniques I have discussed have been more load-spreading solutions than proper load-balancing solutions.
You can use Citrix ADC to configure a proper load-balancing solution for your App-V Management and Publishing Servers. Rather than reinventing the wheel I will refer you to this excellent blog by wilkyit.com that will walk you through the process of getting it all configured.
Now, there is a problem!
Citrix Studio uses remote PowerShell calls to the App-V API on the Management Server to discover packages. It also verifies and discovers the port WSMAN is listening on to confirm that that both Management and Publishing Servers are configured correctly. However, calls to WSMAN and remote PowerShell do not work for the load balanced VIP or the alias FQDN. Unlike in the DNS Round-Robin scenario above we cannot determine any real FQDN behind the alias to make the WSMAN calls so Studio complains that the servers are inaccessible.
This is a blocking issue for the Management Server. Without the real FQDN we simply cannot discover the packages. However, I would argue that there is actually little benefit to pointing Studio at a load-balanced Management Server. The earlier points about having identical configurations aside, Studio is not in constant or continuous contact with the server and once discovery is done there is no communication necessary until another discovery is required. By all means have other parts of your infrastructures set up to load balance the Management Server but you must point studio at a real address.
The same is not true with regards to the Publishing Server. Studio tries the WSMAN calls to verify the server’s existence (and can’t), but that is all Studio does with the Publishing Server. It never actually needs to read any data from it. The result is that you can ignore the error that Studio gives about the publishing server not being contactable and continue. When the alias FQDN gets down to the VDA, just as is the case with the DNS RR configuration everything works fine.
In Conclusion
There are a few options for getting some load-spreading and load-balancing around your App-V Server infrastructure and app delivery with Citrix Virtual Apps. As is so often the case it is down to you, the administrator, do decide what strategy, or combination of strategies will work best for your requirements. But bear in mind that there is room to configure your way into trouble, particularly when it comes to Management Servers. My advice would be to leave your Management Servers non-load-balanced (I was going to say un-balanced, but that sounded bad), at least from Studio’s point of view and make sure that all Publishing Servers in a single load-balancing configuration are being served by the same Management Server.
Of course we will welcome your feedback, suggestions, and tales of success or otherwise with configuring load-balancers to play nicely with WSMAN and remote PowerShell.
Citrix TechBytes – Created by Citrix Experts, made for Citrix Technologists! Learn from passionate Citrix Experts and gain technical insights into the latest Citrix Technologies.
Click here for more TechBytes and subscribe.
Want specific TechBytes? Let us know! tech-content-feedback@citrix.com
