Disk Arrays
cancel
Showing results for 
Search instead for 
Did you mean: 

Fully Pre-Carving an EVA Array - Good or Bad?

SOLVED
Go to solution
Alzhy
Honored Contributor

Fully Pre-Carving an EVA Array - Good or Bad?

We use EVA arrays in alongside an XP12K which we've standardised on LUN Sizes (i.e. 25,100,200 GB). We are thinking if it is considered good practice to pre-carve standard sized VDISKS on the EVA .. so all DiskGroups are just about fully occupied. The VDISKS will thence be treated as we do an XP LUN.. allocate and deallocate (actually present/de-present)- instead of totally deleting the VDISK...

So is pre-carving an EVA to however many standard sized VDISKS to fully reach accepted full occupancy of the Diskgroups considered Good Practice? What about the notion of just de-presenting a VDISK from a server if it is done being used - instead of totally deleting the VDISK?

Hakuna Matata.
11 REPLIES
Uwe Zessin
Honored Contributor

Re: Fully Pre-Carving an EVA Array - Good or Bad?

Sounds OK to me, provided that you can live with the fact that there is old data on the Vdisk when you present it to a new server.

The disk area of a new Vdisk is implicitly erased by the EVA firmware, but the deletion / recreation / zeroing of a new disk takes up time and I/Os.

Remember not to fill a disk group 100% - if I remember correctly, you should leave at least 10 (or was that 5?) raw GigaBytes free.
.
Alzhy
Honored Contributor

Re: Fully Pre-Carving an EVA Array - Good or Bad?

Thanks Uwe..

The reason we'd like to do this as a standard for all our existing EVA5K's and possibky new ones is based on experience as well.. It takes a fair amount of time carving VDISKs (as well as removing them). Plus it really slows down the arrays durng Vdisk creation as well as deletion.

It also gives us the advantage of not worrying anymore about reaching the 95% occupancy with a very dynamic system... With VDISKS pre-carved and pre-sized, all we have to do is treat it like our XP simply allocate and de-allocate.. We already have processes anyway that ensure once a disk is no longer used by a Volume Manager on UNIX/NT.. it is zeroed out and a database of sorts updated to show it as a free VDISK...

Plus I think it nicely lays out all your VDISKS within your Diskgroups... for optimum Performance..

Hakuna Matata.
Mark Poeschl_2
Honored Contributor

Re: Fully Pre-Carving an EVA Array - Good or Bad?

The only disadvantage to doing this that I can think of is that migration (in the event of a disk failure) or ungrouping (when replacing disks) will take longer. All that allocated, but unpresented capacity will have to be migrated or ungrouped.
Alzhy
Honored Contributor

Re: Fully Pre-Carving an EVA Array - Good or Bad?

Mark,

Why would it take longer?

Educate me please.
Hakuna Matata.
Uwe Zessin
Honored Contributor

Re: Fully Pre-Carving an EVA Array - Good or Bad?

Lets assume a disk group is filled by 30% with virtual disks. Then all disks are filled by 30%. If a disk group is filled with 50%, then all disks are filled by 50%.

If a disk is ungrouped, all its data must be moved to the remaining disks in the group. If a new disk is added to a group, data from other disks will be moved to the new disk in order to reach the same filling - that's the leveling.

If the disk group has a higher fill factor, more data needs to be moved from/to disks during leveling.
.
Alzhy
Honored Contributor

Re: Fully Pre-Carving an EVA Array - Good or Bad?

Okay.

So regardless of whether we'll have a fully populated diskgroup - either by way of pre-carving or natural progression of filling up the diskgroup, we'll always have a situation of massive "levelling" - right?

Is there also "levelling" that happens when a VDISK is killed/decommisioned or born?

And say I have 48 Disks in a Diskgroup and I only carve a 2GB VDISK - is the EVA architecture such that the VDISK will have bits of its existence on ALL 48 Drives?


Hakuna Matata.
Uwe Zessin
Honored Contributor

Re: Fully Pre-Carving an EVA Array - Good or Bad?

I have seen an indication that the EVA tried to level after a Vdisk deletion, but that was really, really quick. It looks like the code is very keen to do leveling, but finds out that here is no need to do ;-)

You can use an EVA with 240 disk drives in one single group. The internal structures allow for a full spread over all disk drives, even for a 1 GigaByte Vdisk.
.
Mark Poeschl_2
Honored Contributor

Re: Fully Pre-Carving an EVA Array - Good or Bad?

Yes, as Uwe says, data is always spread over ALL spindles in a disk group.

Deleting a Vdisk doesn't require re-leveling and is pretty quick. That's because you don't need to move/re-create data from other spindles to those remaining in the disk group when you delete a Vdisk. It's just a matter of updating the metadata to reflect the fact that some space is no longer allocated.
Peter Mattei
Honored Contributor

Re: Fully Pre-Carving an EVA Array - Good or Bad?

What EVA models are you using?

Why am I asking!
One of the taks that needs lots of CPU ressources in an EVA is deleting VDISKs. The larger the VDISK is and the more blocks that are actually allocated the longer it takes.

This was on of the reasons for introducing the containers concept available starting with VCS4.x (EVA3/5k)and XCS5.x (EVA4/6/8k).
With containers you do not need to delet a VDISK anymore; you can convert a VDISK or a snapclone into a container and reuse it as VDISK or as a target for a snapclone.

I believe it is containers you are looking for (unless you are at VCS3.x)

Cheers
Peter
I love storage
Alzhy
Honored Contributor

Re: Fully Pre-Carving an EVA Array - Good or Bad?

Peter,

Glad this caught your attention..

"One of the taks that needs lots of CPU ressources in an EVA is deleting VDISKs. The larger the VDISK is and the more blocks that are actually allocated the longer it takes. "

So do you agree that pre-allocating and simply re-using VDISKS can be considered a good practice?


We currently have EVA5K's -- currently at VCS 3.028 which we are planning to upgrade to VCS 4.004 or whatever will be available early next year. The reason for this is so we can do away with SecurePath and just use DMP on VxVM. We've been using VxVM/DMP on both EVA 5K and XP disks that are currently co-presented on our HP-UX/Solaris hosts. The EVA side, it is still path protected by SecurePath and DMP ignores it.. Once we are at A/A(VCS 4.X) on the EVA5Ks - we intend to drop SecurePath and just have VxVM/DMP manage pathing/balancing on the EVA LUNS...

And with this, we will now be managing/treating EVA Vdisks as if they were XP disks... we will no longer "delete" vdisks but simply uninitialize and de-present them.

Hakuna Matata.
Peter Mattei
Honored Contributor
Solution

Re: Fully Pre-Carving an EVA Array - Good or Bad?

Hi Nelson

Yes, preallocating is a good practice!

When going to VCS4.004 you need to make sure that you set your pathes correctly especially when doing heavy reads!
You know since with VCS4.x all LUNs can be accessed through both controllers and if you set round robbin you could end up doing lots of proxy reads through the "wrong" controller which means overhead!

So best is to have your preferred pathes on the LUN owning controller!
This will be adresse by implementing ALUA which for the EVA to my knowledge is currently only available for Windows with MPIO DSM 2.01.00 and Solaris with MPxIO.

ALUA means Asymmetric Logical Units Access and has been defined by INCITS T10.
You will see it more and more in the future!
Perhaps with VxVM/DMP as well?!

Cheers
Peter

PS: To make my previous post clearer: You cannot convert a container directly to a VDISK, you can use it to create snapshots or snapclones! See attached a scteenshot of CV with the button to create a container. Note that the vdisk needs to be unpresented before you get this option!
I love storage