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