JDMils3
1 Nickel

Limiting bandwidth on the initial sync b/w SANs using RP3.2

Jump to solution

We have just setup two new CX4 SANs in 2 sites (CLA & CRS sites). We have copied over about 1 TB of data from the old CX500 SAN (CLA site) to the CX4 SAN in the CLA site which has automatically intiated a sync b/w the RP modules in the CLA & CRS sites.

The site-to-site traffic is running at around 40 Mbs even though I have set the Bandwidth Limitation in Policy\Resource Allocation of the Consistency group to 0.5 Mb/s. Is this limitation only for the "regular" data sync only because no matter what I set the value to, the inter-site bandwidth hovers around 40 Mbps.

If I pause the transfer, the inter-site bandwidth drops to 0. Can someone pls shed some light on the subject? Thanks.

Labels (1)
Tags (2)
0 Kudos
1 Solution

Accepted Solutions
8 Krypton

Re: Limiting bandwidth on the initial sync b/w SANs using RP3.2

Jump to solution

Yes it will impact all replication including the intial sync, but as I stated earlier.. it is dependent on the sum of the limits of all CG's configured.. it does not matter that no other CG is replicating..

If consistency groups with settings of ‘limited’ and ‘unlimited’run on the same RPA, the effect is that there is no limit to the outgoing throughput from the RPA. When limiting the bandwidth, ensure that groups with limited bandwidthare not configuredto run on an RPA with other consistency groups whose bandwidth is unlimited orthis feature will not work.  This can be achieved by using the ‘Preferred RPAsetting

0 Kudos
6 Replies
8 Krypton

Re: Limiting bandwidth on the initial sync b/w SANs using RP3.2

Jump to solution

This policy limit is implemented on a per RPA basis, meaning that you will need to apply the same policy for all CG's that are running on the same RPA to have the effect of limiting the bandwidth.  The sum of the limit on all CG's on a given RPA determines the bandwidth  that the RPA will use. If one CG is set to the default, unlimited.. then there is no limit of any CG.

There are planned enhancments to this policy setting to give it greater functionality in the future.

0 Kudos
JDMils3
1 Nickel

Re: Limiting bandwidth on the initial sync b/w SANs using RP3.2

Jump to solution

Thanks Rick, I understand what you are saying. The CX4 in the CLA site is brand new, and as such, has no data on it. This is the first attempt to copy data from the old CX500 SAN to the new CX4.

There are multiple consistency groups configured on the RPAs but none have data to replicate across the site. This one CG now does, and it is flooding the inter-site link as the data is copied to the main LUN.

My question is does the Bandwidth Limiter in the RPA affect the initial sync?

0 Kudos
8 Krypton

Re: Limiting bandwidth on the initial sync b/w SANs using RP3.2

Jump to solution

Yes it will impact all replication including the intial sync, but as I stated earlier.. it is dependent on the sum of the limits of all CG's configured.. it does not matter that no other CG is replicating..

If consistency groups with settings of ‘limited’ and ‘unlimited’run on the same RPA, the effect is that there is no limit to the outgoing throughput from the RPA. When limiting the bandwidth, ensure that groups with limited bandwidthare not configuredto run on an RPA with other consistency groups whose bandwidth is unlimited orthis feature will not work.  This can be achieved by using the ‘Preferred RPAsetting

0 Kudos
JDMils3
1 Nickel

Re: Limiting bandwidth on the initial sync b/w SANs using RP3.2

Jump to solution

WOW! It works now!

But it just does not make sense why? If I only want to limit one CG and not the rest, why would the RPA care about the other CGs and if they are limited or not? It should take the replication of each CG as a unique unit, following the set limits, if any, for the respective CG. It doesn't make sense that limit settings on other CGs would affect another CG.

I might want to have many CGs running at full potential, say, because their data changes at different times of the day wrt each other, thus keeping the inter-site pipe full at all times. This would be classed as unlimited bandwidth.

But I might have on CG which is changing every second, and just want to limit that CG so that it does not overwhelm the rest as its replication priority is low. But in this case, from what you have told me, I have to define a limit on the other CGs as well. (?)

Is this by design and if so, by what reasoning?

Thanks for the help Rick.

0 Kudos
8 Krypton

Re: Limiting bandwidth on the initial sync b/w SANs using RP3.2

Jump to solution

Glad you had success.

Agree..it is an odd way to implement, but it is by design and you are not alone in your complaint, but today it is tied to the RPA. Yes you would need all CG's that have the same preferred RPA to have a defined limit.. and the sum of these limits determines what is consumed.

We have made suggestion to our R&D on improving this to make it more like a resource pool with reservations and limits which are sharable or not between CG's  If you have ever used vmware CPU/memory resource poolsand the constraints which are defined.. this is the general idea of what we would like to see in the product, if you would like to see other enhancements feel free to post those..

Per CG policy shall allow for three options surrounding Bandwidth Resource Allocation

  1. Bandwidth reservation
  2. Sharable Bandwidth reservation
  3. Bandwidth Limit.

Where they have the following behavior:

  • Reservation:is a bw amount that is exclusively reserved for the CG unless it is flagged assharable
  • Reservation Sharable: On or Off. If ‘ON’ the reserved amount can be shared and utilized byother CG’s when the CG with the reservation is not consuming it.. ( ie. Youhave a shared resource pool that is the sum of all bw that has not beenreserved + the sharable reservation not to exceed the total RPA functionality )
  • Limit: is a bwamount that the CG cannot exceed ( i.e. a true limit the CG can never consumemore that this value)

When the useris allowed to input the BW of the reservation value, BW available = RPA BWcapability (75MB/s) minus any previously assigned non sharable reservations)

If a CG has no setting.. it gets the amount of BW that remains in the sharedpool that is not currently utilized, any CG with a reservation can steal theresources away from a CG that has no defined reservation.

As part of the enhancement the amount of bw reserved –vs- used should beinstrumented and reported on.  And rulesand warnings in place to handle situation where a CG is running on anon-preferred RPA.. it's policy gets lower priority if the RPA that takes overdoes not have the required resources

JDMils3
1 Nickel

Re: Limiting bandwidth on the initial sync b/w SANs using RP3.2

Jump to solution

Thanks Rick,

Your answers are most helpful. Your suggestions to the R&D team are spot-on and supported by myself and I am sure by most other RPA users. Yes, I am a VMWare admin, and VMWare indeed uses Resource Pools very nicely to share resources to all guests. This is probably what made the RPA bandwidth limiting option so confusing to initially understand. Let's hope the R&D team listens to its support staff and customers.

But I understand now (how to fix it)! Thanks.

0 Kudos