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

advice on expanding EVA 4400

Bob_Vance
Esteemed Contributor

advice on expanding EVA 4400

Have 2c2d w 24 300g (=279G) drives,
split into 2 DG of 12 each.
(Why? Because there are 2 application groups who wanted no data commingling.)

Well, of course, they now each want to expand about 2.5 TB.

So, we propose another shelf w 12 600g (=559G) drives.
Ostensibly, that would give, at RAID5, no sparing, 12*559*(4/5)=5366
or about 2.7 for each, but they would have to commingle.

The only way to keep the data separate, is to add 6 600g drives to each existing DG made up of 12 300g drives.
But then we have the drive-size issue.
Now, theoretically, if we humans were in charge, we could simply create a new RSS with 6 disks (making a total of 3 6-disk RSSes) and we would lose no space, other than extra sparing, if used.


So, the Q's are:

1) Is the EVA logic smart enough to know that we are adding 6 out-sized disks and keep them in one RSS to maximize space?

2) If not, can we force it in some way.

3) Will the sparing algorithm work properly with this mixture of drive sizes?
Presumably, at single "protection", it will need 2*559G instead of the current 2*279, so in effect losing the equivalent of one 600g drv, meaning we are really only adding 5*559*(4/5)=2236

Any ideas or comments welcomed.

bv
"The lyf so short, the craft so long to lerne." - Chaucer
4 REPLIES
gabbar
Trusted Contributor

Re: advice on expanding EVA 4400

1) Is the EVA logic smart enough to know that we are adding 6 out-sized disks and keep them in one RSS to maximize space?

.....it will discard the extra space (559 minus 279). hence utilizing only 279 GB out of 559...

2) If not, can we force it in some way.

.....you can create another Disk group.. no other option... ofcourse it will waste some more space for sparing on this Disk Group

3) Will the sparing algorithm work properly with this mixture of drive sizes?
Presumably, at single "protection", it will need 2*559G instead of the current 2*279, so in effect losing the equivalent of one 600g drv, meaning we are really only adding 5*559*(4/5)=2236

.....if you mix the 600 GB drive with 300 GB, it reserve the 600x2 for single sparing
Víctor Cespón
Honored Contributor

Re: advice on expanding EVA 4400

Adding a few bigger drives to a disk group of smaller drives is NOT a good idea.

AS you state, first you lose 600 GB because "disk failure protection" will use 2*600 instead of 2*300.

Second, the bigger drives will be distributed on several RSS to avoid having an RSS with much more traffic than the others. One or two 600 GB disks on an RSS of 300 GB disks will never fill completly, so you'll not have 600 GB available per disk, but less.

How much less depends on how RSSs end up, and if you have mostly VRAID 1 or VRAID 5 vdisks.
Bob_Vance
Esteemed Contributor

Re: advice on expanding EVA 4400

@ gabbar & cespon

Thanks.

So, I understand that by default the EVA would distribute the drives across RSS.
But the question really was,
"Is there any way to alter that behavior or fake it out or re-allocate the disks afterwards?"

Seems both of your votes for answers are:

1) No
2) No
3) Yes

bv
"The lyf so short, the craft so long to lerne." - Chaucer
Bob_Vance
Esteemed Contributor

Re: advice on expanding EVA 4400

OK, that said,

propsed "enhancements" to the EVA logic:

1) Have a setting on a Disk Group that says, "no RAID1 VDisks allowed".

2) in case of mixed drives, allow the option to specify RSS allocation.
Let the administrator decide whether performance or space is more important.



*1) My understanding is that the reason for doubling the protection is to accomodate possible mirrors (although I do not know the actual internals of the sparing algorithm and the disk-failure re-allocation of redundancy).
This option would allow the spare space to be only 1 or 2 of the largest disk, instead of 2 or 4. At some point, if you decide to have a RAID1, you simply turn off the option and more free space becomes reserved, similar to what happens when you change from "single" to "double".



*2) It seems a little unreasonable to *force* the spreading of the new, larger disks out across all RSS.

Of course, the reason for this behavior is to spread the load out:
the larger disks would see more activity (by virtue of simply housing more of the data) and could hurt the "perceived" performance of the DG.

But, what's really happening is that you are not adding larger drives at all.
You're essentially just adding drives with size of the the smallest drive in the DG. Based on the simple algorithm described, you'll always have some small drives in each RSS, thereby reducing the effective capacity of the larger drives.

Not everything boils down to performance.
Sometimes capacity is important.


So, in my scenario, with 2 6x300g-disk RSS, adding a 6x600g-disk RSS, would mean that 1/3 the drives will have 1/2 the I/O, but maybe that should be my call.


Carried to its logical conclusion, then you should always use only small drives.
The maximum performance would from the smallest drive that allows just below I/O saturation point.
Sure, that may help performance, but it's not feasible to figure that out.


bv
"The lyf so short, the craft so long to lerne." - Chaucer