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


Lab Overview - HOL-1825-01-NET - VMware NSX Advanced Consumption

Lab Guidance


Note: It will take more than 90 minutes to complete this lab. You should expect to only finish 2-3 of the modules during your time.  The modules are independent of each other so you can start at the beginning of any module and proceed from there. You can use the Table of Contents to access any module of your choosing.

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

In this lab students will interact with the NSX RESTful API to preform functions available in the GUI and functions available via the API only.  Students will review and configure multi-site NSX.  Students will perform a migration of an application stack between sites.

Lab Module List:

 Lab Captains:

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

 

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.  

 

Lab Topology


This lab consists of two separate sites (named RegionA0 and RegionB0), each one with its own vCenter, dedicated vSphere 6.0 hosts, storage and network subnets. The vCenters share a common Platform Services Controller (PSC), that allow common Identity Management, Licensing and Application Interaction across sites.

Region A consists of two clusters:

The two clusters share a common Management subnet (192.168.110.0/24), as well as a vMotion (10.10.30.0/24) and an IP storage network (10.10.20.0/24).

Networks dedicated to NSX VTEPs (VXLAN Tunnel End Points) are separate per site, RegionA01 is using 192.168.130.0/24. The VTEP subnets are routed together by an external router (vpodrouter).

Region B consists of a single cluster:

Region B has its own Management subnet (192.168.210.0/24), as well as separate vMotion (10.20.30.0/24), IP storage (10.20.20.0/24) and VTEP (192.168.230.0/24) networks.

Management, vMotion and VTEP networks are routed across the different sites to allow common management, Cross vCenter vMotion and network extensibility (VXLAN).

All VTEP networks have a 1600 byte MTU configured, to allow VXLAN encapsulation to occur.


 

Virtual Environment Topology

 

The picture shows the vSphere hosts and how VMs are placed across the different clusters, as well as the Distributed Virtual Switches (DVS). 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 A.

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 (Web_Tier_ULS, App_Tier_ULS, DB_Tier_ULS, RegionA01_Transit, RegionB01_Transit) and a 3-Tier Web Application is configured.  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 Dynamic Routing guarantees route exchange between the ESGs and the external router.

 

 

Final Logical Network Topology

 

Upon competition of Modules 1,2,3 and 4, the topology in the picture will be configured in the lab, as follows:

 

Module 1 - VMware NSX REST API (15 minutes)

NSX RESTful API


NSX is designed ground up with a RESTful API. The NSX REST API can be used to both configure NSX and to provision NSX logical network services. The NSX REST API can be called directly or indirectly from various programming languages. Many orchestration and automation tools such as vRealize Automation via vRealize Orchestrator can call the NSX REST API to perform Layer 2 through Layer 7 network orchestration and automation.

To demonstrate NSX RESTful API calls, you will be using the RESTClient extension to the Mozilla Firefox browser. RESTClient is a debugger for RESTful Web Services and is a useful tool when working with various REST API's.

During this module the following tasks will be completed:


 

Introduction to REST API's

 

A REpresentational State Transfer (REST) API defines a set of simple principles which are loosely followed by most API implementations.

REST leverages the strength of HTTP to send data (Headers and Bodies) between Clients and Servers.

The term Uniform Resource Locator (URL) and Uniform Resource Identifier (URI) can be used interchangeably when working with REST.

Resources (building blocks) are linked together by embedded hyperlinks in HTML documents or URI references, and resources can expose the state via representations containing both metadata (such as size, media type, or character set) and content (binary image or text document).

 

Intro to PowerShell REST cmdlets


PowerShell includes a REST client.  This is an into into the Invoke-RestMethod cmdlet


 

Invoke-RestMethod

The PowerShell Invoke-RestMethod cmdlet allows a user to access RESTfull APIs.  This cmdlet contains all of the methods and options required to interact with the NSX API.  Below is the syntax for the method.

Invoke-RestMethod [-Uri] <Uri> [-Body <Object> ] [-Certificate <X509Certificate> ] [-CertificateThumbprint <String> ] [-ContentType <String> ] [-Credential <PSCredential> ] [-DisableKeepAlive] [-Headers <IDictionary> ] [-InFile <String> ] [-MaximumRedirection <Int32> ] [-Method <WebRequestMethod> {Default | Get | Head | Post | Put | Delete | Trace | Options | Merge | Patch} ] [-OutFile <String> ] [-PassThru] [-Proxy <Uri> ] [-ProxyCredential <PSCredential> ] [-ProxyUseDefaultCredentials] [-SessionVariable <String> ] [-TimeoutSec <Int32> ] [-TransferEncoding <String> {chunked | compress | deflate | gzip | identity} ] [-UseBasicParsing] [-UseDefaultCredentials] [-UserAgent <String> ] [-WebSession <WebRequestSession> ] [ <CommonParameters>]

 

 

Minimize the vSphere Web Client

 

  1. Minimize the vSphere Web Client.

 

 

Open Example PowerShell Script

 

Open the "REST Example.ps1" file in the API Module folder on the desktop with Notepad++

  1. Double Click the API Module folder.
  2. Right click the "REST Example.ps1".
  3. Select Edit with Notepad++.

 

 

Review Script

 

This PowerShell Script will create a Logical Switch

  1. This is the initialization of the script.
  2. This defines the details of the logical switch.
  3. This calls NSX Manager to create the logical switch.  

Note the use of Invoke-WebRequest instead of Invoke-RestMethod.  This had been done to validate HTTP headers upon return of the call.

 

 

Run the Example Script

 

  1. Right Click on REST Example.ps1.
  2. Select Run With PowerShell.
  3. Review the output.

 

 

Return to the vSphere Web Client

 

 

  1. Select the vSphere Web Client window in Chrome.

 

 

Navigate to the Networking & Security tab

 

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

 

 

Verify Logical Switch Creation

 

  1. Click on Logical Switches.
  2. Verify the RestSwitch1 has been created.

 

 

Remove RestSwitch1

 

  1. Right click on RestSwitch1.
  2. Click Remove.
  3. Click Yes.

 

Create Multiple Logical Switches


In this lesson a powershell script will create multiple logical switches via the NSX API.


 

Open Example Script

 

  1. Double Click the API Module folder on the desktop.
  2. Right Click on the Create Switches.ps1 file on the desktop.
  3. Select Open with Notepad++.

 

 

Review the Script

 

This script builds on the previous script by using an array of switch names to build multiple switches.

  1. This defines the $switches array to contain three switch names Web, App, and DB.
  2. This loops through each value of the $switches array.  
  3. The switch name is added to the request body during each loop.

 

 

Run the Create Switches Script

 

  1. Right Click on the Create Switches.ps1 file.
  2. Click Run with PowerShell.

 

 

Review Output

 

The Logical switches Web, App, and DB were created and assigned available virtualwire IDs.  The IDs in the lab may differ.

Press any key to continue.

 

 

Return to the vSphere Web Client

 

  1. Click the Refresh icon.
  2. Verify the App switch was created.
  3. Verify the DB switch was created.
  4. Verify the Web switch was created.

 

Create Distributed Router


In this lesson a powershell script will create a distributed router via the NSX API.


 

Open the Create DLR Script

 

  1. Return to the API Module folder.
  2. Right click on the Create DLR.ps1 file.
  3. Click Edit with Notepad++.

 

 

Review the Script

 

  1. Review the required fields for a distributed router.
  2. Note the URI location.

 

 

Run the Create DLR.ps1 Script

 

  1. Right click on the Create DLR.ps1 file.
  2. Click Run with PowerShell.

Note: Script may take 1-3 minutes to complete.

Review the output.

Press any key to close the window.

 

 

Review the DLR in the vSphere Web Client

 

Return to the vSphere Web Client

  1. Click on the NSX Edges tab.
  2. Verify the Distributed-Router was created.

Note: Edge numbers may be different in your lab!

 

Configure DFW Connection Per Second Alarm Thresholding


In this lesson a powershell script will configure Distributed Firewall Connection Per Second Alarms.  This configuration is only available via the API.


 

Open the DFW CPS.ps1 Script

 

  1. Return to the API Module folder.
  2. Right click on the DFW CPS.ps1 file.
  3. Click Edit with Notepad++.

 

 

Review the Script

 

  1. Review the alarm thresholds.
  2. Note the URI.

 

 

Run the DFW CPS Script

 

  1. Right Click on the DFW CPS.ps1 file on the desktop.
  2. Click Run with PowerShell.

Review the output of the script.  The Distributed Firewall will now alarm when the connections per second goes above 10.

 

Module Clean Up


After the completion of this lab the API created objects must be removed.


 

Delete the Logical Switches

 

Be sure to only remove the Logical Switches that were created using the API.

Return to the vSphere Web Client:

  1. Navigate to the Logical Switches tab.
  2. Click on the App Logical Switch.
  3. Click Remove.
  4. Click Yes.

Repeat these steps for the DB Logical Switch and the Web Logical Switch.

 

 

Delete the Distributed Router

 

  1. Navigate to the NSX Edges tab.
  2. Click on the Distributed-Router.
  3. Click Delete.
  4. Click Yes.

 

Module 1 Conclusion


This module utilized the NSX API to configure multiple NSX objects.  The NSX API provides a powerful tool for configuration, troubleshooting, and monitoring.  


 

You've finished Module 1

Congratulations on completing Module 1.

For additional information on the NSX API visit the URL below and select the NSX API Guide:

The API Guide is also available on the Desktop of the Main Console.  For further exploration of the API the API Guide and the Postman Rest Client available on the desktop of the Main Console as well.  For further examples of configuration of components such as routing and firewalling the Fast-Forward.ps1 file on the desktop is used later in the lab to skip module 3.  

Proceed to any module below which or end the lab.

 Lab Captain:

 

 

How to End Lab

 

To end the lab click on the END button.  

 

Module 2 -Review Pre-Configured Multi-Site (30 minutes)

Module Guidance


This module will review the vSphere and NSX configuration.  This lab includes many configurations and Universal objects that are pre-requisites to a multi-site active/active configuration.

The configurations that will be reviewed include:


 

Pre-Configured Topology

 

The topology diagram above shows the pre-configured objects in this lab.

 

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 enviornments can also be configured in the same vSphere Web Client session.  


 

Select Hosts and Clusters

 

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

 

 

Verify Both vCenter Servers Are Available

 

Ensure that both vCenter servers are visible.

 

Review NSX Manager Configurations


This lesson will review the roles assigned to NSX Manager.  The NSX Manager registered in Region A will have the Primary role.  The NSX Manager registered in Region B 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

 

Click on the Installation tab.

 

 

Verify NSX Manager Roles

 

In this lab two NSX Managers have been configured.  One as Primary and one as Secondary.  Verify that both NSX Managers are assigned a role.

 

Review Universal Controller Cluster


This lesson will review the NSX Universal Controller Cluster.  The NSX Universal Controller Cluster manages logical networking across both vCenter Servers.  This enables the configuration of Universal Logical Switches, Universal Logical Routers, and Universal Distributed Firewall Rules.


 

Verify Controllers on Primary NSX Manager

 

Verify that controller-1, controller-2, and controller-3 are connected to the Primary NSX Manager.

 

 

Verify Controllers on Secondary NSX Manager

 

Scroll down to verify that the controller-1, controller-2, and controller-3 are connected to the Secondary NSX Manager.

 

Review Universal Logical Network Preparation


This lesson will review the pre-configured Logical Network Preparation.


 

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 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

 

Change to the Secondary NSX Manager by:

  1. Click on the NSX Manager drop down.
  2. Select the Secondary NSX Manager.

 

 

Review Universal Segment ID pool on the Secondary NSX Manager

 

The Secondary NSX Manager must also be configured with a Segment ID Pool.  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 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 Edit Clusters.

 

 

Review Clusters Connected to Universal Transport Zones

 

Transport Zones define what clusters can participate in a 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. Verify the cluster RegionB01-COMP01 is connected and in Normal status.
  2. Click Cancel.

Switch to the Primary NSX Manager and review the configuration of the Universal_TZ.  Verify clusters RegionA01-COMP01 and RegionA01-MGMT01 are connected and in Normal status.

 

Review Universal Logical Switches


This lesson will review the pre-configured Universal Logical Switches.


 

Verify 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:

  1. Select the Logical Switches tab.
  2. Select the Primary NSX Manager.
  3. Verify five Logical Switches are configured with a Universal Scope.

The Segment IDs of the Universal Logical Switches 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 available on the the Secondary NSX Manager and that their Segment IDs match the Primary NSX Manager:

  1. Select the Secondary NSX Manager.
  2. Verify the Universal Logical Switches match the configuration on the Primary NSX Manager.

The Names, Transport Zone, and Segment IDs are synchronized on all NSX Managers.

 

 

Create Universal Logical Switch

 

Universal Logical Switches are only configurable on the Primary NSX Manager.  Create a Universal Logical Switch on the Primary NSX Manager:

 

 

Verify Newly Created Universal Logical Switch

 

Verify the NSX_ULS Universal Logical Switch has been created, is in the Universal_TZ Transport Zone, and is configured with a Segment ID from the Universal Segment ID pool.  Switch to the Secondary NSX Manager and verify the Universal Logical Switch has been synchronized:

  1. Select the Primary NSX Manager.
  2. Verify the NSX_ULS.

 

 

Verify Newly Created Universal Logical Switch on Secondary NSX Manager

 

Verify the NSX_ULS Universal Logical Switch has been created, is in the Universal_TZ Transport Zone, and is configured with a Segment ID from the Universal Segment ID pool.  Switch to the Secondary NSX Manager and verify the Universal Logical Switch has been synchronized:

  1. Select the Secondary NSX Manager.
  2. Verify the NSX_ULS.

 

Review NSX Edge Configurations


In this lab NSX Edge devices (ESGs) 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 ESG has been pre-configured as a Universal Logical Distributed Router (ULDR).  This ULDR has been configured for ECMP and local egress.


 

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 ULDR for optimization between VMs.  This configuration requires dynamic routing between the physical network and the ESGs as well as between the ESGs and the ULDR.  The ULDR advertises the configured network to both ESGs.  The ESGs advertises the ULDR networks to both sites 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 ULDR 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.
  2. Ensure the Primary NSX Manager is selected.
  3. Double Click on the RegionA0_Perimeter_GW ESG.

 

 

Review Universal Logical Distributed Router Configuration

 

  1. Ensure the Primary NSX Manager is selected.
  2. Double Click on Universal_DLR_01.

 

Module 2 Conclusion


This module reviewed the preconfigured Universal objects.  These items were preconfigured to allow for focus on configuring Universal Routing constructs in Module 3.


 

You've finished Module 2

Congratulations on completing Module 2.

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

Proceed to any module below.

 Lab Captain:

 

 

How to End Lab

 

To end the lab click on the END button.  

 

Module 3 - Creation of Universal Constructs (30 minutes)

Module Guidance


This module will configure BGP on the Universal Logical Distributed Router (ULDR) and Universal Distributed Firewall rules.

The steps for this module include:


 

Pre-Configured Topology

 

The lab is pre-configured with the virtual network topology shown above.  The Perimeter Gateway VMs are already configured to exchange routing information with the vPod Router.

 

 

Final Configuration

 

At the end of this module BGP will be configured to exchange dynamic routing information between the Perimeter Gateways and the Universal Logical Distributed Router.  Egress optimization will be configured ensuring that traffic egressing the logical networking environment will utilize the Perimeter Gateway closest to the VM.  Universal Distributed Firewall rules will be configured to enable microsegmentation of the three tier application provided in the lab.

 

Enable BGP on Universal Logical Router RegionA0


This module will configure the Universal Logical Distributed Router for dynamic routing and Universal Distributed Firewall for micro-segmentation of a three tier application.


 

View the Locale ID for RegionA0

 

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

 

 

Configure the ULDR for Dynamic Routing

 

To configure the Universal_DLR:

  1. Navigate to the NSX Edges tab.
  2. Ensure the Primary NSX Manager is selected.
  3. Double Click on the Universal_DLR_01.

 

 

Configure the ULDR for BGP

 

BGP must be enabled and the RegionA0_Perimeter_GW must be added as a neighbor:

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

 

Enable BGP on Universal Logical Router RegionB0


This lesson will configure the Universal Logical Distributed Router in RegionB0.


 

View the Locale ID

 

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

 

 

Configure the ULDR for Dynamic Routing

 

To view the configuration of the RegionB0 ULDR:

  1. Navigate to the NSX Edges tab.
  2. Ensure the Seconday NSX Manager is selected.
  3. Double Click on the Universal_DLR_01.

 

 

Configure the ULDR for BGP

 

BGP must be enabled and the RegionB0_Perimeter_GW must be added as a neighbor:

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

 

Verify Connectivity Application Connectivity


This lesson will verify the three tier application is functional in RegionA0.


 

Open a New Tab

 

Click on the New Tab button.

 

 

Open Three Tier App

 

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

 

Open a command prompt on the Main Console.

 

Create Universal Distributed Firewall Rules


This lesson will create Universal Distributed Firewall Rules for the Hands On Labs Three Tier application.  Universal Distributed Firewall Rules must only contain IPs, IP Sets, MAC, or MAC Sets.


 

Navigate to the vSphere Web Client

 

Navigate to the vSphere Web Client tab

 

 

Navigate to the Networking & Security tab

 

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

 

 

Navigate to the Firewall Tab

 

Click on the Firewall tab.

 

 

Ensure the Primary NSX Manager is selected

 

In order to create Universal Firewall Rules the Primary NSX Manager must be selected.  All rules marked for Universal Synchronization will be distributed to the Secondary NSX Managers automatically.

 

 

Add a Section to the Firewall Ruleset

 

Click the Add Section Button.

 

 

Create Section

 

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

 

 

Add a Universal Rule

 

Click the Add Rule icon.

 

 

Configure a Universal Default Rule

 

In this step a universal default rule will be configured.  This rule will be changed to a default deny once all application rules have been defined.  

  1. Ensure the Three Tier App section is expanded.
  2. Click the Edit icon to name the rule.

 

 

Configure a Rule for Web Server Access

 

Click the Add Rule button.

 

 

Configure a Rule for Web to Application Server

 

In this step a rule that allows access to the application tier from the web tier on Tomcat will be configured:

  1. Ensure the Three Tier App section is expanded.
  2. Click the Add Rule icon.
  3. Click the Edit icon to name the rule.

 

 

Configure a Rule for Application to Database Server

 

In this step a rule that allows access to the database tier from the application tier on MySQL will be configured

  1. Ensure the Three Tier App section is expanded
  2. Click the Add Rule icon.
  3. Click the Edit icon to name the rule.

 

 

Configure Deny Rule

 

Click the Edit icon in the Action column.

 

 

Publish Changes

 

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

 

 

Verify Application Connectivity

 

Click on the New Tab button.

 

 

Ping Application Virtual Machines

 

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

 

Module 3 Conclusion


This module configured dynamic routing and local egress for the Universal Logical Distributed Router at two sites.  This configuration allows for Active/Active virtual datacenter configurations.


 

You've finished Module 3

Congratulations on completing Module 3.

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

Proceed to any module below

 Lab Captain:

 

 

How to End Lab

 

To end the lab click on the END button.  

 

Module 4 - Active / Active Multi-Site (15 Minutes)

Module Guidance


In this module you will vMotion an application stack to a secondary site.  

This Module Includes:

If you have not already completed Module 3 complete the steps below to configure the environment.  If you have already completed Module 3 skip to the next lesson:

Module 4 - Lesson 2 - Verify Local Egress


 

Lab Topology

 

In this module you will use the logical network topology shown above.  You will vMotion all the VMs associated with the three tier application to a secondary site.  You will verify local egress of traffic and application availability.

 

 

Minimize the vSphere Web Client

 

  1. Minimize the vSphere Web Client.

 

 

Run the Fast Forward Script

 

  1. Right Click on the Fast-Forward.ps1 file on the desktop.
  2. Select Run with PowerShell.

This script will configure the environment with the prerequisites of Module 4.  Allow the script to complete.  The window will close upon completion.

 

 

Return to the vSphere Web Client

 

 

  1. Select the vSphere Web Client window in Chrome.

 

Verify Local Egress


This lesson will verify that local egress is functioning


 

Login to the vPod Router

 

Launch Putty.

 

 

Open a Connection to the vPod Router

 

  1. Select the vPod Router BGP Saved Session.
  2. Click Open.

 

 

Log In

 

  1. Enter the password VMware1!

 

 

Verify Routing Table

 

Show the routing table.  Verify two active routes per VM network:

  1. Enter:
show ip bgp
  1. Verify routes.
  2. Once completed close the ssh session.

 

 

Switch to the vSphere Web Client and Select Hosts and Clusters

 

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

 

 

Verify the Location of the Application

 

Verify that the VMs web-01a.corp.local, app-01a.corp.local, and db-01a.corp.local are in the RegionA01 datacenter.

 

 

Navigate to the Networking & Security tab

 

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

 

 

Disable Universal Deny Rule

 

  1. Click on the Firewall tab.
  2. Ensure The Primary NSX Manager is selected.
  3. Ensure the Three Tier App section is expanded.
  4. Click on the Green Check Box to disable rule 4.
  5. Click on Publish Changes.

 

 

Wait for Firewall Rule Publishing to Succeed

 

Wait for the publish operation to succeed.

 

 

Log In to web-01a.corp.local

 

Launch Putty.

 

 

Open a Connection to web-01a.corp.local

 

  1. Select the web-01a.corp.local Saved Session.
  2. Press Open.

 

 

Tracepath to Verify Local Egress

 

  1. Tracepath to the vPod Router using the command:
tracepath 192.168.100.1 -m2 -n
  1. Note the egress through 192.168.5.1.  This is the interface of RegionA01-Perimeter_GW.

 

 

vMotion Web VM to RegionB0

 

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

 

 

Expand all collapsed Items

 

Expand all collapsed items by click on the caret symbo.l

 

 

vMotion Web VM

 

  1. Right click on web-01a.corp.local.
  2. Click Migrate.

 

 

Select Migration Type

 

  1. Select Change both computer resource and storage.
  2. Click Select compute resource first.
  3. Click Next.

 

 

Select a Compute Resource

 

  1. Select the RegionB01-COMP01 cluster.
  2. Click Next.

 

 

Select Storage

 

  1. Select RegionB01-ISCSI01-COMP01.
  2. Click Next.

 

 

Select Network

 

  1. Select the Web_Tier_ULS universalwire.
  2. Click Next.

You may need to scroll the network selection drop down to the right to view the names of the Universal Logical Switch.

 

 

Select vMotion Priority

 

Click Next.

 

 

Review Settings

 

Review the selections and click Finish.

 

 

Switch to the Tasks View

 

  1. Click the Home button.
  2. Select the Tasks tab.

 

 

Wait for vMotion to Complete

 

Wait for the vMotion tasks to complete.

 

 

Switch to the vSphere Web Client and Select Hosts and Clusters

 

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

 

 

Launch Web-01a Console

 

Launch Console connection to Web-01a

  1. Select web-01a.corp.local.
  2. Select the Summary tab.
  3. Select the screen area to lunch the console.

 

 

Tracepath to Verify New Egress

 

Use console to verify local egress:

  1. Login: root
  2. Password: VMware1!
traceroute 192.168.100.1 -n -m 2

Verify the egress through 192.168.5.9 This is the interface of RegionB01-Perimeter_GW.

 

Migrate Application Stack to Secondary Site


This lesson will migrate an application stack to a secondary site.


 

Application Topology Review

 

This diagram shows the locations of the virtual machines as well as the traffic flow.

 

 

Open a New Tab

 

Click on the New Tab button.

 

 

Open The Three Tier App

 

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.

 

 

vMotion Remaining Application VMs to RegionB0

 

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

 

 

Expand all collapsed Items

 

Expand all collapsed items by click on the caret symbol.

 

 

vMotion App VM

 

  1. Right click on app-01a.corp.local.
  2. Click Migrate.

 

 

Select Migration Type

 

  1. Select Change both compute resource and storage.
  2. Click Select compute resource first.
  3. Click Next.

 

 

Select a Compute Resource

 

  1. Select the RegionB01-COMP01 cluster.
  2. Click Next.

 

 

Select Storage

 

  1. Select RegionB01-ISCSI01-COMP01.
  2. Click Next.

 

 

Select Network

 

  1. Select the App_Tier_ULS universalwire.
  2. Click Next.

You may need to scroll the network selection drop down to the right to view the names of the Universal Logical Switch.

 

 

Select vMotion Priority

 

Click Next.

 

 

Review Settings

 

Review the selections and click Finish.

 

 

Migrate the Remaining Application VMs

 

Repeat the steps to migrate app-01a.corp.local for db-01a.corp.local.  Change the Network Selection to "vxw-dvs-118-universalwire-3-sid-10002-DB_Tier_ULS".

Once the DB VM has completed migration verify the Three Tier App web page loads.  The topology diagram shows the location of the VMs after migration.

 

Module 4 Conclusion


This module migrated an application stack from one site to another.  Local egress of traffic was verified to ensure an optimal outbound traffic pattern.  With this configuration an Active/Active datacenter configuration can be achieved.  This provides the ability to migrate machines as the need arises within an environment.


 

You've finished Module 4

Congratulations on completing Module 4.

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

Proceed to any module below

 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-01-NET

Version: 20170920-131310