Fault tolerance

May 28, 2016

This document outlines ways in which you can increase the level of fault tolerance in your deployment to make sure that business-critical applications and desktops are always available.

Configure database fault tolerance

All information is stored in the Site configuration database; Delivery Controllers communicate only with the database and not with each other. A Controller can be unplugged or turned off without affecting other Controllers in the Site. This means, however, that the Site configuration database forms a single point of failure. If the database server fails, existing connections to virtual desktops will continue to function until a user either logs off or disconnects from a virtual desktop; new connections cannot be established if the database server is unavailable.

Citrix recommends that you back up the database regularly so that you can restore from the backup if the database server fails. In addition, there are several high availability solutions to consider for ensuring automatic failover:

  • SQL Mirroring — This is the recommended solution. Mirroring the database makes sure that, should you lose the active database server, the automatic failover process happens in a matter of seconds, so that users are generally unaffected. This method, however, is more expensive than other solutions because full SQL Server licenses are required on each database server; you cannot use SQL Server Express edition for a mirrored environment.
  • Using the hypervisor’s high availability features — With this method, you deploy the database as a virtual machine and use your hypervisor’s high availability features. This solution is less expensive than mirroring as it uses your existing hypervisor software and you can also use SQL Express. However, the automatic failover process is slower, as it can take time for a new machine to start for the database, which may interrupt the service to users.
  • SQL Clustering — The Microsoft SQL clustering technology can be used to automatically allow one server to take over the tasks and responsibilities of another server that has failed. However, setting up this solution is more complicated, and the automatic failover process is typically slower than with alternatives such as SQL Mirroring.
  • AlwaysOn Availability Groups is an enterprise-level high-availability and disaster recovery solution introduced in SQL Server 2012 to enable you to maximize availability for one or more user databases. AlwaysOn Availability Groups requires that the SQL Server instances reside on Windows Server Failover Clustering (WSFC) nodes. For more information, see AlwaysOn Availability Groups (SQL Server).

Note: Installing a Controller on a node in an SQL clustering or SQL mirroring installation is not supported.

Configure a Site to use a mirror database

The configuration process involves tasks an administrator completes using SQL Server management tools before creating the Site. The remaining tasks occur when the administrator runs the Site creation wizard.

A mirror environment requires at least two SQL Server machines (in the following example, SQL Server A and SQL Server B). SQL Server Express edition cannot be used as either a principal or mirror.

Using Microsoft SQL Server management tools, configure the SQL Server databases:

  1. Install the SQL Server software on SQL Server A and SQL Server B.
  2. On SQL Server A, create the database intended to be used as the principal (for example, myDatabaseMirror).
    • Make sure that the database uses the full recovery model and not the simple model. (The simple model is configured by default, but prevents the transaction log from being backed up.)
    • Use the following collation setting when creating the database: Latin1_General_100_CI_AS_KS (where Latin1_General varies depending on the country; for example Japanese_100_CI_AS_KS). If this collation setting is not specified during database creation, subsequent creation of the service schemas within the database will fail, and an error similar to “<service>: schema requires a case-insensitive database” appears (where <service> is the name of the service whose schema is being created).
    • Enable a Read-Committed snapshot as described in CTX137161. It is important to enable this before the database is mirrored to avoid errors.
  3. On SQL Server A, back up the database to a file and copy it to SQL Server B.
  4. On SQL Server B, restore the backup file to that server (SQL Server B).
  5. On SQL Server A, start mirroring.

The next step depends on whether the Citrix administrator (that is, the person running the Site creation wizard) also has full database privileges:

  • If the Citrix administrator has database privileges (the same person is the database administrator and the Citrix administrator), Studio does everything for you:
    1. The Citrix administrator uses Studio to create a Site, specifying the address of the previously-created SQL Server A database and its name (myDatabaseMirrorForXD).
    2. The database scripts are automatically applied and the principal and mirror databases are set.
  • If the Citrix administrator does not have database privileges, the Citrix administrator must get help from a database administrator:
    1. The Citrix administrator uses Studio to create a Site, specifying the address of the previously-created SQL Server and its name (myDatabaseMirrorForXD).
    2. In the Site creation wizard, selecting Generate Script generates a mirror script and a primary script. The Citrix administrator gives those scripts to the database administrator, who applies the scripts (the mirror script should be applied first). The database administrator must tell the Citrix administrator when that task is completed.
    3. Back in Studio, the Citrix administrator can now complete the Create Site wizard. The principal and mirror databases are set.

To verify mirroring after creating the Site, run the PowerShell cmdlet get-configdbconnection to make sure that the Failover Partner has been set in the connection string to the mirror.

If you later add, move, or remove a Delivery Controller in a mirrored database environment, see Add, remove, or move Controllers, or move a VDA for considerations.

Ensure desktop and application access if Controllers fail

If all Delivery Controllers in a Site fail, you can configure the Virtual Delivery Agents to operate in high availability mode so that users can continue to access and use their desktops and applications. In high availability mode, the VDA accepts direct ICA connections from users, rather than connections brokered by the Controller.

This feature is for use only on the rare occasion when communication with all Controllers fails; it is not an alternative to other high availability solutions. For more information, see CTX127564.

When the database is not available

The connection leasing feature supplements the SQL Server high availability best practices by enabling users to connect and reconnect to their most recently used applications and desktops, even when the Site database is not available. For details, see Connection leasing.