The other day I saw NetApp announced a new Storage Replication Adapter for VMware Site Recovery Manager so I reached out to my NetApp buddy Chris Gebhardt for more details. Chris shared the following information so I thought I would pass it along.
By Chris Gebhardt, Principal Technical Marketing Engineer at NetApp
For those who may be familiar with VMware Site Recovery Manager (SRM) but not familiar with SRM’s Storage Replication Adapter (SRA), the SRA is a storage vendor-specific plug-in for VMware vCenter that enables communication between SRM and the storage controller. The SRA performs the storage functions for SRM from discovering arrays, test and recovery of DR plans, reprotect, and failback.
Compatibility
The NetApp SRA Server Appliance
The NetApp SRA 4.0 has been divided into two components, the SRA server and the SRA adapter. The SRA server is deployed as an OVA within the vSphere environment and contains the backend services required for SRM / SRA operation. It performs the communication between the vCenter and ONTAP.
There are multiple different deployment models that can be used depending on the number of sites and vCenter and Platform Services Controllers. In this version of the SRA, we have removed the dependency of the VASA Provider and now support vCenter in linked mode. You will be required to install the SRA server and adapter according to the deployment model you choose. Consult the Storage Replication Adapter 4.0 for ONTAP Installation and Setup Guide for more information on deployment models.
For the SRA server OVA deployment all that is required is a name, destination datastore, network configuration and new password for the administrative user. For the SRA adapter, the SRA server must first be installed and configured. Then from the SRM server, double click on the SRA adapter installer, enter the IP of the SRA server and password and you’re good to go!
While this architecture having multiple components may seem more complicated than the previous single installer or OVA, this architecture allows for customers to separate different tenants securely to create a multi-tenant DR capability discussed later in this article.
Version Flexible SnapMirror
NetApp has been working with VMware since the early days of SRM when SRAs were first introduced. VMware’s SRM along with NetApp’s SnapMirror replication has always been a great fit, especially with regards to testing recovery plans without breaking the replication relationships.
However, NetApp customers always struggled with having to upgrade Data ONTAP across their enterprise to maintain their replication relationships. We required that the destination be at the same or higher version as the source. This was especially impactful to customers who have active / active datacenters where they not only run production at both sites, but also replicate their data to each other. It required that they upgrade their entire environment to maintain replication. This inflexibility impacted most of our customers and was a significant pain point.
In Data ONTAP 8.3 NetApp introduced Version-Flexible SnapMirror. Customers could create new relationships or convert existing SnapMirror relationships to be version-flexible. With SRA 4.0, customers can now take advantage of Version-Flexible SnapMirror relationships.
Gone are the days that the entire enterprise had to upgrade Data ONTAP versions because of SnapMirror.
Multi-tenancy Disaster Recovery
Data ONTAP has a long history of supporting multi-tenancy. It started with virtualizing the access in isolated contexts called vFilers and matured with clustered Data ONTAP into Virtual Storage Machines. However, with prior versions of SRM, NetApp required the cluster admin credentials which made multi-tenant SRM, not really a true isolated multi-tenant DR as it required the cluster admin credentials.
With NetApp SRA 4.0, one can now add SVM admin credentials to Site Recovery Manager’s Array Manager to support true tenant isolation for DR.
Once the protected and recovery sites have been configured and replicated, it’s as simple as adding the IP address of the SVM to a new SRM Array Manager at both the protected and recovery site. The result is that each customer or tenant can now have their own isolated SRM environment.
Extended Data Protection
The NetApp SRA 4.0 now allows customers to cascade their SnapMirror relationships. A cascaded SnapMirror relationship is one in which a controller can be both a destination for one SnapMirror relationship and a source for another SnapMirror relationship. The top architecture in the diagram below shows a three hop SnapMirror relationship. The third site could be used as an additional DR site, an aggregated DR site for multiple locations, for test/dev, or could be an NPS (NetApp Private Storage) endpoint in the cloud. The extension of SnapMirror relationships into cascades provides for many varied use cases as they support up to three hops in a cascade as well as one-to-many and many-to-one relationships.
The second architecture shown below is the Mirror-Vault Extension. This gives customers the ability to replicate their data to a secondary site for DR purposes and then to extend that replication to a third site for archival purposes.
VMware Site Recovery Manager and ONTAP are now even more aligned with your data protection and recovery goals. With SRA 4.0, we improve multi-tenant DR capabilities, decrease management burden with version-flexible SnapMirror, and provide more customer use cases with extended DR. I am very happy to say that our joint customers can now support even more use cases with SRM then they could before.
