Richard Siemers wrote:
So 3PAR has a concept of consistency groups, and does take consistent group snaps of volumes (at the source) for periodic replication... your issue with it is that if the periodic replication update fails for whatever reason, it won't roll back the remote group to the last good copy. I misunderstood your original post, I thought you meant they had no consistency feature at all.
To your point, if the customer broke away from using the built in replication scheduler, and wrote their own scripts, could they not mitigate that issue by taking a snapshot of the remote replica before starting the group periodic update? Then delete the snap after successful replication?
That is what we are doing. We are basically taking snapshots of all base volumes on the destination and present those to hosts. We map RC Groups to VVSets and then have a script that watches the date/time of the replicated base volumes, when all of those ina VVSet/RCGroup pair are newer than the exported snapshots AND none of the volumes are replicating we then updateVV against the VVSet. There is a lot of error checking I am adding to catch scenarios with high frequency replication intervals. It is a huge resource drain to write and manage these and not fool proof.
Not to mention with almost 200 RC Groups the CLI load is heavy.
In the end 3par replication has not lived up to our expectation and in hindsight we should have done a more thorough due diligence before selecting our storage technology.