XenDesktop 5 Database Sizing and Mirroring Best Practices

Transcription

1 XenDesktop 5 Database Sizing and Mirroring Best Practices

2 Table of Contents Database Planning... 2 Database Sizing... 2 Sizing the database file... 2 Sizing the transaction log... 3 Database Mirroring... 4 Database Mirroring Options... 4 Database Mirroring Setup... 4 Broker SQL Configuration String Setup... 5 Database Mirroring Best Practices... 6 Controller configuration changes... 6 Database Mirroring Maintenance... 7 Deleting a Mirrored Database... 7 External References... 8 Page 1

3 Database Planning There are a number of important areas to consider when planning an SQL database for XenDesktop 5.0, including: Database Sizing Database Mirroring This article provides information about database sizing and mirroring, discusses some best practices, and provides links to additional information. Database Sizing When sizing an SQL database, two aspects are important: 1. The database file 2. The database transaction log file Sizing the database file The size of the database file depends on the following factors: The number of configured and registered workstations The number of connected sessions The connection rate The number of managed desktops The number of provisioned desktops Each of the above factors impacts the sizing requirements. Each desktop (managed or unmanaged) requires: Approximately 2.9 KB for registration and worker state information Approximately 5.1 KB for session state KB for each connection log record. By default, these are purged after 48 hours. Each MCS provisioned desktop also requires: Approximately 1.8 KB for Active Directory computer account information Approximately 1.94 KB for MCS machine information For example, with 20,000 unmanaged desktops, in a normal day users will log on once, with some users perhaps roaming and reconnecting multiple times, allowing an average per user of two connections per day. Using these numbers and the data above, we can calculate the database file size as: Per Worker: 2.9 KB X 20,000 = 58,000 KB Per Session: 5.1 KB X 20,000 = 102,000 KB Per Connection: KB X 40,000 X 2 days = 3,360 KB Total: 163,360 KB or approximately 160 MB Page 2

4 Based on Citrix testing, this database sizing matches the size of a database for 20,000 users. Using the above data we can calculate expected database sizes for different user counts. The sizing for a variety of user counts is shown in the following table: Unmanaged Desktops 5,000 10,000 20,000 Per Worker (KB) 14,500 29,000 58,000 Per Session (KB) 25,500 51, ,000 Per Connection (KB) 840 1,680 3,360 Total (KB) 40,840 81, ,360 Total (MB) Provisioned Desktops 5,000 10,000 20,000 Per Worker (KB) 14,500 29,000 58,000 Per Session (KB) 25,500 51, ,000 Per Connection (KB) 840 1,680 3,360 Per AD Account (KB) 9,000 18,000 36,000 Per MCS machine (KB) 9,700 19,400 38,800 Total (KB) 59, , ,160 Total (MB) Note that this sizing information is a guide only. Your exact database usage might be slightly larger because of the SQL server having spare pages in tables. Also, we have not allowed for the number of catalogs and other smaller tables. Sizing the transaction log The transaction log is more difficult to size because this depends on a number of factors, including: The SQL Database recovery model in use Launch rate at peak times The number of desktops In testing, with the full recovery model, it was found that a launch rate of 40 users a second to 20,000 desktops consumed approximately 1.3 MBs of transaction log space. This would consume approximately 670 MB of transaction log. Idle desktops consume approximately 62 KB of transaction log every hour. Note that this will depend on the heartbeat setting discussed later; increasing the heartbeat interval will decrease the log usage. In a 24 hour period, one desktop will consume 1.45 MB, 20,000 desktops will consume approximately 29 GB. In a large environment this level of transaction log usage requires careful management. Page 3

5 By default, Desktop Studio configures any new SQL databases to use the simple recovery model. However, Citrix recommends that if full recovery model is in use, that the transaction log be sized so that it rarely has to grow. Testing showed that when SQL Server auto-grew the transaction log, all transactions stalled causing an increase in controller response times. Instead, Citrix recommends that a fixed-size transaction log be used and that an SQL Alert is set up so that when the transaction log reaches 50 percent full, the transaction log is backed up, thus freeing it up. This maintains the transaction log at a reasonable size, without impacting SQL Server performance. Database Mirroring This section provides information about SQL database mirroring and discusses best practices. Database Mirroring Options There are multiple methods of setting up a mirrored SQL database. The models are: asynchronous mirroring synchronous mirroring, with witness synchronous mirroring, without witness Of these models only synchronous mirroring, with witness supports automatic failover. Therefore, Citrix recommends using this model for any production environment; otherwise, if the principal database fails, user intervention is required to fail over the database. For more information about the different models and their performance characteristics, see: Database Mirroring Setup This document does not discuss the initial setup of mirroring; for information about this, see: Microsoft s documentation: Note that SQL mirroring can be configured before or after the SQL database is populated. Also, an empty SQL database (mirrored or unmirrored) can be populated using scripts generated by Desktop Studio, the Power Shell SDK, or using Desktop Studio to directly populate the database. Page 4

6 Broker SQL Configuration String Setup If mirroring is configured after the initial deployment of XenDesktop, you must update the connection strings so that the controllers can locate the mirrored SQL server in the event that the principal SQL Server fails. To do this, use the PowerShell SDK. To retrieve your current connection string, use: PS C:\> Get-BrokerDbConnection Server=camr3e1b01.xds2.chsys2.citrix.com;Database=CitrixXenDesktopDB;Trusted_Connection=true To the above string, add the Failover Partner clause, for example: Server=camr3e1b02.xds2.chsys2.citrix.com;Database=CitrixXenDesktopDB;Trusted_Connection=true; Failover Partner=camr3e2b01.xds2.chsys2.citrix.com Next, update the connection string for all the XenDesktop services on all the controllers. To do this, use the following script (with the MirroredConnectionString updated appropriately): $MirroredConnectionString = Server=camr3e1b02.xds2.chsys2.citrix.com;Database=CitrixXenDesktopDB;Trusted_Connection=true; Failover Partner=camr3e2b01.xds2.chsys2.citrix.com $brokers = Get-BrokerController foreach ($broker in $brokers) { = $broker.dnsname Set-ConfigDBConnection DBConnection $null adminaddress Set-ConfigDBConnection DBConnection $MirroredConnectionString adminaddress Set-AcctDBConnection DBConnection $null adminaddress Set-AcctDBConnection DBConnection $MirroredConnectionString adminaddress Set-BrokerDBConnection DBConnection $null adminaddress Set-BrokerDBConnection DBConnection $MirroredConnectionString adminaddress Set-HypDBConnection DBConnection $null adminaddress Set-HypDBConnection DBConnection $MirroredConnectionString adminaddress Set-PvsVmDBConnection DBConnection $null adminaddress Set-PvsVmDBConnection DBConnection $MirroredConnectionString adminaddress Set-ProvDBConnection DBConnection $null adminaddress Set-ProvDBConnection DBConnection $MirroredConnectionString adminaddress } Page 5

7 Database Mirroring Best Practices Controller configuration changes Citrix recommends that you change the default heartbeat timeout when using database mirroring. You can do this by changing registry settings. The two settings you need to change are stored in: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\DesktopServer These settings are: HeartbeatPeriodMs controls the interval that the workstations heartbeat with the controller. Note that the workstations actually heartbeat at half the specified interval. The Controller will terminate a workstation if it does not communicate at the specified interval. The default is 60,000 ms. MaxHeartbeatIntervalMs specifies how long before a controller terminates a workstation; you can use this to override the above setting. By default, this is not configured. In testing, it was found that if network connectivity on the principal SQL Server fails, it can take up to one minute for the XenDesktop services to failover to the mirrored SQL Server. This is because TCP and network timeouts having to occur. When workstations heartbeat every 30 seconds, which requires an SQL operation, this results in workstations de-registering and then attempting to re-register. Also, the controllers attempt to unregister any workers that do not heartbeat for over one minute, which can lead to workstations being marked as unregistered, although these are alive and capable of accepting a session. Based on these findings, Citrix recommends you increase the default HeartbeatPeriodMS to 10 minutes (600,000 ms). Although workstations might still fail to heartbeat during the SQL failover period, this prevents the controllers from de-registering them, so workstations are still available for users. This works well with managed workstations as XenDesktop 5 will remove any session records and automatically de-register any virtual machines that are powered off, but which do not unregister cleanly for any reason. With unmanaged workstations, this increases the risk that a user may be directed to a workstation that is not available; however, the use case for unmanaged workstations is for workstations to be assigned, so it is expected that the user is more aware of the state of their workstation. Note that, when this occurs, the user receives a launch failure error in Web Interface. Page 6

8 Database Mirroring Maintenance As previously mentioned in Database Planning, when an SQL database uses the full recovery model the transaction log must be backed up. Full recovery model is a requirement of database mirroring. During testing, we found it best to avoid SQL transaction log growth because this impacts performance. Therefore, a system was used in which the transaction log is configured to a fixed size (2 GB) and an SQL alert is set so that, if the transaction log reaches 50 percent full, a job is run to backup the log. Note that, for alerts and jobs to be executed, the SQL Server Agent must be set up and configured to auto-start. The job is set up to run an SQL command similar to: BACKUP LOG [CitrixXenDesktopDB] TO DISK = N'D:\Rhone_Log_Backup\CitrixXenDesktopDB.bak' WITH NOFORMAT, NOINIT, COMPRESSION, NAME = N'Rhone-Transaction Log Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10 The alert is configured to monitor the SQL performance counter: SQLServer:Databases - Percent Log Used - CitrixXenDesktopDB For more details on configuring jobs, see: For more details on configuring alerts, see: Deleting a Mirrored Database To delete a mirrored database, you must first remove the mirroring configuration. This is done through the properties of the database on the current principal database. Once the database is no longer mirrored from the former principal database, you can delete the database. On the former mirror, it might not be possible to delete the database while it is in a restoring state. If this is the case, take the database out of the restoring state before you delete it. You can do this by rolling pending transactions forward using the SQL statement: RESTORE DATABASE CitrixXenDesktopDB WITH RECOVERY The database is then treated as a normal database and can be deleted. Page 7

9 External References Microsoft Whitepaper on Database Mirroring Best Practices; while written for SQL 2005, it still applies to SQL 2008 and SQL 2008 R2: o Microsoft s Database Mirroring Deployment How-to Topics: o Page 8