In this article series I’m describing the Failover possibilities within the XenDesktop product based on the server components. In part 1 <<LINK>> I started explaining shortly the differences between Load Balance and Fault Tolerance, followed to mention that one is none for the components. For each component at least two machines should hold the functionality. As the article is about (disaster) failover in the case of two or more datacenters the article continued quickly describing the component, where the past, the current situation, the near future and wishes per component are described. In part 1 the database and the access portal were discussed. In this article I will continue with the Published App/Desktops (aka VDAs) and the PVS infrastructure.
As described in part 1 StoreFront nowadays support fail over functionality based on multiple XenDesktop sites. This is nice methodology and is working fine. For Enterprise environments this is probably the best solution, however for smaller environments setting up more sites including the high available SQL requirement will make it a rather expensive solution, where many companies don’t want to go that way.
In XenApp 6.5 the multi-site configuration was no requirement as with the Worker Groups combined with the Load Balancing Policies functionality “multiple sites” could be defined within one farm.
XenApp servers are added to one or more Worker Groups and within the Load Balancing Policies based on a filter (Access Control, Client IP, Client Name or Users) Worker Groups connections preferences can be defined based on priority. As you can define more policies, you can both define active-standby as active-active set-ups depending on the organization requirements. As this technique is working fine many organizations are using/have used this functionality.
In XenDesktop 7 the Worker Groups and the load balancing policies are not available anymore. However Citrix has noticed that people would like to have some load balancing/fail over possibilities within one site. From XenDesktop 7.5 there is functionality available for applications to use priority for multiple delivery groups. Unfortunate this is functionality is only available as PowerShell command (Add-BrokerApplication -Name "Notepad” -DesktopGroup "VanBragtNet Delivery Group 1” -Priority 1). In the Studio Console you can only see that the application is available via multiple delivery groups. As this is suitable for active/standby solutions, an active/active set-up like XenApp 6.5 is not possible. You need to create two Apps with different priorities to accomplish that, but I don’t think most users will understand that.
For a Desktop there is nothing available. You can create multiple desktops in one delivery group via PowerShell commands. However there is no option to assign priority to those multiple desktops in one delivery groups or more delivery groups. For an active standby you can create two delivery groups and assign a different user group to the delivery group. In case of a disaster you add the users to this group and the desktop is available. It is manual job and not the way you want probably, but it works. I have a few customers who have a set-up running like this.
In the Technology Preview of XenDesktop 7.7 some enhancements can be found according the priority options. Unfortunate it does not bring new functionality. The part that were only available via the PowerShell commands are now available within the Studio Console. You can configure the priority of application from the console (the Applications now even have an own component within the console).
Also the creation of multiple desktops is now available in the console. However no priority options for the desktops and no options for an active/active set-up. There are rumors that Zones will be re-introduces in XenDesktop 7.7. Currently I don’t know what this potentially could bring for fail-over for applications and desktops, but it could add the desired functionality.
As Citrix stated during last Synergy: Citrix loves XenApp. I think Citrix would need to add the load balancing policies functionality fully back into XenDesktop to make this statement true. Personally I think this is not really hard, but requires a different mindset with the current used names. If we rename Delivery Group to Desktops (now Application is already a subcomponent) and use Machine Catalogs for both the Desktops as Applications.
So when adding an application or desktop you select a machine catalog hosting the application or desktop (I know this is a different mindset than currently in XenDesktop, but it comes really close to XenApp 6.5 with assigning Worker Groups) as shown in the above image (just an example created by myself). After selecting the machine catalog, there should be an option to add filtering to the desktop or application. With this filter the Load Balancing Policies option will be back. As an example I created below shown image.
Via this methodology both an active/active and active/standby set-up can be created, without much effort as priority is already available in the product. Would love to see this added to one of upcoming features.
Not an official part of the Citrix XenDesktop product, but used a lot with XenDesktop and should definitely be included within a failover plan when used. As there are many people thinking the incorrect way about this product on the first hand I will go into the product as well.
Going into the past we need to go back many versions back, so I don’t think it’s useful to go back that far as the methodology has only been improved in time.
In comparison with XenDesktop PVS has also several sites, but those are hosted in the same database. Setting up a second side does not make the infrastructure much complex as XenDestop does. However many people think that sites can act as a fail-over for target devices in another collection, which is not the case. Each site is autonomous, so when no PVS servers are available in the site the target devices will not function.
Besides sites you can use another mechanism available in PVS both for failover, which is available under Load Balancing of each vDisk.
With Subnet Affinity configured on Best Effort you can set-up a failover mechanism. With this setting configured, you need to add your PVS servers and target devices in the same VLAN (which is also a nice solution for load balancing/failover for PXE and TFTP). With Best Effort the target devices “searches” for a PVS server in the same VLAN where the TD is located. When one or more PVS servers are available in the VLAN this PVS server will be used (when there are more than one server available in the same VLAN the default least busy PVS server will be used). When there is no PVS server is available in his own VLAN, the least busy PVS server available will be used. This is nice method both for active/active as active/failover set-ups. The only downside is that if you have more than two VLANs you can not specify it which order the VLANs should be used if in the default VLAN is no PVS server is available.
Currently there is running to Technology Preview of PVS 7.7. This version looks like to have several improvements and enhancements, but as far as I can see now there is nothing new according the fail-over possibilities.
If I think of possible enhancements in PVS concerning fail-over there are two things that came up in my mind. First thing is the possibility to extend the site functionality. As explained in the Current paragraph site are autonomous and do not take functionality for another site. It would be nice if you can configure a back-up site per site that will be used when no PVS servers are available within the site. Graphically I made this in the GUI shown below.
Secondly it would be nice if you can specify a back-up VLAN within the subnet affinity best effort rule. When more than two VLANs the fail over is pretty randomly. It would be nice if you could specify in which order VLANs should be checked. It will be pretty difficult to develop because you currently does not specify the VLANs, the detection of the local VLAN is done automatically in the product. But definitely a nice to have.
In this article series I wrote down how fail-over could be done in the past (aka as the XenXApp 6.5 era), how it’s currently can be done (and what’s missing in comparison with the past) in XenDesktop 7.5/7.6, the near future based on current available Technology Previews (XenDesktop 7.7) and enhancements that Citrix could make in our vision. Part one <<LINK>> described these phases for the database/delivery controller and Storefront. This second part discussed the Published Apps/Desktop and Citrix Provisioning Services.