Dilogoat86 wrote:Any advice for running SQL in a virtual environment?
Ah, SQL, you've caused me some pain over the years! Some things that come to mind are:
SAN connectivity - whats the medium - fiber channel perhaps? If so, setup the zoning to allow redundant links to be use load sharing, a 4Gbit backbnne should be sufficient.
What type of disks are used in the SAN? If SATA, throw them in the bin and invest in SAS or equivalent, SATA can't provide the throughput for transactional systems.
How are the arrays setup, what about the RAID level?
You've a separate partition for transaction logging, right? If possible, locate your transaction log VMDK on a seperate SAN, at a bare minimum, point them at a separate array. Database and logs on the same partition will bring the application to a snails pace in no time.
SQL specific - invest in a decent DB defrag tool such as Diskeeper, I've seen real gains by using the same on busy production systems. In a physical world, the boot, swap, data and log partitions should all be located on separate arrays (using RAID 1+0 for example). Mirror the physical disk layout in your virtual environment for optimum performance. Give the server loads of RAM, SQL's a glutton for it
Tip: Don't deploy new VMs at the drop of a hat just because you can do so easily. The sign-off process for a new VM should be the same as if you were purchasing and deploying a physical server. The system needs to be maintained, licensed, backed up and adds to the load - all factors that incur time and cost.
CJ