EVA: Rearrange disks when adding new enclosure?

[CA1203921]

We have an EVA 5000 that came originally with 6 enclosures, fully populated with disks. These disks are divided in into two disk groups.

Now we are going to add 2 new enclosures, but these enclosures have only 4 disks each.

I know the best practice is to distribute disks evenly across all enclosures. Whe have the opportunity to shut down the EVA, and re-arrange the existing disks to use all 8 enclosures so that we have the same amount of disks per enclosure. But is this recommended, or is it better to just leave the new enclosures with their 4 disks each, and the old enclosures fully populated?

My concern is that by moving around the disks the RSS's are going to be disarranged and perhaps causing more problems than benefits.

Any suggestions?

Thank you!

[Uwe Zessin]

You are right that one should not blindly move disks around, but it absolutely makes sense to redistribute now that you have 8 enclosures. You need to take care about the disk's RSS and their index number to make sure that paired disks do not end up in the same enclosure.

[BR788742]

Hello,

Uwe wrote that it is possible to "destroy" RSS by putting paired disks on the same shelf. My question is: Disks with which RSSID are paired? 0-1 2-3 etc... or 0-2 1-3 etc...?
Regards - Tomasz

[Uwe Zessin]

No, I don't think I wrote that. I have no idea what you mean by 'destroy'.

From what I can tell, paired disks are 0-1, 2-3, ...

[BR788742]

Uwe,
I have EVA5000 2C12D with 56 72GB disks and 96 32GB disks.All disks are distributed equally (as possible) in all shelves, I use only Raid1 Vdisks.
When I started with this configuration the RSS level was ???Mirrored???. Today, after some removing and adding physical disks and creating and deleting Vdisks RSS level is ???None"... I think that moving disks "destroyed" some RSS (paired disks are now in single shelf). I need to find such "destroyed" RSSs - maybe if I ungroup disks from them I get "Mirrored" RSS level.
Take a look at attachment - I'm little supprised with RSS 8 - it has strange RSS indexes - 0,1,2,3,6,7,8,9. I need to write some script to find RSSs with two or more disks on the same

[Uwe Zessin]

Ah, understood. I thought that 'destroy' meant loss of data.

I have a low-priority project to analyze EVA configurations and one part of this is an RSS checker, but I am missing real life test data.

Let's make a deal:
run the attached commands, put them into a .TXT file, attach to a response and I will see what I can find out.

[BR788742]

Ok, I will...

But in a meanwhile please take a look at this RSS:

72 12 0 12 7
147 12 1 10 7
146 12 2 11 7
154 12 3 5 7
134 12 4 2 9
157 12 5 2 10
52 12 6 1 5
27 12 7 6 5

(disk,RSSid,rssidx,shelf,bay). I think, that two disk 134 and 157 should be a pair and they are in the same shelf (2). I think it is wrong.

[Uwe Zessin]

I agree.

[BR788742]

I was right!
I just ungrouped two suspected disks and RSS level is now "Mirrored".
I'll send you config file after finishing migration

[BR788742]

Hi,

here is config file from my EVA after ungrouping disks and data leveling.

/T

[Uwe Zessin]

Thanks, I'll take a look at it. Please have a bit of patience, because:

- it's a spare time project
- I have to adapt to the output of this version SSSU
-- every one is a little different :-(

But, hey, that's why I was asking for more data ;-)

[BR788742]

Ok - thanks.

BTW... we are fighting against Clariion 700 - one of the test is removing one shelf. I'm sure it will kill Clariion with his 5 vital disks in shelf 0 and this is why I needed "Mirrored" RSS in EVA. I HOPE that disconecting one shelf will not kill EVA with "Mirored" RSS and Raid1 Vdisks - wish me good luck :)

/T

[Uwe Zessin]

Ok, had a few minutes, so here is what I could get so far (there is a problem properly detecting the bounds, but that has to do with a different SSSU output and is not your fault).

You'll see a list of all RSS's and where each index is located. You are at mirror state already, but I can't analyze for parity state, because the code is not there, yet. (for example: E11:B04 and E11:B09 belong to the same RSS:003).

It looks like you are not current on disk drive firmware revisions. The column 'NewFW' gives the level for VCS 3.020 and 3.025

Next is the physical layout. It would be nice if you could check a few disks against this picture, because I wasn't able to verify the code on a larger configuration, yet. Thanks!

Is there something special with 'Disk 172'? This disk is ungrouped (like 'Disk 134'), but it's RSS information is reported as 'n/a' while the other disk uses '0'.


The output, by the way, is a nice example to demonstrate the virtualization. Although you have disks of different sizes in the same group, all of them show more or less the same utilization.

[Uwe Zessin]

Tomasz,
attached is a minor update. Implementing the parity state check was easier than I thought and I was able to worm around some parsing problems. Hope you find it useful - have a nice weekend!

[BR788742]

Thank you!

I tried to analyze my configuration and got the same conclusions about RSSs with no "parity" level. During tests i will not use RAID5 - Parity level seems not to be an issue. Please tell me if you have any experience with "failed shelf" - I think that my EVA should survive turning off any shelf. Today I did such a test on Clariion - EMC guys were sure that it will survive - they created vols in such way to not have mirrored disks in one shelf (two engeneers, two hours of work). I turned off shelf 0 - guess what happened... we lost access to all volumes, hung both controllers and got "dirty cache" errors on all vols... It wasn't better after rebooting Clariion - EMC told us that it is hard to "repair" cache errors and they suggest to recreate all vols... We lost all data... Now i'm preparing DoS attack on Clariion. Fast ethernet cards in both controllers should help me:)


/T