CDOT Tips: Replication

Following the “Data has mass” train of thought, here’s how we move and protect data in CDOT.  We have three types of replication:

•           SyncMirror: Synchronous replication.  For redundancy.
•           SnapMirror (DP): Replication to a 1-minute granularity.  For disaster recovery.
•           SnapVault (XDP): Replication to a 1-hour granularity.  Think backups.

In CDOT we’ve simplified the commands and protocol: to create a SnapVault relationship, you run “SnapMirror create –type XDP.”  To create a SnapMirror relationship, you run “SnapMirror create –type DP.”  Here’s an example of setting up SnapMirror via CLI.

vs2::> snapmirror create -destination-path vs2:dept_eng_dp_mirror2 -source-path vs1:dept_eng -type DP

The primary distinction between DP SnapMirror and XDP SnapMirror is that SnapVault allows you to keep more snapshots on the destination.  Essentially, XDP SnapMirror is for long-term backups.  Other differences:

•           DP SnapMirror relationships can be reversed (swap destination and source)
•           DP SnapMirror can replicate every minutes, XDP SnapMirror once per hour.
•           DP SnapMirror destination volumes can be made read/write.

Do you have some datasets that would benefit from a quicker time to recovery or have stricter SLA’s?  If so, DP SnapMirror is the best choice.    Now, with many systems and many volumes being replicated, how do you keep track of it all?  In our no-cost tool OCUM 6.0, there is a “Protection” tab that allows you to setup, change, remove, restore, and monitor all your replication relationships. 

Because ONTAP is our single-platform operating system, this also means you can replicate to the cloud (Cloud ONTAP in AWS or Azure), to an all-SATA NetApp “backup” system, or any other NetApp you have.  This “ONTAP everywhere” ubiquity is part of why ONTAP manages more exabytes than any other storage operating system in the world.

SnapMirror vs SnapVault in CDOT

 In CDOT we’ve simplified the commands and protocol: to create a snapvault relationship, you run “SnapMirror create –type XDP.”  To create a SnapMirror relationship, you run “SnapMirror create –type DP.”  In fact, for CDOT we no longer call it snapvault, it is called XDP SnapMirror. 

e.g., vs2::> snapmirror create -destination-path vs2:dept_eng_dp_mirror2 -source-path vs1:dept_eng -type DP

The primary distinction between DP snapmirror and XDP SnapMirror is that snapvault allows you to keep more snapshots on the destination.  Essentially, XDP snapmirror is for long-term backups.  Other differences:

·         DP SnapMirror relationships can be reversed (swap destination and source)

·         DP SnapMirror can replicate every minutes, XDP SnapMirror once per hour.

·         DP SnapMirror destination volumes can be made read/write.

Do you have some datasets that would benefit from a quicker time to recovery or have stricter SLA’s?  If so, DP SnapMirror is the best choice.  

NetApp Training Brain Dump: Snapshots

The concept here is that a snapshot can become as large as the original dataset in the volume (100%).  Remember that the space occupied by data in the volume is the sum of the existing LUNS/Qtrees and any snapshots that exist in that volume.  Empty space in the volume is ignored by snapshots.


Here's the important background idea: WAFL does not update-in-place when existing data is changed.  This means that for a normal LUN that has no snapshots, when data changes, it is written to a new location (total space occupied increases) and then the old data is deleted (total space occupied goes back to pre-change levels).

Illustration: If in a LUN with 6GB of data a 4KB block is changed, the sum total of space occupied by data rises to 6GB + 4KB, then back to 6GB as the out of date 4KB block is deleted and reclaimed.  WAFL handles this so quickly that your LUN effectively does not increase in size.  This is a great advantage for WAFL because update in place can cause data corruption.

This concept is essential to understanding how snapshots work in ONTAP.  Let's go back to our 6GB LUN with a 4KB change: WAFL writes the new 4KB data to new, unoccupied space and the snapshot is left occupying the space that would be otherwise deleted.  So as data changes, it is not actually the snapshot that is allocated more space, but its existence means that the space that could be reclaimed is now solely assigned to the snapshot.  So any data that is only assigned to the snapshot is considered occupied by the snapshot.  In this example, the snapshot would be considered to be 4KB in size.


If you're a visual learner like me, checking out this diagram will help you picture the concept.  


The size taken up by the snapshot increases in concert with the changes to the original LUN: 500MB of changes to the original LUN means that the snapshot will grow from 0 to 500MB in size.  For 20GB volume that has 6GB of data (including LUNs and other snapshots), the next snapshot can grow as large as 6GB, making the sum total of the original data and the new snapshot 12GB.  


You can find commands to control snapshots here.

NetApp Training Brain Dump: SnapVault

Data replication (DR) is a pretty easy concept: you copy stuff from this system to another.  Ta-da!  
Backups are a pretty easy concept: you copy stuff from this system to another spot (either on the same system or another).  Ta-da!

Where you'll need to concentrate your brainpower is on the nuances of the implementation, both in terms of what a DR/Backup product does and how you need to use that to keep your data protected.  Here's a quick run down of SnapVault, NetApp's flagship DR/Backup product*1:

SnapVault can copy volumes or Qtrees.  You use this product to copy data from one FAS system (primary) to another (secondary, usually cheaper storage system) by setting up a schedule with retention periods.  SV will delete ("roll off") old backups as they get too old based upon how you set it up ("only keep 3 latest copies...").


SV does a basic full copy at first, which obviously takes a bit.  After that, it copies snapshots based upon your schedule, which essentially are incremental backups*2.  This is the most space-efficient method of preserving data, since only the data that has changed is replicated after the full backup.  


The built-in options for SV are hourly, daily, and weekly backups.  Monthly and other options are available but require specialized scripts.  SV obviously gives you flexibility to decide to keep a different number of snapshots on the primary than the secondary.  All backups are read only, but LUNS/Qtrees can be presented normally and used as read only.  


This setup is pretty darn space efficient, extremely fast, protects your data from a lot of dangers, gives you flexibility to set up backup architectures (e.g., present a read-only LUN from the backup to a backup server to send the data to tape), and saves you money by allowing the low-use backup data to be on cheaper storage.  


Digging a little bit deeper, here's how SV works: 

1. You set up a schedule for SV to take snapshots on your primary.
2. You set up a schedule for SV to replicate those snapshots at a certain rate to the secondary
3. SV does a full copy to the secondary
4. SV does a snapshot on the primary
5. From the secondary, SV pulls the primary's first snapshot.
6. SV continues doing snapshots on the primary
7. On the secondary, SV compares the current snapshot it has to the newest snapshot and replicates any changes
8. repeat steps 6 and 7 indefinitely

Remember, we're talking about snapshots vs regular incrementals: this means that the initial snapshot being replicated (step 5) will have no data at all, since none of the data has changed.  But by step 7, the initial snapshot has grown significantly.  It is not this, the first snapshot, that is replicated: it is the latest one.  But the latest snapshot on the primary will itself have less data in it than has changed since the last time the secondary received a snapshot replication, so the secondary must find the changes since the last snapshot replication and copy those.  Draw this out for yourself if you have trouble picturing it.  

Credit: me!

*1: Don't confuse SnapVault with SnapMirror.  SnapMirror does a one to one copy for failover, while SnapVault just copies data for retention. 

*2: refresher: full backups are complete copies, incremental backups are "what's changed since the last full or incremental," and differential backups are "what's changed since the last full."   Differential backups obviously become larger and waste more space as the time goes on since the latest full.


Great, honest convo back-and-forth about SV's strengths and weaknesses:
http://communities.netapp.com/message/26593#26593


Official NetApp SnapVault Doc: tr-3487.pdf