Hyper-V Disaster Recovery using OCPM 4.0 (On Command Plugin for Microsoft) DR Orchestrator Integration Packs

I hope you all enjoyed part 1 of the tutorial on how to perform disaster recovery of virtual machines running on Microsoft® Hyper-V® hosts through the DR Microsoft Windows PowerShell® cmdlets that are included with NetApp® OnCommand® plug-in for Microsoft (OCPM) 4.0.

 

In this part 2, I show you how you can use OCPM Orchestrator Integration Packs (OIPs) to automate DR through integration with Microsoft System Center technologies such as System Center Service Manager (SCSM) and System Center Orchestrator (SCORCH).

 

 

Note: OCPM 4.0 SCORCH disaster recovery OIPs are supported only for NetApp Data ONTAP® operating in 7-Mode. They are not supported in clustered Data ONTAP environments.

 

 

 

 

For this particular demonstration, I’m using many of the same Hyper-V hardware and storage configurations that I used in part 1 of my tutorial. I’m also demonstrating the DR workflow for Hyper-V hosts on Microsoft Windows Server® 2012

 

So, let’s start. I have divided my DR workflows into three runbooks: DR-Initialize, DR-Failover, and DR-Failback.

 

DR-Initialize—This workflow comprises OIPs that can be used to initialize the NetApp SnapMirror® solution, create a DR plan, and validate and confirm the DR plan.

DR-Failover—This workflow comprises OIPs that update SnapMirror and perform the actual failover.

 

 

DR-Failback—This workflow comprises OIPs that update the DR plan, set up a SnapMirror reverse resync, clean up the primary DR site, validate the DR plan, and then initialize the failback.

 

Now let’s dig deep into the individual runbooks.

 

DR-Initialize Runbook

 

DR-Initialize consists of four OIPs, which are Initialize SnapMirror, Get SnapMirror Status, Create a DR Plan, and Validate a DR plan.

 

Initialize SnapMirror

 

This OIP creates and initializes the SnapMirror relationship from the source controller to the destination controller.

 

I have appended values for three of the input properties:

 

Destination path—This input property consists of the destination controller name (siteB7mode) along with the volume name (vol5) on Site B, into which the vol6 volume from siteA7mode is mirrored by using SnapMirror.

 

Secondary server name—This input property consists of the secondary site cluster name or Hyper-V host name. In the current scenario, it’s win2k12clusterb from Site B, which consists of two Hyper-V hosts (HyperV-Win12k-3 and HyperV-Win12k-4).

 

Source path—This input property consists of the source controller name (siteA7mode) along with the volume name (vol6). This volume is mirrored to vol5 in siteB7mode by using SnapMirror.

 

Get SnapMirror Status 

 

This OIP obtains the current state of the SnapMirror transfer: either transferring or idle.

 

I have appended values for two of the input properties:

 

Destination path—This input property consists of the destination controller name (siteB7mode) along with the volume name (vol5) on Site B, into which the vol6 volume from siteA7mode is mirrored by using SnapMirror.

 

Secondary server name—This input property consists of the secondary site cluster name or Hyper-V host name. In the current scenario, it’s win2k12clusterb from Site B, which consists of two Hyper-V hosts (HyperV-Win12k-3 and HyperV-Win12k-4).

 

 

Create a DR Plan

 

This OIP creates the DR plan XML for failover from Site A to Site B. It adds in the storage configuration details for both sites and the Windows Management Instrumentation (WMI) information for the Hyper-V hosts across both sites.

 

I have appended values for four of the input properties:

 

Primary server name—This input property consists of the primary site cluster name or Hyper-V host name. In the current scenario, it’s win2k12clustera from Site A, which consists of two Hyper-V hosts (HyperV-Win12k-1 and HyperV-Win12k-2).

 

Secondary server name—This input property consists of the secondary site cluster name or Hyper-V host name. In the current scenario, it’s win2k12clusterb from Site B, which consists of two Hyper-V hosts (HyperV-Win12k-3 and HyperV-Win12k-4).

 

DR plan name—This input property consists of the DR plan name.

 

DR plan in folder—This input property consists of the location where the DR plan is saved. In the current scenario, I save it to a shared folder, kbs, on the HyperV-Win12-1 server.

 

 

Validate a DR Plan

 

This OIP validates the existing updated DR plan XML for failover from Site A to Site B.

 

It adds in the storage configuration details for both sites and the WMI information for the Hyper-V hosts across both sites.

 

I have appended values for two of the input properties:

 

DR plan path—This input property consists of the location where the DR plan is saved. In the current scenario, I subscribed to the published value available from Create a DR Plan Activity.

 

Primary server name—This input property consists of the primary site cluster name or Hyper-V host name. In the current scenario, it’s win2k12clustera from Site A, which consists of two Hyper-V hosts (HyperV-Win12k-1 and HyperV-Win12k-2).

 

 

 

After you feed in these values, you can verify the workflow with the runbook tester. If all goes well, you see a green checkmark (success) for all OIP objects.

 

 

DR-Failover Runbook

 

DR-Failover consists of two OIPs, which are Validate a DR Plan and DR failover.

 

Validate a DR Plan

 

This OIP validates the existing updated DR plan XML for failover from Site A to Site B. It adds in the storage configuration details for both sites and the WMI information for the Hyper-V hosts across both sites.

 

I have appended values for two of the input properties:

 

DR plan path—This input property consists of the location where the DR plan is saved. In the current scenario, it’s saved at a share path in the hyperv-win12k-1 server on Site A.

 

Primary server name—This input property consists of the primary site cluster name or Hyper-V host name. In the current scenario, it’s win2k12clustera from Site A, which consists of two Hyper-V hosts (HyperV-Win12k-1 and HyperV-Win12k-2).

 

 

 

DR Failover

 

This OIP performs the failover to Site B (win2k12clusterb) based on the DR plan.

 

I have appended values for four of the input properties:

 

DR plan path—This input property consists of the location where the DR plan is saved. In the current scenario, I subscribed to the published value available from Create a DR Plan Activity.

 

Secondary server name—This input property consists of the secondary site cluster name or Hyper-V host name. In the current scenario, it’s win2k12clusterb from Site B, which consists of two Hyper-V hosts (HyperV-Win12k-3 and HyperV-Win12k-4).

 

Online VMs after restore—This input property should be set to True if you need the VMs to be turned on after they fail over to Site B.

 

Force disconnect conflicted storage—This input property should be set to True if you need the conflicting storage to be cleared out before the DR mirrored LUNs are mounted.

 

After you feed in these values, you can verify the workflow with the runbook tester. If all goes well, you see a green checkmark (success) for all OIP objects.

 

 

DR-Failback Runbook

 

The DR-Failback runbook consists of five OIPs, which perform the failback of resources from Site B to Site A when Site A is restored to its normal state after recovery.

 

Update a DR Plan

 

This OIP updates the already existing DR plan with the new primary site (Site B) and the secondary site (Site A) details after the failover takes place.

 

I have appended values for four of the input properties:

 

Primary server name—This input property consists of the primary site cluster name or Hyper-V host name. In the current scenario, after the failover, it’s win2k12clusterb from Site B, which consists of two Hyper-V hosts (HyperV-Win12k-3 and HyperV-Win12k-4).

 

Secondary server name—This input property consists of the secondary site cluster name or Hyper-V host name. In the current scenario, after the failover, it’s win2k12clustera from Site A, which consists of two Hyper-V hosts (HyperV-Win12k-1 and HyperV-Win12k-2).

 

DR plan path—This input property consists of the location where the DR plan is saved. In the current scenario, it’s at a share location on the HyperV-Win12k-1 host.

 

Operation direction—The operation direction is specified as Failback because it’s a failback from Site B to Site A.

 

 

Reverse Resync SnapMirror

 

This OIP creates and initializes the reverse SnapMirror relationship from the source controller (siteB7mode) to the destination controller (siteA7mode).

 

I have appended values for three of the input properties:

 

Destination path—This input property consists of the destination controller name (siteA7mode) along with the volume name (vol6) on Site A, into which the vol5 volume from siteB7mode is mirrored by using SnapMirror.

 

Secondary server name—This input property consists of the secondary site cluster name or Hyper-V host name. In the current scenario, after the failover, it’s win2k12clustera from Site A, which consists of two Hyper-V hosts (HyperV-Win12k-1 and HyperV-Win12k-2).

 

Source path—This input property consists of the source controller name (siteB7mode) along with the volume name (vol5), which is mirrored to vol6 in siteA7mode by using SnapMirror.

 

 

 

Clean up a DR Site

 

This OIP cleans up the DR site. It removes conflicting LUNs and also removes the conflicting VM resources. This OIP is meant to invoke a total SiteClean up on Site A, which still has some sets of conflicting LUNs or VMs on it.

 

I have appended values for three of the input properties:

 

Secondary server name—This input property consists of the secondary site cluster name or Hyper-V host name. In the current scenario, after the failover, it’s win2k12clustera from Site A, which consists of two Hyper-V hosts (HyperV-Win12k-1 and HyperV-Win12k-2).

 

DR plan path—This input property consists of the location where the DR plan is saved. In the current scenario, it’s at a share location on the HyperV-Win12k-1 host.

 

Remove DRPlan resources and conflicting LUNs—This input property, when set to True, removes all conflicting resource LUNs and VMs existing on Site A (win2k12clustera).

 

Validate a DR Plan

 

This OIP validates the existing updated DR plan XML for failback from Site B to Site A. It adds in the storage configuration details for both sites and the WMI information for the Hyper-V hosts across both sites.

 

I have appended values for two of the input properties:

 

DR plan path—This input property consists of the location where the DR plan is saved. In the current scenario, it’s at a share location on the HyperV-Win12k-1 host.

 

Primary server name—This input property consists of the primary site cluster name or Hyper-V host name. In the current scenario, it’s win2k12clusterb from Site B, which consists of two Hyper-V hosts (HyperV-Win12k-3 and HyperV-Win12k-4).

 

 

DR Failback

 

This OIP performs the failback from Site B to Site A based on the DR plan XML.

 

I have appended values for four of the input properties:

 

DR plan path—This input property consists of the location where the DR plan is saved. In the current scenario, it’s at a share location on the HyperV-Win12k-1 host.

 

Secondary server name—This input property consists of the secondary site cluster name or Hyper-V host name. In the current scenario, it’s win2k12clustera from Site A, which consists of two Hyper-V hosts (HyperV-Win12k-1 and HyperV-Win12k-2).

 

Online VMs after restore—This input property should be set to True if you need the VMs to be turned on after they fail over to Site B.

 

Force disconnect conflicted storage before connect—This input property should be set to True if you need the conflicting storage to be cleared out before the DR mirrored LUNs are mounted.

 

After you feed in these values, you can verify the workflow with the runbook tester. If all goes well, you see a green checkmark (success) for all OIP objects.

 

 

Here's a video clip which shows the OCPM 4.0 DR OIP's in action.

 

Video Link : 3481

 

 

You can also integrate this workflow with Microsoft System Center Service Manager (SCSM) and SCORCH 2012. With this integration, the entire workflow can be implemented in accordance with Information Technology Infrastructure Library standards.

 

For example, when a change ticket comes in, after it’s approved, the request can be made to trigger this workflow and perform seamless DR failover and failback, with all the tasks recorded in the Configuration Management Database.

 

Now, to set up your SCSM and SCORCH connectors, I suggest that you go through my blog NetApp Storage Provisioning Using System Center Service Manager (SCSM) and Orchestrator (SCORCH) and Data ONTAP PowerShell Toolkit, and get started right away!  

 

I hope that you have enjoyed this session on how to perform DR with OCPM Orchestrator Integration Packs and have found this information helpful.

 

Good Luck!

 

Thanks,

Vinith

Comments
New Contributor

Hello Vinith,

Many thanks! Really amazing...

Any suggestion to trigger it without human intervention in case of siteA complete failure?...

Jose