Re: Remote Copy
Posted: Wed Mar 19, 2014 11:35 am
Does that limit exist for both synch and asynch?
Page 3 of 3
Re: Remote Copy
Posted: Wed Mar 19, 2014 2:41 pm
Sync should be a different animal since it is replicating IO in real time and will not acknowledge the IO until the destination has acknowledged it. The current OS only has Sync and Periodic.
Re: Remote Copy
Posted: Wed Mar 19, 2014 2:50 pm
I think I follow. If synch doesn't have the concurrent sessions limit, should we just go that route? Does it create issues with app consistency? You'll have to forgive my ignorance, as I am currently investigating the platform. 
We haven't purchased anything at this point 
We haven't purchased anything at this point Re: Remote Copy
Posted: Wed Mar 19, 2014 6:00 pm
Sync is real time and therefore guarantees the identical data exists in both sites at any point in time, but as with all synchronous solutions you need low latency links and good bandwidth, so distance between sites is typically limited.
Periodic async as the name implies resyncs between sites from snapshot deltas periodically, the update process today has a maximum number of threads assigned to the resync queue, so if you have large RC consistency groups, at a given point in time some volumes can be up to date on the remote site whilst others are still updating. This depends on the number of volumes, size of the groups, the deltas between snaps and the link bandwidth between sites etc. This sounds pretty bad but the system is designed to provide guaranteed consistency when used as designed as a DR solution, but there can be other use cases where this can cause issues......see below.
For DR purposes this isn't really an issue since once you initiate failover all of the volumes in a given RC group are rolled back (promoted) to the groups last consistency point, providing a true consistent point in time view of all volumes within the failed over RC group. However if you're trying to snap and mount the remote volumes for testing, backup etc then you bypass the failover step and the subsequent roll back (promote), so there's no guarantee of a consistent view across the entire RC group. This is because the user initiated remote snap has no knowledge of the ongoing resync, as such it will simply capture the exact point in time requested and the resync process may still be ongoing for some volumes at that particular point in time.
Because of this lack of coordination, using this method for non DR e.g remote backup or testing etc whilst replication is ongoing typically requires some amount of scripting. This is required to provide additional logic to ensure replication has completed across the entire group before you take and mount the snaps for use in the remote site. This use case isn't really part of Periodic Async's design brief, its intended for replication and DR over relatively poor links and long distanced, hence the need to add your own logic for other use cases. The above is how it's implemented today and as stated it meets the intended design goal, but as with most features the current functionality isn't necessarily set in stone.
Alternatively you can use the Recovery Manager products to drive the RC resync process and coordinate the remote snaps to provide true application consistent copies at the remote site.
Hope that makes sense.
Periodic async as the name implies resyncs between sites from snapshot deltas periodically, the update process today has a maximum number of threads assigned to the resync queue, so if you have large RC consistency groups, at a given point in time some volumes can be up to date on the remote site whilst others are still updating. This depends on the number of volumes, size of the groups, the deltas between snaps and the link bandwidth between sites etc. This sounds pretty bad but the system is designed to provide guaranteed consistency when used as designed as a DR solution, but there can be other use cases where this can cause issues......see below.
For DR purposes this isn't really an issue since once you initiate failover all of the volumes in a given RC group are rolled back (promoted) to the groups last consistency point, providing a true consistent point in time view of all volumes within the failed over RC group. However if you're trying to snap and mount the remote volumes for testing, backup etc then you bypass the failover step and the subsequent roll back (promote), so there's no guarantee of a consistent view across the entire RC group. This is because the user initiated remote snap has no knowledge of the ongoing resync, as such it will simply capture the exact point in time requested and the resync process may still be ongoing for some volumes at that particular point in time.
Because of this lack of coordination, using this method for non DR e.g remote backup or testing etc whilst replication is ongoing typically requires some amount of scripting. This is required to provide additional logic to ensure replication has completed across the entire group before you take and mount the snaps for use in the remote site. This use case isn't really part of Periodic Async's design brief, its intended for replication and DR over relatively poor links and long distanced, hence the need to add your own logic for other use cases. The above is how it's implemented today and as stated it meets the intended design goal, but as with most features the current functionality isn't necessarily set in stone.
Alternatively you can use the Recovery Manager products to drive the RC resync process and coordinate the remote snaps to provide true application consistent copies at the remote site.
Hope that makes sense.