Thanks Shankar - that was the bit I was looking for. Vic
> On 19 Apr 2016, at 12:07, Shankar Balasubramanian <[email protected]> wrote: > > You can disable snapshots creation on DR by simply disabling RPO feature on > DR. > > > Best Regards, > Shankar Balasubramanian > AFM & Async DR Development > IBM Systems > Bangalore - Embassy Golf Links > India > > > > > > From: Vic Cornell <[email protected]> > To: gpfsug main discussion list <[email protected]> > Date: 04/19/2016 04:34 PM > Subject: Re: [gpfsug-discuss] AFM Question > Sent by: [email protected] > > > > Thanks Luke, > > The whole business of “promoting” a cache from one type to another isn’t > documented very well in the places that I am looking. I would be grateful to > anyone with more info to share. > > I am in the process of investigating Async DR for new customers. It would > just be useful to see what can be done with existing ones who have no > interest in upgrading. > > Also Async DR means that I have to create snapshots (and worse delete them) > on the “working” side of a replication pair and this is something I’m not in > a tearing hurry to do. > > > Regards, > > Vic > > On 19 Apr 2016, at 11:46, Luke Raimbach <[email protected] > <mailto:[email protected]>> wrote: > > Hi Shankar, Vic, > > Would it not be possible, once the original cache site is useable, to bring > it up in local-update mode so that you can pre-fetch all the metadata from > home? > > Once you are ready to do the switchover: stop writing to home, do a final > sync of metadata, then “promote” the local-update cache to a single-writer; > continue writing new data in to the original cache. > > I am assuming the only reason you’d want to repopulate the SW cache with > metadata is to prevent someone accidentally creating the same file after the > disaster and overwriting the original at home without any knowledge? > > Cheers, > Luke. > <> > From: [email protected] > <mailto:[email protected]>[mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Shankar > Balasubramanian > Sent: 19 April 2016 06:47 > To: gpfsug main discussion list <[email protected] > <mailto:[email protected]>> > Subject: Re: [gpfsug-discuss] AFM Question > > SW mode does not support failover. IW does, so this will not work. > > > Best Regards, > Shankar Balasubramanian > AFM & Async DR Development > IBM Systems > Bangalore - Embassy Golf Links > India > > > > > > From: Vic Cornell <[email protected] <mailto:[email protected]>> > To: gpfsug main discussion list <[email protected] > <mailto:[email protected]>> > Date: 04/18/2016 07:13 PM > Subject: [gpfsug-discuss] AFM Question > Sent by: [email protected] > <mailto:[email protected]> > > > > > Hi All, > Is there a bandwidth efficient way (downtime is allowed) to reverse the > relationship between HOME and CACHE in a single writer AFM relationship? > > If it is not immediately obvious why this might be useful, see the following > scenario: > > Fileset A is a GPFS fileset which is acting as CACHE for a single writer HOME > on fileset B located on a separate filesystem. > > The system hosting A fails and all data on fileset A is lost. > > Admin uses fileset B as a recovery volume and users read and write data to B > until the system hosting A is recovered, albeit without data. > > Admin uses mmafmctl to “failover” AFM relationship to a new fileset on A, all > data are copied from B to A over time and users continue to access the data > via B. > > So is there a bandwidth efficient way (downtime is allowed) to reverse the > relationship between A and B such that the replication flow is as it was to > start with? > > Cheers, > > Vic > _______________________________________________ > gpfsug-discuss mailing list > gpfsug-discuss at spectrumscale.org <http://spectrumscale.org/> > http://gpfsug.org/mailman/listinfo/gpfsug-discuss > <http://gpfsug.org/mailman/listinfo/gpfsug-discuss> > The Francis Crick Institute Limited is a registered charity in England and > Wales no. 1140062 and a company registered in England and Wales no. 06885462, > with its registered office at 215 Euston Road, London NW1 2BE. > > _______________________________________________ > gpfsug-discuss mailing list > gpfsug-discuss at spectrumscale.org <http://spectrumscale.org/> > http://gpfsug.org/mailman/listinfo/gpfsug-discuss > <http://gpfsug.org/mailman/listinfo/gpfsug-discuss> > _______________________________________________ > gpfsug-discuss mailing list > gpfsug-discuss at spectrumscale.org > http://gpfsug.org/mailman/listinfo/gpfsug-discuss > <http://gpfsug.org/mailman/listinfo/gpfsug-discuss> > > > _______________________________________________ > gpfsug-discuss mailing list > gpfsug-discuss at spectrumscale.org > http://gpfsug.org/mailman/listinfo/gpfsug-discuss >
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
