Extents, 512GB LUNs, I/O - What's your opinion?

[andrewsp]

Hi,

we use Hitachi AMS500's. Our ESX servers connect to that environment via 2Gb/s fibre. I have a white paper from Hitachi in regards to the VMware environment about configuring for best performance on 256Gb or 512GB LUNs due to SCSI reservations, queue lengths etc.

What is regarded as best for I/O performance as in this coming year we are looking to virtualise our Exchange servers and a big nasty horrible IO intensive SQL database.

Multiple datastores either 256GB or 512GB in size

or

A few large datastoresmade up of 256Gb or 512GB extents?

I can see within the community and blogs that some people are against extents. And that's fine but I need to understand why. I was kind of figuring that visually less datastores is just less overwhelming. I can see from datastores that I already have with extents that IO generally balances out across the LUNs that host the extents so is it just caution from the community or would I find everything 18.2% faster :smileysilly: running in non-extented VMFS's?

Thanks in advance for your time.

Scott

[krowczynski]

Hi,

as heared from many people for vsphere it is recommended to create e.g. 1TB LUNs with max 15 VMs on it.

I would not use extends!

MCP, VCP

[andrewsp]

Thanks for the feedback - but why would you not use extents? They are there as an option from VMware...

You are what you eat - who wants to be a lettuce?

[krowczynski]

Well if you create extens an the "master" LUN crashes all your data on the extens will become unavailable.

MCP, VCP

[andrewsp]

Hi

I knew about the VMFS corruption - but I have to put my trust in the storage. What about extents and performance though? Anyone know?

[andrewsp]

I have found the answer on a blog here about SCSI reservations -

The key bit is as follows

"

In the VMFS implementation it is possible for files span multiple

volumes. The implication is that a single write on a file traversing extents

can result in SCSI reservations across multiple LUNs, with the associated

degradation on overall performance.

In VMFS, all metadata is located on the master extent (typically the first

LUN on which you created the datastore). If one of the extents goes offline,

its data becomes inaccessible... e.g. entire .vmdk's, or in the worse case,

those partial .vmdk's that span the extent. If the master extent goes offline,

the entire datastore becomes inaccessible.

By default, VMFS will attempt to keep individual files confined to an extent.

Nonetheless, considering that file data on a VMFS file system consists of more

than just our defined .vmx and .vmdk's, you can see how, for example, a dynamically

created swap file, or a dynamically growing snapshot file for a VM could

potentially span extents.

Finally, VMFS issues SCSI bus resets rather than target or LUN resets,

which can have a more global affect on the attached fabric. In a poorly

designed environment employing extents and experiencing excessive SCSI reservations,

reservation conflicts, and bus resets, this can result in extents becoming

inaccessible."

So I knew about the master extent and possible losing of data, but I wasn't aware about the SCSI reservations across extents when the SCSI reservation is on one extent. I'll be reviewing my VMFS provisioning!

You are what you eat - who wants to be a lettuce?