About Cross-Region Replication and how it can save your business
Like a Love-Relationship
The secrets to a long-lasting relationship are can be different depending on who you might ask, however most of us agree, that trust is one of the main pillars of a successful relationship. Full trust also means letting go of some apprehensions and being sure that the other side can take care of their responsibilities. In other words, your partner always has your back. They are with you when things get tough and help you out if you are not at your best! Isn’t that beautiful!?
You might be wondering: isn’t this a tech blog? Yes.
So, what does this analogy have to do with the Azure Cloud, ANF and that new feature called Cross Region Replication?
To explain this, we need to first establish what Cross-Region Replication is.
The Basics
If you are not too familiar with ANF, check out this blog post to get started.
If you’d like to get an overview first, here is a summary of all disaster recovery and backup options in Azur NetApp Files with pros and cons.
Cross Region Replication (short: CRR) is a disaster recovery tool for your ANF environment. It continuously replicates all data on a schedule between two physically separated locations in a different region. Let me explain with an image:
There is a primary and a secondary location. The primary location is the production system, and it asynchronously replicates the changes from the stored data and apps to the secondary location (DR system). You can specify the replication frequency depending on your requirements: If you need a low Recover Point Objective (RPO), you should be replicating more frequently. (RPO / RTO explained below)
How It works / Steps
If the primary location is compromised, hardware broke or the region is down, the secondary location becomes the primary storage location, and the services can continue running from there until the primary location is restored. The replication relationship has to be re-established after a disaster, so that the primary location and secondary location can fail back again. All this is done inside the Azure Portal.
- An ongoing replication between the source and the destination volumes (see Create volume replication) prepares you for a disaster recovery event.
- When such an event occurs, you can fail over to the destination volume, enabling the client to read and write to the destination volume.
- After disaster recovery, you can perform a resync operation to fail back to the source volume.
- You then re-establish the source-to-destination replication and remount the source volume for the client to access.
RPO / RTO for Cross-Region-Replication:
The RTO (maximum tolerable business application downtime) depends on how fast you can spin up the application including data access in the secondary site. The storage part of it can be completed within one minute.
The RPO (Recovery Point Objective for instance, is typically less than twice the replication schedule. You can read examples in the ANF documentation:
- For the replication schedule of 10 minutes, the typical RPO is less than 20 minutes.
- For the hourly replication schedule, the typical RPO is less than two hours.
- For the daily replication schedule, the typical RPO is less than two days.
When you have snapshots on the primary location, they are also duplicated to the secondary location. Consequently, it is also a backup, which gives you another restore point for your infrastructure.
Going back to our analogy, we can say that our partners in the story are like the two region-pairs in a Cross-Region-Replication relationship. When everything is fine, both go about their ways and replicate the data from the primary to the secondary – you can imagine this to be the dinner conversation, exchanging about the day, entrusting information. Then comes a day where one partner, the primary location, is not at its best. The secondary location comes and saves the day! Also just like a relationship, the more often communication occurs, the less likely a misunderstanding can arise: replicating more frequently has the advantage of less downtime in the event of a disaster failure.
With this feature being generally available in Azure NetApp Files now, we are adding one more portion to the simple, secure and enterprise-ready storage solution in the cloud.