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.
2 Responses
We have a VMware setup connected to our SAN with two RAID arrays one two physical sets of disks. The first is a RAID10 and the second is a RAID6. It sounds like our logs should go on a LUN on the RAID10 array. The blades that the VMs run on boots from the SAN and has no internal storage of its own.
Is there any performance improvement between having the data files and the TempDB on the same LUN vs separate LUNs if they are both on the same RAID6 array? It seems to me that the SAN would still be optimizing the writes to this same array as best as it could whether they were the same LUN or separate. But then I read a post somewhere that SQL will assign a different I/O thread if the info is on two separate drives and this might increase performance. Again, this doesn’t sound right since the bottleneck is the I/O, not the O/S handling of the I/O thread.
Any comments?
I would still recommend putting them on different LUNs. You’ll get different IO paths to the SAN so there’s less chance of the HBAs being saturated that way. Also you’ll get separate IO queues in Windows this way which will help you out if a path starts to have performance issues.
(This is all assuming the native Windows MPIO driver. If you have EMC’s PowerPath installed this change a little.)