Mailing List Archive

[no subject]
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters
Re: SnapMirror Bi-directional possible? [ In reply to ]
On 2018-07-24 23:35, Scott M Gelb via Toasters wrote:
> For the same data set, bi-directional, you might want to POC Peer Software.
> They PeerSync bi-directional and also have PeerLink which locks files on
> either side while keeping in sync. FPOLICY is used for real time event
> notification without file scans.

Locks files... Well, if you can live with that, then *maybe* it's viable.

But cumbersome and slow. Now, in many use cases w.r.t. NFS (which is what is
used by the Applications to *do* something with that data right?) the
problems which such locking incur can be devastating in practice. If it's
just some ppl browsing files manually, then sure -- go ahead.

But with many heavy application systems it's just not acceptable. So the
whole things falls over in any case. This might not be detectable in a PoC;
race conditions. It's a bogmire of ifs and buts.

In a way normal one-directional SM also "locks" (or rather, makes
not-available) files and dirs in the RO target volume. In a certain way. So
if you run applications intensely on the RO copy (target FlexVol) via NFS
there is always a short moment when inodes are shifted at the updates. This
is absolutely unavoidable, but what will happen to the App is then 'Stale
NFS file handle'. Ka-boom. So then you go into the complexity of trying to
asynchronously time the app chain to not run (in certain ways at least) at
the exact second(s) this shift inside the inode structure happens.

And then you give up. Been there, done that.

/M
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters
RE: SnapMirror Bi-directional possible? [ In reply to ]
Thanks all, for confirming that bi-directional SnapMirror on the *same* volume is not possible. We're still in the requirements gathering/planning part of the project, so we have some time to figure this out. This would be for keeping user profiles in sync between 2 different sites. I may take a look at that PeerSync software.

Eric

-----Original Message-----
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Michael Bergman
Sent: Tuesday, July 24, 2018 3:07 PM
To: Toasters <toasters@teaparty.net>
Subject: Re: SnapMirror Bi-directional possible?

On 2018-07-24 23:35, Scott M Gelb via Toasters wrote:
> For the same data set, bi-directional, you might want to POC Peer Software.
> They PeerSync bi-directional and also have PeerLink which locks files
> on either side while keeping in sync. FPOLICY is used for real time
> event notification without file scans.

Locks files... Well, if you can live with that, then *maybe* it's viable.

But cumbersome and slow. Now, in many use cases w.r.t. NFS (which is what is used by the Applications to *do* something with that data right?) the problems which such locking incur can be devastating in practice. If it's just some ppl browsing files manually, then sure -- go ahead.

But with many heavy application systems it's just not acceptable. So the whole things falls over in any case. This might not be detectable in a PoC; race conditions. It's a bogmire of ifs and buts.

In a way normal one-directional SM also "locks" (or rather, makes
not-available) files and dirs in the RO target volume. In a certain way. So if you run applications intensely on the RO copy (target FlexVol) via NFS there is always a short moment when inodes are shifted at the updates. This is absolutely unavoidable, but what will happen to the App is then 'Stale NFS file handle'. Ka-boom. So then you go into the complexity of trying to asynchronously time the app chain to not run (in certain ways at least) at the exact second(s) this shift inside the inode structure happens.

And then you give up. Been there, done that.

/M
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.teaparty.net_mailman_listinfo_toasters&d=DwICAg&c=n6-cguzQvX_tUIrZOS_4Og&r=h6vm_U-QjJzaJVBWrJgENg&m=a_Y39R6Z-Ia3wQLBBWB9e31aIa9njsGt89Auv32KkTk&s=0c6YVdesBUeGO-ndK0xSTodqdPIlqFDNnAxsDSli0WY&e=

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters
[no subject] [ In reply to ]
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters