2010-01-19 09:58 AM
I read that compression mechanism for snapmirror comes with ontap 7.3.2
I tried to enable it, but with no luck.
According to documentation I edited snapmirror.conf on destination filer like this:
conection1:vol1 netapp2:vol1_rep kbs=5120,compression=enable * * * *
After that i'm getting error: Current Transfer Error: transfer from source not possible; snapmirror may be misconfigured, the source volume may be busy or unavailable.
My goal is to enable snapmirror from netapp1 filer (vol1) to netapp2 filer (vol1_rep) with 5120 kbs restriction on bandwidth, compression=enable and * * * * schedule.
Does anyone know how the snapmirror.conf should look like for this configuration?
Do i have to edit it on destination or source filer ?
2010-01-19 10:03 PM
Hi Roch, see if this is a syntax error.
|kbs=kbs||Maximum transfer speed, in kilobytes per second, that Data ONTAP can use to transfer data.|
The kbs and restart arguments are expressed as a comma-separated list of name=value pairs, with no spaces. For example:kbs=2000,restart=always
If not using restart option, t
ry remove the comma after kbs=5120 and add the space.
2010-01-20 06:24 AM
See my conf below. You will see some that are compressed and some that aren't.
#Regenerated by registry Wed Aug 13 17:25:37 GMT 2008
# Min 0-59 or reoccuring /5 = evey 5 min
# Hour 0-23
# Day of Month 1-31
# Day of Week 0-7
starbuck_filer2:dfs_shares filer2:dfs_shares compression=enable 5 * * *
starbuck_filer2:users filer2:users compression=enable 10 * * *
starbuck_filer2:dmzsvrs filer2:dmzsvrs compression=enable 15 * * *
starbuck_filer2:assesspro filer2:assesspro compression=enable 20 * * *
apollo_filer2:tier1apps filer2:tier1apps compression=enable 25 * * *
apollo_filer2:dmzsharepoint filer2:dmzsharepoint compression=enable 30 * * *
starbuck_filer2:tier2apps filer2:tier2apps compression=enable 35 * * *
starbuck_filer2:tier3apps filer2:tier3apps compression=enable 40 * * *
starbuck:sqlbkup_t1 filer2:sqlbkup_t1 - 1,15,30,45 * * *
starbuck:sqlbkup_t2 filer2:sqlbkup_t2 - 5,20,35,50 * * *
For replication throttling, I use the system option since I am primarily concerned with wan utalization. The following options are used. Combine this with staggered volume replication and we make out ok.
2010-01-20 07:26 PM
Simply remember that SnapMirror is a pull technology.
Hence, to define any relationship you need to define it on the destination and not the source.
This means snapmirror.conf file needs to be created on the destination and not the source.
Now for the syntax part, you can try using the FilerView for creating the relationship, if you are facing syntax error.
For a restricted throttle option of 5120kbps, you can implement is at either individual relation level or system level.
Above, David has highlighted it at the system level.
Keep us posted !
2010-01-21 04:52 AM
This is an area where thus far, reporting seems to be lacking. You can only see the compression ratio for current snapmirrors. Since we do them every hour, with a new volume every 5 minuites, it's kinda hard to keep tabs on it. I guess I could schedule an rsh script and dump that into text. <Rant Over>
What I have seen in the past is around 1.5 to 1. Most volumes are already de-duped and either have 8 VMs in them or are CIFS volumes.
2010-01-21 05:10 AM
Compression ratios are also logged in the SnapMirror log file after the transfer is completed. Therefore you have two ways:
1. During the transfer, a long listing of SnapMirror status command will report a ratio
2. After the completion of the transfer, check the /etc/log/snapmirror file.
Also, check out the SnapMirror Async tech report (page 27).
SnapMirror Async Overview and Best Practices Guide
2010-01-21 05:24 AM
Nice. Looking through the log, at transfers of a meg or more, I'm seeing 1.4:1 up to 6.1:1. Many are in the 4.0:1 range and I'd have to guess that is the overall average, at least for last night.
So, it's a free license! The only penalty is CPU overhead. If you need it, turn it on for everything, examin the logs, then turn it back off for volumes that don't seem to benefit from it. Since we have a cluster, we have extra CPU (allowing room for failover). I guess it could be something to keep an eye on if we are in a failover mode for an extended period.
2010-02-11 09:14 AM
Would you mind elaborating on the below lines in your conf file?
I've read conflicting threads noting that these lines are required for the compression option. Thanks in advance!
2010-02-11 09:26 AM
I too had questions regarding these lines as they show up in the latest documentation but are not explained. When I called support, they didn't even know that you could compress a snapmirror transmission. I guess all of the sales hype over dedupe and how that could enable a form of compression prior to replication led everyone to believe that there wasn't anything else needed.
If you are not using compression, they are not needed. If you are using using compression, you have to define a relationship. This seems stupid to me because you define the relationship in each line of the config file. I suspect that this line is going to facilitate some other functionality in the future but who knows, it could have been some poor coding.
starbuck_filer2=multi (starbuck, filer2)
The first half of the statement "starbuck_filer2" is the connection string. I used "source_destination" for my naming scheme.
The last part of the statement (starbuck,filer2) are your source and destination filers.
I have not seen or had explained to me what the purpose of "multi" is in the statement, nor have I found any other choices. Perhaps it enables one to many replication targets. But if this is the case, of what benefit would it be to have a single option, unless there was a performance gain (doubtful). Security doen't make sense because both this statement and the actual schedule are in the same file. Oh well.
If you find someone who can enable the compression with out these statements, please, let me know. However, when I set it up using 7.3.2, it wouldn't work with out.