This post was authored by Dwayne Lessner, Principal Technical Marketing Engineer

AOS 5.17 in my mind should be officially named the “Disaster Recovery” release. This release provides many great updates for customers using Nutanix Leap: DR orchestration to keep their business running. This release gives more flexibility to protection topologies, reduces system overhead, gives users more choice and reduces recovery point objective times.

Single Prism Central Support

In past releases in order to perform DR orchestration between two different sites you would have to have Prism Central (PC) at each location forming an availability zone. An availability zone in Nutanix is what one PC manages as a fault domain. This makes good sense in large environments if you were to failover, you would still need a management plane to initiate the action. For smaller sites that want to utilize leap for deploying a PC VM at each site can take of a lot of resources. So now with 5.17 you can replicate between clusters in the same availability zone.

The below picture shows the ability to select the local AZ as our recovery location. If you have prism Central managing your Robo sites you can now create individual protection policies and recovery plans for your sites. Prism Central and your remote present elements will need to be at 5.17 for this new feature.

NearSync Support for Leap

NearSync now is supported with DR orchestration of giving more parity to the native data protection built into prism element. To enable NearSync you do need to have prism Central in both locations. The source and destination targets do need to meet the minimum NearSync requirements. With this change customers do not have to worry about creating remote sites and managing vertical machines at the cluster level as this feature is added to prism Central. This will help to reduce configuration drift and give customers one place to configure all of their DR needs.

Support for Custom Scripts

After your workloads failover you can now configure a custom script to run. The custom script is embedded inside of the virtual machine and can be used for configure anything inside of the guest. Change wallpaper, desktop settings, DNS or registry setting. You could even use it to kick off another script. You can make the script as easy or complicated you want.

Custom Static IP Mapping

Pervious Leap used offset-based IP mapping tracks the last four digits of VM IP addresses so they can be maintained or changed automatically based on the subnet configuration in the recovery plan. If you keep the source and destination subnets the same, you can maintain the IP address. If you change the destination subnet to a new value, the new subnet keeps the last four digits. The following example migrates a SQL server with the IP address 192.168.0.100 to a new subnet with the IP address 192.168.1.1/24. When the SQL server fails over into the new subnet, the server’s IP address is 192.168.1.100. Because you know the new IP address, you can plan any changes like updating DNS records allows you to do any changes (like updating DNS records) before the failover happens.

• The IP address for the Production1 subnet is 192.168.0.1/24.
• The IP address for the Production2 subnet is 192.168.1.1/24.
• The IP address for the SQL server in the Production1 subnet is 192.168.0.100.
• The extract host offset of the VM is 0.0.0.100.
• The mapped SQL Server IP address is 192.168.1.0. Add 0.0.0.100 to get the IP address after it fails over to a new subnet: 192.168.1.100.

Now if you want to manually assign static IPs to your VMs on failover, you can use custom IP mapping to do so as part of the recovery plan. This gives a lot more flexibility in environments that might have the offset IP’s already used in the destination subnet.

For a quick visual review of this article check out the following youtube video. This release continues to make business continuity a check box item for system administrators.  Download the release automatically on your clusters today and sleep a little bit more easy tonight.

2020 Nutanix, Inc.  All rights reserved. Nutanix, the Nutanix logo and all Nutanix product, feature and service names mentioned herein are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s). This post may contain links to external websites that are not part of Nutanix.com. Nutanix does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such a site. Certain information contained in this post may relate to or be based on studies, publications, surveys and other data obtained from third-party sources and our own internal estimates and research. While we believe these third-party studies, publications, surveys and other data are reliable as of the date of this post, they have not independently verified, and we make no representation as to the adequacy, fairness, accuracy, or completeness of any information obtained from third-party sources.