SQL Server in Citrix Environments - UK Citrix User Group ·  · 2012-05-30dependent SQL Server Databases, just to support infrastructure ... Replication – replicates database tables

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 bi-directionally. 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 <£100 for 8GB – no excuse not to fill that server up!

Key SQL performance factor particularly in large scale environments

SQL Mirroring on local storage – clustering requires shared (SAN) storage

Ensure write back caching is used – taken for granted on SAN but often overlooked on DAS

Segregate Data and Log files

Also consider segregation of SQL Binaries, Windows Pagefile and TempDB files

Don’t neglect/overlook spindle count

Large number of volumes – use mount points

Consider deploying SQL in named instances

Instances are to a large degree isolated and managed individually

Instances can be stopped/started invididually

Instances can be at different patch / service pack levels

Instances can failover individually on clusters

Provides useful security boundary

Consider deploying an instance for each dependent application

Always use limited privilege service accounts – dedicated per application / database / instance

Use windows authentication wherever possible. If some apps require legacy SQL authentication put them in their own ‘less secure’ instance.

Be aware of requirements and dependencies

Citrix techies may want to improve their knowledge and awareness of SQL Server design and implementation best practices

Consider these requirements early in project plans especially in large scale enterprise deployments – resource plans may need to expand to include specialist DBAs and more $$$$ on SQL hardware and licenses than expected

Neil Burton [email protected] @neildmb