ONTAP Discussions
ONTAP Discussions
Hello, I am planning a Volume migration from two older Nodes (FAS3250) to two new Nodes (AFF8040) inside same cluster (ONTAP9.1).
My pan is to start all volume moves at one time (65 Volumes) and set manual Cutover in Maintenance Window.
How many of those Vol moves can be active at the same time? Could not find that information.
Some details
65 Volumes
10 Volume are above 1 TB used space (20TB)
20 Volumes between 1GB and 1TB (10TB)
35 Volumes below 1G (2GB)
105 LUNs
Any help is appreciated.
regards Frank
Solved! See The Solution
Found it in TR- 4075
Concurrent Volume Move Jobs
Volume move jobs can run concurrently on the same node or different nodes in a cluster. In general, all jobs serviced by the same controller share the available background resources, which are also shared with other traffic such as SnapMirror. Vol move replication is automatically and transparently throttled during the initial transfer so as not to increase client latency. Therefore, kicking off many volume move jobs in parallel on a single node may not result in the vol moves completing any faster than if multiple batches of volume move jobs were started sequentially.
In Data ONTAP 8.3, an automatic and transparent governor process queues and regulates vol move jobs so that an administrator can initiate as many individual jobs as required. Counters are kept of the number of references to the aggregates owned by each node in all the current vol move jobs, whether as a source or target aggregate. If 8 or fewer aggregate references for a node are involved in the initiated vol move jobs, all jobs will execute uninterrupted. If additional references are made to aggregates on that node in subsequent vol move jobs, these will wait in the setup phase after creating the target volume until one of the executing jobs completes.
Found it in TR- 4075
Concurrent Volume Move Jobs
Volume move jobs can run concurrently on the same node or different nodes in a cluster. In general, all jobs serviced by the same controller share the available background resources, which are also shared with other traffic such as SnapMirror. Vol move replication is automatically and transparently throttled during the initial transfer so as not to increase client latency. Therefore, kicking off many volume move jobs in parallel on a single node may not result in the vol moves completing any faster than if multiple batches of volume move jobs were started sequentially.
In Data ONTAP 8.3, an automatic and transparent governor process queues and regulates vol move jobs so that an administrator can initiate as many individual jobs as required. Counters are kept of the number of references to the aggregates owned by each node in all the current vol move jobs, whether as a source or target aggregate. If 8 or fewer aggregate references for a node are involved in the initiated vol move jobs, all jobs will execute uninterrupted. If additional references are made to aggregates on that node in subsequent vol move jobs, these will wait in the setup phase after creating the target volume until one of the executing jobs completes.
Ok, so no more limit but a kind of automatic scheduler. Becareful with performance impact.
Hello,
the max of simultaneous volume moves in 8.2 was 16. But concurrent reads (on SAS/SATA disk particularly) could impact severly your 3250. So, moving lot of volumes simultaneously can last long (more than your maintenance window).
Even if you move one by one your volume (max 16) with manual cutover, periodically, any changes made to the source volume are replicated to the destination aggregate, with possible impact on performances.
So, you should move first your volumes with the biggest workload, cut over them during maintenance window if necessary, migrate the LIFs to the 8040, and move other volumes.
It would be really interesting to know what the performance impact for a volume move is.
I have started a volume move on a FAS2552 from Aggr1 to Aggr2 with each about 100TB space. The volume I'm moving is 20TB big.
On another volume on aggr2 there is a share. That share has a folder with 500 small files. There's a process with these files replacing the files then unpacking, modifying, packing it back... this process usually takes 15-20 minutes... and runs every hour... now since I started the vol move it's taking 1h 20 minutes... so it's four times the time it has consumed before the vol move. I can see with statistics show-periodic that the CPU (95% and higher) is pretty high on the controller node that owns the disks of Aggr2. Now I'm not saying that it's ONLY the vol move but clearly the move process has an impact on the performance - can anyone point me to any literature that is discussing this?
Thank you!
axsys