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
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...
You could look at metrocluster, potentially
Sent from my mobile phone
On Jul 24, 2018, at 5:53 PM, Eric Peng epeng@esri.com wrote:
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...
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
It sounds like you won't need file locking with a user in one location at a time, and agreed it adds overhead.
On Tuesday, July 24, 2018, 6:01:52 PM CDT, Eric Peng epeng@esri.com wrote:
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...
_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
"Eric" == Eric Peng epeng@esri.com writes:
Eric> Thanks all, for confirming that bi-directional SnapMirror on the Eric> *same* volume is not possible. We're still in the requirements Eric> gathering/planning part of the project, so we have some time to Eric> figure this out. This would be for keeping user profiles in Eric> sync between 2 different sites. I may take a look at that Eric> PeerSync software.
Hmm... if a user is logged into one site, will they be logged into another site at the same time? Maybe you just do robocopy once an hour to bring them all in sync, with last written winning?
Or, since profiles should be small, can you simply share the CIFS share holding the profiles across the WAN from the main site to the remote site?
-
Eric Peng -
John Stoffel -
Michael Bergman -
Mike Gossett -
Scott M Gelb