Unidesk High Availability notes. Unidesk was bought over by Citrix in January 2017.
The Unidesk environment largely depends on the infrastructure it works alongside to be highly available:
These components include:
- Hyper-V using clustering using Unidesk 3.x. Unidesk 2.x for example required clustered VMware hosts.
- Active Directory so that machine assignment can occur and users can actually log on and process group policies.
- DHCP so that Unidesk desktops and session hosts receive a configurable IP address.
- Networking infrastructure connecting each system
- Storage that is shared between hosts that is highly available as this is where the layers reside.
- Citrix components such as Delivery Controllers highly available so that users can be brokered on to desktops.
- SQL server high availability for the Citrix Site database.
Scenarios:
- Unidesk Management Appliance fails – If the Management Appliance fails, running desktops will continue to function because they connect directly to their layers (virtual disks). When the Management Appliance is not available you will not be able to manage existing desktops including rebuilding them, assigning new layers, creating new desktops etc.
- Unidesk Master CachePoint fails – If the Master CachePoint fails you can not create new OS Layers, Application Layers or versions. OS Layers and Application Layers that have already been replicated to Secondary CachePoint’s continue to serve desktops without issue.
- Unidesk Secondary CachePoint fails – No new desktops can be created to the failed Secondary CachePoint and existing desktops cannot be modified or deleted unless the CachePoint they are connected to is unnafected. Desktops that have already been created and are managed by a failed SCP continue to run.
- Hyper-V clustered hosts do not share storage – Unidesk will work however if a Unidesk desktop or Session Host is moved to a server that does not have a connection to storage containing the required layers the desktop will simply not work. For this reason and in this situation, virtual machine failover should be configured to prevent failover to hosts without the necessary storage.
- DHCP Servers fail – If one or more DHCP servers fail, Unidesk desktops and/or Session Hosts may be unable to renew or request a new DHCP lease. As a result, machnies will be as good as failed.
- Active Directory fails – If one domain controller fails more load will be placed on the remaining domain controllers so this should be kept in mind during sizing. If Active Directory becomes unavailable completely users will mostly not be able to authenticate. Persistent desktops should be able to log a user on as the user profile is cached in the Personlization Layer however no Group Policy will apply and in fact log the user probably will not be able to do anything useful.
- SQL server fails, affecting Citrix – Citrix (XenApp/XenDekstop 7.9 and above) will enter Connection Leasing mode so that users who have recently connected to resources within the past two weeks will be able to connect as normal. Users who are already connected during the database outage will not be affected. XenApp/XenDesktop 7.12+ introduced LHC (Local Host Cache) which goes a step further than Connection Leasing. To read up on Connection Leasing see https://jgspiers.com/citrix-connection-leasing/
Backup and availability performance:
Back up requirements for Unidesk are simple because the layering technology actually reduces the need to back up so much data. With Unidesk, you have one copy of the OS Layer and one copy of the Application Layer instead of having 100 copies for every full cloned desktop. Not only does this massively reduce space, it also means you only need to backup each OS and Application Layer once, and this can be done by backing up the Master CachePoint. Persistent desktops need to have their boot image and personlization layer backed up. These recommendations from Unidesk can provide better backup performance and availability:
- Spread departments across hosts and CachePoint’s for redundancy. You don’t want a host or CachePoint failure to affect a whole department.
- Spread Non Persistent deskop collections across hosts so that no single host failure affects all desktops.
- Place the Master CachePoint and Secondary CachePoint on highly available hosts using redundant hardware.
- Create recovery desktops/recovery collection for persistent use cases.
- Backup persistent desktops personalization layers if desktops have significant customization.
- Backup the Master CachePoint and Management Appliance.
- Backup the MCP, MA and Unidesk Persistent desktop personlization layer and boot images to different storage so one storage failure doesn’t invalidate all backups.