Disk Design for vCenter database

Like all databases the VMware vCenter database needs to have the disks configured properly for best possible performance.  Don’t get me wrong, if you’ve got a very small vCenter database that’s only a couple of gigs in size then the disk size isn’t all that big of a deal.  However if you have a larger vCenter database with dozens of hosts and hundreds or thousands of guests you’ll want to spend a little time setting up your disk systems for the vCenter database correctly.

For a proper disk configuration you’ll want at least three different LUNs or local RAID arrays (I’ll assume you are SAN attached here, so if you are using local disk just replace LUN with RAID array).  These three LUNs should be RAID 1 (or RAID 10, 0+1, whatever your storage provider calls this).  One of these LUNs will host the Main Data File (the files that have a file extension of mdf).  Another one of these LUNs will host the transaction log file (the files that have a file extension of ldf).  The last LUN will be for the files for the tempdb database.

Now these three LUNs shouldn’t be sitting on the same physical disks (if you are using a 3PAR, IBM XIV, etc. that is shared everything you can probably ignore this part).  You especially don’t want the data file and transaction log file on the same LUN.  The reason for this is that both of these LUNs will be written to at the same time so having these on the same physical disks will cause contention at the disk level.  You don’t want the tempdb on the same disks as either of these other LUNs either.  Now if I had to pick one of these LUNs that I would put the tempdb LUN on the same physical disks with I could have it share spindles with the vCenter databases transaction log file.  My reason for this is because most of the time that tempdb database will be used by the vCenter database it’ll be reading data from the main vCenter databases and putting it into the tempdb database for processing.  So there should be less contention if the tempdb shares spindles with the transaction log file.  If possible keep all three LUNs on separate sets of spindles.

When sizing the LUNs don’t forget that the vCenter database will be keeping at least a years worth of data, so make sure that you give the system plenty of room.  At least 20 or 30 Gigs would be a good starting point.  VMware should have some sizing estimates that you can use on their website.  The bigger your VMware environment is the more disk space you’ll need.

When it comes to moving the vCenter databases to the new LUNs (assuming that you aren’t starting with a new vCenter database here) you’ll want to shutdown the vCenter services, then right click on the vCenter databases in SQL Server Management Studio and select all tasks, then detach.  Then move the databases to the correct location.  Then in SQL Server management studio right click on databases and select All Tasks then Attach database.  Locate the database in the new location in the popup window and attach the database.  Once the databases have been attached to the SQL Server instance you can restart the vCenter services to get vCenter up and running again.  This whole process should only take an hour or so depending on how large your vCenter databases are.

Don’t forget about the update manager database and cache folder.  You’ll probably want to put the update manager database on the same LUNs as the other vCenter databases, which is fine.  The cache how ever should go on another LUN as it’ll take a lot of space, and we don’t want all that space causing space problems for the vCenter database files.  Also you’ll probably want to use fast storage for the vCenter database as the data within that database is always changing and slower SATA storage for the update manager’s cache files as they are static are almost never written to or read from so you don’t want to waste expensive storage on storing gigs of update files.

Hopefully this information helps you build a more tuned VMware vCenter server.  If you have questions feel free to contact me, we can probably get them resolved pretty quickly.