SyncIQ fan out or cascade

Please consider moving this question as-is (no need to recreate) to the proper forum for maximum visibility.  Questions written to the users' own "Discussions" space don't get the same amount of attention and can go unanswered for a long time.

You can do so by selecting "Move" under ACTIONS along the upper-right.  Then search for and select: "Isilon Support Forum".

Isilon Support Forum

Yes, here are the official statements regarding your inquiries:

1) fan-out/one-to-many (A -> B, and A -> C): supported

Keep in mind that you will be limited by the following maximums on cluster "A" which is now shared between two clusters (in other words the maximums don't double because you have 2 separate target clusters):

a) maximum 5 sessions running simultaneously

b) maximum 40 workers per session (per session maximum 8 workers per node)

c) maximum 200 workers total running at a time

2) cascading (A -> B -> C): you are able to configure it (the official word as I understand it is that it isn't entirely supported) with several requirements:

a) You will have to manage it so that A -> B and B -> C can *not* be running simultaneously; one must finish before the other is started.  This will of course increase your RPO.

b) This implies that you either need to manually start them or you schedule them far enough apart which may be difficult as change rate is often not constant.  Also variations in consumed cluster and/or networking resources will of course affect the time it takes to complete a refresh.

c) Also, on the cluster B, before you start B -> C (after A -> B completes) you will need to delete or rename a file: .tmp-working-dir (it will warn you).  Keep in mind though that the directory on cluster B will be in R/O mode so you will have to make it (temporarily) writable to be able to do so.

- With v7.0 and the introduction of the local target option: "Make writable" this would allow you to do so (without having to restart A -> B with a full copy or doing a diff-sync). 

- However, if cluster B is running v6.5, it only has the option for the local target to "Break".  That would mean that a refresh from A -> B you will be running a diff-sync to copy just the changes since it last ran.

Just a few things to keep in mind in particular with cascading.

Christopher,

I understand that is possible from a ONEFSCluster to treplicate via SyncIQ to many cluster, but I'm not sure if the same FileSystem can be replicated to different clusters concurrrently. Or a single FS can be replicated only on one destination?

Flavio

Flaviovarriale wrote: Christopher, I'm not sure if the same FileSystem can be replicated to different clusters concurrrently. Or a single FS can be replicated only on one destination?

Yes, in a one-to-many configuration, the same directory (you mention FS but I know what you mean) can be concurrently replicating to more than one cluster.  It is in the cascading configuration (A -> B -> C where B is a target directory for A and then that same directory is a source for C) that you have to worry about any locking and timing as mentioned above.

Hi,

knowing the limitations stated by Christopher  - how does SyncIQ behave with continuous replication introduced with OneFS 7.1 ?

so what happens if I have the following cascading setup:

1) A - continuous replication -> B - continuous replication -> C

2) A - continuous replication -> B - scheduled replication -> C

can the replications run simultaneous?

does it cause "tmp-working-dir" events?

Rob,

any issues with running policies A>B and A>C concurrently ?

Thanks

Of course, if there is no possible path between A and C, one must do otherwise.  I would only say in this day and age, it's hard to imagine no connectivity between any given two sites of an enterprise.  Ethernet ports are quite inexpensive, especially compared to the lack thereof and the impact on operations.

Nonetheless, should you find yourself in this situation, cascading is possible but you must be diligent in scheduling SIQ jobs to never overlap.  Doing this with A->B in continuous (10-second) mode is a practical impossibility.  Just managing the tmp-working-dir as above is, as the kids say, a PITA and not trivial to automate.

Best of luck in any event -

Rob

None whatsoever.  In fact there is a slight benefit from read caching effects when running two SIQ jobs in parallel.  The only thing to be cognizant of is bandwidth consumed and the SIQ parallel job limit, but running two is no problem for the latter.

Hi Rob,

thanks for the answer - but I have to disagree. There are scenarios where a cascaded replication is reasonable.

Think about having two CEs (Customer Edge) for the WAN access

- one for Cluster A (active)

- one for Cluster B (standby)

and Cluster C (standby) on a Remote site with a separate CE

BUT you have a dedicated LAN connection between Cluster A and Cluster B. Since you use one CE actively for userinteraction you don't want to double the traffic on that CE you use the other one (the one for Cluster B) for your replication traffic.

given specific needs for FSN and throughput and a small node-per-cluster relation you run short on eth-ports

try to implement your cascade, in a way where the replications nearly don't interfere so that B->C is done when A->B starts and vis versa

That's the only possibility i know to lower the amount of tickets / alerts in a cascaded replication.