nsx-t backup and restore configuration and...

NSX-T Backup and Restore Configuration and Automation | Part 1 – Windows SFTP Backup Targets Posted on September 4, 2019 by gwilmington Source Link – Part 1 – Windows SFTP Backup Targets (https://vwilmo.wordpress.com/2019/09/04/nsx-t-backup-and-restore-configuration-and-automation-part-1-windows-sftp-backup-targets/) Part 2a – Using NSX-T to Test NSX-T and Virtual Machine Recovery with Automation – Conceptual (https://vwilmo.wordpress.com/2019/09/17/using-nsx-t-to-test-nsx-t-and-virtual-machine-recovery-with-automation-conceptual/) Part 2b – Using NSX-T to Test NSX-T and Virtual Machine Recovery with Automation – Practical (https://vwilmo.wordpress.com/2019/09/17/using-nsx-t-to-test-nsx-t-and-virtual-machine-recovery-with-automation-practical/) Part 1 – Windows SFTP Backup Targets Now that the Healthcare organization has completed their journey of migrating from NSX Data Center for vSphere over to NSX-T Data Center, it’s time to do a bit of day 2 configuration, specifically configuring the backups of the NSX-T Manager.

The infrastructure admins that are currently in charge of running the NSX-T environment for the organization are expanding their scripting knowledge a bit and working on automating many of the configurations and operations that NSX-T Data Center requires. The first area where some simple scripting can help is around configuration and management of NSX-T Backups.

Typically, the admin could go into the NSX-T Manager UI and perform these configurations via the UI.

Since the admins are wanting to expand their knowledge in scripting and using REST APIs, and the plan is to bring this knowledge forward into performing and checking NSX-T restores later, they’ve opted to use a different approach.

Requirements:

• Setup Backup configuration for the NSX-T Manager with an eye on automation • At least 3 backups per day and automatic backups after configuration changes • Maintaining at least 30 days of backups for the NSX-T Manager Requirement 1 – Setup Backup configuration for the NSX-T Manager with an eye on automation

REPORT THIS AD REPORT THIS AD

Requirement 2 – At least 3 backups per day and automatic backups after configuration changes The first two requirements can be handled with one straightforward approach. The organization currently has a Cerberus SFTP server that backs up configuration from other devices on their network. It’s a FIPS 140-2 compliant software package that will work well with NSX-T. This software package runs on a Windows Server 2016 machine for the organization to store the backups. Consulting the official NSX-T documentation for Backup and Restore, the admin finds the required items to be able to perform the configuration. The information is put into a chart for documentation purposes so that they can be tracked and the infrastructure and security team know the settings being used.

Now that the settings have been documented accordingly, the admin can take a further look at how to configure the settings in NSX-T. The admin has decided that they will take the following approach around automating the installation of the configuration. They will use the NSX-T REST API to perform the configuration using the documented settings. To be able to do this a few things will need to happen.

• Installation of a REST API client – Postman • Code example from the NSX-T Data Center API Guide for configuration and testing backups This post will not go into the installation of Postman, it’s a simple installation. The following configuration is however needed to properly ensure Postman will call the NSX-T Manager REST API.

After consulting the NSX-T Data Center API Guide, the following code was pulled that should provide the necessary single API call to configure the NSX-T Manager backup schedule. Example code for backup configuration:

Taking the information collected during the documentation process, the admin can now substitute in the organization-specific configuration that will be used for the body of the REST API call.

Organization-specific code for backup configuration:

REPORT THIS AD When the admin pastes the above configuration into the body of the REST API PUT command and sends the command, they receive a Status 200 OK meaning the command was realized and accepted.

There are several ways that the admin can check the work, but the Status 200 OK will display the result from the command in the Body section from the

response. It is also possible to change the same command from PUT to GET and resend it to get the same result. With the configuration in place, the admin can issue another command via the REST API that will initiate a backup from the NSX-T Manager to the SFTP server.

Running this command will take some time to send the request and get a response as the actual process of performing the backup needs to take place and send back a Status 200 OK which is only sent when the backup actually completes successfully. As you can see from the Postman output below, the request took 1 minute and 1.08 seconds to actually perform the command.


The admin can now go into the NSX-T Manager UI and check the configuration and backup status visually as well and it appears that all is configured properly and backing up to the SFTP server as they’d expect it to.

REPORT THIS AD The admin also takes a quick look at the SFTP server and the backup directory to check that files have been created.

Requirement 3 – Maintaining at least 30 days of backups for the NSX-T Manager To meet the last requirement, while still maintaining Requirement 1 around an eye for automation, the admin needs to find a way to only keep 30 days of backups for the NSX-T Manager. The official NSX-T documentation has several scripts that can be run on Linux-based systems and coupled with a cron job, can be used to clean up the backup directory on an automatic and scheduled basis. However, there are no scripts supplied for Windows-based SFTP systems and the Healthcare organization is using a Windows machine for their SFTP server. The admin decides to create

their own script using PowerShell and using a Windows Scheduled task to provide the same benefit. Taking a look at the SFTP server, the admin can see that there are several folders created for the backup files.

• ccp-backups – Contains .tar files of the Control Plane backup for NSX-T • cluster-node-backups – Contains .tar files in date specific folders for the NSX-T Manager/Policy/Controller Cluster and each individual NSX-T Manager backup • inventory-summary – Contains .json files for every inventory object in the NSX-T Manager backup Each of these folders contains multiple files after a backup occurs for NSX-T. Below is an example:


The admin determines that the easiest way to handle this is to use PowerShell to create a script that will automatically look for files older than 30 days and remove the folders and files within the folders appropriately. The code looks like this and can be found on GitHub as well.

REPORT THIS AD The admin tests this script by changing the $Daysback variable in the script to -0 as that will delete all of the backups that have been taken thus far. Running the script, the admin can see that all of the backups have been removed and the folder structure for the backups is still intact.

After running the backup again, the admin can see that the new backup files are present in the folder.

REPORT THIS AD

With the script working as intended, the admin can now create a Windows scheduled task to call the PowerShell script on a nightly basis to clean up the SFTP backup directory

With the task created, the admin runs the task manually and verifies that the current backup is removed as intended. The admin can now run a current backup of the configuration and change the $Daysback variable to -30 again.

The requirements have been fulfilled and the admin can now move onto the next task which is testing the backup and restore process in Part 2.

Using NSX-T to Test NSX-T and Virtual Machine Recovery with Automation – Conceptual Posted on September 17, 2019 by gwilmington Part 2a – Using NSX-T to Test NSX-T and Virtual Machine Recovery with Automation – Conceptual The Healthcare organization, last post, configured their NSX-T Manager to send its backups to an SFTP backup server so they can perform restores if necessary. The Healthcare organization also utilizes Veeam Backup and Recovery to provide virtual machine-based backups for their virtual infrastructure. Unfortunately, the NSX-T Manager is not supported to be backed up using Veeam, and requires a new fresh NSX-T Manager installation deployed and a backup configuration restored to it and the Healthcare organization would like to test restores of the NSX-T Manager.

Configuring and actually backing up the NSX-T Manager configuration or a virtual machine is one thing, actually being able to test the backups is another. A backup is no good if you can’t restore from it. The organization has found a way to test both their NSX-T backups and their virtual machine backups at the same time to meet the requirements. Taking some pointers from what they’ve learned previously around using automation tools, they plan to expand their automation learning with this same process.

NSX-T can provide exact copies of production environments running on top of the same underlying physical network with no changes to the physical network. The Healthcare organization has placed a very large bet on NSX-T being their networking and security platform for their infrastructure, and looking to use this capability to provide an isolated backup environment to test restoring their backups. Keeping an automation mindset in place, the Healthcare organization admins take a look at the requirements they’ll need to accomplish the tasks:

Requirements: 1. Use NSX-T to build a production replica network to test restores of the NSX-T Manager and show virtual machines can also be restored and tested on the same network 2. Use Veeam to restore the following virtual machines: A. Backup Server – Will be used to run automation scripts from B. Active Directory – Will be needed for DNS purposes C. SFTP Server – Hosts the NSX-T backups that restores will be tested from 3. Deploy a new NSX-T Manager to test the restore process to it

4. Use automation wherever possible to continue expanding automated techniques The following topology is drawn out by the admin that will ensure that they can rebuild a production network replica while not overlapping with the actual production networking. This topology consists of the following constructs to build out the production replica network:

• Standalone Tier-1 Gateway – not connected to any Tier-0 Gateway, preventing northbound communications that would conflict with the production networking • Restore Network Segment – Provides a logical network for the restored VMs to attach to • Restored Domain Controller – One of the organizations domain controllers that will provide DNS for the replica network and the VMs attached • Restored Backup Server – Hosts the PowerShell scripts that are necessary for scripting part of the deployment on the restored NSX-T Manager. Some of the scripts will need to be run from the Production Backup Server and some of them from the Restored Backup Server since there will be no outside communications to the Restore environment other than vCenter Server direct console access • Restored SFTP Server – Hosts the backups of the NSX-T Manager • Restored NSX-T Manager – Will be used to test its own restores • vCenter Server B – Manages the Compute Cluster B • Compute Cluster B – Provides a non-production host for the restored systems to be placed on that’s not managed by the production vCenter Server A.

REPORT THIS AD

Before any automation can begin, the admin needs to understand all of the workflow steps that will be necessary and how to perform them so they can put automation around each workflow process.

NSX-T 2.4.x provides a hierarchical intent-based Policy API for customers to use for automation techniques. The admin takes a look at the NSX-T API official documentation on the Policy API and finds a few REST API commands that could be useful for creating the necessary constructs. From the configuration of the backup of the NSX-T Manager in the previous post, the admin can also use the information collected there and REST API commands to automate adding the restore configuration into the NSX-T Manager that will be deployed. The NSX-T Manager comes from the VMware download site as an OVA type of download. Using a tool such as the OVFTOOL, could be used to help automate the process of deploying the NSX-T Manager to the new network that will be created.


To wrap all of these different automation techniques into scripts that the admin can use, they’re planning to use PowerCLI and PowerShell Core 6 to build scripts that can be run to automate as much of this process as possible.

The admin performs the following actions to be able to use PowerShell Core 6 and VMware PowerCLI on the Backup Server. The Backup Server will host the scripts and also be the server where the scripts are run from, both in production and in the restored segment.

Install Prerequisites: • Download and install PowerShell Core 6 – https://github.com/PowerShell/PowerShell • Install VMware PowerCLI Module – Install-Module -Name VMware.PowerCLI • Install the OVFtool – https://code.vmware.com/web/tool/4.3.0/ovf • Download the NSX-T Manager OVA from the VMware download site and copy to the Backup Server The post isn’t going to go into how to install these items as they are fairly simple to install with mostly click, click, next.

Each of these processes will be necessary to meet all of the requirements. There are specific portions of the workflow where processes can be joined together into singular scripts and the admin will attempt to do so within their experience.

The first and second workflow process in the table consists of building a Veeam Backup Job around all of the virtual machines needed, and ensuring that NSX-T is sending backups to the SFTP server.

Requirement 2 – Use Veeam to restore the following virtual machines • Backup Server – Will be used to run automation scripts from • Active Directory – Will be needed for DNS purposes • SFTP Server – Hosts the NSX-T backups that restores will be tested from Regardless of the order of the requirements, first and foremost to test the restore process, the admin needs to ensure that they have backups of the systems that they’re planning to perform restore testing. The admin also hops into the NSX-T Manager console and checks that the latest backup job has completed or can press the ‘BACKUP NOW’ button to start a latest backup to the SFTP server.

REPORT THIS AD For the process of testing backups in this use case, the admins have configured a separate backup job in Veeam that has the 3 virtual machines that will be used for this testing procedure.

The admin waits to start the backup job in Veeam until the scripts are all built as they’ll be needed once the Backup Server is restored. The admin can start to take a look at how to build an NSX-T isolated copy of the production network.

Requirement 1 – Use NSX-T to build a production IP-based isolated network to test restores to NSX-T and show virtual machines can also be restored and tested on the same network Requirement 3 – Deploy a new NSX-T Manager to test the restore process to it Requirement 4 – Use automation wherever possible to continue expanding automated techniques The process of building the production replica network can be accomplished using the NSX-T REST API. The admin has taken a look at the NSX-T REST API official documentation and found an example of using the hierarchical intent-based API to build the Tier-1 Gateway and the Segment that will be used. The next process is around using the OVF Tool to deploy the NSX-T Manager to the same segment previously created. Since these processes can be called from PowerCLI, the admin decides to combine these two workflows into one script.

REPORT THIS AD The code that was built for this resembles the following:

REPORT THIS AD This script builds the Tier-1 Gateway and Segment using the NSX-T Policy API, then immediately jumps to using the OVF Tool to deploy the new NSX-T Manager to the previously created Segment. You can find the actual script over here – github link. For ease of reading, the OVF arguments were word wrapped. Those need to be in one-line, normally.

The next process is around changing the Memory resources of the NSX-T Manager. Typically, the NSX-T Manager has a memory reservation to ensure enough memory is available for it to run. Given this is a testing environment restore,

the admin wants to remove this reservation so they can start the NSX-T Manager without running into issues. The admin builds another script to adjust this and start the VM.

The code that was built for this resembles the following:

This script adjusts the memory reservation down to 8GB and then starts the NSX-T Manager VM.

The next piece of scripting that the admin chooses to do is around putting in the Restore Configuration for the NSX-T Manager into the new NSX-T Manager virtual machine using PowerCLI and the REST API. The code that was built for this resembles the following:


This script sends a REST API command to put in the Restore Server configuration into the NSX-T Manager so it can now see the NSX-T Backups on the restored SFTP-01a and can choose which one the admin wants to test the restore to.

The final script the admin decides to build is around clean up of all of the virtual machines and networking components created to test with. The code built for this resembles the following:

This script powers down and deletes all of the restored virtual machines and the NSX-T Manager, and then runs the NSX-T Policy API to remove the Tier-1 Gateway and testing Segment created resetting the infrastructure back to its original configuration.

There are obviously several areas where the scripting can be improved and even further simplified. This is a good first start for the admin to meet the requirements and grow their automation skills and further refine the scripting. In the next post, the admin will put all of these scripts and processes to work and test the full process. The screenshots of the script code may be tough to read, so the admin has uploaded all of the scripts to this location

– https://github.com/vwilmo/NSXT_RESTORE_TESTING

Using NSX-T to Test NSX-T and Virtual Machine Recovery with Automation – Practical Posted on September 17, 2019 by gwilmington Part 2b –Using NSX-T to Test NSX-T and Virtual Machine Recovery with Automation – Practical In Part 2a, the Healthcare organization admins had created several scripts using VMware PowerCLI, PowerShell Core 6, OVF Tool, and NSX-T Policy REST APIs. Those scripts are located at the following GitHub link for other community admins to consume as well.

The original requirements that were put forth for the admins to provide a design for were:

Requirements: 1. Use NSX-T to build a production replica network to test restores of the NSX-T Manager and show virtual machines can also be restored and tested on the same network 2. Use Veeam to restore the following virtual machines:

A. Backup Server – Will be used to run automation scripts from B. Active Directory – Will be needed for DNS purposes C. SFTP Server – Hosts the NSX-T backups that restores will be tested from

3. Deploy a new NSX-T Manager to test the restore process to it 4. Use automation wherever possible to continue expanding automated techniques To meet these requirements the admin had designed the following topology to meet these requirements:

• Standalone Tier-1 Gateway – not connected to any Tier-0 Gateway, preventing northbound communications that would conflict with the production networking • Restore Network Segment – Provides a logical network for the restored VMs to attach to • Restored Domain Controller – One of the organizations domain controllers that will provide DNS for the replica network and the VMs attached • Restored Backup Server – Hosts the PowerShell scripts that are necessary for scripting part of the deployment on the restored NSX-T Manager. Some of the scripts will need to be run from the Production Backup Server and some of them

from the Restored Backup Server since there will be no outside communications to the Restore environment other than vCenter Server direct console access • Restored SFTP Server – Hosts the backups of the NSX-T Manager • Restored NSX-T Manager – Will be used to test its own restores. NSX-T Manager restores requires that the new NSX-T Manager have the same IP address as the production copy. To test this appropriately, we have to create a copy of the production network and IP addressing • vCenter Server B – Manages the Compute Cluster B • Compute Cluster B – Provides a non-production host for the restored systems to be placed on that’s not managed by the production vCenter Server A.


For further details on reasonings for this topology, you can take a look at Part 2a referenced at the top of this thread.

With the scripts created, it’s now time for the admin to work through the workflow processes and test that this strategy will meet the requirements in practice. This is a review of the workflow process:

Step 1 – Copy scripts to BACKUP-01a – GitHub download and copy The scripts just need to be pulled down from GitHub and copied to a location on the BACKUP-01a server

Step 2 – Copy NSX-T OVA to BACKUP-01a – Download and copy Another straightforward step with downloading the NSX-T OVA that’s the exact version of the current NSX-T Manager and copying it to a location on BACKUP-01a

Step 3 – Install PowerShell Core 6, PowerCLI, and OVFTool – Download installs and install

REPORT THIS AD

Step 4 – Perform a Backup of the NSX-T Manager – Native Backup Tool A pretty simple step by just going into the NSX-T Manager and the Backup & Restore tab and pressing the ‘BACKUP NOW’ button and verifying its completion.

REPORT THIS AD Step 5 – Backup SFTP-01a, AD-01a, BACKUP-01a – Single Veeam Backup Job Once all of the components to perform the remaining workflows are done and installed and configured, the backups of the necessary virtual machines, especially the BACKUP-01a machine, can occur.

Step 6 and 7 – Deploy Testing Tier-1 Gateway and Segment – NSX-T Policy API via PowerCLI From the BACKUP-01a production server, the admin runs the 01_NSXT_DEPLOY.ps1 to build the Tier-1 Gateway and Segment and then it will start the OVF Tool to deploy the NSX-T Manager OVA file to the Compute Cluster B.


Tier-1 Gateway has been created, not linked to a Tier-0 Gateway to prevent Northbound connectivity with the overlapping production network and ‘nsxt-restore-segment’ created for the virtual machines and new NSX-T Manager to attach to.

The admin can also see that the new NSX-T Manager, connected to the ‘nsxt-restore-segment’ is being deployed.

REPORT THIS AD Step 8 – Adjust NSX-T CPU/Mem Resources and Power-On – PowerCLI Once the new NSX-T Manager is deployed, the admin wants to adjust the memory reservation so that they can start the NSX-T Manager without running into memory constraints since the test environment is rather limited. The deployed NSX-T Manager is in ‘small’ form factor, but still has a 16GB Memory reservation on it. From the BACKUP-01a production server, the admin runs the 02_NSXT_RESERVATION_ADJUST.ps1 to adjust the memory reservation down to 8GB and then power on the appliance.

Step 9 – Restore VMs to NSX-T Testing Segment – Veeam Restore Job To get the virtual machines necessary to help in the NSX-T restore process and to prove that the admins can restore NSX-T and virtual machines from native and Veeam backups respectively, the admin runs a restore entire VM job of the three VMs previously backed up, and…

• Points the Veeam restores to the Compute Cluster B host • Places them on the VM Network • Appends ‘_restored’ to each of their VM names • Leaves them powered Off. They’re left powered off so that once restored, the admin can adjust their network configurations to be attached to the ‘nsxt-restore-segment’.

Step 10 – Change Restored VMs networking to NSX-T Testing Segment – vCenter Server network vMotion The restored VMs can easily be moved in bulk to the ‘nsxt-restore-segment’ by using the Migrate VMs to Another Network option.


Once the VMs are restored and moved to the ‘nsxt-restore-segment’, they can be powered on and the next step can proceed.

Step 11 – Add NSX-T Restore Config – NSX-T Policy API via PowerCLI Now that the restored VMs are all added to the ‘nsxt-restore-segment’ and the new NSX-T Manager is online and attached as well, the admin can access these VMs by using the vSphere Client and using a direct console to the BACKUP-01a_restored VM. It’s critical to run the remaining scripts from that machine, as there is no outside network access to the new NSX-T Manager appliance, as intended.

Consoling into the BACKUP-01a_restored server, the admin can make some checks to see if network connectivity is indeed limited to the ‘nsxt-restore-segment’. Taking a quick look at the IPCONFIG of the BACKUP-01a_restored server, the admin can see that they cannot PING the default gateway of the network, however they are able to PING the other VMs and the NSX-T Manager (which has the same IP address as the Production NSX-T Manager).


The admin can also log into the UI of the NSX-T Manager from the BACKUP-01_restored server as well and can see that this is a brand-new deployment with no configurations.

The admin can also see that the Restore configuration is no longer configured as well. The next step is to get the configuration for restoring the NSX-T Manager put back into the new NSX-T Manager. This NSX-T Manager is already the same IP and Name as the production version, which is a requirement for restoration.


With connectivity to the NSX-T Manager, and confirmation that there’s no configurations, the admin can proceed with running the PowerCLI script to add the Restore Configuration into the NSX-T Manager from script 03_NSXT_RESTORE_CONFIG.ps1.

A quick run of the script and a refresh of the NSX-T Manager UI, and the admin can see that the SFTP server configuration is back and all of the backups that have been taken are showing up as well.

REPORT THIS AD After checking the backup files, the admin picks the first one in the list of Available Backups and clicks on the restore button to apply the configuration. During the restore process, since this is not a full restore and components such as Edge Nodes and Transport Node hosts are not contactable, the admin may get a few error messages that they can skip through. Once the restore is done, the admin can take a look at the restored configuration and see that the NSX-T Manager configuration matches the production instance and the restore was successfully finished and validated.

REPORT THIS AD With a successful test and the requirements accomplished, the admin can now perform the final steps running the last two scripts on the BACKUP-01a production server. One of the scripts, 04_NSXT_RESTORE_CLEANUP.ps1 will shutdown and then forcibly delete all of the restored virtual machines and the NSX-T Manager. The last script, 05_NSXT_DEPLOY_CLEANUP.ps1, runs a Policy API REST command to remove the Tier-1 Gateway and Segment to bring the entire deployment back to its original, clean state.

The last 2 posts have shown the Healthcare organization the power of using NSX-T and how it can be used with even a small amount of automated techniques to accomplish several use case examples and provide a real value to the organization that requires them to test their backups.

nsx-t backup and restore configuration and...

Documents