SyncIQ Copy issues...

Question

I'll probably need EMC engineering on this but...here's the issue.

Customer wants SyncIQ Copy (not failover, just a BACKUP copy).
Source Cluster is connected to ECS, so there will be pointers to cloud data on both sites.
Customer wants at some point to be able to map to the backup share and delete older data if they want and access it.

In testing we copied their test data to the Source, clouded the data off and then ran SyncIQ Copy...

SyncIQ Copy works fine. We can access cloud data on both sites. The issue we run into is if we have to break Sync for any reason. The data on the backup doesn't end up being read/write as it should. Its just a COPY of the data. If we needed to break sync OR if the source is unavailable and the customer needs to go to the backup copy and get data, drop off files, etc -- they can't. Everything is read only. Can't even create a new folder (probably shouldn't need to but that was part of testing).

From a logical standpoint, I understand people are going to say "Why not just use SyncIQ and failover/failback?!" They don't need/want to be able to failover. They want a BACKUP solution but still want to be able to get to that data and manipulate it if in a very rare case something goes haywire with the source.

In testing we've found if for some reason the customer deletes a file on the source and creates a new file of the same name, it overwrites the data on the target. I can see why they shouldn't do that, but they might and I do understand exactly why it overwrites data with the same name on the target. We should be telling them "Uhhh, just don't do that!" but you know someone will eventually do it. The point of using backup for SyncIQ is to make sure we have a copy so this presents an issue if not clearly defined.

Peter_Sero · Answer

Brian, only one cluster can write to a given CloudPool target at one point in time.

So you have to transfer the write permission from the primary to the backup cluster

in order to make the backup writable.

This paper

ISILON CLOUDPOOLS AND ELASTIC CLOUD STORAGE

shows on pp37 how it is done, as step 2 of a procedure where step 1 is a formal failover.

Frankly I don't know wether it makes sense to replace step 1 by merely breaking the sync.

What's the problem with doing a proper failover?

Want to keep both clusters writable? Not possible with CloudPools, by design.

Don't want to touch DNS to redirect clients? Not needed, from the Isilon perspective,

if it's okay to have most clients disconnected or on halt, and only manually reconnect

a few clients to the backup cluster.

Not clear how your last observation is connected to the SyncIQ & CloudPools question.

Cheers

-- Peter

Brian_Coulombe_ · Answer

>>Brian, only one cluster can write to a given CloudPool target at one point in time.

Hi Peter and yes, correct!

>>So you have to transfer the write permission from the primary to the backup cluster in order to make the backup
>>writable.

Ok fair enough, the permissions should be coming over from SyncIQ Copy but if not, I have to rethink what we're doing.

>>This paper

>>ISILON CLOUDPOOLS AND ELASTIC CLOUD STORAGE

>>shows on pp37 how it is done, as step 2 of a procedure where step 1 is a formal failover.

>>Frankly I don't know wether it makes sense to replace step 1 by merely breaking the sync

I'll read up on that section.

>>What's the problem with doing a proper failover?

Our customer only wants backup online to Isilon, not SyncIQ failover/failback. Failover is not needed.

>>Want to keep both clusters writable? Not possible with CloudPools, by design.

That I know.

>>Don't want to touch DNS to redirect clients? Not needed, from the Isilon perspective,

>>if it's okay to have most clients disconnected or on halt, and only manually reconnect

>>a few clients to the backup cluster.

They want the ability to go to the COPIED data on the TARGET cluster and delete very old data rather than worry about increasing the quota. That's why I am trying to figure out if this is even possible.

>>Not clear how your last observation is connected to the SyncIQ & CloudPools question.

Because on the source, the data will be Cloupooled off and the pointers will go to the BACKUP Isilon target. We've tested this and it works just fine. We are just not seeing a way to make the BACKUP side r/w temporarily to delete data in case the customer wants to do that. We are not using a Failover/Failback solution here, just BACKUP/ACCESS/DELETE option.

If not possible, no worries. I was trying to find out if it was even possible.

Isilon

SyncIQ Copy issues...

Was this post helpful?