NSX can be used with a Disaster Recovery (DR) orchestration tool such as VMware’s Site Recovery Manager (SRM) for an Enhanced Disaster Recovery solution that solves many of the problems related to traditional Disaster Recovery solutions. Checkout this whitepaper on recovering NSX backed data centers with SRM.
This document is targeted and written for virtualization architects and administrators with experience in designing, deploying and troubleshooting technologies such as VMware vSphere, SRM, and NSX along with standard storage technologies.
The white paper addresses the following topics:
■ Challenges with existing DR Solutions
■ Migration/Disaster Recovery Scenarios
■ Solution Requirements and Details
■ Design Considerations
■ Recovering NSX Components
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. SRM recovers replicated Virtual Machines in a Secondary DataCenter and can perform network mapping (and re-mapping) between the Primary and Secondary locations so that Virtual Machines that are recovered can be reconnected to a L2 Network. These networks can be a VLAN backed Distributed Virtual Port Group (dvPG) or a NSX Logical Switch.
NSX and network virtualization enhances the Disaster Recovery (DR) solution by not only preserving L2 but also 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).
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 document will explain the process of recovering workloads running at Protected and Recovery sites backed by NSX virtual networks.
NSX supports seamless spanning of network and security policies across multiple sites through the use of the Cross-VC NSX feature introduced in NSX 6.2. The DR solution described in this solution brief is based on this Cross-VC NSX feature; however, a DR solution can also be built without leveraging Cross-VCNSX using an external replication/synchronization mechanism (such as vRO) to recreate Logical Networks and Security between NSX instances across the two sites.
Cross vCenter NSX greatly simplifies the process. Deployment consists of Universal Logical Switches, Universal Distributed Logical Router, and Universal Distributed Firewall. These universal objects facilitate the creation of a single unified logical network (L2, L3, DFW) across the protected and recovery site; 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.
Thanks to all the contributors and reviewers of this document.
Feedback and Comments to the Authors and the NSX Solution Team are highly appreciated.
Download out the ful Disaster Recovery with NSX and SRM Guide
VMware NSX is a software defined solution that brings the power of virtualization to network and security.
There are many great papers about NSX in general: for example here & here and many others, the purpose of this demo is not to dive into everything that NSX does, Instead I have focused on one capability in particular and that is the intelligent grouping of NSX Service Composer with the Distributed Firewall (DFW) and how to utilize it to make life easier for SQL DBAs and security admins, its doesn’t have to be only SQL Server, it can be any other database or application for that matter but for this demo I am focusing on SQL Server.
First, a bit of background: The NSX Service Composer allows us to create groups called “Security groups”. These Security groups can have a dynamic membership criteria that can be based on multiple factors: It can be part of the computer name of a VM, its guest OS name, the VM name, AD membership or a tag (tags are especially cool as they can be set automatically by 3rd party tools like antivirus and IPSs, but that is for a different demo)
These Security groups are than placed inside the Distributed Firewall (DFW) rules which allows us to manage thousands of entities with just a few rules and without the need to add these entities to the Security Group manually.
In the demo I have created an environment that is set with 0 trust policy, that means that everything is secured and every packet between the VMs is inspected, the inspection is done on the VMs vNIC level in an east-west micro segmentation way. That means that if a certain traffic is not defined in the DFW it is not allowed to go through.
This is something that wasn’t really possible to do before NSX!
Our production app database is an SQL database and in the demo the DBA wants to hot-clone it aside for testing purposes, but obviously the cloned SQL Server needs to have some network traffic allowed to pass to it, yet it needs to be secured from everything else.
Instead of having the traditional testing FW zone with its own physical servers, I created the rules that apply to a test DBs in the DFW, created a dynamic membership Security Group, and nested that group in the rules. Now, any database server that I will clone which corresponds to the criteria will be automatically placed in the rules. What’s really nice about this is that no traffic is going northbound to the perimeter FW because the packet inspection is done on the vNIC of the VMs (and only relevant rules to it are set on it) , no additional calls to security admins to configure the FW are needed after the first configuration has been made. This is a huge time saver , much more efficient in terms of resources (physical servers are now shared between zones) and a much more secure environment than having only a perimeter FW.
As usual any comment or feedback is welcome
VMworld 2014 MGT1969 vCloud Automation Center and NSX Integration Technical Deep Dive.
NOTE: This video is roughly 60 minutes in length so it would be worth blocking out some time to watch it!
1st in our 5 part series on VMware NSX with Horizon
Watch Rory Clements from VMware’s End-User Computing team step through a quick demo of network micro-segmentation using VMware NSX™ and Horizon® 6.
This video is the ninth in a new series of free Webinars that we are releasing in which our Technical Support staff members present on various topics across a wide range of VMware’s product portfolio.
The title for this presentation is “Introduction to VMware NSX” and it provides an overview of what NSX is and how it relates to the SDDC or Software Defined Datacenter.
To see the details of upcoming webinars in this series, see the Support Insider Blog post at http://blogs.vmware.com/kb/2015/02/ne…
NOTE: This video is roughly 37 minutes in length so it would be worth blocking out some time to watch it!
The Nexus 1000V can be installed in 7 minutes./
Tech Data hosted a live stream event with special guests from VMware for a training and demo on NSX.
NOTE: This video is roughly 18 minutes in length so it would be worth blocking out some time to watch it!
Raj is back to tell the team all about one of VMware NSX’s top security benefit, micro segmentation!
This session will focus on introducing NSX. It will detail the product and its components, the key use cases, partner integrations and pricing and packaging.
NOTE: This video is roughly 50 minutes in length so it would be worth blocking out some time to watch it!