Integrating Red Hat Virtualization and Red Hat OpenStack Platform with Neutron Networking

As applications are designed, redesigned, or even simply thought about at a high level, we frequently think about technical barriers along side business needs. Business needs may dictate that a new architecture move forward, but technical limitations can sometimes counter how far forward - unless there is something to bridge the gap. The new Neutron network integration between Red Hat Virtualization (RHV) and Red Hat OpenStack Platform (RHOSP) provides such a bridge for business and technical solutions.

Primary Use Cases

While there are numerous things that the aforementioned integration enables, I’d like to highlight three use cases:

1. The ability to support applications that require both scale up and scale out technologies simultaneously for different segments of the application.
2. The ability to support software defined networking (SDN) in virtualization along with overlay, encapsulation, and security groups.
3. The ability the manage the network topology from a single management platform for both the virtualization environment and the OpenStack environment.

The first use case is arguably the most powerful. For example, a new e-commerce application design calls for the front end, middleware, and business intelligence to all have the ability to scale out and then back in on demand based on sales. This is clearly a workload suited for RHOSP. But because of service level agreements around performance, backups, and the stateful nature of the workload, the back end database needs to continue to reside in traditional virtualization. The database workload is better suited for RHV.

However, the front end and the back end still need to talk to each other in order for the application to work. Up until now, there were two primary options:

• Choose one platform or the other (traditional virtualization or OpenStack) and potentially have one portion of the architecture be sub-optimal.
• Create a potentially complicated network that bridges the two environments - knowing that this option will be difficult to troubleshoot, maintain, and likely negates the benefits of OpenStack's SDN capabilities or ignores them altogether.

Neutron integration allows architects to avoid these options (by bridging the gap) and allows administrators to quickly configure the integration.

Now, with Neutron integration, the application scenario takes on a more progressive tone. The front end, middleware, and business intelligence can exist in OpenStack. They can scale out as necessary and networks can be defined on demand. The back end data persistence can continue to thrive in traditional virtualization. Backup schedules, storage integration, and scale up performance don’t need to compromise from a design or architecture standpoint.

This is the first point: that Red Hat Virtualization and Red Hat OpenStack Platform, Mode 1 and Mode 2 (if you will), can be deployed in such a manner that applications can be designed to utilize them simultaneously using the Neutron integration.

The second use case is still powerful. Perhaps workloads on traditional virtualization in the target data center are well on their way to being streamlined from a deployment and provisioning standpoint. RHV Templates, snapshots, and other tools have sped up delivery time. However, because of the overall pace of work and general workload in the data center, new network creation (physical) and switch configuration for things like VLANs (etc.) takes time; again, the overall provisioning and deployment process is still not optimal.

However, if RHOSP is also deployed in the data center and we're utilizing Neutron integration - this means that even if applications are not deployed across both platforms - the SDN capabilities can be shared. As the Neutron integration is configured, SDN’s can be created on demand versus waiting on physical networks or for the manual editing of physical switch configurations.

In other words, in addition to the SDN's that are deployed in RHOSP for its own workloads, SDNs can be created just for the RHV environment. The benefits of VXLAN, Open vSwitch, and SDN are then afforded to RHV as an option over traditional VLANs and Linux bridges.

The final point is that, regardless of the use case, the SDN’s can be managed from a single OpenStack interface (web-based or programmatic). Whether applications are to be deployed across both RHOSP and RHV or deployed separately, network management can be simplified by standardizing on Neutron and taking advantage of Neutron integration. This also streamlines operations as it means there aren’t separate network management tools for different environments.

High Level View of Deployment Operations

From a deployment and operations standpoint, Neutron integration is easy to configure and it is fully supported by Red Hat. From a security standpoint, the networks are “read only”, meaning that the RHV environment can only access, not change the Neutron networks. Nothing has changed the IPtables or SELinux configuration on the RHV side to open up any security holes. Likewise, nothing has been changed on the OpenStack side to change how things are accessed.

The actual steps to take advantage of the integration between RHV 4 and RHOSP 8 are straightforward. The steps are as follows:

1. Install the OpenStack Neutron packages on the RHV hypervisor hosts
2. Configure hosts (hypervisor nodes) - a very quick text edit
3. Define OpenStack Neutron as an “External Network Provider” in RHV Manager
4. Create one or more hosts in RHV that utilize the Neutron integration
5. Import one or more networks from RHOSP into RHV
6. Create one or more virtual machines that use the Neutron network(s)

The entire setup process takes less than 10 minutes for a virtualization administrator to put together.

Additional Information

For more information on Red Hat Virtualization:

https://www.redhat.com/en/technologies/virtualization

For more information on Red Hat OpenStack Platform:

https://www.redhat.com/en/technologies/linux-platforms/openstack-platform

Many thanks to Tony James for his assistance in putting this article together.

Comments and questions are always welcome.

Hope this helps,

Captain KVM