Allocating all space on EVA 4400

[st3reo]

Hello,

I'm kind of new to the SAN world and I would like some help please.

We have an EVA 4400 with 2 disk enclosures, each with 12 300GB 15k FC disks, so in total 24 disks.

I intend to use this array for virtualization with VMware ESX.
As I understand, the vmware best practice is to create a big disk to which all hosts have access, makes sense.
So in EVA I created a Vdisk using all the available space (in my case, as raid5 that ends up to 4909GB).
The disk is created ok but the problem is it triggers a warning that space allocation is above the alarm rate of 90%.

My question is...is it ok to leave it like this? Will there be any performance issues if I allocated all the space? should I leave some free?

Thanks,

[Uwe Zessin · Accepted solution]

> a big disk disk

I highly doubt that this is 'best practice'. You have consolidated free space, but also limited all I/Os to one file system.
And there is no work for the second controller you paid for ;-)

Unfortunately, there is no single correct size for a datastore. I have customers with as low as 250 GB and as high as 800-1000 GB.

> ends up to 4909GB

You will find out that it does not work anyway, because the maximum size is 2 TeraBytes - 512 Bytes, so use 2047GB.

> alarm rate of 90%

That is only an information. If you don't make use of BC/CA you should leave at least 5 GigaBytes free, and make sure you have set the so-called "protection level" to single. The EVA does not use dedicate spare disks and the "protection level" reserves enough capacity in the disk group.

[st3reo]

Thanks for your answer.

Yes, that was one of my main concerns, leaving the second controller unused.
(By the way how do I set vdisks to be managed by controller 2? I tried setting the path to "path B failover/failback" but it still shows ctrl 1 as the one managing.)

And I'm not sure what you mean by "it won't work because max size is 2TB" ...
I know there is a file size limit in the VMware VMFS of 2TB but the datastore I think can be a lot bigger than that.

Basically I'm going to have a handfull of ProLiant servers as ESX hosts connected to the EVA and on those, a few virtual machines will have 1TB or bigger hard disks, and some more virtual machines will have smaller HDD, maybe up to 100-200GB.
I wanted to have a single big datastore presented to all hosts because I figured it would be a lot easier to manage space allocation.
Because for example lets say I would make a LUN of 2TB for the "big" virtual machines (2 VMs each with 1TB hdd) and one of 1TB for the smaller VMs.
As I'm going to use thin provisioning, the space on the big machines won't actually be used all up, and it might be years before usage goes up, so most of that space on that LUN (datastore) will be empty.
But on the other hand, on my "small datastore" I will keep adding small VMs and I run out of space.
That's why I figured having all the storage space available for everyone would be better.
But I guess I might be wrong, I don't have much experience with this so an expert opinion is very appreciated.

Also I'm not sure what BC/CA is, I think it has to do with replication...and I don't have that.
So basically even if I have one or more LUNs it's ok to allocate up all the available space in EVA?
I'm asking because I remember reading somehwere that there seems to be some performance issues after 80% or something like that, not exactly sure if that was about allocated space or actuall used storage space.

Thanks,

[jhetrick]

While I am not an expert I would recommend that you split up the LUN's into smaller sizes.

Here was my issue...previous SAN person used a 1.5 TB single LUN to present to 8 hosts. The I/O's slamming this single channel were causing a ton of SCSI reserve errors on ESX. To resolve this I created 4 400 GB LUN's and had the hosts spread out the load over these 4 LUN's...this may or may not be what you are trying to do...but just be aware that one huge LUN is not a good idea for I/O.

Also I do not think VMware recommends one large disk due to the SCSI reserve issue. So you might check with VMware on that one.

[MKemp_1]

Actually VMWare best practices suggest that you use more moderate size datastores. I have been deploying VMWare since version 2.4 and our policy is to use 500GB LUNs to datastores. there are several reasons for this, not the least being the I/O distribution. I use both EVA 8100 and a 4400. We also have reduced the alarm to 80% from 90% in oder to reduce other issues with storage management.

[Uwe Zessin]

> (By the way how do I set vdisks to be managed by controller 2?

Exactly by the way you did it. Sometimes the command is 'ignored' and you have to retry it a bit later.
Or select a path to the B controller on the ESX servers and constantly do I/Os. After an hour the EVA should automatically move the virtual disk to controller B.


> And I'm not sure what you mean by "it won't work because max size is 2TB" ...

KB3371739 - ESX does not support 2 terabyte LUN sizes
http://kb.vmware.com/kb/3371739

I understand that management would be 'easier' if you could work with one single datastore (remember I wrote "You have consolidated free space" ;-)
but it is simply not possible to go above 2TB - see above.


jhetrick mentions another thing: SCSI reservation. While a simple read/write I/O does NOT cause a SCSI reservation - any change to a VMFS will.
Such changes are: power on/off of a VM, creation /deletion /expansion (log files, snapshot deltas, ...) of files.
A SCSI reservation will block all I/Os from all other servers to a given disk.

You mention thin provisioning. Any allocation of space for a VMDK requires meta-data changes which require SCSI reservations.


BC is short for Business Copy and means local replication (snapshots, clones + mirror clones of virtual disks.
CA is short for Continuous Access and means remote replication (all writes to a virtual disk are send to another virtual disk on a second EVA).

Even if you don't make use of them - keep at least 5 GBytes of space free in the disk group and use "protection level" single.

[st3reo]

I see,
Well thanks a lot for your answers, they have been very helpfull, You might have just saved me from quite a lot of trouble :)