SQL Server in Citrix Environments

Neil Burton

XenApp Datastore Probably the only database “Citrix people” cared about

Easy to accommodate Not life threatening if it died (for short periods)

Citrix XenApp datastore (1 per farm) XenApp config logging (1 per farm) XenDesktop (1 per farm) EdgeSight Provisioning Services

The list goes on… Command Centre (Netscalers) Workflow Studio Receiver Storefront, SmartAuditor, CloudPortal

AppSense Management Personalization

RES Software Automation Manager Workspace Manager

App-V Printing Solutions (ThinPrint, Uniprint, etc) Platform Management SCVMM, Citrix Essentials, VMware vCentre

A Citrix project may have 10-15 or more directly dependent SQL Server Databases, just to support infrastructure Some of these databases can have significant requirements for high availability and scalability – these are becoming key design factors in any XenApp and XenDesktop project Dedicated DBA resources (beards) aren’t always available so this can end up falling in the remit of Citrix architects!

Know which SQL versions your products support http://support.citrix.com/article/CTX114501

Try and estimate capacity for databases which are likely to grow e.g. EdgeSight and AppSense personalization. Both vendors offer sizing guidelines with documentation.

Database availability now increasingly important for infrastructure databases. Post-IMA XenDesktop 5 architecture needs SQL to be available – XenApp to follow? Same with AppSense personalization SQL options are extensive - get to know them Clustering Mirroring Log Shipping Replication

Clustering – conventional Windows failover clustering on shared storage. Provides HA with automatic failover without requiring application awareness as SQL Server name and IP remains the same. Mirroring – mirrors transactions on a secondary copy of the database. Can provide HA when combined with witness server and application awareness. Commonly used for HA and DR. Log Shipping – similar to Mirroring but based on transaction log shipping. Less commonly used.

Replication – replicates database tables between a master publisher and one or more subscriber databases. All databases can be queried but typically writes are directed to publisher. Merge Replication – writes can be made on multiple servers and updates are replicated bidirectionally. In the event of a conflict the publisher takes precedence. Merge Replication used by AppSense Personalisation

Last but not least – ensure proper SQL aware backups are taken of all key databases! In a small environment this could just consist of a scheduled SQL backup to disk (flat file) for copy elsewhere.

CAL or CPU/Core based – work out which is most cost effective (or indeed if already licensed) SQL 2012 just introduced new Core license – priced equivalent to 4 cores = 1 old CPU license. So be careful with new 8-core CPUs! SQL Standard supports 2-node active/passive failover clustering and asynchronous mirroring SQL Enterprise needed for advanced HA Windows Enterprise Edition needed for >32GB RAM and Failover clustering

Consensus used to be SQL = physical but there are obvious benefits to virtualisation In today’s multi-core world CPU is rarely a bottleneck – don’t overlook memory and disk which are far more likely to strangle SQL Amazingly common to see 12+ CPU cores, 32GB RAM and a handful of disks in RAID5 – oblivious to the bottleneck RAM costs