I'm currently in the process of getting used to our new EVA 4400 - it's the first EVA I'm dealing with.
I've read both the installation and user guide but didn't find any information about functions like leveling and ungrouping. Are there any other documents where those things are described?
Thanks
Note: If you are the author of this question and wish to assign points to any of the answers, please login first.For more information on assigning points ,click
here
Just to note: From what I understand (still very basic) is that ungrouping just means to remove a disk from a disk group and leveling has something to do with reorganizing the data in the group.
I'm currently ungrouping a 300GB drive from a 24disk disk group and it is taking quite long - the process is at about 70% now and is running for almost 30 minutes. Does ungrouping a disk automatically trigger a leveling? If I understand corretly the EVA somehow needs to get the data of the ungrouped drive to other disks in the group doesn't it?
Anyway, some documentation about this would really be appreciated!
I've never found anything explaining ungrouping, it seems HP just assumes you always expand disk groups.
What I discovered during my few years moving around disks between EVAs is that you can ungroup multiple disks at the same time, provided you have enough free space. But use at your own risk...
thanks for all your input. Especially the Best practices white paper is extremely helpful to understand how the EVA works. It also states what the EVA does during an ungroup event. When performing an ungroup operation, the EVA simply moves all the data contained on the disk to free space (not to the space that is reserverd for the protection level):
--snip--
Proactive disk management: Proactive disk management (PDM) is a request by a customer or HP Services to ungroup a disk, or it is a predictive disk failure request by the EVA to ungroup a disk. In either case, the array migrates the contents of the disk to free space before removing the disk from use. PDM can occur only if sufficient free space is available. PDM operation capacity is independent of protection level capacity. Customers who desire the highest levels of availability elect to reserve additional free space for PDM.
--snap--
Thanks again, you really helped me a lot (though it may still be possible that I come up with additional questions the next days :)
- I can loose one disk in each RSS without affecting any of my Vdisks. I can loose a second disk in one of those RSS if the disk that failed first has been reconstructed to the free/protection level reserved space.
- If two disks in one RSS fail simultaneously I'll definitively loose *all* my Vraid5 Disks (since the Vdisks are striped over the whole disk group) and possibly also all of my Vraid 1 LUNs (only if the failed disks were married to one pair).
- The Vraid 6 LUNs can withstand a simultaneous fail of two disks in each RSS, which means a total of six drives (two per RSS).
- The Vraid 1 LUNs can withstand a simultaneous fail of four disks in each RSS as long as no married pair is affected, which means a total of 12 drives (very unlikely but theoretically possible).
What I currently don't understand from the best practice whitepaper is the following part in the description of the RSS:
--snip-- The EVA can thus sustain multiple simultaneous disk failures while not losing user data, as long as no more than one disk per RSS fails with Vraid1 and Vraid5, and no more than two disks per RSS fails with Vraid6. --snap--
If I'm correct with my above thoughts about the RSS I think that the EVA actually can also sustain a loss of multiple disks with Vraid1 as long as no married pair is affected. So either the documentation is not completely accurate here or I am missing something.
Furthermore there's one last about the type of the disk group that I don't understand either:
--snip-- The original supported disk group type now referred to as basic, stores metadata in a Vraid1 format. A basic disk group will support Vraid0, Vraid1, and Vraid5 configurations. With the introduction of Vraid6, metadata has additional availability requirements. The new enhanced disk group type will store metadata in a double Vraid1 format and will support Vraid0, Vraid1, Vraid5, and Vraid6 configurations. --snap--
What is the storing of "metadata" in Vraid1 supposed to mean? Sounds like this is something different than the Vdisks.
no offense, but you can make many calculations how many disk drives you can lose without data loss. With creative thinking you can lose an amazing amount of disk drives without data loss...
... the problem is that you don't know in advance _which_ disks will go bad!
This is similar when discussing the MTBF (mean time between failure) of a disk drive. The value for a 'quality' one is quite high, but what does that mean to you, the end-user?
On a storage training we got told that the MTBF is really interesting for the manufacturer or a service provider. Based on the MTBF value they can calculate the number of spare parts they have to stock.
The value does not mean much for a specifc disk drive a user has. You could receive a disk DOA (dead on arrival) and it is still within the MTBF because that is just a statistical value across a whole manufacturing series.
I don't know what is meant by "stores metadata in a Vraid1 format". I have never heard that before -- is that a quote from some document?
What I learned is that the configuration information is stored on a maximum of 5 different disk drives [for some strange reason called the "quorum disks"] (if possible in different enclosures) in a disk group. Add a new group and part of the data moves from one disk to another disk in the new group. Add a 6th disk group and a 6th quorum disk is created.
Now, many, many, many, many details of the EVA are not published. I would not be surprised if my description above was a simplification.
I know that I can't protect from everything but that actually wasn't my concern with the question. The intention is to get some confirmation of an expert like you whether my thoughts are correct or wrong - so I know I understood the basics of EVA RSS/redundancy. If your time still allows it, I really would appreciate if you had a second look and give me a short feedback.
Regarding the "metadata in a Vraid1 format" - it indeed is also a quote from the "Best Practices" document (page 9):
Printable version
