[gpfsug-discuss] AFM Question

Vic Cornell viccornell at gmail.com
Tue Apr 19 12:04:31 BST 2016


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 <Luke.Raimbach at crick.ac.uk> 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: gpfsug-discuss-bounces at spectrumscale.org <mailto:gpfsug-discuss-bounces at spectrumscale.org> [mailto:gpfsug-discuss-bounces at spectrumscale.org <mailto:gpfsug-discuss-bounces at spectrumscale.org>] On Behalf Of Shankar Balasubramanian
> Sent: 19 April 2016 06:47
> To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org <mailto:gpfsug-discuss at spectrumscale.org>>
> 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 <viccornell at gmail.com <mailto:viccornell at gmail.com>>
> To:        gpfsug main discussion list <gpfsug-discuss at spectrumscale.org <mailto:gpfsug-discuss at spectrumscale.org>>
> Date:        04/18/2016 07:13 PM
> Subject:        [gpfsug-discuss] AFM Question
> Sent by:        gpfsug-discuss-bounces at spectrumscale.org <mailto:gpfsug-discuss-bounces at spectrumscale.org>
> 
> 
> 
> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss/attachments/20160419/4d1916d5/attachment.html>


More information about the gpfsug-discuss mailing list