Not all virtual networks are going to be connected to the physical world in the same way; some VXLAN logical switches may need to be directly layer 2 adjacent to an existing VLAN backed network, or need to reach a gateway or service interface that resides on a physically defined VLAN. These are some reasons VLAN to VXLAN bridge(s) may need to be implemented within VMware NSX. This is most common in the case of a migration effort to, or if a layer 2 domain containing workloads attached to both VXLAN and VLAN backed networks required.
The VMware NSX Distributed Firewall is unique in the market for its ability to operate at the vNIC level, in kernel in the hypervisor – giving you control you’ve never had before.
Why virtualized environments will ultimately incorporate network virtualization; why networking and security go hand in hand; and how organizations can get started TODAY on the journey with security components.
Our team has been working on building solutions for NSX with Business Critical Applications around Zero trust security, application mobility, operational efficiency, increased security and more .
In a previous post I published a demo about database cloning and enforcing dynamic security policies using NSX:
Demo – Dynamically Enforcing Security on a Hot Cloned SQL Server with VMware NSX
In this blog post we are showcasing the ability to stretch an Oracle RAC solution in an Extended Oracle RAC deployment between multi-datacenter and using VMware NSX for L2 Adjacency.
With Extended Oracle RAC , both Storage and Network virtualization needs to be deployed to provided high availability, workload Mobility, workload balancing and effective Site Maintenance between sites.
NSX supports multi-datacenter deployments to allow L2 adjacency in software, to put it in simple words stretching the network to allow VM too utilize the same subnets in multiple sites.
The really cool thing here is that this is 100% implemented in software and can be easily augmented and replicated to your needs. You can even choose multiple implementation paths and configurations and apply all of them at the same time with minimal dependency to the physical infrastructure and it configuration. After all, this is virtual!
Multi-datacenter NSX can be implemented in multiple ways for different use cases:
- For Disaster Recovery – where we deploy NSX to support a failover scenario where one site is mainly active for a workload and in case of site failure we flip a switch to support the networking from the secondary site.
- For Disaster Avoidance and Workload Mobility – Where we move the networking of VMs to a secondary site on demand
In both cases a workload and its networking is either communicating from one site’s physical infrastructure or the other and when active from one site (the primary) it will traverse from that site’s physical infrastructure to the secondary site if needed.
You can see in the diagram below that Site A is the primary and therefore Site B utilizes Site A’s physical routers for ingress and egress communication.
In case of a failure or a migration Site B’s infrastructure becomes active for ingress and egress:
The solution we created for Oracle RAC is different, and that is based on Oracle RAC’s unique requirements. You can see in the demo here
Oracle RAC, requires active networking from each respective site. It requires all nodes to have IPs on the same segment and if the nodes are placed in multiple sites , we then need to setup a solution to allow the same segment in both datacenters.
Since all Oracle RAC nodes are serving the applications and users in read/write for scalability purposes, performance needs to be interchangeable between them, the requirement is that each site will be active on its own infrastructure,
In the diagram below taken from the demo video, you can see the two sites and that each RAC node has “Optimized ingress” and “Locale egress” networking configuration in the respective site’s physical infrastructure and no site is considered “Primary”.
The way this was achieved in this implementation of the solution is by utilizing /32 static routes for site B’s Oracel RAC node that are injected on site B’s edge devices and than advertised to the uplink router using OSPF
One of the interesting challenges with this implementation was regarding the Oracle RAC SCAN IP’s. SCAN (Single Client Access Name) IP’s are IP’s assigned to ann Oracle RAC implementation which is used for client side load balancing between the cluster instances..
SCAN IP’s can comprise of a max of 3 IP’s configured in the DNS and they can come up on any node in the cluster in each one of the sites randomly.
To solve that problem , we created vRO workflows that can detect a VM coming up on site B and going down and run a workflow that can either add or remove a /32 static route from that sites edge device to support the movement of Vms or in our case the SCAN IPs.
Disclaimer, this solution can and will be improved from a scalability perspective, in particular automating route injection, from a performance and availability it is production ready.
Also, Route injection is not the only way to go about this, one can solve the challenge of moving IPs through other means or even from the presentation layer.
The demo explains step by step how this was implemented from an NSX perspective, here is the full link to the demo:
This is a demo of a solution we created for Oracle RAC stretched across sites and using VMware NSX to stretch the L2 network.
Blog post aboput the demo here: http://blogs.vmware.com/apps/2016/09/…
Helped in building this demo and solution:
Sudhir Balasubramanian – Oracle Master
Agustin Malanco – NSX expert
Christophe Decanini – Automation guru
This demo was also featured in Sudhir and my session at VMworld 2016 here: VIRT7575 – Architecting NSX with Business Critical Applications for Security, Automation and Business Continuity
Worked with me in creating this solution :
Sudhir Balasubramanian – Oracle
Agustin Malanco – NSX
Christpohe Decanini – Automation
As always any comments or questions are welcome.
This is the fifth and last video of a series of 5 demos that show how the NSX Security Model works through several use cases. Don’t just believe what you see, try it yourself for free with VMware Hands-On-Labs (see below):
This is the fourth of a series of 5 demos that show how the NSX Security Model works through several use cases. Don’t just believe what you see, try it yourself for free with VMware Hands-On-Labs (see below):
The VMware Validated Design for SDDC is a blueprint for the private cloud that results in an SDDC that is consistent, thoroughly documented, extensively tested from end-to-end, and continuously validated to incorporate new releases of software components. VMware NSX reproduces the complete set of Layer 2 through 7 networking services in software. This includes: switching, routing, access control, firewalling and load balancing. In this video, we will demonstrate the configuration of VMware NSX for use in this design. This demo focuses primarily on the configuration in management stack. Learn more about VMware Validated Designs at www.vmware.com/go/vvd or follow updates on Twitter @VMwareSDDC
In this second of a three-part video series, VMware’s general manager and executive vice president for the networking and security business unit, Rajiv Ramaswami, discusses VMwareⓇ NSX™ customer adoptions and how NSX can help businesses build out their clouds. View the first video on NSX use cases here.
Global enterprises are adopting VMware NSX at an impressive rate. In the past quarter alone, VMware added more than 200 new customers. Essential to this momentum is the growing realization that NSX provides a key foundation for businesses looking to extend their operations to the cloud. “One of the largest banks in the world is using NSX to build out very large private clouds, and they’re with us on a journey to extend NSX into the public cloud,” says Rajiv Ramaswami, VMware’s general manager and executive vice president for networking and security.
Customers Paving the Way With NSX
Companies of every size and every vertical are committing to making NSX a foundational part of their IT futures. Examples of the sheer range of NSX customers include Armor, Fulton County School District, Heartland Payment Systems, IBM Global Technology Services, Novamedia, SugarCreek, and the University of New Mexico.
Ramaswami highlights a media company that came to VMware for help with building out its private cloud, consolidating a number of recent acquisitions and bringing them in-house. Ramaswami notes that this VMware customer, like many, uses NSX not just for security, but also for automation and disaster recovery. This is the trifecta of key use cases Ramaswami recently explained.
Making the Journey Together
Helping customers realize these kinds of notable IT achievements with NSX is only the beginning. With NSX, customers are realizing how much more they can accomplish across their businesses and the broader communities they serve.
Watch the video to learn more from Rajiv Ramaswami about how customers are using NSX.
VMware’s GM and EVP Rajiv Ramaswami explains how VMware NSX is becoming critical to multi-cloud strategies. Enterprises of all sizes are achieving success by leveraging NSX to build out their cloud deployments. With NSX, customers are realizing how much more they can accomplish across their businesses and the broader communities they serve.
Across industries, the race is on to digital transformation. It’s all about business innovation and redefinition. The transformations are huge: Tesla isn’t just a car manufacturer; it’s a software business that makes cars. CITI is a software business that makes loans. GE is a software business that makes industrial equipment.
Register for this VMworld 2016 session to learn about the future of VMware NSX.
Like most of the customers we talk with, your business is also going through a transformation. Lots of change. Lots of disruption. Lots of innovation. More apps, representing more services and new business models. More lines of business empowered to make decisions about the IT they’ll use to take their innovations to market. And there’s no doubt that a huge enabler of all of this has been the cloud.
Consider what some of the leading industry pundits are predicting:
- By 2019, the majority of virtual machines (VMs) will be delivered by IaaS providers.
- By 2019, more than 30% of the 100 largest vendors’ new software investments will have shifted from cloud-first to cloud-only.
- By 2020, a corporate “no-cloud” policy will be as rare as a “no-internet” policy is today
- By 2020, 50% of applications running in public cloud environments will be considered mission-critical by the organizations using them (Gartner)
Through all of this, networking is undergoing fundamental change. It’s evolving to support both traditional and 3rd Platform architectures. It’s expanding and becoming more agile and flexible to support tomorrow’s application infrastructures spanning different hypervisors and containers, and living partly on-premises and partly across multiple public clouds.
At the heart of all of this change is VMware NSX. When you consider that just three years ago, VMware NSX did not even exist as a product, it is amazing to see the sheer number of production customers across every market segment and every region across the world.
At VMworld 2016, in Session NET9989-S, join VMware Chief Technology Strategy Officer Guido Appenzeller for a preview into what lies ahead for VMware NSX and network virtualization.
Created by Humair Ahmed on Jul 22, 2016 1:36 PM. Last modified by Humair Ahmed on Jul 25, 2016 2:19 PM.
This design guide is in initial draft status and feedback is welcome for next updated version release.
Please send feedback to email@example.com.
The goal of this design guide is to outline several NSX solutions available for multi-site data center connectivity before digging deeper into the details of the Cross-VC NSX multi-site solution. Learn how Cross-VC NSX enables logical networking and security across multiple vCenter domains/sites and how it provides enhanced solutions for specific use cases. No longer is logical networking and security constrained to a single vCenter domain. Cross-VC NSX use cases, architecture, functionality, deployment models, design, and failure/recovery scenarios are discussed in detail.
This document is targeted toward virtualization and network architects interested in deploying VMware® NSX Network virtualization solution in a vSphere environment.
The design guide addresses the following topics:
- Why Multi-site?
- Traditional Multi-site Challenges
- Why VMware NSX for Multi-site Data Center Solutions
- NSX Multi-site Solution
- Use Cases
- Architecture and Functionality
- Deployment Models
- Design Guidance
- Failure/Recovery scenarios
Cross VC NSX Overview
VMware NSX provides network virtualization technology that decouples the networking services from the underlying physical infrastructure. By replicating traditional networking hardware constructs and moving the network intelligence to software, logical networks can be created efficiently over any basic IP network transport. The software based approach to networking provides the same benefits to the network as server virtualization provided for compute.
Pre-NSX 6.2, although NSX provides the flexibility, agility, efficiency and other benefits of network virtualization, the logical networking and security was constrained to the boundaries of one vCenter domain.
Although it was possible to use NSX with one vCenter domain and stretch logical networking security across sites, the benefits of network virtualization with NSX was still limited to one vCenter domain. Figure 17 below shows multiple vCenter domains which happen to also be at different sites all requiring separate NSX controllers and having isolated logical networking and security.
Thanks to all the contributors and reviewers of this document.
This will also soon be posted on our NSX Technical Resources website (link below):
Feedback and Comments to the Authors and the NSX Solution Team are highly appreciated.
– The VMware NSX Solution Team
Download Multi-site Options and Cross-VC NSX Design Guide.pdf (15.5 MB).