EMC Invista EVA6000 & EVA6100 Queue-Full

[Stephan Stein]

Hi guys!
in our environment we run an storage-virtualization from emc named "invista" with 2 EVAs 6000 and 6100.
The EMC Solution based on 4 Cisco-FC-Switches with 2 intelligent Modules.
We have configured 7 virtual volumes on the invista. This will be mirrored to both eva's and presented agains the front-end (VMWare-Cluster).
Take a look at the attachment.

Everything is fine till the eva's get a high payload from the front-end.If it is, the invista get an "Queue-Full(28h)" and sometimes the configured mirrors goes down! In this case the invista starts an re-sync.
This operation does not speed up the performance of the virtual disk array and takes approximately 24 hours.

The invsita make round-robin to the back-end evas. So on hight I/O must be heavy load on the eva controller. In my opinion the eva controller have to route many I/O's through "mirror-port" to the "preferred copntroller" of the aim-volume. if there is to much I/O's the eva sends Queue-Full(28h). This trigger we only could get with an fiberchanel-analyzer.
So the protocol shows the fc-reply of the eva:


<1> <000:23:00.872_861_230> <1,1,3 / 1,1,4> <14>

Is there possibility to fix this issue?

- Setup the "Host Properties" on the EVA, like "Operating System" or else..?
- configure Controllers..?

[Bill Costigan]

Just my 2 cents, but I would look at the configuration options on the invista. I doubt the mirror-port is the root of the problem, but I would think the invista could be configured to only use the ports on the perferred controller unless that controller went down.

If the write load is high and the primary EVA is faster than the secondary EVA (e.g. more spindles in the disk group) then it is easy to see that the secondary EVA may not be able to keep up. At this point the invista has three option (don't know if it supports these options or not)
1. stop writing to the mirror and resync later (best performance for application)
2. throttle the writes from the application to match the speed of the slowest mirror.
3. Buffer the writes to the mirror and send them later (async mirroring - of course this would require storage on the invista would it may not have)