Customers are increasingly looking to streamline disaster recovery testing. But merely having a DR solution is not enough; you need to verify that your workloads and applications are functioning as required. Senior Staff Solution Architect William Lam shares a step-by-step guide on how this process can be automated for disaster recovery on VMware Cloud on AWS.
Disaster Recovery (DR) and Disaster Avoidance (DA) on VMware Cloud on AWS is still one of the most popular use case amongst our customers, just second to Datacenter Migration and Evacuation. The VMware Site Recovery service makes it extremely easy and cost effective for customers to protect their critical workloads without having to worry about the underlying infrastructure. Most often, the biggest cost of having a dedicated DR site is the on-going operational and maintenance cost of that infrastructure.
Most recently I have seen several requests come in where customers were looking to streamline their DR testing which is fantastic to hear. Just having a DR solution is not enough, you actually need to exercise it and verify that your workloads and applications are functioning as expected. Today, customers can verify that their applications are functioning as expected by creating NSX-T network segments that are “Disconnected” and then using a VM-based router to provide internal connectivity between these isolated environments.
Here is a screenshot of the VMware Cloud console and under the Networking & Security tab, when creating a new segment you can specify whether the segment is “Connected” (Routed) or “Disconnected”.
Obviously, the NSX-T UI is just one way of creating a segment. In fact, most customers that have asked about this is wanting to do this via Automation which not only brings speed to testing but also consistency! With that, I have updated my NSX-T PowerShell Community Module for VMC to include two new updates. If you have never used this VMC module before, please take a look at the Getting Started guide here.
1. New-NSXTSegment function now supports a new -Disconnected parameter which will automatically create the segment in a Disconnected state as shown in the screenshot below.
2. For those that have already created a segment, I have added a new Set-NSXTSegment function which supports toggling both Routed/Disconnected state using -Connected or –Disconnected as demonstrated in the screenshot below.
Note: You can only create a segment that is disconnected when DHCP is NOT used, you will receive an error from the API and the UI, it will prevent you from filling in the DHCP settings. This is important if you have an existing segment which you wish to disconnect, it must not have DHCP enabled.
For those interested in the underlying NSX-T REST API details and wish to consume it not using PowerShell, you can specify the -Troubleshoot parameter which will show you the exact HTTP verb along with the respective payload. You can also simply look at the source code to see the endpoint and payload as I am simply using the Invoke-Webrequest cmdlet from PowerShell.
