With the release of clustered Data ONTAP 8.3.1 comes a whole new and exciting set of features, such as:
- Improved inline compression
- FlashEssentials flash optimizations
- Online foreign LUN import
But the one I’ll cover here is Storage Virtual Machine DR, which is a key component of the enterprise storage story.
Let’s start off with some terminology definitions:
Clustered Data ONTAP
Clustered Data ONTAP is enterprise-capable, unified scale-out storage. It is the basis for virtualized
shared storage infrastructures. Clustered Data ONTAP is architected for nondisruptive operations,
storage and operational efficiency, and scalability over the lifetime of the system.
A Data ONTAP cluster typically consists of fabric-attached storage (FAS) controllers: computers
optimized to run the clustered Data ONTAP operating system. The controllers provide network ports that
clients and hosts use to access storage. These controllers are also connected to each other using a
dedicated, redundant 10-gigabit Ethernet interconnect. The interconnect allows the controllers to act as a
single cluster. Data is stored on shelves attached to the controllers. The drive bays in these shelves can
contain hard disks, flash media, or both.
Storage Virtual Machine (SVM)
A cluster provides hardware resources, but clients and hosts access storage in clustered Data ONTAP
through storage virtual machines (SVMs). SVMs exist natively inside clustered Data ONTAP. They define
the storage available to the clients and hosts. SVMs define authentication, network access to the storage
in the form of logical interfaces (LIFs), and the storage itself in the form of SAN LUNs or NAS volumes.
Clients and hosts are aware of SVMs, but they may be unaware of the underlying cluster. The cluster
provides the physical resources the SVMs need in order to serve data. The clients and hosts connect to
an SVM, rather than to a physical storage array.
Like compute virtual machines, SVMs decouple services from hardware. Unlike compute virtual
machines, a single SVM can use the network ports and storage of many controllers, enabling scale-out.
One controller’s physical network ports and physical storage also can be shared by many SVMs, enabling
NetApp® SnapMirror® technology provides fast, efficient data replication and disaster recovery (DR) for your critical data.
Use a single solution across all NetApp storage arrays and protocols. SnapMirror technology works with any application, in both virtual and traditional environments, and in multiple configurations, including hybrid cloud.
Tune SnapMirror technology to meet recovery-point objectives ranging from minutes to hours. Fail over to a specific point in time in the DR copy to recover at once from mirrored data corruption.
Disaster Recovery (DR)
This is pretty standard; it’s a set of policies and procedures put in place for enterprise IT organizations to recover from a catastrophic loss of service at a primary site. Ideally, the failover will be instantaneous and service will be restored quickly, with as little disruption as possible.
No one needs DR… until they do.
One of the most criminally ignored sections of IT is backup and DR. This is because it costs money and doesn’t immediately make you any money. The ROI is low, so it becomes a low priority when it should be one of the highest priorities.
Luckily, the cloud is making DR more of a reality (through things like DRaaS, offered by Cloud ONTAP), as cloud storage prices are dropping and allowing companies to start taking DR more seriously. And remember – your data is only as good as your last restore test.
What is SVM DR?
Storage Virtual Machines (SVMs) are essentially blades running Data ONTAP, more or less. They act as their own tenants in a cluster and could represent individual divisions, companies or test/prod environments.
However, even with multiple SVMs, you still end up with a single point of failure – the storage system itself. If a meteor hit your datacenter, your cluster would be toast and your clients would be dead in the water, unless you planned for disaster recovery accordingly.
SVM DR allows disaster recovery capability at a granular SVM level, as opposed to having to replicate an entire cluster or filer. This is analogous to the vfiler DR functionality available in 7-Mode.
SVM DR does the following:
- Leverages NetApp SnapMirror to replicate data to a secondary site.
- Leverages the new Configuration Replication Service (CRS) application to replicate SVM configuration, including CIFS/SMB shares, network information, NFS exports, etc.
- Allows two flavors of SVM DR – Identity Preserving and Identity Discarding.
This replicates the primary SVM’s configuration and allows us to change to that identity in a failover scenario. One use case for this would be DR on the same physical campus/site (two separate buildings).
The following graphic shows what is (and is not) replicated for SVM DR in Identity Preserve:
This allows us to use a different network configuration on a secondary SVM and bring it online as its own identity. A use case for this would be DR to a different geographical location in the world.
The following graphic shows what is (and is not) replicated for SVM DR in Identity Discard:
How it works
The flow of operation in SVM DR is essentially:
- Create SVM DR relationship/schedule
- Initialize the SnapMirror
- Ensure updates are successful
- Test DR
When we test (or do a real failover) to DR, the following happens:
- SnapMirror break; break means we can now do R/W operations
- SnapMirror goes from snapmirrored to broken-off
- Depending on identity type, we either preserve or discard old identity
- SVM DR destination goes from dp-destination to default
- Once source site is back up, we can do a resync/flip-resync
When the flip resync occurs:
- Data written to DR destination gets synced back to source to ensure we have current copy of data and config; this uses a new SVM DR relationship
- After we’re synced up, the original SVM DR relationship is re-established
- The flip resync SnapMirror gets broken off and removed
- SVM DR destination changes from default to dp-destination
- Snapmirror goes from broken-off to snapmirrored
Some things to keep in mind
While SVM DR makes heavy use of SnapMirror functionality, it is not a true SnapMirror in terms of how it is managed.
- qtrees in the SVM root volume do *not* get replicated.
- If you mount a qtree under SVM root and then mount a volume below that qtree, SVM DR will fail unless there is a qtree with the same name created in the destination SVM root volume.
- All non-SVM root volumes (data volumes) have are type DP.
- You cannot manage SVM DR SnapMirrors independently. They must be managed via the SVM level as a single entity.
- SVM DR snapshots are named with vserverdr….
- If reverting from 8.3.1, all SVM DR relationships and snapshots must be deleted before revert.
- Source and destination should be at 8.3.1 or later; source version should never be higher than destination.
- Source and destination must have SnapMirror licenses.
- Destination cluster should have at least one non-root aggregate with at least 10GB free space for configuration replication.
- Destination cluster must have same licenses (ie, CIFS, NFS, FCP, etc.) as source to ensure full functionality as source upon failover.
- If using NFS mounts, clients must remount the volumes on DR failover, as the FSIDs will change. NOTE: ONTAP 9 now supports FSID preservation on SVM DR!
For more information on SVM DR, be sure to check TR-4015 for updates as 8.3.1 goes to general availability (GA – find out what that is here) and follow the SVM DR/Multi-tenancy TME Doug Moore on Twitter @mooredo21. Doug will also be presenting SVM DR sessions at NetApp Insight 2015 in Las Vegas and Berlin.
I’ll also be presenting some sessions at NetApp Insight 2015, so keep checking back at whyistheinternetbroken.com for updates!
If you’re interested in step by step guides of how to set up SVM DR, check out the Express Guides for your version of ONTAP!