NetApp SnapMirror

NetApp SnapMirror is a pretty easy utility to use, but offers great power. NetApp snapview snapshots a LUN to a given destination either on a demand basis or a schedule. You can set this up via the UI or you can run commands via SSH. In the following example, we will be setting up snapview on a LUN. 

However, there is one key concept here. You can dedicate different interfaces to handle different roles. So if you have your production data accessible on say e0a, then consider setting up your snapshot traffic on e0b. This way you do not flood the interface or the upstream network components. Also you are spreading the load.

Here's a quick overview or some key concepts you need to consider:



We have a volume
ontap> vol status cloud01

Volume  State
cloud01 online


We have a lun

ontap> lun show

/vol/cloud01/cloud01-na-lun01    100g (107374182400)  (r/w,online,mapped)

And this is our satatus of SnapMirror

ontap> snapmirror status
Snapmirror is on.
ontap> snapmirror destinations
snapmirror destination: no known destinations

We need to edit the /etc/snapmirror.conf file and place some information in ro configure a snapmirror job. Here is a good article on what options you can use. http://www.wafl.co.uk/tag/snapmirrorconf/

The following snapmirror.conf entry indicates that filer ontap1′s volume cloud04_mirror will mirror volume cloud04 via the ontap0-gig interface. The ontap0-gig interface is whatever IP address ontap1 can resolve that name to. In this case, it might be a gigabit ethernet link on filer ontap0. The mirror is updated at 9:30 a.m., 1:30 p.m., and 7:30 p.m., Monday through Friday. The asterisk means that the data replication schedule is not affected by the day of month; it is the same as entering numbers 1 through 31 (comma-separated) in that space. It is actually similar to a cron format. 

ontap0-gig:cloud01 ontap1:cloud01_mirror – 30 9, 13, 19 * 1, 2, 3, 4, 5 

The important part here is you can tell snapmirror.conf the interface name to send the snapmirror replication traffic down.

You may also need to set the /etc/snapmirror.allow to allow snapview connetions, otherwise you may see a connection denied issue.

Here is the commands you need to look at

ontap0> wrfile /etc/snapmirror.allow
 10.10.10.2
 ontap1
 

This will configure ontap0 to allow snapmirror connections to ontap1. As long as the name resolution is set correctly, it will traverse the interface as generic IP routing will take care of the traffic flow.

The other iimportant thing you can consider is the bandwidth shaping. The dash (–) in the command above, which is actually at the argu_ments field location, indicates that both the kbs and restart arguments are set to default. 

So what is the ksb? 

Taken from the link above (I said it was good) is this extract:

The value for this argument specifies the maximum speed (in kilobytes per second) at which SnapMirror data is transferred over the network. The kbs setting is used to throttle network bandwidth consumed, disk I/O, and CPU usage. By default, the filer transfers the data as fast as it can. The throttle value is not used while synchronously mirroring.  

You can set it something like this:

kbs=2000

This means the transfer speed is set at a maximum rate of 2, 000 kilobytes per second.

Asyn, Sync or semi sync

In async mode, snapshot copies of the volume are created periodically on the source. Only blocks that have changed or have been newly created since the last replication cycle are transferred to the target, making this method very efficient in terms of storage system overhead and network bandwidth.

Sync mode sends updates from the source to the destination as they occur, rather than according to a predetermined schedule. This helps data written on the source system to be protected on the destination even if the entire source system fails. NVLOG forwarding and consistency point (CP) forwarding are used to keep the target completely up to date. NVLOG forwarding enables data from the write log that is normally cached in NVRAM on NetApp storage to be synchronized with the target. Consistency point forwarding keeps the on-disk file system images synchronized.

Semi-sync mode differs from sync mode in two ways. Writes to the source aren't required to wait for acknowledgement from the target before they are committed and acknowledged, and NVLOG forwarding is not used. These two changes speed up application response with only a very small hit in terms of achievable recovery point objective (RPO).

SnapMirror status?

We have can see the status through both the CLI and the UI. Here is the CLI


ontap0> snapmirror status
Snapmirror is on.
Source         Destination            State          Lag       Status
ontap0:cloud01 ontap1:cloud01_mirror  Snapmirrored   00:00:29  Idle

Here you can see the command snapmirror status shows the output of the status of the SnapMirror replication. Pretty simple right?

The UI shows a little more information as shown here:

Nice images :( but you get the drift. 

There lots more to this and maybe I will add to this blog at a later date, but you can see how SnapMirror can provide real time data by using synchronous mirroring for your volumes.

Also, using methods of traffic shaping and IP routing, you can traverse your snapmirror vols over a specific interface. Lots of good options. Enjoy!