January 26, 2015 at 21:34NetApp 7-Mode: Undocumented Features or Making DR from SnapVault
In continuation of the article on the NetApp backup paradigm , I want to talk about the undocumented possibility of converting “archival copies” to “backups” for the FAS series . A distinctive feature of NetApp FAS storage systems is that they are all unified. The unification is not only in the fact that one device provides access to hosts both in block and file protocols, but also in the method of application. FAS systems are used for virtualization, for Data Compliance, for storing archive copies, for building Disaster Recovery solutions, etc. The same storagecan perform many functions at once. So for each function you do not need to keep one “specialized” device, and in case you urgently need a “spare” storage system , you can always “re-profile” it from what it is, for example, from storage system for data archiving. Thanks to this versatility, there is no need to retrain for each of these tasks, because the operating system, command line and all configuration principles are the same for all FAS systems.
In this article, I will tell you how to convert the built-in solution "Archiving data on NetApp" into the solution "Disaster Recovery".
From a business perspective, Disaster Recovery and archiving differ in that:
Let me explain by example: when you have at least two storage systems with configured SnapMirror replication, in such a scheme one of them plays the role of a source (primary), and the second role of a receiver (Secondary). In the event of an accident, when replication breaks (with the break command, and not just a link break), the Secondary system will switch the replicated mirror from read-only mode to read-write mode. Those. it is a tool for creating the solution “Switching to a spare site in case of an accident” (Disaster Recovery). It is logical that both systems have plus or minus the same performance to provide all switched nodes from one site to another with the proper level of performance.
While SnapVault is designed for archiving to a backup (Secondary) system, then later restore all data from it back to the primary system or even to the third system. It is worth noting that for archiving tasks it is very important to store data in an unchanged state all the time. In this case, the secondary system, where all the archives are stored, can be of any model. It makes sense to have the cheapest NetApp FAS model with slower and cheaper larger drives. For example, FAS2554 or FAS2520 .
In more detail how SnapMirror and SnapVault work, you can read the relevant articles, as well as compare these two solutions from a technical point of view.
QSMSnapMirror works almost the same as SnapVault and uses the same algorithm and internal replication device, SnapMirror except QSM , also includes block replication VSM . Block replication can be synchronous or asynchronous, while SnapVault and QSM SnapMirror only asynchronously replicate scheduled data. But for that, SnapVault archives transmitted in the form of snapshots after hitting a remote system can be published ( WAFL File Folding works in a similar way), with the contents of previous snapshots (not to be confused with deduplication inside the active file system). Thus, SnapVault will provide an analogue of various kinds, types of archives, transferring only changed data in the form of snapshots to the remote system and storing them in deduplicated form. Those. snapshots are an analog of incremental backups, if you try to approximate the terminology to the standard terminology of backups, then snapshots with NetApp are an analog of reverse incremental backups. Such backups (snapshots) do not need to be assembled into a “full backup” and wasting time loading the system, while archives occupy a place like ordinary incremental backups. I want to draw attention to the fact that the "classic implementation" of snapshots using COW technologyfrom other manufacturers differs from NetApp snapshot technology. So snapshots working on COW technology have a drop in performance, with an increase in their number. More details .
The downside of SnapVault is that in the event of a break in relations, the data on the secondary system does not go into read-write mode, these are archives, right?
Therefore, the SnapVault archiving license is much cheaper than SnapMirror. I must say right away that I’m not going to talk about prices here, these questions, please, to authorized persons - to your integrators, distributors and representatives. I am an engineer and work with technology, not pricing.
Let me remind you that both in the case of SnapVault, and in the case of SnapMirror, licenses are not "per terabyte", but "per-controller", i.e. a license is required both at the source and at the recipient. Let me give you an example: there are two HA (two controllers in a fault-tolerant pair) systems, one on the main one, the other on the backup site, in the amount of 4 controllers, for replication whether it is SnapMirror or SnapVault, you need to purchase 4 corresponding licenses.
Sometimes it happens that when using SnapVault, it’s very straightforward to urgently need to transfer our archive to read-write mode and in an emergency, emergency or emergency case, on the basis of a secondary system, raise the DR site. That is, convert the archive system to a DR system, even if it is weaker than the main one. BecauseQSM SnapMirror and inside the "under the hood" is the same SnapVault, this can be done with the help of undocumented service commands.
Let me remind you that you perform all operations at your own peril and risk, the author does not bear any obligations and guarantees.
Add a SnapMirror license, you can request a trial license from a representative office, usually this is a very fast process:
Make sure SnapMirror is turned off:
If you have a FlexClone license or have ordered a trial license, I recommend using it so as not to touch or damage your backup archives, but to make a full thin copy of the data and work with it already. By the way, I remind you of thin cloning NetApp, unlike, for example, IBM Storwize block cloning, there is no performance drop from any number of such clones. If there is no license, and you will convert the backup, skip this step and proceed to the next.
During cloning, “SnapVault relationships” will be copied.
Next, we perform a magic combination of commands for conversion:
SnapVault only works with Qtree * , so you need to convert Qtree. Not only Qtree itself is converted to SnapMirror, but also the “relationship” of replication. In the same way, you can convert the “other way” from QSM to SnapVault.
Turn on SnapMirror
Without SnapMirror enabled, you cannot break off relationships (now SnapMirror relationships, they converted too)
Stop the relationship. And finally they are torn (if necessary) in order to translate the volume into the RW state.
Delete the SnapMirror license if necessary:
I want to draw attention to the fact that as a result, you can see in the current NetApp file system the latest data that has been replicated to it and is available for recording. But to restore the older snepshoty, in several ways:
Copy them from snepshotov handles, for example by using NDMP commands ndmpcopy command-line storage or copy all the data through the host in a standard way for him, going to the hidden folder «snapshoot».
You can also use another SnapRestore license , which instantly rolls back the current file system to the required snapshot.
The third option is that at the stage of cloning the archive (the volume with qtree), you can clone not the state of the actual data on the NetApp FS , but one of the stored snapshots, thus, without resorting to the SnapRestore license or to lengthy manual copying.
* Qtree - Application for replication in NetApp FAS systems with DataONTAp Cluster-Mode (Clustered ONTAP), is no longer required, since SnapVault and SnapMirror QSM are now able to replicate and restore data at the Volume level .
Please send messages about errors in the text to the LAN .
Comments and additions on the contrary please comment
In this article, I will tell you how to convert the built-in solution "Archiving data on NetApp" into the solution "Disaster Recovery".
From a business perspective, Disaster Recovery and archiving differ in that:
- Archiving (SnapVault) - the solution is intended for long-term storage and protection of data from changes, for their subsequent restoration to where they were copied (or to another place).
- Disaster Recovery (SnapMirror) - storage of data on a backup site, to switch to it (and, accordingly, change data) in case of a disaster.
Let me explain by example: when you have at least two storage systems with configured SnapMirror replication, in such a scheme one of them plays the role of a source (primary), and the second role of a receiver (Secondary). In the event of an accident, when replication breaks (with the break command, and not just a link break), the Secondary system will switch the replicated mirror from read-only mode to read-write mode. Those. it is a tool for creating the solution “Switching to a spare site in case of an accident” (Disaster Recovery). It is logical that both systems have plus or minus the same performance to provide all switched nodes from one site to another with the proper level of performance.
While SnapVault is designed for archiving to a backup (Secondary) system, then later restore all data from it back to the primary system or even to the third system. It is worth noting that for archiving tasks it is very important to store data in an unchanged state all the time. In this case, the secondary system, where all the archives are stored, can be of any model. It makes sense to have the cheapest NetApp FAS model with slower and cheaper larger drives. For example, FAS2554 or FAS2520 .
In more detail how SnapMirror and SnapVault work, you can read the relevant articles, as well as compare these two solutions from a technical point of view.
QSMSnapMirror works almost the same as SnapVault and uses the same algorithm and internal replication device, SnapMirror except QSM , also includes block replication VSM . Block replication can be synchronous or asynchronous, while SnapVault and QSM SnapMirror only asynchronously replicate scheduled data. But for that, SnapVault archives transmitted in the form of snapshots after hitting a remote system can be published ( WAFL File Folding works in a similar way), with the contents of previous snapshots (not to be confused with deduplication inside the active file system). Thus, SnapVault will provide an analogue of various kinds, types of archives, transferring only changed data in the form of snapshots to the remote system and storing them in deduplicated form. Those. snapshots are an analog of incremental backups, if you try to approximate the terminology to the standard terminology of backups, then snapshots with NetApp are an analog of reverse incremental backups. Such backups (snapshots) do not need to be assembled into a “full backup” and wasting time loading the system, while archives occupy a place like ordinary incremental backups. I want to draw attention to the fact that the "classic implementation" of snapshots using COW technologyfrom other manufacturers differs from NetApp snapshot technology. So snapshots working on COW technology have a drop in performance, with an increase in their number. More details .
The downside of SnapVault is that in the event of a break in relations, the data on the secondary system does not go into read-write mode, these are archives, right?
Therefore, the SnapVault archiving license is much cheaper than SnapMirror. I must say right away that I’m not going to talk about prices here, these questions, please, to authorized persons - to your integrators, distributors and representatives. I am an engineer and work with technology, not pricing.
Let me remind you that both in the case of SnapVault, and in the case of SnapMirror, licenses are not "per terabyte", but "per-controller", i.e. a license is required both at the source and at the recipient. Let me give you an example: there are two HA (two controllers in a fault-tolerant pair) systems, one on the main one, the other on the backup site, in the amount of 4 controllers, for replication whether it is SnapMirror or SnapVault, you need to purchase 4 corresponding licenses.
Sometimes it happens that when using SnapVault, it’s very straightforward to urgently need to transfer our archive to read-write mode and in an emergency, emergency or emergency case, on the basis of a secondary system, raise the DR site. That is, convert the archive system to a DR system, even if it is weaker than the main one. BecauseQSM SnapMirror and inside the "under the hood" is the same SnapVault, this can be done with the help of undocumented service commands.
Let me remind you that you perform all operations at your own peril and risk, the author does not bear any obligations and guarantees.
Add a SnapMirror license, you can request a trial license from a representative office, usually this is a very fast process:
netapp-sec1-7M> license add SNAPMIRRORCODE
Make sure SnapMirror is turned off:
netapp-sec1-7M> snapmirror off
If you have a FlexClone license or have ordered a trial license, I recommend using it so as not to touch or damage your backup archives, but to make a full thin copy of the data and work with it already. By the way, I remind you of thin cloning NetApp, unlike, for example, IBM Storwize block cloning, there is no performance drop from any number of such clones. If there is no license, and you will convert the backup, skip this step and proceed to the next.
netapp-sec1-7M> vol clone create new_infra -b backup
During cloning, “SnapVault relationships” will be copied.
Next, we perform a magic combination of commands for conversion:
netapp-sec1-7M> options snapvault.enable off
netapp-sec1-7M> priv set diag; snapmirror convert /vol/new_infra/nfs; priv set
netapp-sec1-7M> options snapvault.enable on
SnapVault only works with Qtree * , so you need to convert Qtree. Not only Qtree itself is converted to SnapMirror, but also the “relationship” of replication. In the same way, you can convert the “other way” from QSM to SnapVault.
Turn on SnapMirror
netapp-sec1-7M> snapmirror on
Without SnapMirror enabled, you cannot break off relationships (now SnapMirror relationships, they converted too)
Stop the relationship. And finally they are torn (if necessary) in order to translate the volume into the RW state.
netapp-sec1-7M> snapmirror quiesce /vol/new_infra/nfs
netapp-sec1-7M> snapmirror break /vol/new_infra/nfs
Delete the SnapMirror license if necessary:
netapp-sec1-7M> license delete SNAPMIRRORCODE
I want to draw attention to the fact that as a result, you can see in the current NetApp file system the latest data that has been replicated to it and is available for recording. But to restore the older snepshoty, in several ways:
Copy them from snepshotov handles, for example by using NDMP commands ndmpcopy command-line storage or copy all the data through the host in a standard way for him, going to the hidden folder «snapshoot».
You can also use another SnapRestore license , which instantly rolls back the current file system to the required snapshot.
The third option is that at the stage of cloning the archive (the volume with qtree), you can clone not the state of the actual data on the NetApp FS , but one of the stored snapshots, thus, without resorting to the SnapRestore license or to lengthy manual copying.
* Qtree - Application for replication in NetApp FAS systems with DataONTAp Cluster-Mode (Clustered ONTAP), is no longer required, since SnapVault and SnapMirror QSM are now able to replicate and restore data at the Volume level .
Please send messages about errors in the text to the LAN .
Comments and additions on the contrary please comment