HPE Storage Users Group

Seems RC needs a lot of work. Had another call with Product team they can't even agree among themselves how it is supposed to work.

Consistency is guaranteed , with Periodic mode Volumes that fail to complete a resync will be promoted (reverted back to snapshot) volumes that didn't fail will be left as is. This means that following the volume promotion the RC group will not appear consistent. However the group will become consistent when the user completes either of the following actions.


1. Assuming this is a DR failover scenario - Executes a ‘failover’ operation on the secondary array, at which time ALL the volumes in the consistency group are promoted (reverted back to previous snapshots and made consistent).
2. Assuming this is transitory failure - The user restarts the consistency group and allows the re synchronization operation to complete successfully.

The reasons for this behavior are :-

1. Promotes take time to complete across large consistency groups with big delta's and until all the promotes have completed the group cannot be restarted, so unless you are initiating failover i.e this isn't just a link outage there's little point in going through the promotion (reverting) of all volumes to the previous snapshot.
2. If the system were to automatically promote all the volumes before failover were initiated by the user this would just mean having to needlessly resync all of the previously successfully synced volumes again once the group gets restarted, wasting both bandwidth and time.

This is really describing an edge case where connectivity is lost during a sync and could be documented better, but what it means is if a sync fails due to the primary array going offline or the links going down part way through the sync the remote volumes will remain read only and you won't have a consistent view. Until that is, you initiate failover, at which point they will ALL be promoted and made read / writeable at the remote site.

Checked and this is now documented correctly in the current Remote Copy guide (August 2013)

FYI patch was released for the RC issue with large VLUNs and seems to have fixed our issue.

Have you got a patch number for that patch?

P21

Cleanur wrote:Consistency is guaranteed , with Periodic mode Volumes that fail to complete a resync will be promoted (reverted back to snapshot) volumes that didn't fail will be left as is. This means that following the volume promotion the RC group will not appear consistent. However the group will become consistent when the user completes either of the following actions.


1. Assuming this is a DR failover scenario - Executes a ‘failover’ operation on the secondary array, at which time ALL the volumes in the consistency group are promoted (reverted back to previous snapshots and made consistent).
2. Assuming this is transitory failure - The user restarts the consistency group and allows the re synchronization operation to complete successfully.

The reasons for this behavior are :-

1. Promotes take time to complete across large consistency groups with big delta's and until all the promotes have completed the group cannot be restarted, so unless you are initiating failover i.e this isn't just a link outage there's little point in going through the promotion (reverting) of all volumes to the previous snapshot.
2. If the system were to automatically promote all the volumes before failover were initiated by the user this would just mean having to needlessly resync all of the previously successfully synced volumes again once the group gets restarted, wasting both bandwidth and time.

This is really describing an edge case where connectivity is lost during a sync and could be documented better, but what it means is if a sync fails due to the primary array going offline or the links going down part way through the sync the remote volumes will remain read only and you won't have a consistent view. Until that is, you initiate failover, at which point they will ALL be promoted and made read / writeable at the remote site.

Checked and this is now documented correctly in the current Remote Copy guide (August 2013)

So find me a complex system, particularly databases (SQL, Oracle), that will handle some of their volumes being older than others? We replicate dozens of Oracle and SQL systems and this some volumes roll back and other don't creates chaos with all of our databases as well as other paps that have data across multiple volumes.

reread my message, the volumes are not guaranteed consistent until you hit failover in the RC group at which point they are all promoted back to the same point in time.

For DR this isn't an issue as you would always issue a failover and the volumes would be made consistent. However if you were looking to mount the remote copy for backup or data mining etc without using the failover command, then the volumes may not be consistent since some may still be replicating whilst others will have finished (depends on the delta).

If you need that then sync replication or the recovery manager products would be the way to go.

Cleanur wrote:reread my message, the volumes are not guaranteed consistent until you hit failover in the RC group at which point they are all promoted back to the same point in time.

For DR this isn't an issue as you would always issue a failover and the volumes would be made consistent. However if you were looking to mount the remote copy for backup or data mining etc without using the failover command, then the volumes may not be consistent since some may still be replicating whilst others will have finished (depends on the delta).

If you need that then sync replication or the recovery manager products would be the way to go.

Sync is too expensive and not valid for long distances. Also We tried the Recovery Manager products, started with RM-V and found it very laggy, buggy and did not scale.

I'm curious if the concurrent synchronization limit is in effect in 3.1.3. I see the limit listed in 3.1.1, but not in the newer user guides.

I know of no plan to remove the 20 concurrent volume limit for Periodic replication to the point that after month of discussion with HP we are buying a second array to overcome that issue. We can not be limited by 20 replication slots for the number of volumes we replicate (over 600) causes a nightmare for the number of volumes we have that need to replicate every 15 minutes.