[gpfsug-discuss] migrating data from GPFS3.5 to ESS appliance(GPFS4.1)
Yaron Daniel
YARD at il.ibm.com
Mon Feb 22 13:39:16 GMT 2016
Hi
AFM - Active File Management (AFM) is an asynchronous cross cluster
utility
It means u create new GPFS cluster - migrate the data without downtime ,
and when u r ready - u do last sync and cut-over.
Hope this help.
Regards
Yaron Daniel
94 Em Ha'Moshavot Rd
Server, Storage and Data Services - Team Leader
Petach Tiqva, 49527
Global Technology Services
Israel
Phone:
+972-3-916-5672
Fax:
+972-3-916-5672
Mobile:
+972-52-8395593
e-mail:
yard at il.ibm.com
IBM Israel
gpfsug-discuss-bounces at spectrumscale.org wrote on 02/22/2016 03:12:14 PM:
> From: Damir Krstic <damir.krstic at gmail.com>
> To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
> Date: 02/22/2016 03:12 PM
> Subject: Re: [gpfsug-discuss] migrating data from GPFS3.5 to ESS
> appliance (GPFS4.1)
> Sent by: gpfsug-discuss-bounces at spectrumscale.org
>
> Sorry to revisit this question - AFM seems to be the best way to do
> this. I was wondering if anyone has done AFM migration. I am looking
> at this wiki page for instructions:
> https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/
> wiki/General%20Parallel%20File%20System%20(GPFS)/page/Migrating%
> 20Data%20Using%20AFM
> and I am little confused by step 3 "cut over users" <-- does this
> mean, unmount existing filesystem and point users to new filesystem?
>
> The reason we were looking at AFM is to not have downtime - make the
> transition as seamless as possible to the end user. Not sure what,
> then, AFM buys us if we still have to take "downtime" in order to
> cut users over to the new system.
>
> Thanks,
> Damir
>
> On Thu, Feb 4, 2016 at 3:15 PM Damir Krstic <damir.krstic at gmail.com>
wrote:
> Thanks all for great suggestions. We will most likely end up using
> either AFM or some mechanism of file copy (tar/rsync etc.).
>
> On Mon, Feb 1, 2016 at 12:39 PM Wahl, Edward <ewahl at osc.edu> wrote:
> Along the same vein I've patched rsync to maintain source atimes in
> Linux for large transitions such as this. Along with the stadnard
> "patches" mod for destination atimes it is quite useful. Works in
> 3.0.8 and 3.0.9. I've not yet ported it to 3.1.x
> https://www.osc.edu/sites/osc.edu/files/staff_files/ewahl/onoatime.diff
>
> Ed Wahl
> OSC
>
> ________________________________________
> From: gpfsug-discuss-bounces at spectrumscale.org [gpfsug-discuss-
> bounces at spectrumscale.org] on behalf of Orlando Richards [
> orlando.richards at ed.ac.uk]
> Sent: Monday, February 01, 2016 4:25 AM
> To: gpfsug-discuss at spectrumscale.org
> Subject: Re: [gpfsug-discuss] migrating data from GPFS3.5 to ESS
> appliance (GPFS4.1)
>
> For what it's worth - there's a patch for rsync which IBM provided a
> while back that will copy NFSv4 ACLs (maybe other stuff?). I put it up
> on the gpfsug github here:
>
> https://github.com/gpfsug/gpfsug-tools/tree/master/bin/rsync
>
>
>
> On 29/01/16 22:36, Sven Oehme wrote:
> > Doug,
> >
> > This won't really work if you make use of ACL's or use special GPFS
> > extended attributes or set quotas, filesets, etc
> > so unfortunate the answer is you need to use a combination of things
and
> > there is work going on to make some of this simpler (e.g. for ACL's) ,
> > but its a longer road to get there. so until then you need to think
> > about multiple aspects .
> >
> > 1. you need to get the data across and there are various ways to do
this.
> >
> > a) AFM is the simplest of all as it not just takes care of ACL's and
> > extended attributes and alike as it understands the GPFS internals it
> > also is operating in parallel can prefetch data, etc so its a
efficient
> > way to do this but as already pointed out doesn't transfer quota or
> > fileset informations.
> >
> > b) you can either use rsync or any other pipe based copy program. the
> > downside is that they are typical single threaded and do a file by
file
> > approach, means very metadata intensive on the source as well as
target
> > side and cause a lot of ios on both side.
> >
> > c) you can use the policy engine to create a list of files to transfer
> > to at least address the single threaded scan part, then partition the
> > data and run multiple instances of cp or rsync in parallel, still
> > doesn't fix the ACL / EA issues, but the data gets there faster.
> >
> > 2. you need to get ACL/EA informations over too. there are several
> > command line options to dump the data and restore it, they kind of
> > suffer the same problem as data transfers , which is why using AFM is
> > the best way of doing this if you rely on ACL/EA informations.
> >
> > 3. transfer quota / fileset infos. there are several ways to do this,
> > but all require some level of scripting to do this.
> >
> > if you have TSM/HSM you could also transfer the data using SOBAR it's
> > described in the advanced admin book.
> >
> > sven
> >
> >
> > On Fri, Jan 29, 2016 at 11:35 AM, Hughes, Doug
> > <Douglas.Hughes at deshawresearch.com
> > <mailto:Douglas.Hughes at deshawresearch.com>> wrote:
> >
> > I have found that a tar pipe is much faster than rsync for this
sort
> > of thing. The fastest of these is ?star? (schily tar). On average
it
> > is about 2x-5x faster than rsync for doing this. After one pass
with
> > this, you can use rsync for a subsequent or last pass synch.____
> >
> > __ __
> >
> > e.g.____
> >
> > $ cd /export/gpfs1/foo____
> >
> > $ star ?c H=xtar | (cd /export/gpfs2/foo; star ?xp)____
> >
> > __ __
> >
> > This also will not preserve filesets and quotas, though. You
should
> > be able to automate that with a little bit of awk, perl, or
whatnot.____
> >
> > __ __
> >
> > __ __
> >
> > *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
> > *Damir Krstic
> > *Sent:* Friday, January 29, 2016 2:32 PM
> > *To:* gpfsug main discussion list
> > *Subject:* [gpfsug-discuss] migrating data from GPFS3.5 to ESS
> > appliance (GPFS4.1)____
> >
> > __ __
> >
> > We have recently purchased ESS appliance from IBM (GL6) with 1.5PT
> > of storage. We are in planning stages of implementation. We would
> > like to migrate date from our existing GPFS installation (around
> > 300TB) to new solution. ____
> >
> > __ __
> >
> > We were planning of adding ESS to our existing GPFS cluster and
> > adding its disks and then deleting our old disks and having the
data
> > migrated this way. However, our existing block size on our
projects
> > filesystem is 1M and in order to extract as much performance out
of
> > ESS we would like its filesystem created with larger block size.
> > Besides rsync do you have any suggestions of how to do this
without
> > downtime and in fastest way possible? ____
> >
> > __ __
> >
> > I have looked at AFM but it does not seem to migrate quotas and
> > filesets so that may not be an optimal solution. ____
> >
> >
> > _______________________________________________
> > gpfsug-discuss mailing list
> > gpfsug-discuss at spectrumscale.org <http://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
> >
>
> --
> --
> Dr Orlando Richards
> Research Services Manager
> Information Services
> IT Infrastructure Division
> Tel: 0131 650 4994
> skype: orlando.richards
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> _______________________________________________
> 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
> _______________________________________________
> 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/20160222/86f9f94a/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1851 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20160222/86f9f94a/attachment-0002.gif>
More information about the gpfsug-discuss
mailing list