With XenApp and previous versions of XenDesktop, the database was just the storage repository for static information. We really didn’t spend much time thinking about the impact of the database on production environments. The databases were small. They databases didn’t have a big impact on the underlying system. So what about XenDesktop 5’s SQL Database? Let me just say that the database is now the King.
What happens if you don’t plan your database appropriately? How about this:
- You run out of disk space
- You have a XenDesktop environment that fails
- You have poor enumerating and launching performance
I’m not trying to be an alarmist, but I want to make sure that everyone doing a XenDesktop 5 design spends enough time focusing on the importance of the SQL database instead of brushing it aside like we all did in previous versions.
Let me give you some stats to help you understand how the database might impact you. First, you must understand that the database contains all of the information about the XenDesktop site. It knows who is logged in, where, how long, resources in use, desktop states, etc. Anytime something changes within the site, the database is updated. Plus, in order to validate that the previous information is correct, there is a constant heartbeat within the environment. This helps provide a better fault tolerant infrastructure. But this comes at a price. Let’s run through a few examples:
- A XenDesktop site with 20,000 defined desktops will consume 250MB of space within the database.
This isn’t very large and shouldn’t bother us too much… right? True, the database is small, but what about the transaction log?
- Ten defined desktops in a site are idle for 24 hours will consume 14.5MB of space in the transaction log
Now that is interesting. Multiply this by 20,000 desktops and your transaction log for 24 hours (idle) is 29GB!!!! Hopefully that caught your attention. But all is not lost. You can use the “Simple Recovery Method” in your database configuration to keep the file small, but you do lose the ability to do SQL Mirroring. If you want to mirror, just do more frequent full backups of your database, which will also help to keep the transaction log small.
The point is you don’t want to be caught off guard with a SQL Server out of disk space. You can manage the transaction log, but you have to be smart about it.
If you want to know more, check out the Planning Guide: SQL Database in the XenDesktop Design Handbook. This is a great article you want to be aware of.
Daniel – Lead Architect