VMware Cloud Community
fraber01
Enthusiast
Enthusiast
Jump to solution

San storage setup

Hi all, I want to know the best way to setup the space on the san for an bunch of 4 esx 3.5 servers. I have my own idea and the San administrator has his...

My idea is one big space (I need around 2 Tb of space) on one lun, formatted as vmfs with vm each inside a folder...

The san admin want to give me separate spaces for each vm, a lun for each vm...

I doubt this is good practice but I want to have 'back-up' in order to support my point.

So what's best? one big space or a lot of separate spaces, one for each vm?

Reply
0 Kudos
1 Solution

Accepted Solutions
gdesmo
Enthusiast
Enthusiast
Jump to solution

I do 500 gig lun's. This gives me enough space to put quite a few 20 gig vm's on. With room for snapshots to take place.

And it's not too large that IO bottlenecks would become a factor.

View solution in original post

Reply
0 Kudos
9 Replies
raadek
Enthusiast
Enthusiast
Jump to solution

If you want to use HA/DRS/VMotion goodies, the simplest way is to have just one big LUN formatted with VMFS.

There is a flip-side to that though, as for performance reasons you could be better off having few smaller LUNs (say 500GB-700GB each), but it is a massive topic for a discussion in itself Smiley Happy

And then you can have something which your SAN admin is after, i.e. a separate LUN for each VM (or to be precise for each logical disk within VM) - so called Raw Device Mappings. There is administration overhead associated with that, so typically it is used for database volumes, as performance should be a tad better.

It is a bit surprising though, that your SAN admin is after something which will give him more work! :smileygrin:

Rgds.

Reply
0 Kudos
gdesmo
Enthusiast
Enthusiast
Jump to solution

I do 500 gig lun's. This gives me enough space to put quite a few 20 gig vm's on. With room for snapshots to take place.

And it's not too large that IO bottlenecks would become a factor.

Reply
0 Kudos
khughes
Virtuoso
Virtuoso
Jump to solution

Well like the person above me said, this is a huge topic itself. It really depends on your enviroment and your disk sizes for your VM's. I would generally say that a single LUN for each VM isn't the best idea, but a handful of LUNs isn't a bad idea either. We break our LUN's up by the rack trays, makes it easy to physically see where each LUN is etc.

As for your folders inside the LUN's, VMware takes care of that. I also agree that its a little amussing that your SAN admin wants to create himself some more work but overall you really need to sit down look at the space you have and look at your VM's. You may want your more intensive VM's on different LUN's instead all of them on one giant one, but it really is up to you (and i guess your san admin) on how you should carve it up. Remember when you build out the LUN's to choose the correct block sizing.

-- Kyle "RParker wrote: I guess I was wrong, everything CAN be virtualized "
DCasota
Expert
Expert
Jump to solution

Hi,

As already said: It depends on your environment and needs. Have a look at following thread: http://communities.vmware.com/thread/104211. All aspects small LUN <-> bigger LUN, amount of VMs per LUN, etc. are discussed in that thread.

Hope it helps.

Daniel

Eldron
Enthusiast
Enthusiast
Jump to solution

You should also consider the I/O ability of your SAN. Your individual SAN performance will dictate what you can do. A very high I/O SAN can handle one big LUN without contention. Smaller ones may respond better when they are cut up a little more.

Reply
0 Kudos
raadek
Enthusiast
Enthusiast
Jump to solution

A very high I/O SAN can handle one big LUN without contention.

That's not necessarily the case when you connect large number of 'chatty' ESX hosts to a single LUN.

Every VM power-on or VM snapshot being taken generates a LUN-wide SCSI reservation, so effectively the LUN is exclusively owned for a while by just one ESX host, whilst the others have to wait.

Rgds.

Reply
0 Kudos
jamieorth
Expert
Expert
Jump to solution

Again, this topic has been around for a while, and just like mac vs. windows, Ford vs. Chevy, and taste great vc. less filling, everyone has their opinion. Depending on how many VM's total in your environment, the one LUN per VM isn't a bad idea, it can just get hard to manage as the envrionment grows. You also have to consider vMotion, snapshots, etc. in the design. We typically plan LUN's around performance, and then place VM's accordingly, although not a 1 to 1 ratio. We had 50+ vm's spread over 4 high performing LUN's, with data partition vmdk's assigned to lower cost storage options on the SAN.

Reply
0 Kudos
fraber01
Enthusiast
Enthusiast
Jump to solution

Thank you guys! I didn't knew I was getting into someything that big lol. What I understood is: It depends on me... but 1 to 1 is not a very good idea.

I will go for something right in the middle with luns around 500Gb. It will be more easy to manage and will give some space if a vm has to 'grow'.

I didn't fully understand the 'performance' part of the answers, but since we have IBM Fast600 SANs, I guess they can handle large i/o.

I started last year with 2 servers, I now have 4 of them and we are planning to add 4 more soon... so, it's growing fast and I want it to grow on a way I keep control AND performance.

Thank you again!

Reply
0 Kudos
DCasota
Expert
Expert
Jump to solution

Hi,

Just as last remark: Newer SANs uses storage virtualization techniques. Theoretical example:

You have a SAN with 10TB space, separated in 20 LUNs, each with 500GB. Let's say that each LUN contains only VMFS and this VMFs contains only one VM. Each VM uses only one 300GB vmdk, the rest space (200GB) on the VMFS is only for possible VMware snapshots, swapfile ,etc.

With an older SAN you would waste 20*200GB = 4TB, with storage virtualization the SAN allows to overcommit the storage space up to 14TB. Of course, the SAN storage space must be monitored.

Maybe your administrator can tell you if the IBM Fast600 already uses this storage virtualization technique.

- Daniel

Reply
0 Kudos