VMware Hands-on Labs - HOL-1825-02-NET


Lab Overview - HOL-1825-02-NET - VMware NSX Multi-Site and SRM in an Active-Standby Setup

Lab Introduction


IT organizations require a methodology for replicating and recovering workloads from a primary site to a recovery site in an event of a disaster or an un-planned outage. To facilitate and automate this recovery process of workloads VMware has products such as Site Recovery Manager (SRM) and vSphere Replication that can automate and orchestrate the recovery process during a failure from a primary site to a recovery site. Today, SRM recovers replicated virtual machines from a primary to a secondary data center. SRM can perform network mapping (and re-mapping) between the primary and secondary locations so that recovered virtual machines can be re-connected to the appropriate network. These networks can be a VLAN-backed Distributed Virtual Port Group (dvPG) or a NSX Logical Switch.

NSX and network virtualization enhance the Disaster Recovery solution by preserving L2 and recovering the entire logical network topology at the recovery site. NSX also adds API based automation at the networking layer to further improve Recovery Point Objective (RPO) and Recovery Time Objective (RTO) goals. Combining NSX with a SRM based DR design dramatically simplifies the recovery of vital networking services in the secondary location including Logical Switches, Distributed Logical Routers and Distributed Firewall (DFW) Rules. This lab will describe the process of recovering workloads backed by NSX virtual networks.

NSX supports seamless spanning of network and security policies across multiple sites through the use of the Cross-VC NSX feature introduced in NSX 6.2. The DR solution  can also be built without leveraging Cross-VC NSX by using an external replication/synchronization mechanism (such as vRO) to recreate Logical Networks and Security between separate NSX instances across the two sites.

However, Cross vCenter NSX greatly simplifies the process. Deployment elements consist of Universal Logical Switches, Universal Distributed Logical Router and Universal Distributed Firewalls. These universal objects facilitate the creation of a single unified logical network (L2, L3, DFW) across protected and recovery sites. The application can failover and recover seamlessly without the need for manually re-creating the network on the recovery site or manually mapping/re-mapping IP addresses.

 In this lab, we will address the most popular scenario of full failover of the 3-Tier application in case of extended outage or a catastrophic failure.


Lab Guidance


Note: It can take more than 90 minutes to complete this lab. If you have taken HOL-1825-01-NET, you can skip the following sections of this lab to save time but we still recommend to check the various NSX components are in operational state.

The Table of Contents can be accessed in the upper right-hand corner of the Lab Manual.

This lab assumes that students know the basics of NSX and are equipped with basic knowledge of SRM in multi-site scenarios. This lab is not intended to equip the students with the basic knowledge of SRM. If this is your first NSX lab, we recommend taking the following labs before you attempt this lab in order to build the basic knowledge on NSX:

  1. HOL-1803-01-NET  NSX Feature Tour
  2. HOL-1825-01-NET  NSX Advanced Consumption

In this lab, students will review and configure NSX for multiple sites. In this case, we will refer to each site as the Protected Site and Recovery Site.  Students will configure SRM components including protection plan and recovery plan for a web-based 3-Tier application. Then, they will facilitate full failover of 3-Tier application. We have configured the building blocks of NSX and SRM in order to save the time. Both the modules of the labs are independent of each other. If you are doing the entire Lab then you can follow the modules one by one. If you would like to only learn about SRM portion and are familiar with NSX in a multi-site configuration, then you can skip Module 1 and jump to the Module 2. Before jumping to Module 2 run the SRM FastFailover.ps1 power shell script. The process to run the script is described in the following section:

Lab Module List:

 Lab Captain:

  • Module 1-2 - Dev Sharma, Staff Systems Engineer,  Canada

This lab manual can be downloaded from the Hands-on Labs Document site found here:

http://docs.hol.vmware.com

This lab may be available in other languages.  To set your language preference and have a localized manual deployed with your lab, you may utilize this document to help guide you through the process:

http://docs.hol.vmware.com/announcements/nee-default-language.pdf


 

Location of the Main Console

 

  1. The area in the RED box contains the Main Console.  The Lab Manual is on the tab to the Right of the Main Console.
  2. A particular lab may have additional consoles found on separate tabs in the upper left. You will be directed to open another specific console if needed.
  3. Your lab starts with 90 minutes on the timer.  The lab can not be saved.  All your work must be done during the lab session.  But you can click the EXTEND to increase your time.  If you are at a VMware event, you can extend your lab time twice, for up to 30 minutes.  Each click gives you an additional 15 minutes.  Outside of VMware events, you can extend your lab time up to 9 hours and 30 minutes. Each click gives you an additional hour.

 

 

Alternate Methods of Keyboard Data Entry

During this module, you will input text into the Main Console. Besides directly typing it in, there are two very helpful methods of entering data which make it easier to enter complex data.

 

 

Click and Drag Lab Manual Content Into Console Active Window

 
 

You can also click and drag text and Command Line Interface (CLI) commands directly from the Lab Manual into the active window in the Main Console.  

 

 

Accessing the Online International Keyboard

 

You can also use the Online International Keyboard found in the Main Console.

  1. Click on the Keyboard Icon found on the Windows Quick Launch Task Bar.

 

 

Minimize Chrome and look at the lower right portion of the screen

 

In this lab, the Chrome browser will be automatically launched.  DO NOT CLOSE this window, but you can minimize the browser window to the task bar.

Please check to see that your lab is finished all the startup routines and is ready for you to start. If you see anything other than "Ready", please wait a few minutes.  If after 5 minutes your lab has not changed to "Ready", please ask for assistance.

 

 

Activation Prompt or Watermark

 

In this lab, the Chrome browser will be automatically launched.  DO NOT CLOSE this window, but you can minimize the browser window to the task bar.  

When you first start your lab, you may notice a watermark on the desktop indicating that Windows is not activated.  

One of the major benefits of virtualization is that virtual machines can be moved and run on any platform.  The Hands-on Labs utilizes this benefit and we are able to run the labs out of multiple datacenters.  However, these datacenters may not have identical processors, which triggers a Microsoft activation check through the Internet.

Rest assured, VMware and the Hands-on Labs are in full compliance with Microsoft licensing requirements.  The lab that you are using is a self-contained pod and does not have full access to the Internet, which is required for Windows to verify the activation.  Without full access to the Internet, this automated process fails and you see this watermark.

This cosmetic issue has no effect on your lab.  

 

Module 1 - Review Pre-Configured Multi-Site NSX and Configure Site-Local Routing (45 Minutes)

Module Guidance


In this module, students will review the existing multi-site configuration for various components such as NSX Managers, vCenter configuration, controller cluster, host preparation, logical network preparation as well as configuration of Edge GW's on both sites.  Students will also modify the Locale-ID of the Site RegionB01 to influence the egress traffic for all the application traffic. We will also walk you through configuring routing between Universal Distributed Logical Routers and Edge GW's on both sites using BGP.


Topology Overview


This section will familiarize you with the overall lab setup. It describes and explains the environment including the pre-configured logical topology and final logical topology after you are done with both Module 1 and 2.


 

Virtual Environment Topology

 

The picture shows the vSphere hosts and how VMs are placed across the different clusters,the Distributed Virtual Switches (DVS). The VTEP IP addresses associated to the hosts are also displayed.

Clusters RegionA01-MGMT01& RegionA01-COMP01 are both managed by vCenter Server A (vcsa-01a.corp.local).

RegionB01-COMP01 is managed by vCenter Server B (vcsa-01b.corp.local).

Both vCenters are connected to a common Platform Services Controller (psc-01a.corp.local) that resides on the management network of Region A01.

NSX Transport Zone (TZ) configuration in the lab consists in the following:

 

 

Pre-configured Logical Network Topology

 

When first accessing the lab, the topology shown in the picture is already implemented. Five NSX Universal Logical Switches are configured:

The simple 3-Tier application is already configured and Web Servers are Load Balanced through One-Arm Load Balancer attached to Web_Tier_ULS. The One-Arm Load Balancer is configured identically on both RegionA0 and RegionB0 but the difference is that the LIF of One-Arm Load Balancer is detached on RegionB0. The Logical Switches are attached to a Universal Distributed Logical Router (UDLR), which is in turn attached to an NSX Edge Services Gateway (ESG) in each region.  BGP routing guarantees route exchange between the ESGs and the external router. In addition, vSphere Replication is configured to replicate the 3-Tier application VMs.  SRM has also been pre-installed and configured with the initial pairing.

All this configuration is done in advance to concentrate on the actual use case we intend to highlight. During the course of the lab, you will configure elements shown in red boxes above including configuring Locale ID on Recovery Site, configuring iBGP between UDLR and ESGs on both the sites. Students will also configure a BGP prefix list for filtering routes.

 

 

Logical Topology after Full Application Failover

 

The topology shown above represents the environment after performing a full application failover. The north-south as well as east-west traffic including Load Balancer will exist in only in the Recovery Site.

 

Review vCenter Configurations


In this lab, the two vCenter servers have been configured in Enhanced Linked Mode.  This allows both vCenter Servers to be managed through the same vSphere Web Client session.  While in Enhanced Linked Mode, both NSX envionrments can also be configured in the the same vSphere Web Client session.  


 

Login to the vSphere Web Client and Select Hosts and Clusters

 

Your Chrome browser should already be logged in with the appropriate credentials.  Verify that you can see both vCenter inventories.

  1. Click on the Home button
  2. Click on Hosts and Clusters

 

Review NSX Manager Configurations


You will review the roles of assigned to NSX Manager.  The NSX manager register in Region A0 will have the Primary role.  The NSX manager registered in Region B0 will have the secondary role.


 

Navigate to the Networking & Security tab

 

  1. Click on the Home button
  2. Select Networking & Security

 

 

Navigate to the Installation tab

 

  1. Click on Installation

 

 

Verify NSX Manager Roles

 

  1. Click on Management Tab

You will now be taken to the NSX Manager Installation page.  In this lab, two NSX Manager's have been configured with Primary and Secondar roles. Verify that both NSX Managers are assigned a role.

 

Review Universal Controller Cluster


Now you will review the NSX Universal Controller Cluster.  The NSX Universal Controller Cluster performs the required control plane functions across both vCenter Servers and their respective NSX Managers.  This enables the configuration of Universal Logical Switches, Universal Logical Routers, and Universal Distributed Firewall Rules.


 

Verify Controllers on Primary NSX Manager

 

In the NSX Controller nodes window under the NSX Manager, verify that controller-1, controller-2, and controller-3 are connected to the Primary NSX Manager and Peers are showing green

 

 

Verify Controllers on Secondary NSX Manager

 

If you further scroll down in the NSX Controller window, you can verify that the controller-1, controller-2, and controller-3 are also connected to the Secondary NSX Manager.

 

Review Universal Logical Network Preparation


You will now review the pre-configured elements in the Logical Network Preparation tab.


 

Review Universal Segment ID pool on the Primary NSX Manager

 

Before Universal Logical Switches can be configured, a Universal Segment ID pool must be created.  The Universal Segment ID pool must be a unique range from all other Segment ID pools in use on both NSX Managers configured in a cross vCenter environment.

  1. Select Logical Network Preparation
  2. Select the Primary NSX Manager
  3. Select Segment ID
  4. Verify the Segment ID pool
  5. Note the different range used for Universal Segment ID pool

 

 

Change to the Secondary NSX Manager

 

To change the View to the Secondary NSX Manager:

  1. Click on the NSX Manager drop down
  2. Select the 192.168.210.42(Role:Secondary)

 

 

Review Universal Segment ID pool on the Secondary NSX Manager

 

The Secondary NSX Manager must also be configured with a Segment ID Pool(s).  The Segment ID pools configured on all NSX Managers must be non overlapping. The Universal Segment ID pool is synchronized from the Primary NSX Manager.

  1. Verify the Segment ID pool on the Secondary NSX Manager does not overlap with the Segment ID pool on the Primary NSX Manager
  2. Verify the Universal Segment ID pool is synchronized

 

 

Review Universal Transport Zones

 

Transport Zones define what clusters can participate in a specific Logical Network.  Global Transport Zones are confined to a single vCenter Server.  Universal Transport Zones may span vCenter Servers.  Verify the clusters connected to the Universal Transit Zone.

  1. Select Transport Zones
  2. Select Universal_TZ
  3. Click the Connect Clusters icon
  4. Verify the cluster RegionB01-COMP01 is connected and in Normal status

Switch to the Primary NSX Manager by changing the in the drop-down from the previous step and review the configuration of the Universal_TZ. Using the same view and steps outlined above.  Verify clusters RegionA01-COMP01 and RegionA01-MGMT01 are connected and in Normal status.

 

 

Review the Logical Switches in the Environment


Next, you will review the pre-configured Universal Logical Switches and create a new ULS.


 

Review Universal Logical Switches on Primary NSX Manager

 

Universal Logical Switches are configured in the same tab as Global Logical Switches.  Verify the five pre-configured Universal Logical Switches exist.

  1. Select the Logical Switches tab on the left side menu
  2. Select 192.168.110.42(Role:Primary)
  3. Verify five Logical Switches are configured and defined in the Universal TZ.

You can see that the Segment IDs of each Universal Logical Switche falls within the range of the Universal Segment ID pool.

 

 

Verify Universal Logical Switches on Secondary NSX Manager

 

Once configured Universal Logical Switches are synchronized to all secondary NSX managers.  Verify all switches are also avalabile on the the secondary NSX manager as well that their Segment IDs match those seen in the previous step.

  1. Select 192.168.210.42(Role:Secondary) from the drop-down
  2. Verify the Universal Logical Switches match the configuration on the Primary NSX Manager

The Logical Switches,Transport Zone, and Segment IDs are syncronized on all NSX Managers in this environment.

 

Review NSX Edge Configurations


In this lab, NSX Edge devices provide connectivity for north-south communication as well as east-west communication.  There are two pre-configured NSX Edge devices for north-south communication.  These perimeter gateways are configured with dynamic routing utilizing BGP.  The perimeter gateways utilize equal cost multipathing (ECMP) to allow traffic in and out of both sites.  A third NSX Edge has been pre-configured as a Universal Distributed Logical Router (UDLR) providing east-west routing among the application logical switches as well as connectivity to a transit ULS's in each site for north-south communication to the perimeter gateway ESGs.  This UDLR has been configured for ECMP and local egress.There is also another NSX Edge on RegionA0 and RegionB0 which is identical in configuration and is implemeted as One-Arm Load Balancer utilized for Web Server Load Balancing.


 

Local Egress

 

Local egress enables egress optimization per site.  Traffic is routed through the ESG at the site the traffic originated from.  East-west traffic utilizes the UDLR for optimization between VMs.  This configuration requires dynamic routing between the physical network and the ESGs as well as between the ESGs and the UDLR.  The UDLR advertises the configured network to both ESGs.  The ESGs advertises the UDLR networks to both site's physical network.  This configuration allows the physical network to transmit and receive traffic to and from the same network at both sites.

  1. Traffic originating from RegionA0 VMs egresses the logical network through the RegionA0 ESG
  2. Traffic originating from RegionB0 VMs egresses the logical network through the RegionB0 ESG
  3. Traffic between VMs utilizes the UDLR for east-west optimization

 

 

Review Perimeter Gateway Configurations

 

To view the configuration of the RegionA0_Perimeter_GW ESG

  1. Navigate to the NSX Edges tab on the left side menu
  2. Select 192.168.110.42(Role:Primary)
  3. Double Click on the RegionA0_Perimeter_GW ESG

 

 

Review the Interface Configuration

 

To view the interface configuration

  1. Select the Manage tab
  2. Select the Settings tab
  3. Select the Interfaces section

Review the Interfaces configured

vNIC0 is configured with an address in the subnet of the RegionA0 uplink network.  It is connected to the VLAN backed portgroup ESXi-RegionA01-vDS-COMP.  The type of interface is an uplink typically providing updates to the datacenter's physical routing infrastructure.

vNIC1 is configured with an address in the subnet of the RegionA0_Transit network.  It is connected to the Universal Logical Switch RegionA0_Transit.  The type of interface is internal (and in this case) connected downstream to a logical switch shared by the UDLR.

 

 

Review Routing Configuration

 

ECMP and BGP have been preconfigured on each ESG.  To view the configuration:

  1. Select the Routing Tab
  2. Review the Global Configuration.  Note that ECMP and BGP are enabled.
  3. Select the BGP section
  4. Review the configured neighbors.

The ESG has neighbors configured for 192.168.100.1 which is the upstream router.  As well as 192.168.5.3 which is the ULDR.  

 

 

Switch to the Secondary NSX Manager

 

Switch to the Secondary NSX Manager and review the configuration of RegionB0_Perimeter_GW using the same steps you did on the previous page.

  1. Click the Back navigation button on the left hand menu. This will take you to the main NSX Edges menu
  2. Select 192.168.210.42(Role:Secondary)

Once you have completed the review of the RegionB0_Perimeter_GW, repeat the above steps to return to the NSX Edges screen on the main left hand menu. and change back to the Primary NSX Manager.

 

 

Review Universal Distributed Logical Router Configuration

 

  1. Ensure 192.168.110.42(Role:Primary) is selected
  2. Double Click on Universal_DLR_01

 

 

Review UDLR General Configuration

 

To review the UDLR settings, perform the following :

  1. Select the Manage tab
  2. Click on the Settings tab
  3. Click on Configuration

Note Local Egress is enabled.  This can only be enabled during creation of the ULDR

 

 

Review UDLR Interface Configuration

 

  1. Select the Interfaces section
  2. Review the configured vNICs

There are two uplink interfaces configured.  The RegionA0_Uplink interface is configured on the Primary NSX Manager UDLR.  The RegionB0_Uplink interface is configured on the Secondary NSX Manager UDLR.  The internal interfaces are configured on the Primary NSX Manager.  The configuration of the UDLR is synchronized with the Secondary NSX Manager.  To review the UDLR appliance configuration on the Secondary NSX Manager return to the NSX Edges view and switch to the Secondary NSX Manager.

 

 

Review the One-Arm Load Balancer Configuration

 

  1. Double click on edge-2

 

 

Navigate to Load Balancer Section

 

  1. Click on Load Balancer
  2. Click on Pools

 

 

Check the Status of Pool

 

  1. Click on Show Pool Statistics

Make sure the Pool Status is up.

 

Set Locale-ID on RegionB0


You wil now set the Locale-ID on RegionB0 to the Locale-ID of RegionA0. Setting the Locale ID same on both sites will ensure that the north-south traffic is always entering and exiting out of Protected Site.


 

Pre-Configured Topology

 

The Locale ID is configured per cluster.  The Locale ID allows the ULDR to make routing decisions based on site.

 

 

Navigate to the Networking & Security tab

 

  1. Click on the Home button
  2. Select Networking & Security

 

 

Navigate to the Installation tab

 

You will now see a list of options which include creating logical switches, NSX Edges, Firewall rules etc.  

  1. Click on the Installation tab

 

 

Change the Locale ID of RegionB0

 

  1. Click on the Host Preparation tab (if you are not already there)
  2. Click on NSX Manager drop down
  3. Select 192.168.210.42 (Role:Secondary) option

 

 

Navigate to Change Locale ID

 

  1. Click on the gear icon located in the Installation Status column and click it to expand the menu
  2. Click on Change Locale ID

Then, minimize your browser session to return to the Main Console desktop.

 

 

Copy the Locale ID

 

On the Main Console Desktop, there is a text file entitled "HOL-1825-02-NET - VMware NSX Multi-Site and SRM in an Active-Standby Setup - README.txt" The file name may not be 100% visible due to screen resolution.

  1. Double-Click to open with Notepad.

 

 

Find the Locale ID for Site A

 

  1. Highlight the Site A Locale ID

 

 

Copy the Locale ID

 

Open the on-screen keyboard in the lower right hand of the task bar.

  1. Click the Ctrl Button
  2. Click the C or Copy button

 

 

Paste the New Locale ID

 

Return to your browser session.  Place your cursor in the Locale ID field.

Using the on-screen keyboard, click the CTRL and V or Paste.  Verify that the Locale ID in the field matches the one in the text file.

  1. Click OK

In next lesson we will configure routing between UDLR and Edge Gateways on RegionA0 and RegionB0

 

Configure BGP Filter on RegionB0_Perimeter_GW


In this section, you will configure a BGP Route Filter on the perimeter gateway in recovery site (RegionB0) to deny route advertisements for Web, App and DB networks out of Recovery Site RegionB0.


 

Navigate to the NSX Edges

 

  1. Click on NSX Edges in the left hand menu

 

 

Access the RegionB0_Perimeter_GW

 

  1. Double click the RegionB0_Perimeter_GW

 

 

Navigate to Routing Option

 

  1. Click on Manage
  2. Select the Routing tab to enter the routing configuration

 

 

Edit the BGP Neighbor Settings

 

  1. Click on BGP
  2. Select the neighbor 192.168.200.1
  3. Click on Edit (the pencil icon)

 

 

Add the BGP Filters for the neighbor

 

  1. In the BGP Filters section, click on the green plus or add button

 

 

Create Filters

 

  1. Click on Direction and select Out
  2. Click on Action and select Deny
  3. Click on Network and type 172.16.10.0/24
  4. Click OK  

Click the + again and Repeat steps 1-4 for 172.16.20.0/24 and 172.16.30.0/24 networks

 

 

Permit Rule

 

Add another filter by clicking the + sign again

  1. Click on Action and select Permit
  2. Click on Network and type 192.168.200.0/24
  3. Click OK

 

 

Finish creating filters

 

  1. Verify your filters match above
  2. Click OK to finish creating the filters

 

 

Publish Changes

 

  1. Click Publish Changes

The BGP filter created on Edge GW will block the publishing of 172.16.10.0/24, 172.16.20.0/24 and 172.16.30.0/24 subnets to the external router.

 

Enable BGP on Universal Logical Router RegionA0


You will now configure BGP on the Universal Logical Distributed Router.  


 

Navigate to NSX Edges

 

  1. Click on NSX Edges on the left side menu

 

 

Select the Primary NSX Manager

 

  1. Click on the NSX Manager drop down menu
  2. Select 192.168.110.42 (Role:Primary)

 

 

Navigate to the UDLR

 

  1. Double click on Universal_DLR_01

 

 

Edit the Routing of the UDLR

 

  1. Click on Manage
  2. Click on Routing

 

 

Navigate to Global Configuration

 

  1. Click on Global Configuration

 

 

Edit Dynamic Routing Configuration

 

The Router ID is a required setting for dynamic routing.  The Router ID is a unique value that identifies the router in the routing table.  This is normally an IP address configured on the router.

  1. Click the Edit Button in the upper right hand corner
  2. Select RegionA0_Uplink as the Router ID
  3. Click OK

 

 

Publish Changes

 

  1. Click Publish Changes

 

 

Configure the ULDR for BGP

 

  1. Select the BGP section
  2. Under BGP Configuration click Edit

 

 

Enable BGP

 

BGP must be enabled and a Local Autonomous System (AS) must be configured.  The AS is configured globally on an ESG, DLR, & ULDR.

  1. Check the Enable BGP check box
  2. Enter 65001 as the Local AS
  3. Click OK

 

 

Add a Neighbor

 

Add the RegionA0_Perimeter_GW as a Neighboor.  The IP address is the IP of the internal interface or the RegionA0_Perimeter_GW.  The forwarding address is the IP address of the Universal_DLR RegionA0 uplink interface.  The protocol address is an unused IP address in the same network as the forwarding address.  The RegionA0_Perimeter_GW ESG is configured with this address as a BGP neighboor.  The forwarding address is used as the data plane while the protocol address is used in the control plane.

  1. In the Neighbour Section, Click the Green Plus
  2. in the IP Address field, enter 192.168.5.1
  3. In the Forwarding Address field, enter 192.168.5.2
  4. In the Protocol Address field, enter 192.168.5.3
  5. In the Remote AS Field, Enter 65001

Leave all other fields as their default.

  1. Click OK

 

 

Publish Changes

 

  1. Click Publish Changes

 

 

Enable Route Redistribution

 

Route Redistribution must be enabled on the ULDR for connected network to be advertised via BGP.

  1. Select the Route Redistribution section
  2. Click Edit

 

 

Enable Route Redistribution for BGP

 

  1. Disable redistribution for OSPF
  2. Enable redistribution for BGP
  3. Click OK

OSPF is not configured in this lab and should be disabled

 

 

Configure Route Redistributing for BGP

 

A new redistribution criteria must be added for BGP to learn connected interfaces

  1. Under the Route Redistribution table, select the green plus or add icon
  2. Select BGP as the Learner Protocol
  3. Select Connected in the "Allow Learning From"
  4. Click OK

 

 

Publish Changes

 

  1. Click Publish Changes

In this section we configured iBGP between UDLR in RegionA0 to Edge GW in RegionA0

 

 

Verify BGP Neighborship

 

  1. Click on Putty
  2. Click on nsxmgr-01a.corp.local
  3. Click on Load
  4. Click on Open

 

Login as admin with password VMware1!

Run the command show edge all

Highlight the UDLR edge as shown

Run the command show edge edge-9f9881d3-b602-4eaa-a85c-bf45d451d698 ip bgp neighbor

Make sure the BGP State is Established up

 

Enable BGP on Universal Logical Router RegionB0



 

Configure the UDLR for Dynamic Routing

 

If you are not already on the NSX Edges Menu, navigate back to it.  To view the configuration of the RegionB0 UDLR

  1. Navigate to the NSX Edges
  2. Click on NSX Manager Drop Down
  3. Select 192.168.210.42(Role:Secondary)

 

 

Verify BGP Neigborship status

 

 

Login as admin with password VMware1!

Run the command show edge all

Highlight the UDLR edge as shown

Run the command show edge edge-9f9881d3-b602-4eaa-a85c-bf45d451d698 ip bgp neighbor

Make sure the BGP State is Established up

 

Verify Application Connectivity


You will now verify that the 3-Tier application is functional in RegionA0.


 

Open a New Tab

 

  1. Open a new Tab in the Chrome web browser--DO NOT CLOSE THE EXISITING TAB

 

 

Open Three Tier App

 

  1. Click on a New Tab, do not close your existing one
  2. Click on the webapp.corp.local

 

 

Verify Three Tier App

 

Verify that the Hands on Labs Multi Tier Application page is loaded and data is retrieved.  

 

 

Ping Application Virtual Machines

 

Open a command prompt on the Main Console

 

 

Ping Each Virtual Machine

 

Ping each virtual machine

  1. ping 172.16.10.11
  2. ping 172.16.20.11
  3. ping 172.16.30.11

All pings will be successful

 

Create Universal Distributed Firewall Rules Leveraging Universal Security Tags


You will now create Universal Distributed Firewall Rules for the Customer_DB_App application. Universal Distributed Firewall Rules now support use of Dynamic Criteria and Universal Tags in an Active-Passive Setup. Universal Distributed Firewall rules can span between vCenters in same Data Center or across multiple Data Centers. In this section, Universal Rules are created so that they can span between protected and recovery site.We are going to use Universal Security Tags as a static membership criteria. You can also use VM Name as the criteria as well.


 

Navigate to the vSphere Web Client

 

If you not already there, return to your vSphere web client session

  1. Click on the tab to your vSphere Web Client Section

 

 

Navigate to the Networking & Security tab

 

If you are not already there, navigate back to the Network & Security Section

  1. Click on the Home button
  2. Select Networking & Security

 

 

Change the Unique Selection Criteria for NSX Manager

In earlier releases of NSX, security tags are local to a NSX Manager,  and are mapped to VMs using the VM's managed object ID. In an  active-standby environment, the managed object ID for a given VM might  not be the same in the active and standby datacenters. NSX 6.3.x allows  you to configure a Unique ID Selection Criteria on the primary NSX Manager to use to identify VMs when attaching to universal security tags: VM instance UUID, VM BIOS UUID, VM name, or a combination of these  options.

 

  1. Click on Installation
  2. Highlight Primary NSX Manager
  3. Click on Actions
  4. Click on Unique ID Selection Criteria

 

 

Select the Unique ID Selection Criteria

 

  1. Check the box Use Virtual Machine Instance UUID
  2. Click OK

 

 

Navigate to NSX Managers

 

  1. Click on NSX Managers

 

  1. Click on 192.168.110.42 which is the Primary NSX Manager
  2. Click on Manage

 

 

Create Universal Security Tags

 

  1. Click on Security Tags
  2. Click on green plus sign to create new Tags
  3. Create the Tag with name ST-WEB
  4. Check the box Mark this object for Universal Synchronization
  5. Click OK
  6. Repeat steps 3,4,5 for creating security tags ST-APP,ST-DB and ST-3-Tier

 

 

Verify the creation on Primary and Secondary NSX managers

 

  1. Click on Secondary NSX Manager:192.168.210.42 and very the sync of Tags from Primary NSX manager

 

 

Add Security Tags to the VM's

 

  1. Click on Primary NSX Manager:192.168.110.42
  2. Click on ST-WEB Tag
  3. Click on Assign Security Tag
  4. In the Assign Security tag to Virtual Machines Window, double click on web-01a.corp.local and web-02a.corp.local
  5. Verify it in the Selected Objects pane
  6. Click OK

Repeat steps 2 to 6 for other Tags and assign them to their respective VM's ST-APP to app-01a.corp.local and ST-DB to db-01a.corp.local

 

 

Assign Security Tag ST-3-Tier to all the VM's

 

  1. Click on ST-3-Tier
  2. Click on Assign Tag
  3. Double Click on app-01a.corp.local
  4. Double Click on db-01a.corp.local
  5. Double click on web-01a.corp.local and web-02.corp.local
  6. Click OK

 

 

Create Universal Security Groups for Application Tiers

 

  1. Click on Grouping Objects
  2. Click on Security Group
  3. Click on green plus sign

 

 

Create New Universal Security Group and include Security Tag

 

  1. Type the name SG-WEB
  2. Click on check box Mark this object for Universal Synchronization
  3. Click the check box Use for active standby deployments
  4. Click on Select objects to include
  5. Click on drop down and select Security Tag
  6. Double click on ST-WEB
  7. Click Finish

Repeat Steps 1 to 7 for creating security groups SG-APP and SG-DB. Use the Tag ST-APP for SG-APP and ST-DB for SG-DB as criteria.

 

 

Create Security Group SG-3-Tier to wrap all the tiers of application

 

  1. Name the secuirty group SG-3-Tier
  2. Check the option Mark this object for Universal Synchronization
  3. Check the option Use for active standby depolyments
  4. Click on Select objects to include
  5. Select Security Tag
  6. Double Click on ST-3-Tier
  7. Click Finish

 

 

 

Verify Creation of Security Groups on Primary and Secondary NSX Managers

 

As soon as you create the Security Groups on Primary NSX manager, the Universal Syncronization Service will push the Security Groups to the Secondary NSX manager.  It is important to validate that the synchronization is taking place across both NSX Managers.

  1. Click on 192.168.210.42
  2. Verify creation of Security Groups

 

 

Navigate to the Firewall Tab

 

Navigate to the Distributed Firewall Configuration page:

  1. Click on NSX Managers at the top of the left hand menu to return to the main Network & Security menu
  2. Click on the Firewall in the left hand menu

 

 

Add a Section to the Firewall Ruleset

 

Insure that you are accessing the Primary NSX Manager in the NSX Manager drop-down.

  1. Click the Add Section Icon (Hint: It is a folder with a green plus sign) in the Default Section Layer3 (Rule 1-3)

 

 

Create Section

 

  1. Name the Section Three Tier App
  2. Select Mark this section for Universal Synchronization
  3. Select Save

 

 

Add a Universal Rule

 

In the newly created Section, add a place holder for a universal rule

  1. Click the Add Rule icon (Hint: It is the green plus sign)

 

 

Expand the Three Tier App Section

 

  1. Expand the section by clicking on the triangle (or twistie) next to the Three Tier App (Rule 1)

This will expose the placeholder for the new universal rule.  In the following steps we will populate this rule.

 

 

Configure a Rule for Web Server Access

 

In this step you will configure a rule that allows access to the web tier from any on http

  1. Click the Edit or pencil icon to name the rule

 

 

Name the Rule

 

  1. Name the rule Inbound Web Server
  2. Click Save

 

 

Configure Destination

 

For this rule, you will leave the source column set to any as we do not wish to filter for a particular source.  However, we will modify the destination for a specific IP Set of addresses.

  1. Locate the Destination Column, and Click on edit or the pencil in the upper right hand corner.

 

 

Configure Destination Security Group

 

In the resulting window, find the Object Type window and select the drop down to change the setting to Security Groups.

  1. Click on the Object Type drop down menu
  2. Double click on SG-WEB
  3. Click OK

 

 

Confirm Destination in the Firewall Rule

 

Confirm that the Destination column now shows the SG-WEB you just created.

 

 

Configure Services for the rule

 

  1. In the Services column, Click on edit or pencil icon in the upper right hand column

 

 

Define Services for the Rule

 

  1. Enter http in the search field
  2. Double click HTTPS service listing. Validate that the service is moved to the Selected Objects menu.
  3. Click OK

 

 

Apply the Rule to SG-WEB

 

  1. Click on the pencil icon to open the Applied To configuration box

 

 

Apply the Rule to SG-3-Tier

 

  1. Click on Logical Switch drop down
  2. Click on Security Group
  3. Double click SG-3-Tier in the Available Objects pane
  4. Click OK

 

 

Configure a Rule for Web to Application Server under previous rule

 

  1. Right Click on the Inbound Web Rule that you just created
  2. In the menu, Click on Add Below

 

 

Add a Rule

 

  1. In the Name column, Click edit or the pencil icon in the upper right corner of the cell to name the rule

 

 

Name the Rule

 

  1. Name the rule Web to App
  2. Click Save

 

 

Configure the Source for the rule

 

In the source column, edit it to specify a specific source

  1. Click on the edit or pencil icon

 

 

Select SG-WEB as source

 

The source of this rule will be previously created Web-USG and the destination will be new security group App-USG

  1. Click on the Object Type drop down menu and select Security Group
  2. Double Click SG-WEB and validate that it shows on the Selected Objects menu
  3. Click OK

 

 

Configure Destination Security Group

 

  1. In the Destination column, Click on edit or the pencil icon

 

 

Define the Destination as the App Tier Security Group

 

The previous created IP Set corresponding to the App Tier will be used to create the destination Security Group for this rule.  

  1. Click on the Object Type drop down menu and select Security Group
  2. Double click SG-APP
  3. Click OK

 

 

Configure Services for the Rule

 

  1. Click on edit or the pencil icon to in the Service column cell for the rule

 

 

Create New Service Tomcat

 

  1. Click on New Service
  2. In the Add Service box type the name Tomcat
  3. Select the protocol TCP
  4. Type the destination port 8443
  5. Click OK

 

 

Apply the Rule to SG-APP

 

  1. Click on the pencil icon to open the Applied To configuration box

 

 

Apply the Rule to SG-3-Tier

 

  1. Click on Logical Switch drop down
  2. Click on Security Group
  3. Double click SG-3-Tier in the Available Objects pane
  4. Click OK

 

 

Configure a Rule for Application to Database Server

 

You will create the rule to allow Application Tier to access Database Tier. Right Click beside Rule 2 as shown above

  1. Right Click on the Web to App Rule that you just created
  2. In the menu,  Click on Add Below

 

 

Edit the Name of the newly created rule

 

  1. In the Name column, Click edit or the pencil icon in the upper right corner of the cell to name the rule

 

 

Name the Rule

 

  1. Name the rule App to DB
  2. Click Save

 

 

Configure the Source

 

  1. Click on edit or the pencil icon

 

 

Select security group SG-APP created previously

 

  1. Click on Object Type drop down menu and select Security Group
  2. Double click to select SG-APP and validate that SG-APP has appeared in the Selected Objects menu
  3. Click OK

 

 

Configure Destination

 

  1. Click on edit or pencil icon to add destination

 

 

Select  Security Groups

 

  1. Click on the Object Type drop down menu
  2. Select Security Group

 

 

Configure Service

 

  1. Click on edit or the pencil icon in the Service column cell for the rule

 

 

Select HTTP

 

  1. Enter HTTP in the search field(This is a lab application and it is listening on port 80 for DB but in real world the port will be 3306 or 1433)
  2. Double Click HTTP
  3. Click OK

 

 

Apply the Rule to SG-3-Tier

 

  1. Click on Logical Switch drop down
  2. Click on Security Group
  3. Double click SG-3-Tier in the Available Objects pane
  4. Click OK

 

 

Configure Default Rule to reject every other traffic

 

You will create a default deny rule. Right Click beside Rule 3 as shown above

  1. Right Click on the App to DB Rule that you just created
  2. In the menu,  Click on Add Below

 

 

Name the Rule

 

  1. Enter the Rule Name as Block any to 3-Tier App
  2. Click on Save

 

 

Change the destination of the Rule to SG-3-Tier

 

This rule will block all other traffic not explicitly defined earlier.

  1. Select Security Group
  2. Double click SG-3-Tier
  3. Click OK

 

 

Edit the Action

 

  1. Change the Action to Reject
  2. Click Save

 

 

Apply the Rule to SG-3-Tier

 

  1. Click on Logical Switch drop down
  2. Click on Security Group
  3. Double click SG-3-Tier in the Available Objects pane
  4. Click OK

 

 

Verify the Rules

 

 

 

Publish Changes

 

Verify that your new section looks similar to the one pictured above.

  1. Click Publish Changes to publish the Universal Firewall Rules.  No rules will be enforced until changes are Published

 

 

Verify Creation on Secondary NSX Manager

 

 

 

Verify Application Connectivity

 

  1. Click on the New Tab button
  2. Click on the webapp.corp.local Bookmark

 

 

Verify Three Tier App

 

Verify that the Hands on Labs Multi Tier Application page is loaded and data is retrieved.  

 

 

Ping Application Virtual Machines

 

To verify the default deny rule open a command prompt on the Main Console

 

 

Ping Each Virtual Machine

 

Ping each virtual machine to verify the default deny rule.

  1. ping 172.16.10.11
  2. ping 172.16.20.11
  3. ping 172.16.30.11

No pings will be successful

This concludes this section. In this section we configured Universal Distributed Firewall Rules and used Universal Security Groups to protect flows between the various tiers of the application across multiple sites. Universal Rules synchronize automatically from one site to another.

 

 

Disable the 3-Tier-App Block Rule

We will disable the defaut 3-Tier Block Rule as we will use Traceroute in the Next Module to trace the Path from Main Console to Web Server VM

 

  1. Click on Home icon
  2. Click on Networking and Security

 

  1. Click on Firewall
  2. Expand the Three Tier App Rules
  3. Click on green Check mark (It will turn grey)
  4. Click on Publish Changes

 

Module 1 Conclusion


This module walked you through the various pre-configured components of NSX in a multi-site configuration. You also learned how to configure Locale ID, dynamic routing on UDLR,configuring Universal Distributed Firewall rules and route filtering for making one site preferred over another. The techniques used in this module are not the only way you can influence ingress/egress traffic. There are other ways to do it and we showed you one of the popular way to do it.


 

You've finished Module 1

Congratulations on completing Module 1. You can proceed to Module 2 for configuring the SRM and performing partial and full failover of the application or End the Lab. Process to end the lab is described in "How to End Lab" section.

For additional information on NSX Universal configurations and cross vC scenarios, visit the URL below and select the Cross-vCenter Installation Guide:

 Lab Captain:

 

 

How to End Lab

 

To end the lab click on the END button.  

 

Module 2 - Site Recovery Manager Configuration (45 Minutes)

Module Guidance


In this module, students will learn how to configure the important SRM components such as Protection Groups, Folder Mappings, Resource Mappings, Recovery Plans, etc. In addition to configuring these various components, students will perform full failover of a 3-Tier application without changing IP addresses.

IMPORTANT NOTE: IF YOU ARE TAKING MODULE 2 WITHOUT FIRST COMPLETING MODULE 1, THEN YOU MUST EXECUTE THE SCRIPT DETAILED BELOW.

If you have already completed Module 1, then you can skip the next step and proceed to "Creating SRM Protection Groups for Application".

 

 


 

Running the SRM FastForward Script

 

ONLY PERFORM THE STEP BELOW IF YOU INTEND TO SKIP DIRECTLY TO MODULE 2. IF YOU INTEND TO TAKE MODULE 1, THEN PROCEED TO

  1. Right-Click on SRM FastForward.ps1 script placed on desktop of Main Console
  2. Click on Run with PowerShell

The script will perform the following configuration within the NSX environment:

  1. Configure Locale-ID for RegionB0
  2. Configure BGP Filters
  3. Routing for Primary Universal Distributed Logical Router
  4. Routing for Secondary Universal Distributed Logical Router
  5. Configure Universal Security Tags
  6. Configure Universal Security Groups
  7. Configure Universal Distributed Firewall Rules

 

 

 

 

Script Execution

 

Once the script is finished running, the window will disappear. This script will configure all the steps required to proceed to the next step.

NOTE: The script will also create a "Reject" rule for the 3-Tier Application. Please go ahead and disable the rule as shown in the next steps. The rule needs to be disabled for testing reachibility to the various tiers of the application by using PING and Traceroute.

 

 

Disable the 3-Tier-App Block Rule

We will disable the defaut 3-Tier Block Rule as we will use Traceroute in the Next Module to trace the Path from Main Console to Web Server VM

 

  1. Click on Home icon
  2. Click on Networking and Security

 

  1. Click on Firewall
  2. Expand the Three Tier App Rules
  3. Click on green Check mark (It will turn grey)
  4. Click on Publish Changes

 

Creation of SRM protection groups for Application


You will now setup SRM Protection Groups and Protection Plans for the Web Application in order to be able to fail over the application. We have already setup vSphere Replication and replicated the VMs to Site B in order to save time.


 

Navigate to Site Recovery

 

  1. Click Home Icon
  2. Select Site Recovery

 

Configure Network Mappings


As a part of the SRM configuration, network mappings are needed.  These enable the recovery plan to connect VMs to the appropriate networks during a failover plan.


 

Configure Network Mappings

 

We need to configure the mappings between Site A and Site B for the NSX Networks we just created.

  1. Select Sites

 

 

Navigate to Site A Network Mappings

 

  1. Select vcsa-01a-corp.local (the RegionA0 vCenter)
  2. Click Manage
  3. Click Network Mappings
  4. Click the Add New Mapping Icon

 

 

Manual Mappings

 

The Create Network Mapping Wizard will appear.

  1. Select Prepare Mappings Manually
  2. Click Next

 

 

Expand Sites

 

In the prepare mappings section of the wizard, you will need to expand the inventories so that you can see the entirety of the available networks for mapping.  

  1. Fully expand the inventory by clicking on the triangles or "twisties"  so that you see both sites and their respective Compute vDS.  RegionA0 has a vDS names RegionA01-vDS-COMP & RegionB0 has a vDS named RegionB01-vDS-COMP.

 

 

Create Mappings

 

Pay special attention to the steps in this part. Due to the length of the names of the VXLAN Port Groups exceeding the window size, we need to match them by the Unique ID of the VXLAN Segments.

  1. Select the network with the Logical Switch or "universal wire" with ID of 4 on the Site A tree
  2. Select the network with the Logical Switch or "universal wire"with ID of 4 on the Site B tree
  3. Note the ID's on each name
  4. Click Add Mappings

Complete Steps 1-4 again and match network with the Logical Switch or "universal wire" with IDs of ID 5 and 6 respectively.

IMPORTANT!  DO NOT click NEXT before proceeding to next step,

If you hover the mouse over the name, you can see the full port group name which will also have the named of the logical switch at the end.  The goal here is to match the Web_Tier_ULS at each site together, then the App_Tier_ULS and the DB_Tier_ULS respectively. Assuming you made the switches in the same order the the manual (e.g. Web first, then App, then DB) the following ID should be as follows:

• Universalwire ID 4 is Web_Tier_ULS

• Universalwire ID 5 is App_Tier_ULS

• Universalwire ID 6 is DB_Tier_ULS

 

 

Verify Mappings and Proceed

 

  1. Verify that all the mappings to the Tiers are correct
  2. Click Next

 

 

Test Networks

 

You are not going to make any changes to the "Select Test networks" portion of the wizard.

  1. Click Next

 

 

Reverse Mappings

 

You are not going to make any changes to the "Prepare Reverse Mappings" portion of the wizard.

  1. Click Finish

 

Folder Mappings


You will now configure folder mappings for the SRM configuration


 

New Folder Mapping

 

  1. Click on Folder Mappings
  2. Click on New Folder Mappings

 

 

Create Folder Mapping

 

  1. In the Create Folder Mapping Wizard, Select the option Prepare Mappings Manually
  2. Click Next

 

 

Prepare Mappings

 

In the Prepare Mappings portion of the Wizard perform the following steps:

  1. Check Region-A01
  2. Check Region-B01
  3. Click on Add mappings
  4. Click Next

 

 

Finish creating folder mapping

 

You will not need to create reverse mappings required for Failback.  This lab will not be focusing on a Failback scenario.

  1. Click Finish

 

Resource Mappings


In this section, you will create resource mapping for your application


 

Create new Resource map

 

  1. Click on Resource Mappings
  2. Select a New Resource Mapping (hint: it's the resource pool icon with the plus sign)

 

 

Prepare Mapping

 

  1. Expand Region_A0 inventory tree in the left hand menu
  2. Expand Region_B0 inventory tree in the right hand menu
  3. Select RegionA01-COMP01

There is only one resource available in RegionB0. The resource "RegionB0-COMP01" Cluster should already be selected.

  1. Click on Add Mappings
  2. Validate the mapping is between RegionA01-COMP-01 and RegionB01-COMP01
  3. Click Next

 

 

Reverse Mapping

 

There is no need to create reverse mapping. We will not be testing a failback scenario in this lab.

  1. Click Finish

 

Placeholder Datastore


You will now add the datastore configuration for SRM.


 

Configure Placeholder Datastore

 

 

  1. Click on Placeholder Datastores
  2. Click the new datastore or "plus" sign as shown

 

 

Select the Datastore

 

  1. Select datastore RegionA01-ISCSI01-COMP01
  2. Click OK

 

 

Create Placeholder Store on RegionB01

 

  1. Now, select vcsa-01b.corp.local in the left hand menu "Sites" menu
  2. Click on Placeholder Datastores if not already there
  3. Hover over the plus sign and click

 

 

Select Placeholder Datastore

 

  1. Select placeholder datastore RegionB01-ISCSI01-COMP01
  2. Click OK

 

Create Protection Group


You must now create the base protection group of the 3-Tier Application for the 4 VMs

 


 

Navigate to Site Recovery Home

 

  1. Click on Site Recovery in the Navigator Menu

 

 

Protection Groups

 

  1. Select Protection Groups
  2. Click on Protection Groups option
  3. Click on Create Protection Group button

 

  1. Type Name 3-Tier-App
  2. Select vcsa-01a.corp.local-vcsa-01b.corp.local
  3. Click Next

 

 

Protection Group Type

 

  1. Select vcsa-01a-corp.local -> vcsa-01b.corp.local to indicate direction of the recovery
  2. Select Individual VM's (vSphere Replication)
  3. Click Next

 

 

Select VMs

 

  1. Select the Checkbox Virtual Machines
  2. Click Next

 

 

Complete 3-Tier App Protection Group creation

 

  1. Click Finish

 

 

Protection Group Verification

 

Please note this step will take a few moments to complete while it is configuring. You can update the window using the vSphere Refresh icon, although it may take up to 2-3 mins to complete.

  1. Note the field that the App and DB Protection Group says Protection Status OK and Recovery Status READY

 

 

Create Recovery Plan


In this section we will create recovery plans for failing over the 3-Tier Application from Protected site to Recovery site


 

Navigate to Site Recovery Home

 

  1. Click on Recovery Plans
  2. Click on Create Recovery Plan

 

 

Name the Recovery Plan

 

  1. Type the name 3-Tier-App
  2. Select on vcsa-01a.corp.local-vcsa-01b.corp.local
  3. Click Next

 

 

Select the Recovery Site

 

  1. Click on radio button for recovery site which is vcsa-01b.corp.local
  2. Click Next

 

 

Select the Protection Group

 

  1. Select the previously created protection group 3-Tier-App
  2. Click Next

 

 

Test Networks

 

In the Test Networks section, leave the test networks as default.

  1. Click Next

 

 

Finish Creating the Recovery Plan

 

  1. Click Finish

 

 

Verify Creation of Recovery Plans

 

The 3-Tier application VM's are now protected with SRM and will be able to fail over to the secondary site, using the same NSX network. In the next section, we will fail it over and verify its functionality.

 

Bring down the Edge GW


In this section, you will shut down the RegionA0_Perimeter_GW to simulate failure. In a real time environment, organizations can have multiple component failure. Those components could be any one of the listed below:

  1. Controller Cluster Failure
  2. Edge GW Failure
  3. Physical Router Failure
  4. WAN Link Failure
  5. NSX Manager Failure
  6. DCI Failure

Within the scope of this lab we are not targeting all the failures. There is an excellent white paper that you can refer to which covers some of the failures in the environment. The white paper is available at the URL below:

https://communities.vmware.com/docs/DOC-31692

 


 

Navigating to Hosts and Clusters

 

  1. Click on Home Icon
  2. Click on Hosts and Clusters

 

 

Shut Down the Edge GW

 

  1. Right Click on RegionA0_Perimeter_GW
  2. Hover over to Power Option
  3. Click on Shut Down Guest OS

 

Run the recovery plan to Failover the site


We will now run the recovery process for 3-Tier-App to failover the full application.


 

Launch the vSphere Web Client for Region-B

 

  1. Click on New Tab
  2. Click on RegionB vCenter

Note: Login to RegionB vCenter might take 2-3 minutes. Wait for the login to complete. This is POD specific behaviour and will not be present in real world.

 

 

Navigate to Site Recovery

 

  1. Go to Home icon
  2. Click on Site Recovery

 

 

Select Recovery Plans

 

  1. Select Recovery Plans

 

 

Select 3-Tier-App

 

  1. Select 3-Tier-App
  2. Click on Monitor
  3. Click on Red Play button

 

 

Confirm Recovery Options

 

  1. Check the "I understand that this process will permanently alter the virtual machines and infrastructure..."
  2. Click on Disaster Recovery radio button
  3. Click Next

 

 

Execute the Plan

 

  1. Click Finish to execute the plan

 

 

Monitor Steps

 

Monitor the progress of the recovery plan.  This could take 3-5 minutes to complete.

 

 

The Trigger-Failover script

 

  1. Minimize the Browser screen. DO NOT CLOSE

 

 

Explore the Trigger-Failover script

 

  1. Right Click on Trigger-Failover.ps1 script
  2. Click on Edit with Notepad++

 

 

Script Functions

 

PLEASE DO NOT EDIT THIS SCRIPT

Please feel free to explore the script. The script is divided into various sections and each task has been given a heading. The script performs the following configuration:

These functions provide automation of the some of the tasks required for a full site failover.  We wanted to show you the steps required in more detail. It should be noted that script execution for this could be completely integrated into a recovery plan so that the entire process is seamless.

 

 

Execute the Trigger-Failover.ps1 file placed on desktop of Main Console

 

  1. Right Click on Trigger-Failover.ps1 script
  2. Click Run with PowerShell

 

 

Monitor the Execution

 

 

 

 

Open the Command Prompt

 

  1. Minimize your current window and open a Command Prompt window on the Main Console

 

 

Run Traceroute from Main Console

 

  1. Type tracert 172.16.10.11 and hit Enter

As shown by the text highlighted in yellow the path to the Web VM is through recovery site Edge GW as well as recovery side UDLR. The traceroute is the evidence that the path to reach the application has changed and is now through recovery site.

 

Connect to 3-Tier App


Let's check the connectivity to the application after the full failover


 

Open a New Tab

 

  1. Click on the New Tab button

 

 

Access the Application

 

  1. Click on webapp.corp.local

 

 

Verify Three Tier App

 

Verify that the Hands on Labs Multi Tier Application page is loaded and data is retrieved.  

 

 

Ping Application Virtual Machines

 

  1. Open a command prompt on the Main Console

 

 

Ping Each Virtual Machine

 

Ping each virtual machine to verify connectivity to the application

  1. ping 172.16.10.11
  2. ping 172.16.20.11
  3. ping 172.16.30.11

All pings will be successful

 

 

Navigate to Hosts and Clusters

 

Notice Web, App and DB tier VM's are sitting in Region-B01 which is the recovery site.

As you can see, the application is accesible after the complete application failed over to Site RegionB01. For the failover, you did not have to change IP addresses of the VM's, or any firewall rules.

 

 

Navigate to Network and Security

 

  1. Click on Home icon
  2. Click on Networking and Security

 

 

Verify the VM's are automatically part of SG-WEB Security Group on Secondary Site

 

  1. Click on Firewall
  2. Click on SG-WEB in the Source Field of Firewall rule and verify the web01a and web02a part of Security Group
  3. Close the box by clicking on X icon

 

Verify the Security Tags enforcement on the web01a VM and also the Security Group Membership as highlighted in yellow. The tags are syncronized automatically from Primary NSX manager to Secondary NSX manager.

 

Module 2 Conclusion


This module walked you through the configuration of SRM including creation of protection groups and recovery plans used as recovery run book for failing over application from protected site to recovery site.

While we did not cover reverse mappings, they are also a very important topic. Reverse mappings are necessary to failback from Recovery Site to Protected site once the Protected site is in a stabilized state.

NSX is a platform built from ground up for supporting automation. In this lab we leveraged scripting to initiate certain workflows which allowed us to failover the traffic including Server Load Balancing from Protected Site to Recovery Site without manually changing routing configuration.

 


 

You've finished Module 2

Congratulations on completing Module 2 and this completes the lab.

 Lab Captain:

 

 

How to End Lab

 

To end the lab click on the END button.  

 

Conclusion

Thank you for participating in the VMware Hands-on Labs. Be sure to visit http://hol.vmware.com/ to continue your lab experience online.

Lab SKU: HOL-1825-02-NET

Version: 20180820-170920