NetApp SVM-DR switching In case of Disaster or Maintenance

By | 16. April 2019

Hello together,

in my last Post I described how to set up a NetApp SVM-DR SnapMirror.

Today I would like to show you how the switchover works in the event of a disaster or even during planned maintenance.

The Initial Situation

In this scenario, I present a volume called “MYTEST” from the AFF A220 To all my ESX hosts. The SVM “NFS-TEST SVM” is in an SVM-DR relationship.

On the datastore “MYTEST” I dropped off a virtual Machine called “SCHMITZ _ TEST.”

Now I’m simulating the failure of the complete DataCenter 1. I want the SVM “NFS-TEST SVM” to bring back online in DataCenter 2.

Disaster has occurred

Switching SVM to the secondary Data Center

My DataCenter 1 is down and no longer provides any data. I now go to my FAS2720 at DataCenter 2. Click on Protection (1), SVM DR Relationships (2), select my SVM, which I would like to take online in the secondary Data center (3), under Operations I click on Activate Destination SVM (4).

Now an assistant appears. Here I have to set the hook that the target SVM is activated and the Mirror relationship is broken. Only then can I click on Activate.

Now the SVM is activated

After a few Seconds, I get the confirmation that the SVM has been activated and the mirror relationship is broken off.

In this scenario, I was so fast that the “SCHMITZ _ TEST” virtual machine continued to run. This means that the entire switching process has happened within the timeout limits for the ESX NFS connection.

In a real-world scenario, however, you have to assume that all running virtual Machines will fall on their nose. Disasters mostly do not do you the favor to pass during your normal working hours. 😉

Disaster weathered, maintenance work over, how do you go back?

After getting everything up and running again at DataCenter 1, I would like to move my SVM and all the data written in the meantime back to DataCenter 1.

To do this, I go to the SVM DR Relationships on my FAS 2720, select my NFS-TEST SVM and select the “Reactivate Source SVM” Item at Operations.

After that, an assitent appears again, which supports me in the switchback process. I click on “Initiate Reactivation” and “Done”

Now I quickly check if my NFS-TEST SVM is running again on the primary system and click on “Verify” and “Done”

Now a resync of the data takes place and my destination SVM is stopped again.

Again, the switchback happens so quickly that my “SCHMITZ _ TEST” VM just kept running. But I recommend you not to do this with productive machines. In this case, plan a downtime. Shutdown the VMs so that no more data is generated on the volumes, and then make the switchback.

I hope I was able to give you a little insight into the world of the SVM-DR. If you have any questions, use the comment feature here in the blog.

Greetings
DerSchmitz

DISCLAIMER: This post represents my personal observations and is not officially by NetApp or other authorized. Subject to misinterpretation or misunderstanding.

2 thoughts on “NetApp SVM-DR switching In case of Disaster or Maintenance

  1. Beyti

    Hi, I have a question. In your example looks like you just initiate Activate Destination SVM and it does everything automatically. Why my cluster is asking me to do all the steps manually? I have to Quiesce – Abort – Break snapmirror. Stop source SVM and then I can activate Destination SVM. Is it because I`m doing test and source data center is up, there is no actual disaster?

    Reply
    1. DerSchmitz Post author

      I am so sorry to answer so late. I have overread your comment.I apologize for that. The behavior of how the SVM-DR Cutover works has varied in the latest versions of ONTAP. I did my Blog with ONTAP 9.5. Now we are at 9.7. In the past people “forget” to shutdown the source SVM and to break the mirror so they ended up in a kind of split brain while testing a DR scenario. That´s one of the reasons why ONTAP is now asking you about the steps.

      Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.