snapmirror

NetApp cDOT – Restore SVM root volume

In my previous entry I have briefly describe how you can protect SVM root volume by using load-sharing mirrors. (The post can be found here: NetApp cDOT – SVM root volume protection). If you haven’t read it, and you are not sure what are the consequences of root volume not being accessible, I would encourage to give the article a try. Long story short, each SVM (Storage Virtual Machine, a.k.a vserver), has it’s own namespace. Root volume is a root (/) path of SVM. If SVM root volume becomes unavailable all NAS (CIFS/NFS) clients will lose access to all shares from that particular SVM. If you want to read a little bit more into namespace concept, check out my other entry: NetApp cDOT – Namespace, junction path.

Remember: when a SVM root volume became unavailable, it will be disruptive for all NAS clients! Never “experiment” on production environment.

Continue reading

NetApp cDOT – SVM root volume protection

In this entry I would like briefly  describe how to protect the SVM (vserver) root volume by creating load-sharing mirrors on every node of a cluster. If you are unfamiliar with SVMs, check out my article NetApp cDOT – what is SVM or vserver ?. Every vserver has it’s root volume, which is an entry point fo a namespace provided by that SVM (You can read more about namespaces in NetApp cDOT – Namespace, junction path entry). Continue reading

SnapMirror – set it up!

What is SnapMirror?

SnapMirror is a feature that enables us to replicate data. You can replicate data from specified source volume or qtree to another destination. The destination can be on the same filer, or it can be in complete other location as long as there is a connection between source and destination.

There are three modes availabe:

  • SnapMirror Sync – replicated data to the destination ASAP – so basically when data is written to the source volume it is being replicated instantly.
  • SnapMirror Semi-Sync – The lag between source and destination is maximum 10 seconds. This mode give us better performance compared to sync mode, and still RPO (Recovery Point Objective) is close to be zero.
  • SnapMirror Async – I would say this is the one you will probably meet the most. The snapmirror is being updated based on the schedule, it can be updated as often as every minute, or once a month. This mode I will focus on in this post.

 How does SnapMirror work?

SnapMirrors task is to replicate the data from a source volume (or qtree!) to a partner destination volume (or qtree). Before using SnapMirror you have to establish a relationship between the source and the destination.
In case of SnapMirror Async you have to set up the schedule that goes to /etc/snapmirror.conf file on the destination filer/vfiler. Well – by definition you do not have to setup the schedule, but without the schedule the relationship will never get updated as long as storage admin will not update it manually.
So – how SnapMirror works when the relationship is initialized:

  1. Creates a Snapshot copy of the data on the surce volume
  2. Copies it to the destination, which can be a read-only volume or qtree
  3. Source and destination share the common snapshot.

As you can notice, when the relationship is initlized for the first time, step 2 is transferring all the data, in other words it is base-line copy.

How SnapMirror works when the relationship is already initialized and the update is executed:

  1. Create a Snapshot copy of the data on the source volume
  2. Compare the new Snapshot with the last common snapshot copy between the source and the destination
  3. Transfer to destination only the data that has changed since the last update

 Let’s set up of the Volume SnapMirror a-sync relationship

Step 1.  Add a proper licence to both source and destination filer:

filerA> license add xxxyyy
filerB> license add xxxyyy

Step 2. Turn on the SnapMirror

filerA> options snapmirror.enable on
filerB> options snapmirror.enable on

Step 3. Allow the access on the source (snapmirror.allow vs snapmirror.access)

filerA> options snapmirror.access host=filerB

Step 4. Create a source and a destination volume

filerA> vol create sourcevol aggr1 50g
filerB> vol create destvol aggr1 50g

Step 5. Restrict the destination volume (the destinatnio volume has to be restricted)

filerB> vol restrict destvol

Step 6. Initialize the snapmirror

filerB> snapmirror initialize -S filerA:sourcevol filerB:destvol
Transfer started.
Monitor progress with ‘snapmirror status’ or the snapmirror log.

Step 7. Check the status. If it’s empty volume the initialization shoud go really fast so after a minute or two you can see

filerB> snapmirror status
Snapmirror is on.
Source              Destination      State         Lag    Status
filerA:sourcevol    filerB:destvol   Snapmirrored   00:00:45   Idle

Step 8. Setup the snapmirror schedule

The snapmirror schedule has to be setup on the destination volume (/etc/snapmirror.conf)

The syntax of the schedule is:

src_system :/vol/src_vol[/src_qtree] dest_system :/vol/dest_vol[/dest_qtree] arguments schedule

Simple example, which will update the snapmirror relationship at 10 a.m. every Monday, Wednesday and Friday would be:

filerB>rdfile /etc/snapmirror.conf

filerA:sourcevol  filerB:destvol – 0 10 * 1,3,5

Summary

SnapMirror is a complex technology. In this post I presented only the most simple setup of asynchronus Volume Snapmirror. If you would like to go a little bit deeper into how the transfer works, how to setup the QSM or what arguments can you specify try this book:
Data Protection Online Backup and Recovery Guide