[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