There is currently a lot of debate going on about whether or not you should be running SQL server or Exchange on ESX. Rather than jump into the middle of this debate, I'll offer the best way that you could possibly run a high performance SQL server on virtual hardware.
I/O
I/O is by and large the biggest concern when running a database on an ESX cluster. Your main concern here is going to be ensuring that your database files are not impacted by I/O operations on your other VMs. We can ensure this through Raw Device Mappings.
Generally, for a high-performance database, you'll want your data files, log files, tempdb and program/OS/backup files to all live on separate spindles. To accomplish this, we do the following:
Data Files - RAID5 or RAID10 (RAID5 is more economical but you will suffer a hit on write performance).
Log Files - RAID10
TempDB - RAID10
OS/Program Files/Backup/File Share - This can be run from a standard VMDK.
Memory
In addition to I/O, memory is very important. If a database server has sufficient memory, it will not need to go to disk for its data as often, vastly improving performance. To be absolutely sure that your server receives sufficient memory, you can set your memory reservation equal to the amount of memory given to your VM. This will ensure that ESX never swaps out active memory from your database and that the SQL query optimizer can make accurate predictions about hardware performance.
CPU
On my key instances, CPU has never been much of a bottleneck, so I generally treat this as I would with any other VM.
Subscribe to:
Post Comments (Atom)
2 comments:
This post spawned a discussion over at VM/ETC which brought up some useful information. The highlight is a link to the Malaysia VMWare Communities in which one admin ran actual I/O benchmarking tests comparing RDMs with VMFS volumes. Worth checking out...
If you only create the VMFS datastore for single VM usage, what been stated here maybe right. Bear in mind, you will not only have single VM on 1 datastore. RDM has better performance and flexibility of the physical LUN which can be easily assign to another virtual or physical server, which VMDK will not able to do this. Again, is really depend what you try to achieve.
Post a Comment