EVA 5000 disk installation

[AIMC]

Hi All,

My customer has an EVA5K with 4 new shelves (total 8), they have added 2 disks to each new shelf but in bays 13 & 14, subsequently 2 of these disks were grouped. They are now experiencing hundreds of loop errors & have had 2 9000 servers grind to a hault when they extended into this new space.

Question:

Do you need a disk in bay 1 of an enclosure to address an enclosure properly, or for any other reason?

Regards,

Aidan

[Uwe Zessin]

No, the requirement is for a minimum of 4 disk drives per enclosure. It's possible that there are other back-end errors.

Is this EVA missing the loop switches? I thought they were mandatory with 6 and more disk drive enclosures.

[AIMC]

Hi Uwe,

The loop switches are installed, but there have been alot of loop related errors relating to these disks since they were installed. None of the disks are failed & only 2 of them are grouped. I have conflicting views from people who say that a disk is required in bay 1 for emu reasons but i'm wondering is there anything deeper than this. Also do you think that 2 disks in a shelf instead of 4 would cause problems?

Thanks,

Aidan

[Uwe Zessin]

Hello Aidan,

I am aware of several EVAs (although not 5000s) that happily work with no disk drive in bay 1. Technically, the EVA needs at least one per enclosure, because it uses a disk drive (left most one) to talk to the EMU.

For a *supported* configuration, you do need 4 disk drives per enclosure. It's been that way since day 1 and it has not changed (I have asked from time to time).

Is the EVA running on current firmware levels? How old is the system? I know that very old disk drive enclosures had problems with I/O modules - it's possible that a different load does trigger a problem that has always been there or an unrelated disk drive has started to cause troubles. Can you get somebody to analyze the EVA logs?

[AIMC]

Hi Uwe,

I have had the logs analysed but there is nothing to indicate a probem on the EVA, also there are approximately 20 other hosts connected to this EVA that have had no problems at all, it just seems that when the customer extends a logical volume into the disk space added recently (FATA disks) the server grinds to a hault but the EVA is fine, i will investigate the server end aswell but just thought somebody may have seen something similar due to a config problem on the EVA.

Thanks again.

Aidan

[Uwe Zessin]

Huh? Once you put a disk drive into the disk group, the EVA redistributes the existing data onto the new disks - is this what causes the problems?

[AIMC]

Hi Uwe, just had the customer check some things on the servers & i've found that secure path is not set up for load balancing & autorestore is not turned on, there are a couple of databases & a few hundred GB of disk mounted on the server so i think this has a performance impact & maybe the lvextend brought it to a stand still? Would you agree? I think i will try the same procedure on a test server & if it works ok i think the servers are the problem.

Aidan

[Mike Reznak]

Hi,

I've consulted it with HP guy and he said, that the best practice is to put the first disk into first slot. In simple way said - EMU communicates allways with that slot first and if it doesn't find the disk there, it generates error message and tries another slot.

Mike

[Uwe Zessin]

But a Secure Path autorestore does only happen when there was a path failure and it got repaired, no? An autorestore can cause an ownership transfer of virtual disks from one controller to the other. This requires flushing the cache memory and causes a performance impact. So people typically leave autorestore off and do a manual failback when it suits them.

[AIMC]

Its not the autorestore that i think would have a performance impact its the load balancing turned off, all i/o to the EVA is going down 1 channel, 6 luns with a few databases. I agree that autorestore should be left off in most cases.