NetApp 7-Mode: Undocumented features or doing DR from SnapVault
In continuation of the article about the NetApp backup paradigm , I want to talk about the undocumented possibility of converting "archival copies" into "backup" for the FAS series. A distinctive feature of NetApp FAS series storage systems is that they are all unified. Uniformity not only in the fact that one device provides access to hosts both by block and file protocols, but also by the method of application. FAS systems are used for virtualization, for Data Compliance, for storing backup copies, for building Disaster Recovery solutions, etc. The same storage system can perform many functions at once. So for each function, you do not need to keep one “specialized” device, and in case you need an “spare” storage system , you can always “repurpose” it from what is, for example, from a 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 the configuration principles are the same for all FAS systems.
In this article, I’ll tell you how to convert the built-in solution “Archiving Data to NetApp” into a “Disaster Recovery” solution.
From a business perspective, Disaster Recovery and archiving are different in that:
')
Let me explain with an 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 a crash, when replication is discontinued (with the break command, and not just breaking the link), the receiving (Secondary) system will translate the replicable mirror from read-only mode to read-write mode. Those. It is a tool for creating a solution “Switching to a spare site in case of an accident” (Disaster Recovery). It is logical that both systems have a plus or minus of the same performance in order to ensure all the nodes switched from one site to another, due level of performance.
While SnapVault is designed for archiving to a backup (Secondary) system, in order to restore all data from it back to the primary system or to a third system in general. 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 added, can be any model. It is logical to have the cheapest model of NetApp FAS with slower and cheaper larger disks. 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.
QSM SnapMirror 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 replicate data asynchronously on a schedule. But for that, the SnapVault archives transferred as snapshots once on a remote system can be duplicated ( WAFL File Folding works in the same 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 modified data to the remote system in the form of snapshots and storing them in deduplicated form. Those. snapshots are analogous to incremental backups, if you try to bring terminology closer to standard backup terminology, then snapshots from NetApp are analogous to reverse incremental backups. Such backups (snapshots) do not need to be assembled into a “full backup” and waste time loading the system, while taking up such archives place as regular incremental backups. I want to draw attention to the fact that the “classic implementation” of snapshots using COW technology from other manufacturers is different from NetApp snepsing 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 relationship breakdown, the data on the secondary system does not go into read-write mode, these are archives, right?
In this connection, the SnapVault archiving license is much cheaper than SnapMirror. I’ll tell you right now that I’m not going to talk about prices here, please, to authorized persons - your integrators, distributors and representatives. I am an engineer and work with technology, not prices.
Let me remind you that both in the case of SnapVault and in the case of SnapMirror, the licenses are not “terabyte”, but “by controller”, a license is required both at the source and at the recipient. Let me give an example: there are two HA (two controllers in a fault-tolerant pair) of the system, one on the main one, the other on the backup site, in the amount of 4 controllers, for replication whether SnapMirror, whether SnapVault needs to acquire 4 corresponding licenses.
Sometimes it happens that when using SnapVault, well, it’s very straightforward that we need to transfer our archive to read-write mode and, in an emergency, emergency or abnormal case, on the basis of the secondary system, raise the DR site. That is, convert the archive system to the DR system, even if it is weaker than the main one. Since QSM SnapMirror and inside "under the hood" is the same SnapVault, this can be done with the help of not documented service commands.
Let me remind you that all operations you perform 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 the representative office, usually this is a very fast process:
Make sure SnapMirror is turned off:
If you have a FlexClone license or you have ordered a trial license, I recommend using it in order not to touch or damage your backup archives, but to make a complete thin copy of the data and work with it already. By the way, let me remind you that in thin cloning of NetApp, unlike, for example, IBM Storwize block cloning, there is no drop in performance from any number of such clones. If there is no license and you will convert the backup, skip this step and go to the next one.
Cloning will also copy “SnapVault Relationships”
Next, perform the magic combination of the commands for conversion:
SnapVault only works with Qtree * , you need to convert Qtree accordingly. Not only Qtree itself, but also replication “relationships” are converted into SnapMirror. In the same way, you can convert “in the other direction” from QSM to SnapVault.
Turn on SnapMirror
Without SnapMirror enabled, you cannot break a relationship (now SnapMirror is a relationship, they were converted too)
Stop the relationship. And finally we tear them (if necessary) in order to transfer the Volyum to the RW state.
Remove the SnapMirror license if necessary:
I want to draw your attention to the fact that as a result you can see in the current NetApp file system the latest archived data that has been replicated to it, available for recording. But to restore the older snapshots, in several ways:
Copy them with pens from snapshots, for example, using the NDMP ndmpcopy command from the storage command line or copy all the necessary data through the host in the standard way for it, by entering the hidden snapshoot folder.
You can also use another SnapRestore license, which instantly rolls back the current file system to the desired snapshot.
The third option is that at the stage of cloning an archive (volyuma with qtree), you can clone not the state of the actual data on the NetApp filesystem , but one of the stored snapshots, thus, without resorting to a SnapRestore license or a long-term manual copy.
* Qtree - Application for replication in NetApp FAS systems with DataONTAp Cluster-Mode OS (Clustered ONTAP) is no longer required, as SnapVault and SnapMirror QSM are now able to replicate and restore data at the Volume level.
I ask to send messages on errors in the text to the LAN .
Notes and additions on the contrary please in the comments
In this article, I’ll tell you how to convert the built-in solution “Archiving Data to NetApp” into a “Disaster Recovery” solution.
From a business perspective, Disaster Recovery and archiving are different in that:
- Archiving (SnapVault) - the solution is designed for long-term storage and protection of data from changes, for subsequent restoration to where they were copied from (or to another location).
- Disaster Recovery (SnapMirror) - storing data on a backup site, to switch to it (and, accordingly, changing data) in the event of a disaster.
')
Let me explain with an 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 a crash, when replication is discontinued (with the break command, and not just breaking the link), the receiving (Secondary) system will translate the replicable mirror from read-only mode to read-write mode. Those. It is a tool for creating a solution “Switching to a spare site in case of an accident” (Disaster Recovery). It is logical that both systems have a plus or minus of the same performance in order to ensure all the nodes switched from one site to another, due level of performance.
While SnapVault is designed for archiving to a backup (Secondary) system, in order to restore all data from it back to the primary system or to a third system in general. 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 added, can be any model. It is logical to have the cheapest model of NetApp FAS with slower and cheaper larger disks. 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.
QSM SnapMirror 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 replicate data asynchronously on a schedule. But for that, the SnapVault archives transferred as snapshots once on a remote system can be duplicated ( WAFL File Folding works in the same 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 modified data to the remote system in the form of snapshots and storing them in deduplicated form. Those. snapshots are analogous to incremental backups, if you try to bring terminology closer to standard backup terminology, then snapshots from NetApp are analogous to reverse incremental backups. Such backups (snapshots) do not need to be assembled into a “full backup” and waste time loading the system, while taking up such archives place as regular incremental backups. I want to draw attention to the fact that the “classic implementation” of snapshots using COW technology from other manufacturers is different from NetApp snepsing 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 relationship breakdown, the data on the secondary system does not go into read-write mode, these are archives, right?
In this connection, the SnapVault archiving license is much cheaper than SnapMirror. I’ll tell you right now that I’m not going to talk about prices here, please, to authorized persons - your integrators, distributors and representatives. I am an engineer and work with technology, not prices.
Let me remind you that both in the case of SnapVault and in the case of SnapMirror, the licenses are not “terabyte”, but “by controller”, a license is required both at the source and at the recipient. Let me give an example: there are two HA (two controllers in a fault-tolerant pair) of the system, one on the main one, the other on the backup site, in the amount of 4 controllers, for replication whether SnapMirror, whether SnapVault needs to acquire 4 corresponding licenses.
Sometimes it happens that when using SnapVault, well, it’s very straightforward that we need to transfer our archive to read-write mode and, in an emergency, emergency or abnormal case, on the basis of the secondary system, raise the DR site. That is, convert the archive system to the DR system, even if it is weaker than the main one. Since QSM SnapMirror and inside "under the hood" is the same SnapVault, this can be done with the help of not documented service commands.
Let me remind you that all operations you perform 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 the 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 you have ordered a trial license, I recommend using it in order not to touch or damage your backup archives, but to make a complete thin copy of the data and work with it already. By the way, let me remind you that in thin cloning of NetApp, unlike, for example, IBM Storwize block cloning, there is no drop in performance from any number of such clones. If there is no license and you will convert the backup, skip this step and go to the next one.
netapp-sec1-7M> vol clone create new_infra -b backup
Cloning will also copy “SnapVault Relationships”
Next, perform the magic combination of the 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 * , you need to convert Qtree accordingly. Not only Qtree itself, but also replication “relationships” are converted into SnapMirror. In the same way, you can convert “in the other direction” from QSM to SnapVault.
Turn on SnapMirror
netapp-sec1-7M> snapmirror on
Without SnapMirror enabled, you cannot break a relationship (now SnapMirror is a relationship, they were converted too)
Stop the relationship. And finally we tear them (if necessary) in order to transfer the Volyum to the RW state.
netapp-sec1-7M> snapmirror quiesce /vol/new_infra/nfs netapp-sec1-7M> snapmirror break /vol/new_infra/nfs
Remove the SnapMirror license if necessary:
netapp-sec1-7M> license delete SNAPMIRRORCODE
I want to draw your attention to the fact that as a result you can see in the current NetApp file system the latest archived data that has been replicated to it, available for recording. But to restore the older snapshots, in several ways:
Copy them with pens from snapshots, for example, using the NDMP ndmpcopy command from the storage command line or copy all the necessary data through the host in the standard way for it, by entering the hidden snapshoot folder.
You can also use another SnapRestore license, which instantly rolls back the current file system to the desired snapshot.
The third option is that at the stage of cloning an archive (volyuma with qtree), you can clone not the state of the actual data on the NetApp filesystem , but one of the stored snapshots, thus, without resorting to a SnapRestore license or a long-term manual copy.
* Qtree - Application for replication in NetApp FAS systems with DataONTAp Cluster-Mode OS (Clustered ONTAP) is no longer required, as SnapVault and SnapMirror QSM are now able to replicate and restore data at the Volume level.
I ask to send messages on errors in the text to the LAN .
Notes and additions on the contrary please in the comments
Source: https://habr.com/ru/post/244667/
All Articles