VMware

This Question is Answered

1 "correct" answer available (10 pts) 2 "helpful" answers available (6 pts)
7 Replies Last post: Feb 9, 2009 12:57 PM by foxy1977  

ESXi disk setup for SQL server VMs - advice sought posted: Jan 28, 2009 3:57 AM

Click to view foxy1977's profile Enthusiast 53 posts since
Jul 24, 2006
Hi folks,

Just after a bit of advice about the RAID hard drive setup on a new physical host we are putting in to run a couple of virtual SQL servers. I am looking at putting in a Dell 2950 with 16gb RAM (with space for another 16gb taking it to 32gb) and a lot of direct attached storage. My question is really around the RAID config. I am looking at running possibly 3 machines at needing about 300-500gb each storage each.

I know for physical servers we try to setup the system, transaction logs and data files on separate disks. Some of our servers were split between two raid controllers and a number of physical disks. Do we still need to plan the virtual machines along the same lines. I was thinking that we do not need to set them up in the same manner as the underlying physical setup is different. I am thinking about putting the system os on a 20gb partition and a massic 300gb data partition.

At the moment we do not have a budget for shared storage but I am hoping we can get something sorted in the next few months.

I am thinking about whether to go with RAID 5 (5 or 6 x 1tb SAS or SATA drive) or RAID 1+0 with a number of 1TB drives. What setup is going to give me the best performance? I have heard stuff about the more spindles the better. I'm assuming spindles means drives!

We are going to be converting/migrating 2 machines that are running on dual AMD 2218 2.6ghz with 4gb RAM on direct storage. Just run a few sql counters over one of the boxes and it is averaging between 60-100 transactions per second the other box is averaging about 350 per sec. We are also looking at upgrading SQL from 2000 to 2005.

Any tips and ideas gratefully received
Click to view rentonj's profile Hot Shot 217 posts since
Jan 31, 2008

Take a look at this. http://communities.vmware.com/docs/DOC-8964

Should give you all of the answers you require.

John

Click to view Lightbulb's profile Virtuoso 1,391 posts since
Aug 15, 2008
Spindles do mean drives :)

For SQL VMs disk I/O setup is just as important as on a physical system.

I posted about this here last night

http://communities.vmware.com/message/1155224#1155224

You really should take a look at this whitepaper which covers SQL I/O setup and Best practices

http://www.computationpress.com/images/disk_deck_short2.pdf

Also MSFTs take on it

http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/pdpliobp.mspx

As you do not have Shared storage your options are a little limited at this time but setting up the I/O subsystem on a SQL system (Physical or Virtual) is something you want to put some thought into or you will face performance issues and unusual bugs down the line.

Click to view Lightbulb's profile Virtuoso 1,391 posts since
Aug 15, 2008
RDM = Raw Device Mapping

These are LUNS presented from shared storage more or less directly to the VM.

As you do not have shared storage you need not concern yourself with them right now

As to point 2 yes separate system/boot, data and logs (While your at it you could isolate tempdb on separate vmdk, although that might be a bit much)

If not for performance this will at least make a future migration to an RDM a little less difficult.

Click to view JasonVmware's profile Hot Shot 147 posts since
May 19, 2008

Hello,

If you are using direct attached storage right now I would setup the drives as you would in a psyhical server. One thing to remeber when you go virtual is you want to keep the same proven practices that would of been setup on a psyhical system. When you have shared storage you would want to use RAW LUN mappings for the SQL server but since you have direct attached storage I would break up your raid sets into raid 10 (1+0).

Essentially create a raid 10 set of disks for your database, and another raid 10 set for your transaction logs. The OS could be on a mirror if you like as it doesn't require as much perfomance but it is up to you. I would do this for each SQL server. So your setup would look something like this:

Raid 1 Mirror (2 disks) - Datastore for OS's - virtual disk for your os
Raid 10 - (4, or 8 disks) Datastore for SQL database - virutal disks for your SQL database
Riad 10 ( 4 or 8 disk) - Datastore for SQL Transaction Logs - virutal disks for your SQL transaction logs

I hope this helps, if you have any questions let me know.


Click to view Texiwill's profile Guru 10,205 posts since
Jan 13, 2004
Hello,

I would also give a listen to Podcast #32 of the VMware COmmunities Roundtable Podcast. This discusses this in some detail but the long and short of it is, what you do in the physical world translate into the virtual world. If you would normally use multiple disks then you would continue to do so, but remember multiple VMDKs on the same LUN does not map to multiple disks in the physical world you would have to have multiple VMDKs each ondifferent LUNs or using RDMS to get that.


Best regards,
Edward L. Haletky
VMware Communities User Moderator
====
Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.
Blue Gears and SearchVMware Pro Blogs: http://www.astroarch.com/wiki/index.php/Blog_Roll
Top Virtualization Security Links: http://www.astroarch.com/wiki/index.php/Top_Virtualization_Security_Links

VMware Developer

SDKs, APIs, Videos, Learn and much more in the Developer community.

Learn More

Developer Sample Code

Increase your developer productivity with VMware API sample code.

Learn More

VMworld Sessions & Labs

Online access to the latest VMworld Sessions & Labs and online services.

Learn more

Purchase PSO Credits Online

Purchase credits to redeem training and consulting services online.

Buy Now

Community Hardware Software

View reported configurations or report your own.

Learn More

VMware vSphere

Come witness the next giant leap in virtualization.

Register Today

Communities