man5/na_snapmirror.conf(5) manual page

na_snapmirror.conf - volume and qtree replication schedules and configurations

DESCRIPTION

The /etc/snapmirror.conf file exists on the filer containing the mirror used for SnapMirror.

There are two types of lines in the configuration file: lines that define mirror relationships and lines that define connections to source filers to be used in the relationship definitions. Relationship definition lines are used to define the mirror relationships for destination volumes on this filer. Connection definition lines are optional and are used to specify specific network connections to the source volume and allow the specification of dual paths to the source volume.

Each relationship line of the file specifies the volume or qtree to be replicated, arguments for the replication, and the schedule for updating the mirror. You may only have one line for each destination volume or qtree.

Each relationship entry of the /etc/snapmirror.conf file is a single line containing space-separated fields. The entry has this format:

source destination arguments schedule

The following list describes the fields in each entry:

source This is the name of the source host, and the volume name, or the path of the qtree to be mirrored. The name is specified as two colon-separated fields, as follows:

host:volname

host:/vol/volume/qtree

Note that the host field is not necessarily the hostname of the filer (unlike the first field of the destination entry). You can specify a network resolvable name, IP address or connection name. The host field can be considered a definition of how to reach the source over the network.

destination
This is the hostname (must match the result of the hostname command) of the destination filer and the name of the destination volume or the path of the destination qtree. The name is specified as two colon-separated fields, as follows:

name:volume

name:/vol/volume/qtree

The name field must match the hostname of the destination filer (use the hostname(1) function to check this).

arguments
These are a comma-separated list of arguments for the transfer. To specify no arguments, enter a dash (``-'') in this field. Each argument is specified as a key and a value pair, as follows:

key=value

Currently, there are the following argument keys:

cksum This controls which checksum algorithm is used to protect the data transmitted by SnapMirror. Currently supported values are "crc32c" and "none".

kbs: 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.

tries The value for this argument specifies the maximum number of attempts that the destination will make to complete a scheduled snapmirror update. A retry will be attempted on the first minute after the previous attempt was abandoned. Notice that retries are only attempted for retry-able errors, and that some errors do not count as a retry. The tries setting is used to limit the number of retries, for instance to assure that backup transfers are started within a designated backup window, or else abandoned entirely until the next scheduled update. The syntax is "tries=N" or "tries=unlimited", where N is greater or equal to 0, and N is less or equal to 1000000000. If no try count is specified, the default is "unlimited".

restart
This controls the behavior of the SnapMirror scheduler with respect to restartability. If value is set to always, then an interrupted transfer will always restart, if it has a restart checkpoint and the conditions are the same as before the transfer was interrupted. If value is set to never, then an interrupted transfer will never restart, even if it has a restart checkpoint. By default, SnapMirror behaves like the always case, unless it has passed the next scheduled transfer time, in which case it will begin that scheduled transfer instead of restarting.

outstanding
This argument controls the performance versus synchronicity trade-off for synchronous mirrors. The value for this argument is a number followed by the suffixes: ops (operations), ms (milliseconds) or s (seconds). This governs the number of outstanding operations a synchronous mirror can have before forcing the client to wait for acknowledgement. The ops suffix allows the specified number of write operations to be outstanding while the ms and s suffixes allow operations in the last period of time to be outstanding before forcing client waits. If not specified, the default value is zero. This argument is ignored for asynchronous mirrors.

wsize This sets the TCP window size to use for the connection. Due to how TCP negotiates window sizes, the size of the receive window will initially be large and gradually work its way down to the size specified.

visibility_interval
The value for this argument is a number optionally followed by the suffixes: s (seconds), m (minutes) or h (hours). If a suffix is not specified, value is interpreted as seconds. This argument controls the amount of time before an automatic snapshot is created on the source volume that is synchronously mirrored. The value is the number of seconds between automatically created snapshots. The default value is 3 minutes. A small number here can negatively affect the performance of the mirror. This argument is ignored for asynchronous mirrors.

schedule
This is the schedule used by the destination filer for updating the mirror. It informs the SnapMirror scheduler when transfers will be initiated. The schedule field can either contain the word sync to specify synchronous mirroring or a cron-style specification of when to update the mirror. The cronstyle schedule contains four space-separated fields:

minute hour day-of-month day-of-week

Each field consists of one or more numbers or ranges. If a field contains more than one value, the values are separated from each other by a comma. A field consisting solely of an asterisk (``*'') is the same as a field enumerating all possible legal values for that field. A field consisting solely of a dash (``-'') represents a null value; any schedule with a dash in one of its fields will never run any scheduled transfers. Values in a field can take any of the following forms:

number

first-last

first-last/step

A value with a dash in it specifies a range; it is treated as containing all the values between first and last, inclusive. A range value with a slash specifies skips of step size in the range. For example, the value of the entry ``0-23/4'' would be the same as that of the entry ``0,4,8,12,16,20''.

minute Which minutes in each hour to update on. Values are from 0 to 59.

hour Which hours in the day to update on. Values are from 0 to 23.

day-of-month
Which days in the month to update on. Values are from 1 to 31.

day-of-week
Which days in the week to update on. Values are from 0 (Sunday) to 6 (Saturday).

Whenever the current time matches all the specified schedule fields, a transfer from the source to the destination will be invoked.

The other type of line allowed in this file is a connec_tion definition line. These lines define an alternate name for the source filer that can be used as the source host in the relationship lines. They are used to describe more specifically the parameters for the connection(s) to the source filer. SnapMirror supports the multi path specification for both asynchronous and synchronous mirrors.

Each connection definition is a single line giving a name to one or two pairs of IP addresses along with a mode of operation for the connection. The lines are specified in the following format:

name = mode( source_ip_addr1 , dest_ip_addr1 ) ( source_ip_addr2 , dest_ip_addr2 )

name This is the name of the connection you would like to define. This name is to be used as the source filer in relationship definitions.

mode The mode is optional and specifies the mode in which two IP address pairs will be used. Two modes are allowed multiplexing and failover mode and are specified by using the multi and failover keywords. If not specified, multiplexing mode is used.

The multiplexing mode causes snapmirror to use both paths at the same time. If one should fail, it will switch to use the remaining path only and use both again should the failing path be repaired.

Failover mode causes snapmirror to use the first path as the desired path and only use the second path should problems arise with the first path.

source_ip_addr1 source_ip_addr2 dest_ip_addr1 dest_ip_addr2
These are resolvable network names or IP addresses that define a path through the network between the source and the destination. The source addresses are the IP addresses of interfaces to use on the source and respectively for the destination. The pairing denotes a path from source to destination.

EXAMPLES

The following snapmirror.conf entry indicates that filer fridge's qtree home, in volume vol2 will mirror qtree home, in volume vol1 from the filer toaster. Transfer speed is set at a maximum rate of 2,000 kilobytes per second. The four asterisks mean transfers to the mirror are initiated every minute, if possible. (If a previous transfer is in progress at the minute edge, it will continue; a new transfer will be initiated at the first minute edge after the transfer has completed.)

toaster:/vol/vol1/home fridge:/vol/vol2/home kbs=2000 * * * *

The following snapmirror.conf entry indicates that filer myfiler1's volume home_mirror will mirror volume home via the myfiler0-gig interface. (The myfiler0-gig interface is whatever IP address myfiler1 can resolve that name to. In this case, it might be a gigabit ethernet link on filer myfiler0.) 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. The dash in the argu_ments field indicates that both the kbs and restart arguments are set to default.

myfiler0-gig:home myfiler1:home_mirror - 30 9,13,19 * 1,2,3,4,5

The following snapmirror.conf entry makes transfers every half hour, with the first at 8:15 a.m., and the last at 6:45 p.m. The asterisks mean that the data replication schedule is not affected by the day of month or week; in other words, this series of transfers are initiated every day.

filer1:build filer2:backup - 15,45 8,9,10,11,12,13,14,15,16,17,18 * *

The following snapmirror.conf entry, between the docs qtree on dev and docs_bak on icebox, is kicked off on every Sunday, at 12:00 midnight.

dev:/vol/dept/docs icebox:/vol/backup/docs_bak - 0 0 * 0

The following snapmirror.conf entry, between the home and backup volume on icebox, is kicked off once every halfpast the hour between 7:30 a.m. and 9:30 p.m., and once at midnight.

icebox:home icebox:backup - 30 0,7-21 * *

The following snapmirror.conf entry, between the db volumes on fridge-gig dev and icebox, is kicked off on every five minutes, starting at 0. (Note that fridge-gig is just a network interface name. In this case, it could be a gigabit ethernet link on fridge.)

fridge-gig:db icebox:db - 0-55/5 * * *

This can be extended to use the multiple path options and synchronous mirroring.

fridge-con = failover(fridge-gig,icebox-gig)(fridge-slow,icebox-slow) fridge-con:db icebox:db - sync

This changes the relationship into synchronous mode and the connection specifies that we should use a gigabit ethernet path for the mirroring where only if that connection fails, use a slower network connection. Even if you would like to use one path from source to destination, it is a good idea to specify a connection line in your configuration file. This can reduce problems seen with name resolution affects on the relationship configuration line.

NAME

SYNOPSIS

DESCRIPTION

EXAMPLES

SEE ALSO