[prev in list] [next in list] [prev in thread] [next in thread] 

List:       toasters
Subject:    Re:
From:       Joel Krajden <joelk () encs ! concordia ! ca>
Date:       2009-12-10 14:51:09
Message-ID: 4B210ADD.7010602 () encs ! concordia ! ca
[Download RAW message or body]

You are correct and anyways migration would only work on the same filer.

Sorry for suggesting a dead end.

Joel


Michael Barrow wrote:
> 'snapmirror migrate' is only applicable for an existing SnapMirror 
> relationship. In this particular instance, the SnapMirror relationship 
> has effectively been torn down and a new relationship must be built.
> 
> On Wed, Dec 9, 2009 at 5:56 AM, Joel Krajden <joelk@encs.concordia.ca 
> <mailto:joelk@encs.concordia.ca>> wrote:
> 
>     You might want to look at
> 
>     Solution ID: kb40272
>     Last updated: 30 SEP 2009
> 
>     Sample procedure using ' snapmirror migrate ' that avoids remounting
>     in a NFS environment
> 
> 
> 
>     Joel
> 
> 
>     John Stoffel wrote:
> 
>                             "Fox," == Fox, Adam <Adam.Fox@netapp.com
>                             <mailto:Adam.Fox@netapp.com>> writes:
> 
> 
>         Fox> VSM (and therefore SM2T) will preserve inodes, but it will
>         be up
>         Fox> to you to preserve the FSID of the original volume on east.  If
>         Fox> you go into priv set advanced, you will find 'vol
>         read_fsid' and
>         Fox> 'vol rewrite_fsid' which can accomplish this.  Be aware that
>         Fox> Rewriting the fsid requires the volume to be restricted and you
>         Fox> will need to rewrite the original one first to something
>         totally
>         Fox> different.  FSIDs must be unique not only within a
>         controller but
>         Fox> within an HA-pair if you want failover to work properly.
> 
>         Ouch!  Sounds funky and possibly trouble.
> 
>         While I don't have any common snapshots between west> and east>
>         filers, I do have some common snapshots on each filer for other
>         snapmirror relationships, since west> is also snapmirroring tools to
>         two other sites.
> 
>         Would it be possible to do the following:
> 
>              1) quiece all snapmirrors of tools from west> to south> and
>                 north>
>                 - will this leave me with two snap shots for the west->north
>                   pair, or will snapmirror automatically cleanup when done?
> 
>              2) comment out tools entries on all filers: west, south,
>         north &
>                 east.
> 
>              3) on west> (my source), do 'snap rename
>         north(####)_tools.1234 \
>                    east(######)_tools.1234'
>                    4) on east> snapmirror resynnc tools
> 
>                 - wait until competed
> 
>              5) on west> snap rename east(######)_tools.1234 \
>                    north(######)_tools.1234
>              6) do snap update tools on east, north, south to make sure they
>                 can all update again.
> 
>              7) re-enable snapmirror.conf entries for tools.
> 
>         Or I wonder if I need to interrupt the west->north snapmirror in
>         progress, and make sure I only rename the more recent snapshot, so
>         that I still have valid snapshots between west->north, and now a
>         second one to re-purpose as my west->east pair base?
> 
>         Any hope?  
>         Thanks,
>         John
> 
> 
> 
>         Fox> While these commands are perfectly safe when used properly,
>         they are
>         Fox> guns so point them away from you (i.e. know what you're
>         doing before you
>         Fox> it or you could have a disruption you don't want).
> 
>         Fox> -- Adam Fox
>         Fox> Systems Engineer
>         Fox> adamfox@netapp.com <mailto:adamfox@netapp.com>
> 
> 
>         Fox,> -----Original Message-----
>         Fox,> From: John Stoffel [mailto:john.stoffel@taec.toshiba.com
>         <mailto:john.stoffel@taec.toshiba.com>] Fox,> Sent: Monday,
>         December 07, 2009 5:50 PM
>         Fox,> To: toasters@mathworks.com <mailto:toasters@mathworks.com>
>         Fox,> Subject: Redoing snapmirror to a destination
> 
> 
>         Fox,> Guys,
> 
>         Fox,> Do to stupidity on my part, I managed to accidently delete
>         a snapshot
>         Fox,> on the source side of a snapmirror pair, so that
>         snapmirror can't
>         Fox,> continue.  It's not critical, it's just our tools area,
>         which isn't
>         Fox,> updated frequently.
> 
>         Fox,> So now I want to re-snapmirror, but I want to limit the
>         downtime of
>         Fox,> the clients on the destination side as much as possible
>         when I switch
>         Fox,> them to the new re-snapmirrored volume.
> 
>         Fox,> Currently, my clients mount east:/vol/tools, so what I'd
>         like to do
>         Fox,> is:
> 
>         west> snapmirror store tools rst0a,rst1a
> 
>         east> vol create tools ....
>         east> vol restrict tools
>         east> snapmirror retrieve tools_new rst0a,rst1a
> 
>         Fox,> Now for the tricky part:
> 
>         east> nfs off
>         east> vol rename tools tools_old
>         east> vol rename tools_new tools
>         east> nfs on
>         east> exportfs -a -v
> 
>         Fox,> so that all my clients see (on a read-only volume) is a
>         quick outage
>         Fox,> or pause in NFS traffic, then they just continue on using
>         tools and
>         Fox,> such as usual.
> 
>         Fox,> Or will I be forced to reboot all of my client machines
>         one by one?
>         Fox,> Which will be truly truly truly painful...
> 
>         Fox,> The general snapmirror update and cleanup of the old volume is
>         Fox,> trivial.  It's limiting the outage to my clients that I
>         worry about.
>         Fox,> Thanks,
>         Fox,> John
>         Fox,>     John Stoffel - Senior Staff Systems Administrator -
>         System LSI Group
>         Fox,>   Toshiba America Electronic Components, Inc. -
>         Fox,> http://www.toshiba.com/taec
>         Fox,>        john.stoffel@taec.toshiba.com
>         <mailto:john.stoffel@taec.toshiba.com> - 508-486-1087
> 
> 
> 
>                
> 
> 
> 
>     -- 
>     | Joel Krajden           | Rm: EV-7105,  Tel: 514 848-2424 3052    |
>     | Core Technologies Mgr  |                                         |
>     | Engineering &          | Email: joelk@encs.concordia.ca
>     <mailto:joelk@encs.concordia.ca>          |
>     | Computer Science       |                                         |
>     | Concordia University   |  In a circus, the clowns are supposed   |
>     | Montreal, Canada       |  to make you laugh, not cry.            |
> 
> 
> 
> 
> -- 
> Michael Barrow
> michael at barrow dot me
> 


-- 
| Joel Krajden           | Rm: EV-7105,  Tel: 514 848-2424 3052    |
| Core Technologies Mgr  |                                         |
| Engineering &          | Email: joelk@encs.concordia.ca          |
| Computer Science       |                                         |
| Concordia University   |  In a circus, the clowns are supposed   |
| Montreal, Canada       |  to make you laugh, not cry.            |
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic