Quick question that hopefully someone with hands-on experience can help me with. Each VM we are building has a system drive (C:) with 12 GB. Some VMs will need a separate drive for data (F:).
I'm already planning to place each data drive on it's own LUN. But how about the system drives. Do I make a 300 GB or so LUN for all the system drive VMDKs? Or do I place each server on it's own LUN and put the data drive there also if it needs it?
Pretend I have 3 servers named MAIL, DB, and DC (domain controller)...
Scenario 1:
LUN 1: MAIL.vmx MAIL_C.vmdk DB.vmx DB_C.vmdk DC.vmx DC_C.vmdk
LUN 2: MAIL_F.vmdk
LUN 3: DB_F.vmdk
Scenario 2:
LUN 1: MAIL.vmx MAIL_C.vmdk MAIL_F.vmdk
LUN 2: DB.vmx DB_C.vmdk DB_F.vmdk
LUN 3: DC.vmx DC_C.vmdk
Scenario 3:
LUN 1: MAIL.vmx MAIL_C.vmdk
LUN 2: MAIL_F.vmdk
LUN 3: DB.vmx DB_C.vmdk
LUN 4: DB_F.vmdk
LUN 5: DC.vmx DC_C.vmdk
I'm leaning right now towards scenario 3. It will make it easy to do SAN snapshots on individual servers while also keeping the data drive separated...
But that could create a nightmare handling 20 or so LUNs between 2 ESX servers for 12-14 servers...
Any info is appreciated.
IMHO, there are many schools of thought on this topic but no one "right" way to do it. I've become fond of the following technique:
\- Group virtual machines (OS or C_drives) that you would backup together on the same LUN (volume) on the SAN
\- For applications like Exchange and SQL, create separate LUNs (volumes) for data and logs and connect directly to these LUNs (volumes) from within the guest operating system.
\- For file serving, a single additional LUN (volume) will suffice
Benefits:
\- System data is separate from application data, so you can mount different views of the data without having to bring up the same virtual machine in different states (if your SAN allows this)
\- Recovery points can be more granular
\- Some performance benefits (with a possible tradeoff of increased CPU utilization)
Drawbacks:
\- Might be overly complex for small setups or test/dev
Other notes:
\- Make sure you align your partitions on sector boundaries within MS guest OSes to optimize SAN performance per Microsoft best practices. See Microsoft's article:
http://technet.microsoft.com/en-us/library/aa998219.aspx
for more information.
Message was edited by:
ken.cline@hp.com to correct broken URL
This may be of interest to some people too: <a href="http://cmsjustin.blogspot.com/2007/09/equallogic-wants-to-sell-us-stuff.html">http://cmsjustin.blogspot.com/2007/09/equallogic-wants-to-sell-us-stuff.html</a>
Had an interesting converstation down at VMworld about this. Create the C drive in a vmfs folder, but for the data drive, use the MS iSCSI initiatior from within the VM to connect directly to a LUN on the Equallogic. That way if the s*** hit the fan, ESX is removed from the equation and you can map the LUN to any box/laptop using the initiator.
IMHO, there are many schools of thought on this topic but no one "right" way to do it. I've become fond of the following technique:
\- Group virtual machines (OS or C_drives) that you would backup together on the same LUN (volume) on the SAN
\- For applications like Exchange and SQL, create separate LUNs (volumes) for data and logs and connect directly to these LUNs (volumes) from within the guest operating system.
\- For file serving, a single additional LUN (volume) will suffice
Benefits:
\- System data is separate from application data, so you can mount different views of the data without having to bring up the same virtual machine in different states (if your SAN allows this)
\- Recovery points can be more granular
\- Some performance benefits (with a possible tradeoff of increased CPU utilization)
Drawbacks:
\- Might be overly complex for small setups or test/dev
Other notes:
\- Make sure you align your partitions on sector boundaries within MS guest OSes to optimize SAN performance per Microsoft best practices. See Microsoft's article:
http://technet.microsoft.com/en-us/library/aa998219.aspx
for more information.
Message was edited by:
ken.cline@hp.com to correct broken URL
Thanks to both of you. I am going to go with the iSCSI initiator like you suggested for data volumes. Thanks again!
PS that link was broken, I think correct location is here now: <a href="http://technet.microsoft.com/en-us/library/aa998219.aspx">http://technet.microsoft.com/en-us/library/aa998219.aspx</a>
That's exactly the right link - thanks for the correction! I'll correct my post as well so there aren't any broken links in the thread.
Whoops - looks like I can't edit that anymore...notice, correct link given by cmsJustin:
http://technet.microsoft.com/en-us/library/aa998219.aspx
Message was edited by:
sstelter
sstelter...you can edit your posts for 15 minutes after you make it - I made the change for you.
KLC
Thanks Ken!
