IB_IT
Expert
Expert

extending a datastore best practice

Hi all,

Been doing some research about extending a datastore. I have heard from other threads that this can degrade performance....does anyone have, or does VMWare have any evidence to support this? I've looked around the kb's but can't find anything. I have never used the extend feature as I always try and use one single LUN per datastore, but I am getting pushed into a corner about using this want to present some tech notes as to why we shouldn't extend a datastore if need be. I did find this from a best practice guide:

"It's generally best to begin with a single LUN in a VMFS volume."

But I'm just looking for something more...thanks all.

Tags (1)
0 Kudos
4 Replies
TobiasKracht
Expert
Expert

Don`t expand existing. Add new one and add it as extend to existing. You can do it while VMFS is running.

StarWind Software R&D

StarWind Software R&D http://www.starwindsoftware.com
0 Kudos
Rumple
Virtuoso
Virtuoso

The problem with extents is that if you lose one of those lun's then you are going to lose everything in the entire vmfs volume. Picture 2 seperate RAID Groups of RAID 5 and one of the volumes loses 2 drives for whatever reason (offline or dead drives). You lose your ENTIRE environment, not just the VM's on that particular RAId Group.

It also causes rather major problems when you start trying to remove the extent later..you have to delete the entire volume (not just the added extent).

These 2 options right here are where things usually go bad...someone doesn't realize a volume is in use an poof the entire envirement goes bye bye since removing zoning could cause the entire volume to corrupt, whereas 2 seperate vmfs volumes would mean everything goes down on that volume, you re-zone it back and usually powerup your VM's again (/me speaks from experience here btw)

In ESX 4 they have enabled the ability to GROW a vmfs volume so that extents are not a problem anymore, but even with EMC, if you use metaluns and then grow out your VMFS, I've be worried what would happen if you lost one of the metalun groups...probably wouldn't be pretty.

If you have a raid group thats 1TB in size and a 500GB VMFS volume on it, just create another 500GB VMFS volume. In this case its probably better to violate the 1LUN=1VMFS volume best practice then the extent best practice.

Other things to keep in mind is the number of VM's/VMFS volume. You don't want to try and go much beyond 10-15VM's per VMFS volume so even if you grow the 500GB volume to a 1TB VMFS volume you should not be putting more then a combined 10-15 VM;s on that 1TB VMFS volume, whereas you can put 20-30 VM's on 2x500GB (example numbers only). This is due to scsi reservation issues you can encounter during backups or boot storms

kastlr
Expert
Expert

Hi,

The problem with extents is that if you lose one of those lun's then you are going to lose everything in the entire vmfs volume.

This statement is not correct, only data located on the lost LUN is inaccesible.

You should check the following article about VMFS.

Virtual Geek: VMFS Best Practices, and counter-FUD


Hope this helps a bit.

Greetings from Germany. (CET)

Hope this helps a bit.      Greetings from Germany. (CET)
0 Kudos
rubensluque
Enthusiast
Enthusiast

Hi,

The health & check template report available for VMware Partners in www.vmware.com/partnercentral recommends a size between 250GB and 500GB.

Below is a bit of that document:

"When creating datastores on shared

storage, size the LUN with a target of accommodating 20-25 virtual machines per

LUN. The size of the LUN is less important than the total number of active

virtual machines on it being accessed by multiple ESX hosts. Doing so can help

prevent the potential performance impact caused by too many VMs on the same LUN

concurrently starting up. A typical LUN size is around 250-500GB.

Recommendations from the storage

manufacturer on maximum LUN sizes should also be considered as they are also

able to consider specific details such as caching limitations."

Then I would recommend you to create a new LUN instead of expand it.

0 Kudos