Storage Boards Cleanup
To make it easier to find information about HPE Storage products and solutions, we are doing spring cleaning. This includes consolidation of some older boards, and a simpler structure that more accurately reflects how people use HPE Storage.
Disk Arrays
cancel
Showing results for 
Search instead for 
Did you mean: 

EVA 4100 disk group extension

SOLVED
Go to solution
anatol_2
Occasional Visitor

EVA 4100 disk group extension

Hello,

we have a productive EVA 4100 (starter kit) with one disk group composed of 8 disks (146GB each), disk drive protection level set to 'none', capacity completely used up for 2 virtual disks (vraid1 and vraid5) containing both VMware ESX storages (with approximately 80% of used space).
We want to fill up the shelf and add 6 more disks (of the same size) to the default DG in order to create a new virtual disk. How will this impact the system, especially the running VMs? What amount of time will this take approximately? Should we add all the new disks at once or do it one by one over a certain period of time? Is this a process with special risks?

Thank you
8 REPLIES
IBaltay
Honored Contributor
Solution

Re: EVA 4100 disk group extension

Hi,
it has no impact on running system, it is the standard back-end operation.
But there are several rules which have to kept:
1. consider if it is safe to continue with the NONE disk protection (in case of any disk failure it means loss of the whole data in the DG)
2. add the physical disks 1 by 1 (maximum 4) in one time and wait for their proper initialization (approx. 1 minute)
3. group the disk into the existing DG - all 6 disks at once
4. EVA controllers have the feature of automatic redistribution of the existing VDISKs across all new disks

Resume
it is the back-end operation with no impact to the frontend production IO
the pain is one part of the reality
Uwe Zessin
Honored Contributor

Re: EVA 4100 disk group extension

> 1. ... (in case of any disk failure it means
> loss of the whole data in the DG)

I don't think you wanted to write that...

'anatol' is using vraid-1/5 so there is should be no problem with a single disk drive failure as data can be recovered through VRAID redundancy.


I agree that one should not use protection level "NONE" and:

anatol,
you should _NEVER_ fill a disk group completely. The absolute minimum is 5 GBytes of free space.
.
IBaltay
Honored Contributor

Re: EVA 4100 disk group extension

Yes you are right maybe I have intentionaly exagerated the fact that in the production environment without the spare drives with every disk drive failure you are running in the degraded state which is one step before the data loss. Thats why the dedicated additional capacity of 2 disks as spares (single disk protection) seem to be pretty worth to decrease this risk.
the pain is one part of the reality
anatol_2
Occasional Visitor

Re: EVA 4100 disk group extension

Hello IBaltay,

I agree totally with you in saying that this level of 'NONE' is far away from being ideal, but this has been configured in a situation of need for a maximum of space and has never been changed since. We considered these 'disc protection levels' (distributed sparing) as equivalent to hotspare configurations on other storage systems. In fact, we rely on vraid redundancy exclusively and must not loose more than 1 disk (just as Uwe said in his response).

By the way: provided sufficient capacity in the disk group: could we change the protection level of the DG on the fly?

Many thanks
Uwe Zessin
Honored Contributor

Re: EVA 4100 disk group extension

Yes, you can change the level at any time. The EVA does automatically recover as long as enough free space is in the disk group - even with protection level NON. Its only purpose is to prevent you from accidently filling the disk group so that no(t enough) space is left for VRAID recovery.


We have a nice proverb which goes like:
"nothing sticks as long as an 'interim solution'" ;-)
.
anatol_2
Occasional Visitor

Re: EVA 4100 disk group extension

Hello Uwe,

>you should _NEVER_ fill a disk group >completely. The absolute minimum is 5 >GBytes of free space

This hasn't been taken into account for some reason.
So this means, that at present we wouldn't be able to recover successfully from failure at all?
Is this a situation we can escape from, that is: does it prevent us from extending the DG itself?

Thank you

IBaltay
Honored Contributor

Re: EVA 4100 disk group extension

the lack of minimum free space can
dramaticaly increase the time of the metadata operations (ungroup, leveling) and thus the eva becomes to be pretty unflexible to handle...
the pain is one part of the reality
Uwe Zessin
Honored Contributor

Re: EVA 4100 disk group extension

This is a general recommendation and there was a bug in a previous version of the controller firmware that did not cope well with such a situation.

I have not heard that this is a general problem, but I assume that you will follow best practices anyway and make sure you have a good backup before you touch the EVA.
.