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 < 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 neil@burtoncomputing.co.uk @neildmb