Issue moving large snapmirror destination

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Issue moving large snapmirror destination

BERNTSEN Basil

Hi folks, I'm managing a 7-mode system (8.1) with a snapmirror destination of 35TB. I need to move it to a new aggregate on the same head. I really want avoid rebaselining from prod... I've tried a snapmirror cascaded off the normal destination, however it will likely take 4 days to complete using the internal loopback. While this is running, snapmirror scheduled updates to the normal destination volume don't run. I also tried a vol copy, but that seems to require you to keep a CLI session online for the whole transfer.

 

Once it is copied with snapshots to the new aggregate, I'm going to change the source in the snapmirror.conf file. Does anyone have any ideas about how I could move this?

 

Thanks!

 

Basil

************************************************************************* 
This message and any attachments (the "message") are confidential, intended solely for the addressee(s), and may contain legally privileged information.  Any unauthorized use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. Please visit http://sgasdisclosure.com for important information regarding SG Americas Securities, LLC (“SGAS”). Please visit http://swapdisclosure.sgcib.com for important information regarding swap transactions with SOCIETE GENERALE.  
*************************************************************************


_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Issue moving large snapmirror destination

Sebastian Goetze

Hi Basil,


why not just 'move' the volume, if it's connected to the same head?

vol move start ndmsrcvol dstaggr [ -k ] [ -m | -r num_cutover_attempts ] [ -w cutover_window] [ -o] [ -d ]

Starts the vol move of volume named ndmsrcvol to the destination aggregate named dstaggr. The
execution sequence starts with a series of checks on the controller, source volume, source and
destination aggregates. If all the checks are successful, the move starts with Setup phase in which a
placeholder volume in the destination aggregate is created, and baseline transfer from source to
destination volume initiated. This is followed by Data Copy phase wherein the destination volume
requests successive snapmirror updates from source volume to synchronize itself completely with the
source volume. Finally the move completes with the cutover phase.
By default, vol move will initiate cutover automatically, unless invoked with an optional -m that
disables automatic cutover. With the -m option, vol move continues to trigger snapmirror updates from
source volume and the user can initiate cutover at any time with the vol move cutover command.
The duration of the cutover window can be specified by the -w option. The minimum, default and
maximum values for cutover window are respectively 30, 60 and 300. The number of cutover attempts
is provided by an optional -r. The minimum, default and maximum values for cutover attempts are 1, 3
and 25. If user has not specified -m option and cutover cannot be completed in the specified number of
attempts, vol move will pause. The user may either abort or resume vol move with/without -m option.
After successful move, the source volume, by default, will be destroyed unless the move was started
with -k option.

Before executing cutover, vol move performs a series of checks, similar to the checks during the
initialization phase, to verify that the conditions are favorable to cutover. If any of the checks fail, vol
move pauses with an EMS message that indicates the exact reason for pause. The user may wait for the
unfavorable event to complete and resume vol move thereafter.
The -o option is provided to ignore the redundancy characteristics of aggregates in MetroCluster
environment when a vol move is initiated from the mirrored source aggregate to an unmirrored
destination aggregate. In other words, without -o option, vol move will not start when the redundancy
characteristics of the two aggregates are different and if started with -o option, will pause before
entering cutover if the redundancy characteristics of the two aggregates are different.
The -d option is used to perform dry run. When issued with this option, vol move sub system only runs
a series of checks without starting vol move. Appropriate error messages are displayed in case any
checks fail.


It should be way faster than a SnapMirror and you can prep and do the cutover at a specified time...

Hope that helps

Sebastian

On 1/18/2017 8:47 PM, BERNTSEN Basil wrote:

Hi folks, I'm managing a 7-mode system (8.1) with a snapmirror destination of 35TB. I need to move it to a new aggregate on the same head. I really want avoid rebaselining from prod... I've tried a snapmirror cascaded off the normal destination, however it will likely take 4 days to complete using the internal loopback. While this is running, snapmirror scheduled updates to the normal destination volume don't run. I also tried a vol copy, but that seems to require you to keep a CLI session online for the whole transfer.

 

Once it is copied with snapshots to the new aggregate, I'm going to change the source in the snapmirror.conf file. Does anyone have any ideas about how I could move this?

 

Thanks!

 

Basil

************************************************************************* 
This message and any attachments (the "message") are confidential, intended solely for the addressee(s), and may contain legally privileged information.  Any unauthorized use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. Please visit http://sgasdisclosure.com for important information regarding SG Americas Securities, LLC (“SGAS”). Please visit http://swapdisclosure.sgcib.com for important information regarding swap transactions with SOCIETE GENERALE.  
*************************************************************************



_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters


_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Issue moving large snapmirror destination

BERNTSEN Basil

Thanks Sebastian, I actually already checked it with a dry run and it complained about the fact that the volume I'm moving was read-only and snapmirrored.

 

One think I noticed is that the bandwidth available through the prod interface is a lot faster than the loopback- I did a snapmirror cascade to the other head of another similar sized volume and it was done overnight. What about something like using a connections definition line in the snapmirror.conf to send the traffic through another interface than loopback? Or maybe setting snapmirror.volume.local_nwk_bypass.enable to off?

 

From: Sebastian Goetze [mailto:[hidden email]]
Sent: January-18-17 3:49 PM
To: BERNTSEN Basil (EXT) ResgGtsInt; [hidden email]
Subject: Re: Issue moving large snapmirror destination

 

Hi Basil,

 

why not just 'move' the volume, if it's connected to the same head?

vol move start ndmsrcvol dstaggr [ -k ] [ -m | -r num_cutover_attempts ] [ -w cutover_window] [ -o] [ -d ]

Starts the vol move of volume named ndmsrcvol to the destination aggregate named dstaggr. The
execution sequence starts with a series of checks on the controller, source volume, source and
destination aggregates. If all the checks are successful, the move starts with Setup phase in which a
placeholder volume in the destination aggregate is created, and baseline transfer from source to
destination volume initiated. This is followed by Data Copy phase wherein the destination volume
requests successive snapmirror updates from source volume to synchronize itself completely with the
source volume. Finally the move completes with the cutover phase.
By default, vol move will initiate cutover automatically, unless invoked with an optional -m that
disables automatic cutover. With the -m option, vol move continues to trigger snapmirror updates from
source volume and the user can initiate cutover at any time with the vol move cutover command.
The duration of the cutover window can be specified by the -w option. The minimum, default and
maximum values for cutover window are respectively 30, 60 and 300. The number of cutover attempts
is provided by an optional -r. The minimum, default and maximum values for cutover attempts are 1, 3
and 25. If user has not specified -m option and cutover cannot be completed in the specified number of
attempts, vol move will pause. The user may either abort or resume vol move with/without -m option.
After successful move, the source volume, by default, will be destroyed unless the move was started
with -k option.

Before executing cutover, vol move performs a series of checks, similar to the checks during the
initialization phase, to verify that the conditions are favorable to cutover. If any of the checks fail, vol
move pauses with an EMS message that indicates the exact reason for pause. The user may wait for the
unfavorable event to complete and resume vol move thereafter.
The -o option is provided to ignore the redundancy characteristics of aggregates in MetroCluster
environment when a vol move is initiated from the mirrored source aggregate to an unmirrored
destination aggregate. In other words, without -o option, vol move will not start when the redundancy
characteristics of the two aggregates are different and if started with -o option, will pause before
entering cutover if the redundancy characteristics of the two aggregates are different.
The -d option is used to perform dry run. When issued with this option, vol move sub system only runs
a series of checks without starting vol move. Appropriate error messages are displayed in case any
checks fail.


It should be way faster than a SnapMirror and you can prep and do the cutover at a specified time...

Hope that helps

Sebastian

On 1/18/2017 8:47 PM, BERNTSEN Basil wrote:

Hi folks, I'm managing a 7-mode system (8.1) with a snapmirror destination of 35TB. I need to move it to a new aggregate on the same head. I really want avoid rebaselining from prod... I've tried a snapmirror cascaded off the normal destination, however it will likely take 4 days to complete using the internal loopback. While this is running, snapmirror scheduled updates to the normal destination volume don't run. I also tried a vol copy, but that seems to require you to keep a CLI session online for the whole transfer.

 

Once it is copied with snapshots to the new aggregate, I'm going to change the source in the snapmirror.conf file. Does anyone have any ideas about how I could move this?

 

Thanks!

 

Basil

************************************************************************* 
This message and any attachments (the "message") are confidential, intended solely for the addressee(s), and may contain legally privileged information.  Any unauthorized use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. Please visit http://sgasdisclosure.com for important information regarding SG Americas Securities, LLC (“SGAS”). Please visit http://swapdisclosure.sgcib.com for important information regarding swap transactions with SOCIETE GENERALE.  
*************************************************************************




_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters

 

************************************************************************* 
This message and any attachments (the "message") are confidential, intended solely for the addressee(s), and may contain legally privileged information.  Any unauthorized use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. Please visit http://sgasdisclosure.com for important information regarding SG Americas Securities, LLC (“SGAS”). Please visit http://swapdisclosure.sgcib.com for important information regarding swap transactions with SOCIETE GENERALE.  
*************************************************************************


_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Issue moving large snapmirror destination

andrei.borzenkov@ts.fujitsu.com
In reply to this post by BERNTSEN Basil

 

 

Hi folks, I'm managing a 7-mode system (8.1) with a snapmirror destination of 35TB. I need to move it to a new aggregate on the same head. I really want avoid rebaselining from prod... I've tried a snapmirror cascaded off the normal destination, however it will likely take 4 days to complete using the internal loopback. While this is running, snapmirror scheduled updates to the normal destination volume don't run.

[Borzenkov, Andrei]

Do you mean that attempt to initiate update to destination fails?

I also tried a vol copy, but that seems to require you to keep a CLI session online for the whole transfer.

 

Once it is copied with snapshots to the new aggregate, I'm going to change the source in the snapmirror.conf file. Does anyone have any ideas about how I could move this?

 

[Borzenkov, Andrei]

Assuming you have sufficient bandwidth, you can do second copy from original source


_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Issue moving large snapmirror destination

Sebastian Goetze
In reply to this post by BERNTSEN Basil
And you can't: 
break mirror, move volume, resync mirror? 

Sebastian


On Wed, Jan 18, 2017, 23:00 BERNTSEN Basil <[hidden email]> wrote:

Thanks Sebastian, I actually already checked it with a dry run and it complained about the fact that the volume I'm moving was read-only and snapmirrored.

 

One think I noticed is that the bandwidth available through the prod interface is a lot faster than the loopback- I did a snapmirror cascade to the other head of another similar sized volume and it was done overnight. What about something like using a connections definition line in the snapmirror.conf to send the traffic through another interface than loopback? Or maybe setting snapmirror.volume.local_nwk_bypass.enable to off?

 

From: Sebastian Goetze [mailto:[hidden email]]
Sent: January-18-17 3:49 PM
To: BERNTSEN Basil (EXT) ResgGtsInt; [hidden email]
Subject: Re: Issue moving large snapmirror destination

 

Hi Basil,

 

why not just 'move' the volume, if it's connected to the same head?

vol move start ndmsrcvol dstaggr [ -k ] [ -m | -r num_cutover_attempts ] [ -w cutover_window] [ -o] [ -d ]

Starts the vol move of volume named ndmsrcvol to the destination aggregate named dstaggr. The
execution sequence starts with a series of checks on the controller, source volume, source and
destination aggregates. If all the checks are successful, the move starts with Setup phase in which a
placeholder volume in the destination aggregate is created, and baseline transfer from source to
destination volume initiated. This is followed by Data Copy phase wherein the destination volume
requests successive snapmirror updates from source volume to synchronize itself completely with the
source volume. Finally the move completes with the cutover phase.
By default, vol move will initiate cutover automatically, unless invoked with an optional -m that
disables automatic cutover. With the -m option, vol move continues to trigger snapmirror updates from
source volume and the user can initiate cutover at any time with the vol move cutover command.
The duration of the cutover window can be specified by the -w option. The minimum, default and
maximum values for cutover window are respectively 30, 60 and 300. The number of cutover attempts
is provided by an optional -r. The minimum, default and maximum values for cutover attempts are 1, 3
and 25. If user has not specified -m option and cutover cannot be completed in the specified number of
attempts, vol move will pause. The user may either abort or resume vol move with/without -m option.
After successful move, the source volume, by default, will be destroyed unless the move was started
with -k option.

Before executing cutover, vol move performs a series of checks, similar to the checks during the
initialization phase, to verify that the conditions are favorable to cutover. If any of the checks fail, vol
move pauses with an EMS message that indicates the exact reason for pause. The user may wait for the
unfavorable event to complete and resume vol move thereafter.
The -o option is provided to ignore the redundancy characteristics of aggregates in MetroCluster
environment when a vol move is initiated from the mirrored source aggregate to an unmirrored
destination aggregate. In other words, without -o option, vol move will not start when the redundancy
characteristics of the two aggregates are different and if started with -o option, will pause before
entering cutover if the redundancy characteristics of the two aggregates are different.
The -d option is used to perform dry run. When issued with this option, vol move sub system only runs
a series of checks without starting vol move. Appropriate error messages are displayed in case any
checks fail.


It should be way faster than a SnapMirror and you can prep and do the cutover at a specified time...

Hope that helps

Sebastian

On 1/18/2017 8:47 PM, BERNTSEN Basil wrote:

Hi folks, I'm managing a 7-mode system (8.1) with a snapmirror destination of 35TB. I need to move it to a new aggregate on the same head. I really want avoid rebaselining from prod... I've tried a snapmirror cascaded off the normal destination, however it will likely take 4 days to complete using the internal loopback. While this is running, snapmirror scheduled updates to the normal destination volume don't run. I also tried a vol copy, but that seems to require you to keep a CLI session online for the whole transfer.

 

Once it is copied with snapshots to the new aggregate, I'm going to change the source in the snapmirror.conf file. Does anyone have any ideas about how I could move this?

 

Thanks!

 

Basil

************************************************************************* 
This message and any attachments (the "message") are confidential, intended solely for the addressee(s), and may contain legally privileged information.  Any unauthorized use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. Please visit http://sgasdisclosure.com for important information regarding SG Americas Securities, LLC (“SGAS”). Please visit http://swapdisclosure.sgcib.com for important information regarding swap transactions with SOCIETE GENERALE.  
*************************************************************************




_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters

 

************************************************************************* 
This message and any attachments (the "message") are confidential, intended solely for the addressee(s), and may contain legally privileged information.  Any unauthorized use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. Please visit http://sgasdisclosure.com for important information regarding SG Americas Securities, LLC (“SGAS”). Please visit http://swapdisclosure.sgcib.com for important information regarding swap transactions with SOCIETE GENERALE.  
*************************************************************************

--

sent from my mobile, spellcheck might have messed up...


_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Loading...