SRDF/A -- is stuck and not copying

I guess you are in ACP_DISK mode. While in ACP mode, (Adaptive CoPy mode) primary storage will tolerate a moderate number of unaligned tracks between main storage and remote storage. It looks like you are at about 90% of copy process, which is a good value.

Are you using a single RDFG for all devices?

I totally misunderstood your message... Sorry. I swapped what you already synched (2 Tb) with what was still missing (16Tb).

Did you setup the group, create the pairs and jumped directly into ASYNC?

Just my curiosity since when I played with SRDF/A it was needed to transition through ACP mode before enabling ASYNC.

We are currently 16TB out of sync. We only copied 2TB in 2 weeks.

We are using one RDFG for all the disks.

The mode right now is SRDF/A

I tried to test what we would get if it were in ACP_DISK mode and saw sometime 2Mbps and sometimes 3Mbps.

Which is not a whole lot but much better than SRDF/A mode where we are getting 0Mbps each time I check.

Thanks!

My collegue at work set it up and I know he did just that. Created a group, create pairs and set ASYNC.

So are you saying we need to change the mode to ACP and let it finish and then change it to ASYNC? We can absolutely do that.

I just changed the state and we are not getting a great improvement in speed (more like 2Mbps).

What can we do on the array to analyze and see why we are not pushing more like 20Mbps or even 80.

Thanks

I'm talking about ages (2 years) ago. Thus don't considere my words as real directions. :-)

Ideally you do not want to create a SRDF group and at the initial sync put it straight into SRDF/A mode.  SRDF/A will send 30000 tracks maximum per cycle (last number I knew to be accurate).  What most people do is to put the devices in adaptive copy disk mode for the initial sync when the devices get close then put them inot SRDF/A mode, where it start cycling, once it gets consistent you are then fine and have a restartable copy.

You need to start with the link between the arrays how big is it and will it support the amoutn of traffic you are sending.  Did you're co-worker by any chance set a QOS level on the SRDF?  QOS settings are hard settings and no matter how high or low the workload it will not allow traffic to go any faster even if bandwidth is available.

even after 2 years later the SRDF basics still remains the same, dont be skeptical . I had learned a lot from you, especially SRDF area.

No QOS is currently on.

We did not change the default.

The current mode is ACP_DISK. We are still only copying about 15GB per hour. Pretty low by a VMAX standards.

Can I generate HEAT maps using SPA?

I have tried multiple options in SPA and still not able to get a nice HEAT map to check for bottle necks.

Thanks!

In SMaS (SMC/SPA combined) you can set the dashboard to present a HEAT map; it does take some time to load as it is a good chunk of data.

I have seen some unusual things like this when trying to sync up large volumes of data except it usually happens at the other end. We get close to a completed sync and then things slow to a crawl. Especially considering how you started out (in async mode) for a few weeks I would recommend you do what we do when things act like this: suspend the link and then resume it. If that doesn't change anything then try to split it and establish again (making sure that you are starting out in ACP_Disk mode.

This of course is assuming that all the other factors like link speeds are not impacting your throughput. With the kind of throughput you are getting right now it may not hurt to try.