Outages are unpredictable and they can occur in any form. It could be a power interruption, ransomware attack, unknown human error, or a wrong software patch like a recent CrowdStrike update that can affect business operations. There are various factors system may go down and the organization needs to be well prepared to deal with such a situation. NetApp SnapMirror active sync can help in reducing the disruption.
SnapMirror active sync overview
NetApp® SnapMirror® active sync (formerly SnapMirror Business Continuity), provides nonstop data availability with zero RPO and RTO for continuous business operations. Powered by proven synchronous replication technology, it delivers cutting-edge resilience and performance for multisite protection with application-level granularity. With SnapMirror active sync, you get peace of mind with continuous data availability, delivered through a deployment that’s easy to manage and cost-effective. In my previous post published last year, I mentioned SnapMirror active sync’s (formerly SnapMirror Business Continuity) support for SCSI-3 PR from ONTAP 9.14.1 onwards.
What's new in ONTAP 9.15.1
SnapMirror active sync now supports symmetric active/active access enabling read and write IO operation from both copies of protected volumes with bidirectional synchronous replication. SnapMirror active sync can be configured as uniform access or non-uniform access. In uniform access, LUN paths from primary and secondary storage controllers are advertised to the SQL Server host, in the non-uniform path, the paths from primary storage are advertised to the local host available at that site and similarly paths from secondary storage are advertised to the host located at the secondary site.
The host proximity feature is introduced in ONTAP 9.15.1 to enable specific storage connections to be preferred for the host initiator, else by default, IOs will be served from multiple paths on a round-robin basis.
In a typical SQL Server deployment model, only the primary database copy running on primary storage will be active for read/write operations. The mirror copy at the secondary site can be used for generating reports, running batch processes, or testing purposes by creating a clone copy. Users can setup an SQL Server availability group to achieve high availability for databases and servers for business applications. When it comes to managing large-scale deployment, configuring Always On availability groups can be a tedious task for every database. For critical workloads, you may choose the availability group, but the majority of SQL Server databases can be configured with a storage level high availability solution.
SQL Server deployment with SnapMirror active sync
There are multiple ways SQL Server can be deployed with SnapMirror active sync. Organizations setup a standalone setup in virtualized SQL Server instances, for high availability solution they may rely on hypervisor HA capability. So, in the event of a disaster, VM compute may failover to a secondary site, and at the same site storage replication role will failover and IO's will be served from the secondary site. Since storage across the sites is active, failover will be transparent and seamless without any administrator intervention. Due to host proximity, the hypervisor running at the secondary site will discover the LUNs at the local site, discover the datastore, and bring the VM's up.
Similarly, SQL Server failover cluster instances can leverage SnapMirror active sync for database high availability. A SQL Server failover cluster instance provides server-level redundancy, if the primary server and storage go down then SQL Services and storage LUNs will fail over to another instance and storage, and database IOs will be served from secondary storage.
In any situation, since the LUNs are active on both the storage, database files on storage are readily available for IO request and no manual intervention or configuration changes are required in this case.
Three-way disaster recovery
Extending the use case, many organizations need to create three-way disaster recovery. Typically, NetApp SnapMirror synchronous is created between two DCs located in same region and asynchronous relationship is created between DCs located across different regions. If primary storage goes down, then the steps to reconfigure the relationship between the far DR site and the near DR site are explained in NetApp TR 4832 with complete processes and commands. In ONTAP 9.15.1, you don’t have to worry about running any API's as the process of establishing relationship between primary LUN to secondary LUN or vice versa is automated in SnapMirror active sync. Whenever the LUNs fail over to secondary storage, far DR storage controller will establish a relationship with secondary storage without any user intervention.
Simplified relationship
Configuring or managing SnapMirror active sync is simplified. In the latest enhancement, relationship status can be viewed from System Manager for primary and secondary storage systems. In addition, users can initiate a failover process from any controller. Databases using SnapMirror active sync can be backed up using the latest NetApp SnapCenter 6.0.
Managing business continuity is simplified with ONTAP 9.15.1 and you will discover how easy it is to implement based on application workload granularity. Strategizing availability solutions is critical to any organization and NetApp looks for efficient ways to protect data. For a more detailed explanation refer to the documentation SnapMirror active sync. Technical report TR-4878 on SnapMirror active sync architecture and deployment strategy has moved to ONTAP docs under SnapMirror active sync overview (netapp.com). For best practice on configuring Windows Server Failover Cluster on VMware vSphere, refer to documentation on Setup for Windows Server Failover Clustering on VMware vSphere.
