iainbalmer, Q:  the volume is spread across a maximum of 3 members - can it be easily identified exactly what members? A: Yes, in the GUI, select the volume and on the Status Tab, see the “Volume Distribution” section.  You can also see this in the CLI (command line interface).  The command is: Volume select [volume_name] show members (download the CLI command reference for more commands). Q: When we upgrade firmware - we add a spare member into the group, evict the victim of the firmware upgrade, do the upgrade, then classify this as the new spare, and the process rolls on. A:  Yes, your method is time consuming but safe, the down side is you are always deleting a member from the group (this takes time). In the EqualLogic Support KB we have instructions for doing a “Rolling Update”.  This method doesn’t require a spare member, instead, it requires that the multi member group has enough free space in the group on the remaining members to hold the data of the member being updated.  With this method, you would move a member to an temporary update pool, this will force the volumes to move to the remaining members, once the volumes are moved off the member, you then do the update, restart the member and move it back into the production pool.  This is also time consuming but would take less time than your method (only vacates volumes, not the whole member), but is very safe as well. Q: is the firmware process as robust as it should be that it can be done live in a group. A: Yes, other options is the standard “in place” update.  However this requires that all Hosts have the proper settings for the iSCSI disk timeouts (see the document “iSCSI Initiator and Operating System Considerations” on every FW download page).  You do the update during low I/O times or planned outage.  The key to this method, is test first since some host may require longer iSCSI disk timeout values, especially for VM’s (100’s that are all trying to reconnect to the same arrays at the same time). Regards, Joe
Just a query, I've inherited a few groups of EQ's, PS6510's.  And they are all configured into groups of at least 4 members.   My question is, should one Member fail - it seems I can't access any volumes within that group, despite the one member being a small percentage of the group.  I realise that the EQ's have dual controllers and 3 power supplies, but if the box does go bang (like it has) does this mean basically I'm stuffed?  Is there no stretched parity on the volumes across members? If this is the case, could anyone advise on best practice for dealing with multiple Members. I can only imagine we have say 5 volumes in a group, with the critical volumes replicated to another group.  This way I can guarantee no data loss as much as I can - but it seems like a helluva lot of kit being utilised, for something that should be now industry standard? Thanks in advance.
Group Resilience