granite imp
Hi,
We are currently running in the issue that our sync takes longer than it should. The next sync try’s to start and fails because of this.
What’s the best way to find the bottleneck in this situation? Or how many GB per hour should be transferred that we can say the network is the problem?
raw locust
You can do the intial snapmirror without an schedule ( one time ) and after that apply an schedule so you snapmirror will only do the incrementals.
but usually you can se how much data per h you can transfer based on the IC lifs you have ; ex you have 2 ports of 10gbe as IC lifs this means the transfer per node will be 1.25gbps max ( in reality it is under 1gbps ) ; you can do the math if you can handle the initial transfer in a time frame.... but it safer to do the initial snapmiror baseline without a small sampling schedule or just one time and after that modify the schedule based on what you have as a requirement
If you have multiple concurrent snapmirrors you will have to schedule them in a smart way so they do not start in the same time; the traffic goes via the same IC lifs.
to identify the bottleneck you can monitor the IC lifs /ports and throughput between the 2 systems ... maybe you have to dedicate ports for this ( this is kind of the best practice ) not let the IC lifs on ports that serve client data ... it really depends on how you configured it.
hazy stone
There are three things to look at: network performance (WAN distance latency/bandwidth delay product, or packet loss generally), source or destination config (is a throttle set), or storage perf.
If dblade latency is above 1 ms on WAFL on source or destination, there could be storage performance throttling (BRE throttling).
marsh current
SnapMirror troubleshooting boils down to what I call the three C's: Configuration, Connectivity, and Content (of the volume/s)
Paul is spot-on with his guidance
ionic igloo
still wild to me that /vol move show will give you transfer rate, but snapmirror show requires you to do math
tawdry delta
You can use the network test-path command to identify network bottlenecks, or to prequalify network paths between nodes. You can run the command between intercluster nodes or intracluster nodes.