Storage
Mobility
Protection
Analysis and control
TOPICShare
NetApp SnapMirror® has been used for many years to achieve reliable and efficient data replication between on-premises storage appliances. With the advent of Cloud Volumes ONTAP, this capability has been extended to allow cloud-based appliances to be included in a replication topology, greatly simplifying complex deployments, such as the cloud-onboarding of applications or the setup of a cloud-based DR (disaster recovery) environment. Read more about how AWS snapshots can protect cloud deployments here.
Cloud Volumes ONTAP uses Amazon EC2 and Amazon EBS cloud resources to create a virtual storage appliance in AWS. An Cloud Volumes ONTAP instance can act as either the source or destination in a SnapMirror relationship in the same way as on-premises systems have been used previously. Users can synchronize data from on-premises to cloud, cloud to on-premises or cloud to cloud, as they require, keeping the data synchronized through incremental updates. The range of functionality provided by SnapMirror, and it’s integration with other Cloud Volumes ONTAP features, make it a flexible and very powerful data replication solution.In this article, we will examine how NetApp replication with SnapMirror works, how to set it up and the advantages of using SnapMirror to replicate your data to AWS storage.
NetApp SnapMirror Data Replication
What is Data Replication and How does NetApp SnapMirror Replication with AWS work?
Data replication is the process of taking data located in one location and making a copy of it in a different location. As suggested by the name, SnapMirror makes use of Cloud Volumes ONTAP snapshots to manage the transfer of data from one location to another.
Initially, a full copy based on a snapshot of the source volume is copied over to the destination to perform a baseline synchronization. As data changes occur at the source, a new snapshot is created and compared to the baseline snapshot. The blocks found to have changed are then replicated to the destination, with the newer snapshot becoming the current baseline, or newest common snapshot. This enables the process to be repeated and incremental updates to be sent to the destination.
When a SnapMirror relationship has been established, the destination volume is in an online read-only state, and so is still accessible. SnapMirror works with physical blocks of storage, rather than at a file or other logical level. This means that the destination volume is an identical replica of the source, including snapshots, volume settings, etc. If Cloud Volumes ONTAP space efficiency features, such as data compression and data deduplication, are being used by the source volume, the replicated volume will retain these optimizations.
Breaking the SnapMirror relationship makes the destination volume writable and would typically be used to perform a failover when SnapMirror is being used to synchronize data to a DR environment. SnapMirror is sophisticated enough to allow the data changed at the failover site to be efficiently resynchronized back to the primary system, should it later come back online, and then allow for the original SnapMirror relationship to be re-established.
SnapMirror can also be integrated with SnapCenter® in order replicate application consistent snapshots, such as those used for database system backups. The reason why these snapshots standout among other database replication tool and database replication techniques, is because Cloud Volumes ONTAP snapshots are created in coordination with the application using the underlying storage, there is a guarantee that no in-flight I/O operations will cause inconsistencies in the snapshot. After creating an application consistent snapshot, SnapCenter can then trigger SnapMirror to use the snapshot to synchronize all configured destinations. This also makes SnapMirror useful for database migration to the cloud, not to mention AWS data migration.
How do I set it up? SnapMirror NetApp Step-by-Step
NetApp Cloud Manager is the web-based UI for deploying Cloud Volumes ONTAP to AWS and for managing your on-premises and cloud-based NetApp storage infrastructure. Setting up new SnapMirror relationships through this interface couldn’t be easier: simply drag & drop the source ONTAP system in your environment onto the destination to trigger the wizard that guides you through the rest of the process.
The working environments screen in the Cloud Manager
The simple drag-and-drop volume replication process
The wizard will prompt you to choose the source and destination volumes for the new SnapMirror relationship, as well as other options, such as maximum transfer rate, so that you can control the network bandwidth used for synchronization. You will also need to select a synchronization schedule, which may be set to “One-time copy”.
Replication schedule setup
Finally, the wizard will ask you to review the requested setup and confirm that you wish to proceed. When the SnapMirror relationship has been created, the status of the AWS replication and data transfer can be monitored through the dashboard.
Monitoring replication and data transfer in the Cloud Manager
Why should I use SnapMirror?
The following section provides a summary of the main advantages to using SnapMirror:
- Robust enterprise technology: SnapMirror is a mature feature of ONTAP storage systems that NetApp have enhanced and improved over time. SnapMirror is able to recover from update failures, use concurrent processes for replication processing, throttle the network bandwidth used for transfer operations and much more.
- Fast and efficient: Block-level, incremental data transfer ensures that only the data that has changed is sent to destination replicas. SnapMirror can reduce this data volume further, thereby improving transfer performance, through the use of its network compression feature, which performs compression on the data as it leaves the source and decompression at the destination.
Flexible: SnapMirror gives you the ability to define different sync schedules, to better meet your system’s needs. Using SnapMirror, you also have the ability to change the direction of the sync, in case there is ever a problem with the primary repository. SnapMirror can also be used to create a variety of replication topologies, such as fan-out, where a single volume replicates to many secondary systems, and cascade, where the destination volume is itself synchronized to a tertiary system. Though the focus in this article has been on volume replication, SnapMirror is also able to replicate qtrees.- Testable: SnapMirror destination volumes can be instantly cloned as writable volumes, irrespective of their size and in a space-efficient manner, without needing to stop data being replicated from the source. This is made possible by NetApp’s FlexClone feature and is invaluable for performing DR tests, for example.
- Failover and failback: In the event that DR systems need to be brought online, SnapMirror relationships can be broken, making the destination volumes read/write and ready to be used. SnapMirror allows you to later re-synchronize the original source with the changes made at the destination and then re-establish the original SnapMirror relationship.
- Ease of use: With the Cloud Manager, operations take place through the use of a simple drag-and-drop GUI and wizard-guided walkthroughs. With Cloud Manager you also get the ability to monitor and manage all of the SnapMirror replication relationships all in one place.
Conclusion
As we have seen, SnapMirror is a powerful feature of Cloud Volumes ONTAP that is both flexible and easy to use. Whether you’re migrating your production applications to AWS or using Cloud Volumes ONTAP for DR, SnapMirror will empower you to move your data to where it needs to be—as, for example, in massive lift and shift AWS data migrations—as efficiently as possible.
SnapMirror is also tightly integrated with other Cloud Volumes ONTAP features, which can be used to great effect. For example, you can SnapMirror data to a destination volume in Cloud Volumes ONTAP that uses data tiering and offload that data directly to Amazon S3. This can be a very cost-effective solution for infrequently accessed systems, such as DR environments.
