ONTAP Discussions

Estimate duration time to complete Vol Move

Zulhadi
2,707 Views

Hi All,

 

I need an advise from here related on vol move activity. I'm planning to do a vol move from old controller (FAS 8020) to new controller (FAS 8300). Now looking the way to calculate estimated duration to be taken on each volume will be involve in the vol move. Can anyone shared with me, what the formula that I can use to calculate the estimated duration for each volume size or do we have specific this migration calculator for this? Please advise

 

 

 

4 REPLIES 4

AlexDawson
2,687 Views

Hi there,

 

You can do a snapmirror to test how long it is likely to take - I'm not aware of any other methods of determining or calculating. After the snapmirror finishes, clean up the relationship, delete the volumes, wait 24 hours or clean out the delete queue manually, and you're ready to migrate.

 

Hope this helps.

Ontapforrum
2,669 Views

In addition to Alex's advise, some info around 'vol move'.

 

Please note: In ONTAP 8.3 & 9.x, "Automatic throttling" occurs during the initial baseline phase to assure that the workload imposed by the vol move does not adversely affect "end-user latency and throughput". The throttling automatically adjusts itself as client or host traffic increases and decreases, effectively deprioritizing vol move in favor of end-user applications. Throttling may also take effect while certain scanners, such as those for storage efficiency, are running.


Therefore, timing of the vol_move is key here (as you would be more aware of the Node's resource demand, OCUM is a good tool that can suggest how resources are being used). Also, while the vol_move is in progress, it goes through different phases, and it reports the progress in each phase. Vol move show command is handy, as it will report for example:

 

Example: (output of vol move show)

a) Move Phase: replicating
b) Estimated Remaining Duration: 00:00:07.000
c) Replication Throughput: 157.6MB/s
d) Duration of Move: 00:00:42.000


Related:
https://docs.netapp.com/us-en/ontap-sm-classic/volume-move/task_planning_method_timing_volume_move.html


https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/How_many_vol_move_operations_can_be_active_at_the_same_time


https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/Volume_move_too_slow_or_not_working

 

cruxrealm
2,647 Views

As mentioned by @AlexDawson and @Ontapforrum,   there is no calculator for the vol move as it is considered as a non-priority process.   It will depend on how busy the cluster/nodes.  

 

However,   here is how I estimate the vol moves.  First I pick one of the volumes  I am planning to move (typically a mid-size volume).     I schedule the move on the busiest time of the day.   This gives the usual "worse case scenario" transfer speed of the move.  Then use the numbers from the output of snapmirror show "Progress" to calculate the estimated time (total size / transfer speed).  This gives an underestimated vol move completion, but in most of my migrations,  it is a fairly good estimate. 😁

Ashun
350 Views

hi

 

Sorry, there is no such tool. The transfer time can be roughly estimated based on the data volume and transfer rate. However, the actual completion time of the volume move varies with the actual service load.

 

I once encountered such a task, the task is to migrate several vols, there are multiple 500GB luns in the vol, the lun move to the new vol, the migration of each lun takes two hours in the first week, but in the second week, the migration of each 500GB lun only takes one hour to complete.


In this migration process, the service load is large at night, and the transfer is very slow. It takes about 3 hours to migrate each lun, and the actual transfer rate is maintained at 2 hours per 500GB lun during the day. The transmission speed is faster in the second week, because the aggregation of these vol's is the ssd drive used.

 

In my opinion, the "Estimate duration time to complete Vol Move" you mentioned is determined by network bandwidth, latency, storage performance, data type (large files migrate faster than small files) and other factors

Public