Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Netapp: toasters

RE:

 

 

Netapp toasters RSS feed   Index | Next | Previous | View Threaded


Richard.Barlow at netapp

Dec 7, 2009, 4:07 PM

Post #1 of 4 (1572 views)
Permalink
RE:

It might be a good idea to test your procedure within a pair of
snapmirrored simulator instances before you do this with live data.
That saved my behind more than once :)

Richard Barlow
Senior Systems Engineer
Virtualization Specialist
NetApp
804.929.2500

www.netapp.com






-----Original Message-----
From: Fox, Adam
Sent: Monday, December 07, 2009 6:56 PM
To: John Stoffel; toasters [at] mathworks
Subject:

VSM (and therefore SM2T) will preserve inodes, but it will be up to you
to preserve the FSID of the original volume on east.
If you go into priv set advanced, you will find 'vol read_fsid' and 'vol
rewrite_fsid' which can accomplish this. Be aware that
Rewriting the fsid requires the volume to be restricted and you will
need to rewrite the original one first to something totally different.
FSIDs must be unique not only within a controller but within an HA-pair
if you want failover to work properly.

While these commands are perfectly safe when used properly, they are
guns so point them away from you (i.e. know what you're doing before you
it or you could have a disruption you don't want).

-- Adam Fox
Systems Engineer
adamfox [at] netapp


-----Original Message-----
From: John Stoffel [mailto:john.stoffel [at] taec]
Sent: Monday, December 07, 2009 5:50 PM
To: toasters [at] mathworks
Subject: Redoing snapmirror to a destination


Guys,

Do to stupidity on my part, I managed to accidently delete a snapshot
on the source side of a snapmirror pair, so that snapmirror can't
continue. It's not critical, it's just our tools area, which isn't
updated frequently.

So now I want to re-snapmirror, but I want to limit the downtime of
the clients on the destination side as much as possible when I switch
them to the new re-snapmirrored volume.

Currently, my clients mount east:/vol/tools, so what I'd like to do
is:

west> snapmirror store tools rst0a,rst1a

east> vol create tools ....
east> vol restrict tools
east> snapmirror retrieve tools_new rst0a,rst1a

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

so that all my clients see (on a read-only volume) is a quick outage
or pause in NFS traffic, then they just continue on using tools and
such as usual.

Or will I be forced to reboot all of my client machines one by one?
Which will be truly truly truly painful...

The general snapmirror update and cleanup of the old volume is
trivial. It's limiting the outage to my clients that I worry about.

Thanks,
John
John Stoffel - Senior Staff Systems Administrator - System LSI Group
Toshiba America Electronic Components, Inc. -
http://www.toshiba.com/taec
john.stoffel [at] taec - 508-486-1087


john.stoffel at taec

Dec 7, 2009, 8:51 PM

Post #2 of 4 (1481 views)
Permalink
Re: [In reply to]

>>>>> "Fox," == Fox, Adam <Adam.Fox [at] netapp> 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 [at] netapp


Fox,> -----Original Message-----
Fox,> From: John Stoffel [mailto:john.stoffel [at] taec]
Fox,> Sent: Monday, December 07, 2009 5:50 PM
Fox,> To: toasters [at] mathworks
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 [at] taec - 508-486-1087


joelk at encs

Dec 9, 2009, 5:56 AM

Post #3 of 4 (1458 views)
Permalink
Re: [In reply to]

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 [at] netapp> 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 [at] netapp
>
>
> Fox,> -----Original Message-----
> Fox,> From: John Stoffel [mailto:john.stoffel [at] taec]
> Fox,> Sent: Monday, December 07, 2009 5:50 PM
> Fox,> To: toasters [at] mathworks
> 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 [at] taec - 508-486-1087
>
>
>
>


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


joelk at encs

Dec 10, 2009, 6:51 AM

Post #4 of 4 (1444 views)
Permalink
Re: [In reply to]

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 [at] encs
> <mailto:joelk [at] encs>> 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 [at] netapp
> <mailto:Adam.Fox [at] netapp>> 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 [at] netapp <mailto:adamfox [at] netapp>
>
>
> Fox,> -----Original Message-----
> Fox,> From: John Stoffel [mailto:john.stoffel [at] taec
> <mailto:john.stoffel [at] taec>] Fox,> Sent: Monday,
> December 07, 2009 5:50 PM
> Fox,> To: toasters [at] mathworks <mailto:toasters [at] mathworks>
> 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 [at] taec
> <mailto:john.stoffel [at] taec> - 508-486-1087
>
>
>
>
>
>
>
> --
> | Joel Krajden | Rm: EV-7105, Tel: 514 848-2424 3052 |
> | Core Technologies Mgr | |
> | Engineering & | Email: joelk [at] encs
> <mailto:joelk [at] encs> |
> | 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 [at] encs |
| Computer Science | |
| Concordia University | In a circus, the clowns are supposed |
| Montreal, Canada | to make you laugh, not cry. |

Netapp toasters RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.