Table of Contents Lab Overview - - VMware NSX Multi-Site and SRM in an Active- Standby Setup... 2 Lab Guidance... 3 Lab Introduction... 9 Module 1 - Review Pre-Configured Multi-Site NSX and Configure Site-Local Routing (45 Minutes)... 10 Module Guidance... 11 Topology Overview... 12 Review vcenter Configurations... 15 Review NSX Manager Configurations... 17 Review Universal Controller Cluster... 19 Review Universal Logical Network Preparation... 20 Review the Logical Switches in the Environment... 24 Review NSX Edge Configurations... 26 Configure BGP Filter on RegionB0_Perimeter_GW... 37 Enable BGP on Universal Logical Router RegionA0... 43 Enable BGP on Universal Logical Router RegionB0... 52 Verify Application Connectivity... 62 Create Universal Distributed Firewall Rules Leveraging Universal Security Tags... 65 Module 1 Conclusion... 119 Module 2 - Site Recovery Manager Configuration & Execution (45 Minutes)...120 Module Guidance... 121 Creation of SRM protection groups for Application... 125 Configure Network Mappings... 127 Configure Folder Mappings... 136 Configure Resource Mappings... 141 Configure Placeholder Datastore... 145 Create Replications... 149 Create Protection Group... 156 Create Recovery Plan... 162 Bring Down the Edge GW in RegionA0... 167 Deploy OneArm-LB in RegionB0... 170 Run the Recovery Plan to Failover the site... 172 Configure BGP Filter on RegionB0_Perimeter_GW... 179 Connect to 3-Tier App... 185 Module 2 Conclusion... 194 Page 1
Lab Overview - - VMware NSX Multi-Site and SRM in an Active- Standby Setup Page 2
Lab Guidance Note: It may take more than 90 minutes to complete this lab. You are not expected to finish all 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 leverage on Cross VC-NSX and failover a 3-tier application from Primary Site to Protected Site with minimal changes to the environment. Students will learn to resolve some of the difficult challenges faced by traditional disaster recovery solutions such as the need to change networks (IP addresses) and synchronization of security policies. Lab Module List: Module 1 - Review Pre-Configured Multi-Site NSX and Configure Site-Local Routing (45 minutes) (Advanced) In this module, students will review the two different logical topologies which describes the current state and state after the full failover of the application traffic. This module will walk the students through configuring site specific local routing in a multi-site environment, influence egress traffic utilizing Locale ID, influence ingress routing using route filters as well as configuring universal distributed firewall rules by using dynamic criteria and universal security tags. Module 2 - Site Recovery Manager Configuration & Execution (45 minutes) (Advanced) In this module students will configure SRM including protection groups, recovery and protection plans. Subsequently, students will learn full failover of the application. Lab Captains: Module 1 - TAY Wen Bin, Systems Engineer, Singapore Module 2 - TAY Wen Bin, Systems Engineer, Singapore 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: Page 3
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. Page 4
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. Page 5
Click once in active console window In this example, you will use the Online Keyboard to enter the "@" sign used in email addresses. The "@" sign is Shift-2 on US keyboard layouts. 1. Click once in the active console window. 2. Click on the Shift key. Click on the @ key 1. Click on the "@ key". Notice the @ sign entered in the active console window. Page 6
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. Look at the lower right portion of the screen Page 7
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. Page 8
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 with Cross-VC NSX. 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. Page 9
Module 1 - Review Pre- Configured Multi-Site NSX and Configure Site-Local Routing (45 Minutes) Page 10
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 Gateways 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 Gateways on both sites using BGP. Page 11
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). Page 12
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 of the following: RegionA0_TZ: this TZ has a local scope for vcenter A and is available on both clusters of Region A01. It is already pre-configured in the lab upon startup. Universal_TZ: this TZ has a universal scope and is available on both vcenters. It is already pre-configured in the lab upon startup. Pre-configured Logical Network Topology The above diagram shows the topology of this lab. There are five NSX Universal Logical Switches in this lab: Web_Tier_ULS, App_Tier_ULS, & DB_Tier_ULS, RegionA01_Transit, & RegionB01_Transit The 3-Tier application (Web, App and DB) is already configured. The One-Arm Load Balancer in RegionA0 is attached to Web_Tier_ULS and helps to load balance traffic between the two Web Servers. An identical One-Arm Load Balancer has also been configured RegionB0 but has not been deployed. The Logical Switches are attached to a Universal Distributed Logical Router (UDLR), which in turn is attached to an NSX Edge Services Gateway (ESG) in each region. BGP routing guarantees route exchange Page 13
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 ibgp between UDLR and ESGs on both the sites as well as BGP prefix list for filtering routes. Logical Topology after Full Application Failover The above diagram shows the topology of this lab after performing a full application failover. The north-south traffic, east-west traffic and One-Arm Load Balancer will exist only in the Recovery Site after a full application failover. Page 14
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 environments can also be configured in the the same vsphere Web Client session. Login to the vsphere Web Client Open Google Chrome web browser. Login to vsphere Web Client and verify that you can access both vcenter Servers. 1. Enter administrator@vsphere.local as user name 2. Enter VMware1! as password 3. Click Login Page 15
View Hosts and Clusters 1. Click Home icon 2. Click Hosts and Clusters Verify Both vcenter Servers Are Available Ensure that both vcenter Servers are visible Page 16
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 Home icon 2. Click on Networking & Security Page 17
Navigate to the Installation and Upgrade Tab 1. Click on Installation and Upgrade Verify NSX Manager Roles 1. Click on Management 2. Click on NSX Managers In this lab, two NSX Managers have been configured with Primary and Secondary roles. Verify that both NSX Managers are assigned a role. Page 18
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 and Secondary NSX Managers To reduce the amount of required resources for this lab, we only have one controller instead of three. In production environment, we should have three controllers for high availability. In addition, the one controller will appear twice as it is connected to both the primary and secondary NSX managers. Hence verify that Controller-01 appear twice in the NSX Controller Nodes section and are shown as "Connected". Page 19
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 Primary NSX Manager Note the different range used for Segment ID pool and Universal Segment ID pool. Page 20
Change to the Secondary NSX Manager To change the View to the Secondary NSX Manager: 1. Click on NSX Manager drop down 2. Select 192.168.210.42 Secondary Review Universal Segment ID pool on the Secondary NSX Manager Page 21
The Secondary NSX Manager must also be configured with a Segment ID Pool. The Segment ID pools configured on all NSX Managers must not be overlapping. The Universal Segment ID pool is synchronized from the Primary NSX Manager. Note the different range used for Segment ID pool and Universal Segment ID pool. In addition, verify the Segment ID pool on the Secondary NSX Manager does not overlap with the Segment ID pool on the Primary NSX Manager and that 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 Page 22
2. Select Universal_TZ 3. Click Connect Clusters icon 4. Verify the cluster RegionB01-COMP01 is connected and in Normal status 5. Click Cancel 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. Page 23
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 Logical Switches on the left navigator pane 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 Switch falls within the range of the Universal Segment ID pool. Page 24
Verify Universal Logical Switches on Secondary NSX Manager Universal Logical Switches including their Segment ID are synchronized across Primary and Secondary NSX Managers. 1. Select 192.168.210.42 (Role: Secondary) Verify the Universal Logical Switches match the configuration on the Primary NSX Manager. The Logical Switches, Transport Zone and Segment IDs are synchronized on all NSX Managers in this environment. Page 25
Review NSX Edge Configurations NSX Edges provide connectivity for north-south communication and east-west communication. There are two pre-configured NSX Edges for north-south communication. These perimeter gateways are configured with dynamic routing utilizing BGP. A third NSX Edge has been pre-configured as a Universal Distributed Logical Router (UDLR) providing east-west routing among the application logical switches and connectivity to Transit ULS in each site for north-south communication to the perimeter gateway. There are also identical NSX Edges that are implemented as One-Arm Load Balancers on RegionA0 and RegionB0. These One-Arm Load Balancers help to load balance traffic going to the Web Servers. Local Egress Traffic is routed via the ESG at the site which 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 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 UDLR for east-west optimization Page 26
Review Perimeter Gateway Configurations To view the configuration of the RegionA0_Perimeter_GW 1. Click NSX Edges 2. Select 192.168.110.42 (Role: Primary) 3. Double-click on the RegionA0_Perimeter_GW Review the Interface Configuration To view the interface configuration 1. Select Manage 2. Select Settings 3. Select Interfaces Page 27
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-MGMT. 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 Global Configuration 1. Select Routing 2. Select Global Configuration. Note that ECMP and BGP are enabled. Page 28
Review Routing BGP Configuration 1. Select BGP. Review the configured neighbors. The ESG has two neighbors - 192.168.100.1 (upstream router) and 192.168.5.3 (ULDR). Page 29
Navigate to Networking & Security 1. Click Home icon 2. Click Networking & Security Switch to the Secondary NSX Manager Note that this is an optional step and you may proceed to the next step if you are not interested to review RegionB0_Perimeter_GW on Secondary NSX Manager. Page 30
1. Click NSX Edges 2. Select 192.168.210.42 (Role: Secondary) Like RegionA0_Perimeter_GW on Primary NSX Manager, RegionB0_Perimeter_GW on Secondary NSX Manager is also pre-configured. If you wish to review RegionB0_Perimeter_GW, please perform the same steps earlier that were used to review RegionA0_Perimeter_GW. Once you have reviewed the RegionB0_Perimeter_GW, return to this NSX Edges section again and select the Primary NSX Manager. Review Universal Distributed Logical Router Configuration 1. Ensure 192.168.110.42 (Role: Primary) is selected 2. Double-click Universal_DLR_01 Page 31
Review UDLR General Configuration To review the UDLR settings, perform the following: 1. Click Manage 2. Click Settings 3. Click Configuration You may need to scroll down to see that Local Egress is enabled; this can only be enabled during creation of the ULDR. In addition, if you scroll down further, you will see that a logical router appliance has been deployed. Page 32
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 and the configuration of the UDLR is synchronized with the Secondary NSX Manager. Page 33
Navigate to Networking & Security 1. Click Home icon 2. Click Networking & Security Review the One-Arm Load Balancer Configuration 1. Click NSX Edges 2. Double-click RegionA0-OneArm-LB Page 34
Navigate to Load Balancer Section 1. Click Load Balancer 2. Click Pools Page 35
Check the Status of Pool 1. Click Show Pool Statistics 2. Click pool-1 Make sure the status of pool-1 and it's members is up. Page 36
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 Networking & Security 1. Click Home icon 2. Click Networking & Security Page 37
Access the RegionB0_Perimeter_GW 1. Click NSX Edges 2. Select 192.168.210.42 (Role: Secondary) 3. Double-click the RegionB0_Perimeter_GW Navigate to Routing Option 1. Click Manage 2. Click Routing Page 38
3. Click BGP 4. Select the neighbor 192.168.200.1 5. Click Pencil icon Add the BGP Filters for the neighbor 1. Click Green Plus icon Page 39
Create Deny Filters Create BGP Filters to deny 172.16.10.0/24, 172.16.20.0/24 and 172.16.30.0/24 1. Select Out for Direction 2. Select Deny for Action 3. Enter 172.16.10.0/24 for Network 4. Click OK Repeat steps 1-4 for 172.16.20.0/24 and 172.16.30.0/24 networks Create Permit Filter Page 40
Create BGP Filter to permit 192.168.200.0/24 1. Select Out for Direction 2. Select Permit for Action 3. Enter 192.168.200.0/24 for Network 4. Click OK Finish creating filters 1. Verify your filters match above 2. Click OK Page 41
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. Page 42
Enable BGP on Universal Logical Router RegionA0 You will now configure BGP on the Universal Logical Distributed Router. Navigate to Networking & Security 1. Click Home icon 2. Click Networking & Security Page 43
Navigate to the UDLR 1. Click NSX Edges 2. Click NSX Manager drop down list 3. Select 192.168.110.42 (Role: Primary) 4. Double-click Universal_DLR_01 Navigate to Global Configuration 1. Click Manage 2. Click Routing Page 44
3. Click Global Configuration 4. Click Edit 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. Select RegionA0_Uplink as the Router ID 2. Click OK Publish Changes 1. Click Publish Changes Page 45
Configure the ULDR for BGP 1. Click BGP 2. 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 Enable BGP 2. Enter 65001 as the Local AS 3. Click OK Page 46
Add a Neighbor Add the RegionA0_Perimeter_GW as a Neighbor: 1. In the Neighbor 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 6. Click OK Explanation: IP Address - the IP address of the internal interface of RegionA0_Perimeter_GW Forwarding Address - the IP address of the Universal_DLR RegionA0 uplink interface Protocol Address - an unused IP address in the same network as the forwarding address Page 47
Forwarding Address is used as the data plane while the Protocol Address is used in the control plane 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 Page 48
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. Click Green Plus 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 Page 49
In this section we configured ibgp between UDLR in RegionA0 to Edge GW in RegionA0 Access Putty 1. Click Putty 2. Scroll down and double-click nsxmgr-01a.corp.local 3. Click Load 4. Click Open Page 50
Verify BGP Neighbor 1. Login as admin with password VMware1! 2. Enter show edge all 3. Enter show edge edge-c07dc04e-fc43-48d0-90cb-81fcf5498e70 ip bgp neighbor If you want to copy and paste the command for step 3, it is below: show edge edge-c07dc04e-fc43-48d0-90cb-81fcf5498e70 ip bgp neighbor Note the highlighted Edge ID. Make sure the BGP State is "Established, up". Page 51
Enable BGP on Universal Logical Router RegionB0 Navigate to Networking & Security 1. Click Home icon 2. Click Networking & Security Configure the UDLR for Dynamic Routing Page 52
To view the configuration of the RegionB0 UDLR 1. Navigate to the NSX Edges 2. Click on NSX Manager drop down list 3. Select 192.168.210.42 (Role: Secondary) 4. Double-click Universal_DLR_01 Edit Routing Global Configuration 1. Click Manage 2. Click Routing 3. Click Global Configuration 4. Click Edit Page 53
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. Under the Dynamic Routing Section, perform the following: 1. Select RegionB0_Uplink as the Router ID 2. Click OK Publish Changes 1. Click Publish Changes Page 54
Configure the ULDR for BGP BGP must be enabled and the RegionB0_Perimeter_GW must be added as a neighbor 1. Click BGP 2. 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, or ULDR 1. Check Enable BGP 2. Enter 65011 as the Local AS 3. Click OK Page 55
Add a Neighbor Add the RegionA0_Perimeter_GW as a Neighbor. 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 neighbor. The forwarding address is used as the data plane while the protocol address is used in the control plane. 1. Click Green Plus icon 2. In the IP Address field, enter 192.168.5.9 3. In the Forwarding Address field, enter 192.168.5.10 4. In the Protocol Address field, enter 192.168.5.11 5. In the Remote AS field, enter 65011 Page 56
Leave the other fields at their default values 6. 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. Click Route Redistribution 2. Click Edit Page 57
Enable Route Redistribution for BGP 1. Uncheck redistribution for OSPF 2. Check to 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 Page 58
1. Click Green Plus icon 2. Select BGP as the Learner Protocol 3. Select Connected 4. Click OK Publish Changes 1. Click Publish Changes You have now successfully configured ibgp peering of UDLR in RegionB0 to Edge GW in RegionB0 Access Putty Page 59
1. Click Putty 2. Scroll down and double-click nsxmgr-01b.corp.local 3. Click Load 4. Click Open Verify BGP Neighbor 1. Login as admin with password VMware1! 2. Enter show edge all 3. Enter show edge edge-c07dc04e-fc43-48d0-90cb-81fcf5498e70 ip bgp neighbor If you want to copy and paste the command for step 3, it is below: show edge edge-c07dc04e-fc43-48d0-90cb-81fcf5498e70 ip bgp neighbor Page 60
Note the highlighted Edge ID. Make sure the BGP State is "Established, up". Page 61
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 EXISTING TAB Open Three Tier App 1. Click webapp.corp.local Page 62
Verify Three Tier App Verify the Web Application is loaded and data is retrieved. Ping Application Virtual Machines Open a command prompt on the Main Console Page 63
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 Page 64
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 Navigate to vsphere Web Client 1. Click vsphere Web Client tab Page 65
Navigate to the Networking & Security tab Navigate to the Networking & Security Section 1. Click Home icon 2. Click Networking & Security Page 66
Change the Unique Selection Criteria for NSX Manager Page 67
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. From NSX 6.3.x onwards, you are allowed to configure a Unique ID Selection Criteria on the primary NSX Manager for the identifications of VMs when attaching to universal security tags: VM instance UUID, VM BIOS UUID, VM name, or a combination of these options. Page 68
1. Click Installation and Upgrade 2. Click Actions 3. Select Primary NSX Manager 4. Click Unique ID Selection Criteria Select the Unique ID Selection Criteria 1. Check Use Virtual Machine Instance UUID 2. Click SAVE Page 69
Navigate to NSX Managers 1. Click Groups and Tags 2. Select 192.168.110.42 Primary 3. Click Security Tags 4. Click +ADD Create Universal Security Tags 1. Enter ST-WEB as the Name Page 70
2. Enable Universal Synchronization 3. Click ADD Repeat step 1 to 3 to create the following security tags: ST-APP, ST-DB and ST-3-Tier Page 71
Verify the creation on Primary and Secondary NSX managers Page 72
Page 73
Select 192.168.210.42 Secondary and scroll down to ensure the Security Tags are synchronized from the Primary NSX manager Page 74
Add Security Tags to the VMs Page 75
Page 76
1. Select 192.168.110.42 Primary 2. Select ST-WEB tag 3. Click ASSIGN VM 4. Select web-01a.corp.local and web-02a.corp.local 5. Click right-arrow button 6. Click OK Repeat step 1 to 5 to assign security tags for app and db VMs. Assign ST-APP to app-01a.corp.local and ST-DB to db-01a.corp.local. Page 77
Assign Security Tag ST-3-Tier to all the VMs Page 78
Page 79
1. Select ST-3-Tier 2. Click ASSIGN VM 3. Select on app-01a.corp.local, db-01a.corp.local, web-01a.corp.local and web-02a.corp.local 4. Click OK Create Universal Security Groups for Application Tiers 1. Click Security Groups 2. Click +ADD Page 80
Create New Universal Security Group and include Security Tag 1. Enter SG-WEB as the Name 2. Enable Universal Synchronization 3. Enable Active Standby Deployments 4. Click Select Objects to Include 5. Select Security Tag 6. Select ST-WEB Page 81
7. Click FINISH Repeat step 1 to 7 for creating security groups SG-APP and SG-DB. Use the security 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. Enter SG-3-Tier as the Name Page 82
2. Enable Universal Synchronization 3. Enable Active Standby Deployments 4. Click Select Objects to Include 5. Select Security Tag 6. Select ST-3-Tier 7. Click FINISH Page 83
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 Synchronization Service will push the Security Groups to the Secondary NSX manager. It Page 84
is important to validate that the synchronization is taking place across both NSX Managers. Select 192.168.210.42 Secondary and ensure the Security Groups are synchronized from the Primary NSX manager Navigate to the Firewall Tab Navigate to the Firewall section 1. Click Firewall 2. Ensure that 192.168.110.42 Primary is selected 3. Click Triple Dots 4. Click Add Section Above Page 85
Create Section 1. Enter Three Tier App as Section Name 2. Enable Universal Synchronization 3. Click ADD Page 86
Add a Universal Rule In the newly created Section, add a place holder for a universal rule 1. Click Triple Dots 2. Click Add Rule Page 87
Name the Rule 1. Enter Inbound Web Server into the text box Configure Destination 1. Leave the Source as Any (default setting) - We do not wish to filter for a particular source 2. Click Destination text box Page 88
3. Click Pencil icon Source is set to Any as we do not wish to filter for a particular source. Destination is modified to allow specific IP addresses. Configure Destination Security Group 1. Select Security Group 2. Select SG-WEB 3. Click SAVE Page 89
Configure Services for the rule 1. Verify Destination is configured according to previous step 2. Click Service text box 3. Click Pencil icon Define Services for the Rule Page 90
1. Select Services 2. Search https 3. Scroll down to find HTTPS 4. Select HTTPS 5. Click SAVE Apply the Rule to SG-WEB 1. Verify Service is configured according to previous step 2. Click Applied To text box 3. Click Pencil icon Page 91
Apply the Rule to SG-3-Tier 1. Select Security Group 2. Select SG-3-Tier 3. Click SAVE Page 92
Configure a Rule for Web to Application Server under previous rule 1. Click Triple Dots 2. Click Add Rule Below Page 93
Name the Rule 1. Enter Web to App in the text box Page 94
Configure the Source for the rule 1. Click Source text box 2. Click Pencil icon Page 95
Select SG-WEB as source 1. Select Security Group 2. Select SG-WEB 3. Click SAVE Page 96
Configure Destination Security Group 1. Verify Source is configured according to previous step 2. Click Destination text box 3. Click Pencil icon Page 97
Define the Destination as the App Tier Security Group 1. Select Security Group 2. Select SG-APP 3. Click SAVE Page 98
Configure Services for the Rule 1. Verify Destination is configured according to previous step 2. Click Service text box 3. Click Pencil icon Define Services for the Rule 1. Select Services 2. Enter tomcat as the keyword 3. Check Tomcat service Page 99
4. Click right arrow 5. Click SAVE Apply the Rule to SG-APP 1. Verify Service is configured according to previous step 2. Click Applied To text box 3. Click Pencil icon Page 100
Apply the Rule to SG-3-Tier 1. Select Security Group 2. Select SG-3-Tier 3. Click SAVE Page 101
Configure a Rule for Application to Database Server 1. Click Triple Dots 2. Click Add Rule Below Page 102
Name the Rule 1. Enter App to DB in the text box Page 103
Configure the Source 1. Click Source text box 2. Click Pencil icon Page 104
Select security group SG-APP created previously 1. Select Security Group 2. Select SG-APP 3. Click SAVE Page 105
Configure Destination 1. Verify Source is configured according to previous step 2. Click Destination text box 3. Click Pencil icon Page 106
Select Security Groups 1. Select Security Group 2. Select SG-DB 3. Click SAVE Page 107
Configure Service 1. Verify Destination is configured according to previous step 2. Click Service text box 3. Click Pencil icon Select HTTP Page 108
1. Select Services 2. Search http 3. Scroll down to find HTTP 4. Select HTTP 5. Click SAVE Apply the Rule to SG-3-Tier 1. Select Security Group 2. Select SG-3-Tier 3. Click SAVE Page 109
Configure Default Rule to reject every other traffic 1. Click Triple Dots 2. Click Add Rule Below Page 110
Name the Rule 1. Enter Block any to 3-Tier App in the text box Page 111
Change the destination of the Rule to SG-3-Tier 1. Select Security Group 2. Select SG-3-Tier 3. Click SAVE Page 112
Apply the Rule to SG-3-Tier 1. Select Security Group 2. Select SG-3-Tier 3. Click SAVE Edit the Action 1. Select Reject as the Action 2. Click Publish Page 113
Verify your rules are configured as above. Verify Creation on Secondary NSX Manager 1. Select 192.168.210.42 Secondary 2. Verify that all rules appear in the Secondary NSX Manager Verify Application Connectivity 1. Click New Tab 2. Click webapp.corp.local Page 114
Verify Three Tier App Verify the Web Application is loaded and data is retrieved. Ping Application Virtual Machines To verify the default deny rule open a command prompt on the Main Console Page 115
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 have 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. Page 116
Navigate to the Networking & Security tab Navigate to the Networking & Security Section 1. Click Home icon 2. Click Networking & Security Page 117
Disable the 3-Tier-App Block Rule 1. Click Firewall 2. Expand Three Tier App Rules 3. Disable Rule 4. Click PUBLISH We will need to disable the default 3-Tier Block Rule in order for us to use Traceroute in the Next Module; we will be tracing the path from Main Console to Web Server VM. Page 118
Module 1 Conclusion This module walked you through the various pre-configured components of NSX in a multi-site configuration. You have also learned how to configure Locale ID, dynamic routing on UDLR, Universal Distributed Firewall rules and route filtering to favor one site over the other. 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. For additional information on NSX Universal configurations and cross vc scenarios, visit the URL below and select the Cross-vCenter Installation Guide: Go to https://communities.vmware.com/docs/doc-32552 Lab Captain: Module 1 - TAY Wen Bin, Systems Engineer, Singapore Module 2 - TAY Wen Bin, Systems Engineer, Singapore How to End Lab To end the lab click on the END button. Page 119
Module 2 - Site Recovery Manager Configuration & Execution (45 Minutes) Page 120
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 IN THE NEXT PAGE. If you have already completed Module 1, then you can skip the next step and proceed to "Creating SRM Protection Groups for Application". Page 121
Running the SRM FastForward Script Page 122
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 3. Click 'Open" if a security warning pops up The script will perform the following configuration within the NSX environment: 1. Configure BGP Filters on RegionB0_Perimeter_GW 2. Configure Routing for Primary Universal Distributed Logical Router 3. Configure Routing for Secondary Universal Distributed Logical Router 4. Configure Unique Selection Criteria 5. Create Universal Security Tags 6. Create Universal Security Groups 7. Attach Universal Security Tags to VMs 8. Create Universal Distributed Firewall Rules Page 123
Script Execution Once the script has completed all the steps, press Enter to continue and the window will close by itself. This script will configure the lab and allow you to proceed to the next step. After this step, go back to the desktop and continue with the lab. Page 124
Creation of SRM protection groups for Application 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 environments can also be configured in the the same vsphere Web Client session. Login to the vsphere Web Client Open Google Chrome web browser. Login to vsphere Web Client and verify that you can access both vcenter Servers. 1. Enter administrator@vsphere.local as user name 2. Enter VMware1! as password 3. Click Login Page 125
Verify Both vcenter Servers Are Available Ensure that both vcenter Servers are visible 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. Click Site Recovery Page 126
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. Open Site Recovery 1. Click OPEN Site Recovery for 'vcsa-01a.corp.local' View Details of Site Recovery 1. Click VIEW DETAILS of 'vcsa-01a.corp.local <-> vcsa-01b.corp.local' Page 127
Navigate to Site A Network Mappings In this section of the lab, we will be mapping the networks on the protected site to networks on the recovery site. 1. Click Network Mappings 2. Click +NEW Page 128
Manual Mappings 1. Click Prepare Mappings Manually 2. Click Next Page 129
Expand Sites 1. Expand vcsa-01a.corp.local, RegionA01, RegionA01-vDS-COMP 2. Expand vcsa-01b.corp.local, RegionB01, RegionB01-vDS-COMP Page 130
Create Mappings Pay special attention to the following steps: The names of VXLAN port groups are too long, so we will use the Unique ID of the VXLAN Segments to identify the following logical switches: Web_Tier_ULS is universal wire ID 3 App_Tier_ULS is universal wire ID 4 DB_Tier_ULS is universal wire ID 5 We will perform the steps for universal wire ID 3 (Web_Tier-ULS) first. Do not click NEXT until you have perform the same steps for universal wire ID 4 (App_Tier_ULS) and universal wire ID 5 (DB_Tier_ULS): 1. Select universal wire ID 3 on Site A 2. Select universal wire ID 3 on Site B 3. Click Add Mappings Repeat step 1-3 for universal wire ID 4 (App_Tier_ULS) and universal wire ID 5 (DB_Tier_ULS). Page 131
Verify Mappings and Proceed 1. Verify that all the mappings to the Tiers are correct 2. Click NEXT Page 132
Reverse Mappings Reverse mappings will map the networks on the recovery site to networks on the protected site. In a failback scenario, we can quickly re-protect the VMs in the recovery site with the protected site by configuring reverse mappings. However, we will not be performing failback scenario in this lab, so we will not configure reserve mappings. 1. Click NEXT Page 133
Test Networks 1. Click NEXT Page 134
Ready to Complete 1. Click FINISH Page 135
Configure Folder Mappings You will now configure folder mappings for the SRM configuration. New Folder Mapping In this section of the lab, we are mapping the datacenters or virtual machine folders on the protected site to datacenters or virtual machine folders on the recovery site. 1. Click Folder Mappings 2. Click +NEW Page 136
Create Folder Mapping 1. Select Prepare mappings manually 2. Click NEXT Page 137
Prepare Mappings 1. Select RegionA01 2. Select RegionB01 3. Click ADD MAPPINGS 4. Click NEXT Page 138
Reverse Mapping Reverse mappings will map the datacenters or virtual machine folders on the recovery site to datacenters or virtual machine folders on the protected site. In a failback scenario, we can quickly re-protect the VMs in the recovery site with the protected site by configuring reverse mappings. However, we will not be performing failback scenario in this lab, so we will not configure reserve mappings. 1. Click NEXT Page 139
Finish Folder Mapping 1. Click FINISH Page 140
Configure Resource Mappings In this section, you will create resource mapping for the SRM configuration. Create new Resource map In this section of the lab, we are mapping the resource pools, standalone hosts, vapps, or clusters on the protected site to resource pools, standalone hosts, vapps, or clusters on the recovery site. You can map any type of resource on one site to any type of resource on the other site 1. Click Resource Mappings 2. Select +NEW Page 141
Prepare Mapping 1. Expand RegionA01 2. Expand RegionB01 3. Select RegionA01-COMP01 4. Select RegionB01-COMP01 5. Click ADD MAPPINGS 6. Click NEXT Page 142
Reverse Mapping Reverse mappings will map the resource pools, standalone hosts, vapps, or clusters on the recovery site to resource pools, standalone hosts, vapps, or clusters on the protected site. You can map any type of resource on one site to any type of resource on the other site In a failback scenario, we can quickly re-protect the VMs in the recovery site with the protected site by configuring reverse mappings. However, we will not be performing failback scenario in this lab, so we will not configure reserve mappings. 1. Click NEXT Page 143
Finish Resource Mappings 1. Click FINISH Page 144
Configure Placeholder Datastore You will now add the datastore configuration for the SRM configuration. Configure Placeholder Datastore If you use array-based protection groups or vsphere Replication protection groups, you must specify a placeholder datastore on the recovery site for Site Recovery Manager to use to store placeholder virtual machines. In this lab, we are using vsphere Replication protection group. 1. Click Placeholder Datastores 2. Click +NEW Page 145
Select the Datastore 1. Select RegionA01-ISCSI01-COMP01 2. Click ADD Page 146
Create Placeholder Store on RegionB01 1. Select vcsa-01b.corp.local 2. Click +NEW Page 147
Select Placeholder Datastore 1. Select RegionB01-ISCSI01-COMP01 2. Click ADD Page 148
Create Replications You will now create replications. Navigate to Replications 1. Click Replications 2. Click +NEW Page 149
Configure Replication 1. Select app-01a.corp.local 2. Select db-01a.corp.local 3. Select web-01a.corp.local 4. Select web-02a.corp.local 5. Click NEXT We will now create the replications for 4 VMs. Page 150
Target Site 1. Click NEXT Page 151
Target Datastore 1. Select RegionB01-ISCSI01-COMP01 2. Click NEXT Page 152
Replication Settings For the Recovery Point Objective (RPO) setting, you may adjust the sliding scale between 5 minutes and 24 hours. However, we will use the RPO setting as default. 1. Click NEXT Page 153
Protection Group 1. Select Do not add to protection group now 2. Click NEXT Page 154
Ready to Complete 1. Click FINISH Page 155
Create Protection Group You must now create the base protection group of the 3-Tier Application for the 4 VMs. Protection Groups You create protection groups to enable Site Recovery Manager to protect virtual machines. You can organize protection groups in folders. The Protection Groups tab displays the names of the protection groups, but does not display in which folder they are placed. If you have two protection groups with the same name in different folders, it might be difficult to tell them apart. Consequently, ensure that protection group names are unique across all folders. In environments in which not all users have view privileges for Page 156
all folders, to be sure of the uniqueness of protection group names, do not place protection groups in folders. 1. Select Protection Groups 2. Click +NEW Create New Protection for 3-Tier App 1. Enter 3-Tier-App as Name 2. Select vcsa-01a.corp.local -> vcsa-01b.corp.local 3. Click NEXT Page 157
Protection Group Type 1. Select Individual VMs (vsphere Replication) 2. Click NEXT Page 158
Virtual Machines 1. Select all VMs (app-01a.corp.local, db-01a.corp.local, web-01a.corp.local and web02a.corp.local) 2. Click NEXT Note that some of the VMs may show "Sync" instead of "OK" as the status. It is alright to proceed to the next step even if the VMs show "Sync" status. Page 159
Recovery Plan 1. Select Do not add to recovery plan now 2. Click NEXT We will not add this protection group to any recovery plan as we have not created any recovery plan. We will create the recovery plan and add the protection group in the next section. Page 160
Ready to Complete 1. Click FINISH When you create protection groups, wait to ensure that the operations finish as expected. Make sure that Site Recovery Manager creates the protection group and that the protection of the virtual machines in the group is successful Page 161
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 Recovery Plans A recovery plan is like an automated run book. It controls every step of the recovery process, including the order in which Site Recovery Manager powers on and powers off virtual machines, the network addresses that recovered virtual machines use, and so on. Recovery plans are flexible and customizable. 1. Click Recovery Plans 2. Click +NEW Page 162
Name the Recovery Plan 1. Enter 3-Tier-App as Name 2. Select vcsa-01a.corp.local -> vcsa-01b.corp.local 3. Click NEXT Page 163
Select the Protection Group A recovery plan includes one or more protection groups. You can include a protection group in more than one recovery plan. For example, you can create one recovery plan to handle a planned migration of services from the protected site to the recovery site for the whole organization, and another set of plans per individual departments. In this example, having these different recovery plans referencing one protection group allows you to decide how to perform recovery. You can run only one recovery plan at a time to recover a particular protection group. If you test or run a recovery plan with a replication group that is shared in other recovery plans, the other recovery plans change the state of the protection group to Protection Group In Use and you cannot run them. 1. Select Protection groups for individual VMs or datastore groups 2. Select 3-Tier-App 3. Click NEXT Page 164
Test Networks 1. Click NEXT Page 165
Finish Creating the Recovery Plan 1. Click FINISH Page 166
Bring Down the Edge GW in RegionA0 In this section, you will shut down the RegionA0_Perimeter_GW to simulate a failure. In a real time environment, organizations can have multiple component failures. 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 the possible failures within an environment. The white paper is available at the URL below: https://communities.vmware.com/docs/doc-31692 Navigate to vsphere Web Client 1. Click vsphere Web Client tab (we are switching back to the previous tab) Page 167
Navigate to Hosts and Clusters 1. Click Home icon 2. Click Hosts and Clusters Page 168
Shut Down the Edge GW 1. Expand vcsa-01a.corp.local 2. Expand RegionA01 3. Expand RegionA01-MGMT01 4. Click RegionA0_Perimeter_GW-0 5. Click Actions dropdown list 6. Click Power 7. Click Shut Down Guest OS 8. Click Yes to Confirm Guest Shut Down for 'RegionA0_Perimeter_GW-0' Page 169
Deploy OneArm-LB in RegionB0 In this section, we need to deploy the RegionB0-OneArm-LB to load balance the traffic for web-01a.corp.local and web-02a.corp.local. To save time, the RegionB0-OneArm-LB has already been pre-created in this lab. Hence we just need to deploy the RegionB0-OneArm-LB. Navigate to Networking & Security 1. Click Home icon 2. Click Networking & Security Page 170
Deploy One Arm LB on RegionB01 1. Click NSX Edges 2. Select 192.168.210.42 (Role: Secondary) 3. Right-click RegionB0-OneArm-LB 4. Click Deploy 5. Click Yes to deploy the selected edge (RegionB0-OneArm-LB). Note that if you do not see any NSX Managers, it means that you have login to vsphere Web client with the wrong username. Please login with administrator@vsphere.local as username and VMware1! as password to view the NSX Edges in vsphere Web Client. Page 171
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 RegionB 1. Click New Tab 2. Click RegionB on the bookmarks toolbar 3. Click RegionB vcenter Note: Login to RegionB vcenter might take 2-3 minutes. Wait for the login to complete. This is a lab POD specific behavior and will not be present in real world vcenter. Page 172
Navigate to Site Recovery 1. Go Home icon 2. Click Site Recovery Open Site Recovery 1. Click OPEN Site Recovery on 'vcsa-01b.corp.local' Page 173
View Details of Site Recovery 1. Click VIEW DETAILS of 'vcsa-01b.corp.local <-> vcsa-01a.corp.local' Select 3-Tier-App 1. Click Recovery Plans 2. Select the radio button next to 3-Tier-App 3. Click RUN Page 174
Confirm Recovery Options 1. Check "I understand that this process will permanently alter the virtual machines and infrastructure..." 2. Click Disaster Recovery 3. Click NEXT Page 175
Execute the Plan 1. Click FINISH Page 176
Monitor Recovery Steps 1. Click 3-Tier-App 2. Click Recovery Steps Monitor the progress of the recovery plan. This could take 3-5 minutes to complete. Page 177
Recovery Complete 1. Click Summary When the recovery is completed, it will be reflected under Plan Status. Navigate to vsphere Web Client 1. Click vsphere Web Client tab for 'vcsa-01a.corp.local' Page 178
Configure BGP Filter on RegionB0_Perimeter_GW We will need to configure the BGP Filters to permit routes from 172.16.10.0/24 (Web), 172.16.20.0/24 (App), and 172.16.30.0/24 (DB). Navigate to Networking & Security 1. Click Home icon 2. Click Networking & Security Page 179
Navigate to RegionB0 Perimeter GW 1. Click NSX Edges 2. Select 192.168.210.42 (Role: Secondary) 3. Double-click RegionB0_Perimeter_GW Navigate to BGP Routing Page 180
1. Click Manage 2. Click Routing 3. Click BGP 4. Select 192.168.200.1 (you may have to scroll down to see the neighbors) 5. Click Pencil icon If you do not see 192.168.200.1 as the neighbor, return to the previous step and make sure to select Secondary NSX Manager. If you have selected Secondary NSX Manager, you should see 192.168.200.1 as the neighbor. Page 181
Edit BGP Filters Page 182
1. Select 172.16.10.0/24 2. Click Pencil icon 3. Select Permit 4. Click OK Repeat Step 1-4 for 172.16.20.0/24 and 172.16.30.0/24. Verify BGP Filters 1. Verify BGP Filters are configured correctly 2. Click OK Page 183
Publish Changes 1. Click Publish Changes Open the Command Prompt 1. Click Command Prompt on the taskbar Run Traceroute from Main Console 1. Enter tracert 172.16.10.11 Traceroute shows that the path to the Web VM is via the Perimeter GW and UDLR that are residing on recovery site (RegionB0). Page 184
Connect to 3-Tier App Let's check the connectivity to the application after the full failover Open a New Tab 1. Click New Tab Access the Application 1. Click webapp.corp.local Page 185
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. Click Command Prompt icon Page 186
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 Page 187
Navigate to Hosts and Clusters 1. Click Home icon 2. Click Hosts and Clusters Page 188
Navigate to Hosts and Clusters Notice Web, App and DB virtual machines are residing in RegionB01 which is the recovery site. The application is accessible after the complete failover to RegionB01; no IP addresses of the VMs or firewall rules were changed. Page 189
Navigate to Networking and Security 1. Click Home icon 2. Click Networking and Security Page 190
Verify the VMs are automatically part of SG-WEB Security Group on Secondary Site 1. Click Firewall 2. Select 192.168.210.42 Secondary 3. Expand Three Tier App firewall section 4. Click SG-WEB under Source Column Page 191
Verify web-01a,corp.local and web02a.corp.local are part of the Security Group Navigate to Hosts and Clusters 1. Click Home icon 2. Click Hosts and Clusters Page 192
Verify Security Tags 1. Select web-01a.corp.local Verify the Security Tags appear on web-01a.corp.local. The Security Tags are synchronized automatically from Primary NSX manager to Secondary NSX manager. Page 193