Replication Monitoring

[randombuffalo109]

Does anyone else have issues seeing the data remaining in the replication monitor?  I have tried Chrome, Firefox, and IE and none of them show the data remaining for a volume collection.  Only that it is lagging behind.  I am trying to tweak our QoS on the replication so that we can get backups offsited in a reasonable time but without draining the rest of our internet bandwidth.

[Pman]

Not quite sure if yo can see teh amount of data but you can see what snapshot is remaining. Do you have the throttling set on the nimble?

[randombuffalo109]

I have the throttling/QoS set for the replication partner on the Nimble itself.  I don't have any lagging replications right now, but I'l grab a screenshot next time I do.  There is a field that is supposed to show how much data is remaining under Monitor -> Replication -> Send.

[Pman]

After looking again i really don't see a field that shows how much remaining.

[randombuffalo109]

Perry here is what I'm talking about: 

It looks like one decided report its data remaining this time.  But as you can see the data remaining for two of the Volume Collections are just 0 B yet they are awaiting replication.  Not a huge deal but would be nice to see the progress of the replication.

[chris24 · Accepted solution]

Hello,

When the counter is on 0 that's usually because either their are insufficient streams (5) which is not the case here, or the arrays are running the calculations prior to the data hitting the wire. The volume collection in question (high02 for example) I notice has a twice daily schedule and one weekly, the twice daily snapshot is ~21GB in size. To transfer that at the current QoS of 7mbit (as per your graph) is 173859 (mbit) / 7 = 6.8 hours which will complete within the next 12 hour snapshot, however then you have the other volume collections to consider.

The Replication Bandwidth calculator (DR tool) in infosight will help you determine the throughput required.

Also on a side note you have a problem snapshotting MsgSwitch2 Copy2 (vmtools related I expect). Another small point to consider is to keep fewer snapshots on the downstream than the upstream, in the end of the day this is a DR array where the most recent snapshot counts (RPO), perhaps drop the weekly snapshot. Also having fewer snapshots on the downstream means you will never run sudden surprise space issue on the downstream, resolving this can be problematic.