Teneo !!!

Aaron’s blog on Networking, and Enterprise Technology

EMC Luns and vmWare: Best Practices?

Okay, so I’m at a cross-roads right now using iSCSI LUNs with vmWare vSphere.  I have 4 vmWare hosts participating in a cluster.  Among all the benefits of introducing a SAN to a virtual environment, one is intriguing.  “To be able to copy a LUN as another LUN, and attach a vmWare instance to it.  Why?  Testing with production data, such as migrations, upgrades, changes, etc”.  While I know I can do vmWare snapshots, that is using a live server, and not a dedicated instance running in parallel.

With that in mind, I have 2 ways to slice up storage:

1).  Create one large LUN and store lots of virtual machines on it.  This would be like, a 500GB or 1TB LUN.

  • Advantage: 1 LUN to map to each vmWare host, for vMotion
  • Advantage: Less Administrative work.  Lower LUN to virtual instance creation ratio.
  • Disdavantage:  LUN Snapshots for testing won’t work.  It is not efficient to snap a 500GB LUN to test 1 virtual instance that only has 50GB of data on it.

2).  Create individual LUN’s, for each virtual machine instance.

  • Advantage:  Easy to copy that single LUN to another for testing in an isolated environment using production data.
  • Disadvantage:  High administrative overhead, slicing LUNs for each new vmWare instance
  • Disadvantage:  Have to create each LUN on each vCenter host participating in vMotion

From the looks of things, it sounds like there are more advantages to creating larger LUN’s for multiple vmWare Instances than single LUNs.  What is your general practice?

Advertisements

6 responses to “EMC Luns and vmWare: Best Practices?

  1. Jeramiah Dooley November 14, 2010 at 1:33 pm

    I would go #1. If you want to have the ability to snapshot the individual VMs at the storage level, I’d suggest using NFS instead of block. The benefits you are going to see (managability, scalability, etc…) from a multi-VM per LUN environment are going to outweigh the challenges of having a LUN mapped to a single VM.

    Personally, I’ve standardizes on 4x500GB LUNs that are extented to form a 2TB datastore. You get improved performance because of the higher disk count, you get simplified management because you’ve got one logical object to manage in vSphere and you have a enough space to drive efficienty into the RAW-to-Usable equation.

    • Aaron Paxson November 14, 2010 at 2:00 pm

      Excellent! Thanks Jeramiah! Your explanation was awesome! To be honest, I can’t remember if I bought NFS licenses. I’ll have to look. I think I purchased everything *except* for NFS. Go figure! I used NFS when doing *nix to *nix mapping, but not on a SAN/vmWare mount.

  2. Stefan Jagger November 14, 2010 at 4:33 pm

    I agree… Option 1 is the way to go as you could easily grow out of option 2’s fixed style LUN provisioning and it’s a mass of work to administer.

    If you’re looking to create production snapshot type VMs for testing you could either using VMware’s cloning or Veeam Backup & Replication. If you choose to go Veeam it’s great for backup and replication.

    Generally, unless you have Uber-spare-cash laying around, LUN mirror/replication is costly. If you do have the cash then mirror the entire SAN and do local SAN testing, Production/Dev setup.

  3. Kendrick Coleman November 15, 2010 at 8:06 am

    Here’s a best practice on sizing LUNs to fit your vSphere environment. You always want to find out what VMs are going to have your highest I/O and distribute them across datastores. Never put to much contention on a single datastore.

    Say you have 10 VMs that all have intense I/O applications but the other 70 VMs in your environment are low hanging fruit. I would carve up 5 LUNs and place 2 of each heavy I/O in each datastore, then I would start evenly distributing the 70 other VMs across these datastores. But of course you need to calculate the size ahead of time.

    In both of your examples you are going to the extreme polar opposites. Why not settle for somewhere in the middle? In addition to testing with production data and serving up a snapshot LUN on the SAN side, did you take into account all the networking overhead that must be done so you don’t bring up two instances in an environment? As said before, if you really want a cheap and easy sandbox solution, go check out Veeam Backup & Replication.

    Kendrick

    • Aaron Paxson November 15, 2010 at 4:09 pm

      Thanks for the comment, Kendrick! Yes, I was going on the extreme opposites, and I’m sure there is a compromise. I was just trying to paint a picture as to the types of options we have, and what everyone else did. Your comment makes sense. Almost like slicing up network vlan’s in order to cut down on broadcast traffic.

      It just seemed to me that if I have 12 drives for datastores (just a number i through out there, I don’t remember how many I have) assigned to a storage group. And I carve out a 1TB LUN across those 12 drives…. then won’t another 1TB LUN be striped across those same spindles? Unless you are assuming multiple storage groups?

      As far as taking into account the networking, all that is, is just creating a test vlan and assign the server to it…… or just leave it “unplugged” if it doesn’t need access to other systems.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: