Using Compression with SnapMirror transfers in ONTAP 7.3.2

Hello there! If you are new here, you might want to subscribe to the RSS feed for updates on this topic.

One of the new features in Data ONTAP 7.3.2 is that you can now enable compression for your SnapMirror/SnapVault transfers. This is great news for customers with limited bandwidth on their WAN links. We have had customers in the past in this situation with SnapMirror transfers that would never finish and they had to look into WAN accelerators, nice to know that now there may be another option that in included free with ONTAP 7.3.2. The compression is done on the controllers by using a standard gzip compression.

Obviously you need to be aware that enabling compression will add additional load onto your system but keep in mind you can use FlexShare to set lower priority to system level (e.g. SnapMirror) operations. Another thing to keep in mind is that FlexShare is assigned per volume, so it doesn’t have to assign ALL of your SnapMirror transfers a low priority.

Enabling compression is as easy as modifying the /etc/snapmirror.conf file, you can enable compression on existing SnapMirror relationships. The changes you need to make are as follows:

At the top of snapmirror.conf you need to establish a connection name and assign the source and destination filers to it. For my example this will be:

sm1=multi(940-1,940-2)

<connection name>=multi(<sourcefiler>,<destinationfiler>)

Now you need to modify the existing line for the SnapMirror schedule, my example looks like this:

sm1:test_vol 940-2:test_vol_recv compression=enable – 10 * * *

Example:

For my example I was setting this up on a FAS940, I ran ‘sysstat –s 1’ before running the snapmirror and it averaged about 1% CPU usage

Source NetApp:

Destination NetApp:

After kicking off the initial snapmirror transfer I re-ran the same command and it returned an average CPU usage of 72% on the destination and 100% on the source.

Source NetApp:

Destination NetApp:

So again if you have a busy system, you will need to decide if the decreased WAN traffic outweighs the added load on your system. I kicked off a ‘snapmirror initialize’ and then monitored the transfer with ‘snapmirror status -l’ and saw that I was getting a steady 8:1 compression ratio on my transfer.

Popularity: 52% [?]

Cascading SnapMirror, removing the middle NetApp Recently had a customer who had a SnapMirror relationship between...

Related posts brought to you by Yet Another Related Posts Plugin.

Tony Lamont

Hi Mike

good article. Are you sure about the dash after the compression=enable line in the snapmirror? I get this error when I include the dash " /etc/snapmirror.conf: line 8 Invalid Day of Month Specification, ignoring line" and it seems to work when I take it out.

Also, is it normal to get these errors: "[snapmirror.dst.multipath.connErr:error]: SnapMirror is unable to setup a multipath connection to mir_v_citrixdata, resorting to the standard single TCP connection." The snapmiror compression needs a connection of type multi-path but there's only one path declared so I think this error is normal.

What do you think?

Thanks
Tony Lamont
mtellin

Hi Tony,
Just out of curiosity, that wouldn't happen to be a vfiler would it?

I had wondered the same thing about the multi on the snapmirror.conf file, this is the link to the NetApp documentation for 7.3.2 http://now.netapp.com/NOW/knowledge/docs/ontap/... and you can see even on the example they show with only 2 devices they set it up with multi as well (and without the connection name I get an error stating async SM is only allowed when specifying a connection name, ignoring compression option).

The documentation has the dash after the compression though in my lab I just removed it and it worked (I'm not positive but I think at a customer site we had an issue where it wouldn't work on their system *until* they added the dash though).
Richard

Hi,

I'm using 7.3.2P2 and FAS3140's, using single path and it wont work if the dash is there. In the best practices guide (http://media.netapp.com/documents/tr-3446.pdf) there is no dash either (page 26).

Have you guys worked out if you can use compression on the initialization phase yet? I am struggling on that one.

Thanks,
Rich.
mtellin

Hi Rich,
It looks like if you the relationship setup in /etc/snapmirror.conf using compression, I just did one like this:
sm1=multi(prdfiler,fas250)
sm1:SQL_Logs fas250:SQL_Logs_recv compression=enable 10 * * *
then do the initialize as you normally would:
snapmirror initialize -S prdfiler:SQL_Logs fas250:SQL_Logs_recv
Then it will do compression on the baseline transfer:
fas250> snapmirror status -l
Snapmirror is on.

Source: prdfiler:SQL_Logs
Destination: fas250:SQL_Logs_recv
Status: Transferring
Progress: 14848 KB
Compression Ratio: 91.9 : 1
State: Uninitialized
Lag: -
Mirror Timestamp: -
Base Snapshot: -
Current Transfer Type: Initialize

That's the only testing I've done to see if it works, but that compression ratio floats around and the CPU is pegged while base lining that way which would lead me to believe it is working.
Richard

Thanks Mike that does actually work!

I was trying to implement the compression=enable command on the CLI for the initialize. I also tried it with the correct entry in the snapmirror.conf but it error's saying volume is offline (because its still restricted and uninitialized)!

Another case of NetApp documentation leaving a few things out I think.

Thanks again,
Rich.