May 22, 2012

Optimizing SnapMirror performance – Part II

I did not really intend this to be a mult-part blog post on SnapMirror performance, but things are shaping up that way. More and more I encounter folks who are interested learning about the SnapMirror tuning methods. In hind sight, most of this comes across as elementary. It sure helps to know about this stuff before hand.

In what I call the Part I of the blog post on this topic, we discussed setting the TCP window size to optimal setting to maximize the throughput of the network connection. Today we will go over the using of SnapMirror over multiple paths.

Did you know ?
SnapMirror supports both Fibre Channel and Ethernet networks for replication.

In order to use multiple paths, the /etc/snapmirror.conf file is setup using connection strings using the format below:

conn_string = mode (src_nic_name1, dest_nic_name1) (src_nic_name2, dest_nic_name2)

Where,

conn_string
name of the connection
mode
Mode Type. Possible values are multi or failover
src_nic_name1
Network interface name of the first NIC on the source storage system
dest_nic_name1
Network interface name of the first NIC on the destination system
src_nic_name2
Network interface name of the second NIC on the source storage system
dest_nic_name2
Network interface name of the second NIC on the destination system

For this to work, one needs to have 4 network interface connections in total (2 in source system and 2 in destination system) with names for each. Those nics are referenced in the connection string to build a multi-pathed SnapMirror replication connection.

Example:

Source Storage System:  toaster_src
Source Volume: srcvol
Path 1 on the source system: toaster_src_pri
Path 2 on the source system: toaster_src_sec

Dest Storage System:  toaster_dst
Dest Volume: dstvol
Path 1 on the destination system: toaster_dst_pri
Path 2 on the destination system: toaster_dst_sec

To setup a multi-path, load balanced SnapMirror relationship, the snapmirror configuration lines would be

ob_sm_multi = multi (toaster_src_pri, toaster_dst_pri) (toaster_src_sec, toaster_dst_sec)
ob_sm_multi:srcvol toaster_dst:dstvol - -

The same way, to setup a multi-path, failover SnapMirror relationship, the configuration lines would be

ob_sm_multi = failover (toaster_src_pri, toaster_dst_pri) (toaster_src_sec, toaster_dst_sec)
ob_sm_multi:srcvol toaster_dst:dstvol - -

This technique in combination with the bandwidth throttling parameters and TCP window tuning should meet most of your DR and data protection replication requirements, if not all.

Comments

  1. korman says:

    Can you comment on “Deswizzling”. If I understand the process a netapp the destination flexvolume will never the same performance characteristics as production even if the underlying aggregate is identical until the entire volume is deswizzled?

  2. There’s a KB article on NetApp NOW site that explains the deswizzling process.

    https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb16746 (Login Required)

Speak Your Mind

*