Do I need to worry about this? I am setting up Remote Copy and want to use Periodic Mode with a 15 minute Sync Period. I am going to be creating many Remote Copy Groups and it seems to me it would be best if they did not all wake up at the same time and try to sync but I can't seem to find a way to do this in the UI or the CLI. Upon reflection, the interface does not actually imply that it will run the resyncs all at the same time only that they will resync every 15 minutes. I see no cron like function to control the start time of a particular groups' resync. I suppose they are starting randomly? Is the system taking care of it behind the scenes?
Ken
Scheduling Remote Copy in Periodic Mode to avoid contention
Re: Scheduling Remote Copy in Periodic Mode to avoid content
Welcome to my world. I have 265 RC Groups, and a few dozen replicate every 15 minutes. Some things to remember, there are a max of 20 VVs that can replication concurrently, I like to refer to these as replication slots. So depending on your bandwidth and how much the change rate is you have numerous factors to consider. We have moved all our daily replication to schedules using Windows Task scheduler.
I have uploaded a file that is a Powershell script that you can use to have it initiate replication based on the RC Groups names in the txt file defined to the script. The script works, but is missing the logging functions I will be adding. Depending on the number of RC Groups and volumes I would not try and schedule anything less than say an hour. The script will look at all volumes in each RC groups that is processes it and if it is already replicating it will not attempt to sync it. It also has logic to retry any RC Groups that are already syncing. Keep in mind this script was designed for less frequent replication so that we could control what volumes replicate at what times.
With 15 minute intervals you are better off letting the array process them at its own pace. If you are 3.1.2 make sure you have P24 installed as there are known issues with the overhead associated with just queuing up the volumes. We have spent 7-8 months working with 3par on various RC issues because I have 265 RC Groups and replicate over 1000 volumes.
Are you using FCIP or RCIP replication? We use RCIP and Cisco WAAS and get anywhere from 3-1 to 5-1 improvement of throughput, so I generally run 80-100MB/sec through a 300mb WAN with 24ms latency.
Keep in mind also that HP states the 3PAR is able to go up to about 125MB/sec in RC with some bursts to 175MB/sec and then you will be topped out of what the array can move. Of course wan latency and other factors can impact those numbers.
I have uploaded a file that is a Powershell script that you can use to have it initiate replication based on the RC Groups names in the txt file defined to the script. The script works, but is missing the logging functions I will be adding. Depending on the number of RC Groups and volumes I would not try and schedule anything less than say an hour. The script will look at all volumes in each RC groups that is processes it and if it is already replicating it will not attempt to sync it. It also has logic to retry any RC Groups that are already syncing. Keep in mind this script was designed for less frequent replication so that we could control what volumes replicate at what times.
With 15 minute intervals you are better off letting the array process them at its own pace. If you are 3.1.2 make sure you have P24 installed as there are known issues with the overhead associated with just queuing up the volumes. We have spent 7-8 months working with 3par on various RC issues because I have 265 RC Groups and replicate over 1000 volumes.
Are you using FCIP or RCIP replication? We use RCIP and Cisco WAAS and get anywhere from 3-1 to 5-1 improvement of throughput, so I generally run 80-100MB/sec through a 300mb WAN with 24ms latency.
Keep in mind also that HP states the 3PAR is able to go up to about 125MB/sec in RC with some bursts to 175MB/sec and then you will be topped out of what the array can move. Of course wan latency and other factors can impact those numbers.
- Attachments
-
RC_bulk.txt- (6.33 KiB) Downloaded 4043 times