Home > Blogs > OpenStack Blog for VMware


OpenStack Networking with VMware NSX, Part 3

Today’s blog post is the final entry in a series by Marcos Hernandez, one of the OpenStack specialists in VMware’s Networking & Security Business Unit (NSBU). Part 1 discussed the basics of the Neutron integration for VMware NSX. Part 2 discussed foundational integrations for L2 and L3 network services.

Security Groups

Neutron Security Groups have historically implemented either Linux IPTables or Open vSwitch stateless matches to filter traffic at the hypervisor level. Both approaches have presented challenges to operations teams there is serious work underway aimed at improving the experience (VMware is a contributor to these efforts).

When using NSX and vSphere, we deploy a stateful firewall on each and every ESXi host. That means that every hypervisor will protect the microcosm of virtual machines that it hosts, providing the notion of a distributed data plane. We call this a distributed firewall, or DFW. The NSX DFW runs in the kernel of ESXi and enables granular security controls at the VM vNIC level. When using Neutron Security Groups, the NSX DFW is configured, via the plugin integration. Neutron Security Groups are mapped to instances, meaning the NSX DFW will protect the VM unit.

07-fig-3-01

 

Running an actual firewall on each hypervisor within your OpenStack cloud has the following benefits:

The NSX firewall scales as your ESXi footprint grows. The mere act of increasing your compute capacity due to the organic growth of your business, automatically means you are also adding security and compliance to your virtual infrastructure.

It is important to note that Neutron Security Groups and NSX micro-segmentation can be used standalone, without adopting L2 overlays and L3 virtualization. While not as flexible as a full network virtualization implementation, the micro-segmentation use case is very popular with our customers and provides a great on ramp for customers to introduce OpenStack and NSX without disrupting whatever VLAN operational model may already be in place.

Load Balancing

As of the Kilo version of the NSX plugin, Neutron LBaaS v1.0 support was incorporated. The workflow includes the following capabilities:

  • Tenants are able to create application pools (initially empty).
  • Tenants add several members to the pool (instance IP address).
  • Tenants create one or several health monitors.
  • Tenants associate the health monitors with the pool.
  • The tenant finally creates a virtual IP (VIP) with the pool.
  • Supported protocols: TCP, HTTP and HTTPS.

08-fig-3-02

As with other network services in our implementation, we leverage the NSX Edge Services Gateway (ESG) as an inline load balancer as well as a Neutron router. The NSX load balancer is very feature-rich, and it is ready to support the Neutron LBaaS 2.0 API spec in a future version of the plugin.

Summary – Supported Topologies

The table below summarizes the topologies supported by the NSX-Neutron plugin:

Use Case Comments
VLAN-backed L2, no L3 services Micro-segmentation only No overlays. Security Groups leverage Distributed Firewall policies
VLAN-backed L2, L3 services, LBaaS optional Leverage VLANs for L2, NSX Edge for L3 No overlays. L3 provided by NSX Edge. No distributed routing support. Static routes only
L2/L3 overlays, no NAT, LBaaS optional Enterprise customers that don’t need overlapping IP addresses Can use distributed router and/or NSX Edge. No overlapping IPs allowed. Static routes only. Very efficient. Preferred enterprise model
L2/L3 overlay, NAT, LBaaS optional Enterprise customers that need overlapping IPs Can use distributed router and/or NSX Edge. Static routes only. Very efficient. Cloud provider/service provider preferred model

Conclusion – Why NSX-v with OpenStack Neutron?

The benefits of NSX align with the requirements of a robust OpenStack private cloud implementation, which are:

  • Agility – Networking at the speed of apps.
  • Mobility – Provision anywhere, move anywhere.
  • Security – Micro-segment, detect anywhere, detect early
  • Multi-tenancy – Share hardware across multiple tenants.
  • Simplified operations – Centrally manage, monitor everywhere.

By leveraging the NSX Neutron Plugin for vSphere developed by VMware, cloud administrators can introduce NSX into their OpenStack environment and offer their users and developers the open APIs they require, all without compromising uptime, stability and scalability.

This concludes the series discussing OpenStack Neutron integrations with VMware NSX. You can get some hands-on experience with VMware Integrated OpenStack with our revamped VMworld Hands-on Lab (HOL-1620) featuring VMware Integrated OpenStack and NSX Optimized for vSphere. You can also check out Part 1 and Part 2 of this blog series to read more about NSX integrations with OpenStack.

Marcos Hernandez is a Staff Systems Engineer in the Network and Security Business Unit (NSBU). He is responsible for supporting large Global Enterprise accounts and providing technical guidance around VMware’s suite of networking and cloud solutions, including NSX and OpenStack. Marcos has a background in datacenter networking design and expert knowledge in routing and switching technologies. Marcos holds the CCIE (#8283) and VCIX certifications, and he has a Masters Degree in Telecommunications from Universidad Politécnica de Madrid.

This entry was posted in Technical and tagged , , on by .
Trevor Roberts Jr.

About Trevor Roberts Jr.

Trevor Roberts, Jr. is the Senior Technical Marketing Manager for OpenStack at VMware and the lead author of the VMware Press title, “DevOps for VMware Administrators". He enjoys speaking to customers and partners about the benefits of using OpenStack with VMware technologies. In his spare time, Trevor shares his insights on data center technologies via the VMware Blogs and on Twitter (@VMTrooper). His contributions to the IT community have garnered recognition by his designation as a VMware vExpert, Cisco Data Center Champion, and EMC Elect.

Leave a Reply

Your email address will not be published. Required fields are marked *

*