XenDesktop 7 Database High-Availability

Table 1

The following table highlights the impact from database outage:

Decision: Vendor and Version

In order to streamline the daily maintenance and support of used Citrix products it is recommended to use the same type of database engine for all installed products. The previous versions of Citrix XenApp supports database software from Microsoft, Oracle and IBM, while support for all other Citrix products has been limited to Microsoft SQL Server. Starting from XenDesktop 7.0 only Microsoft SQL server is the supported database engine.

For more information on supported database vendors and versions for Citrix products, please refer to the Citrix knowledge base article CTX114501 – Supported Databases.

Decision: Edition

There are five editions of Microsoft SQL Server 2012:

• Express
• Web
• Standard
• Business Intelligence
• Enterprise

The the most important features of each edition, which are applicable to Citrix databases are shown in the table 3 below.

Table 3

As opposed to older versions, XenDesktop 7 uses three databases:

• Site database – Contains static configuration and dynamic runtime data
• Monitoring database – Contains monitoring data which is accessible via XenDesktop Director
• Configuration logging database – Contains a record for each administrative change performed within the XenDesktop site. Data is accessible via XenDesktop Studio.

By default, the monitoring and configuration logging databases are located within the site database. It is recommended changing the location of these secondary databases as soon as the configuration of the XenDesktop site has been completed. For more information, please refer to my post XenDesktop 7 configuration logging explained

Decision: High-Availability Type

In addition to the built-in Citrix database redundancy options, Microsoft SQL Server, as well as the underlying hypervisor (in virtual environments), offer a number of high availability features. These enable administrators to ensure single server outages will have a minimal impact (if any) on the Citrix infrastructure. The following the SQL / hypervisor high availability features are available:

• VM-level HA – This high availability option is available for virtual SQL servers only, which need to be marked for High Availability at the hypervisor layer. In case of an unexpected shutdown of the virtual machine or the underlying hypervisor host, the hypervisor will try to restart the VM immediately on a different host. While VM-level HA can minimize downtimes in power-outage scenarios, it cannot protect from operating system level corruption. This solution is less expensive than mirroring or clustering because it uses a built-in hypervisor feature. However, the automatic failover process is slower, as it can take time detect an outage and start the virtual SQL server on another host. This may interrupt the service to users.
• Mirroring – Database mirroring increases database availability with almost instantaneous failover. Database mirroring can be used to maintain a single standby or mirror database, for a corresponding principal or production database. Database mirroring runs with either synchronous operation in high-safety mode, or asynchronous operation in high- performance mode. In high-safety mode with automatic failover (recommended for XenDesktop) a third server instance, known as a witness, is required, which enables the mirror server to act as a hot standby server. Failover from the principal database to the mirror database happens automatically and is typically completed within a few seconds. It is a good practice to enable VM-level HA (or a similar automatic restart functionality) for at least the witness to ensure SQL service availability in case of a multi-server outage.
• SQL Clustering – Failover clustering provides high-availability support for an entire instance of Microsoft SQL Server. A failover cluster is a combination of two or more nodes, or servers, with two or more shared disks. A Microsoft SQL Server failover cluster instance appears on the network as a single computer, but has functionality that provides failover from one node to another if the current node becomes unavailable. The transition from one note to the other node is seamless for the clients connected to the cluster.
• AlwaysOn – AlwaysOn Availability Groups is an enterpriselevel high-availability and disaster recovery solution introduced in Microsoft SQL Server 2012, which enables administrators to maximize availability for one or more user databases. AlwaysOn Availability Groups require that the Microsoft SQL Server instances reside on Windows Server failover clustering (WSFC) nodes. Similar to failover clustering a single virtual IP / network name is exposed to the database users. In contrast to failover clustering, shared storage is not required since the data is transferred using a network connection. Both synchronous and asynchronous replication to one or more secondary servers is supported. As opposed to mirroring or clustering secondary servers can be actively used for processing incoming read-only requests, backups or integrity checks. This feature can be used to offload user resource enumeration requests to a secondary SQL server in XenDesktop environments to essentially scale-out a SQL server infrastructure. Since the data on active secondary servers can lag multiple seconds behind the primary server, the read-only routing feature cannot be used for other XenDesktop database requests at this point in time. For more information, please refer to MSDN – AlwaysOn Availability Groups (SQL Server).

Recommended SQL high availability features for each database are shown in the table 4 below.

Table 4