[gpfsug-discuss] AFM Question

[Shankar Balasubramanian]

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 <viccornell at gmail.com>
To:     gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Date:   04/19/2016 04:34 PM
Subject:        Re: [gpfsug-discuss] AFM Question
Sent by:        gpfsug-discuss-bounces at spectrumscale.org



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] On Behalf Of Shankar 
Balasubramanian
Sent: 19 April 2016 06:47
To: gpfsug main discussion list <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>
To:        gpfsug main discussion list <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




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://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://gpfsug.org/mailman/listinfo/gpfsug-discuss
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20160419/da7694fb/attachment.htm>