Red Hat OpenStack Platform 13, based on the upstream Queens release, is now Generally Available. Of course this version brings in many improvements and enhancements across the stack, but in this blog post I’m going to focus on the five biggest and most exciting networking features found this latest release.
Continue reading “Red Hat OpenStack Platform 13: five things you need to know about networking”
OpenDaylight is an open source project under the Linux Foundation with the goal of furthering the adoption and innovation of software-defined networking (SDN) through the creation of a common industry supported platform. Red Hat is a Platinum Founding member of OpenDaylight and part of the community alongside a list of participants that covers the gamut from individual contributors to large network companies, making it a powerful and innovative engine that can cover many use-cases.
Continue reading “SDN with Red Hat OpenStack Platform: OpenDaylight Integration”
With software-defined networking (SDN) and network functions virtualization (NFV) gaining traction, more cloud service providers are looking for open solutions, based on standardized hardware platforms and open source software. In particular, communication service providers (CSPs) are undergoing a major shift from specialized hardware-based network elements to a software based provisioning paradigm where virtualized network functions (VNFs) are deployed in private or hybrid clouds of network operators. Increasingly, OpenStack is seen as the virtual infrastructure platform of choice for NFV, with many of the world’s largest communications companies implementing solutions with OpenStack today.
Continue reading “Boosting the NFV datapath with RHEL OpenStack Platform”
Network troubleshooting can be hard. Network troubleshooting in a complex distributed system like OpenStack can be even harder. With a typical Neutron deployment using the Open vSwitch (OVS) plug-in, one can expect rich networking configurations on the Red Hat Enterprise Linux OpenStack Platform nodes, the Compute and Controller nodes in particular.
While the network implementation details are well hidden from the end customer (who interfaces with the Neutron API or the Horizon Dashboard), the actual backend implementation involves the creation of various Linux devices, bridges, tunnel interfaces, and network namespaces. This is where the “magic” happens, and how OpenStack tenants can create and consume network resources such as networks, IP subnets and virtual routers, and get proper communication for their applications.
Continue reading “Troubleshooting Networking with RHEL OpenStack Platform: meet ‘plotnetcfg’”
The next OpenStack Summit is just around the corner, October 27-30, in Tokyo, Japan, and we would like your help shaping the agenda. The OpenStack Foundation manages voting by allowing its members to choose the topics and presentations they would like to see.
Virtual networking and software-defined networking (SDN) has become an increasingly exciting topic in recent years, and a great focus for us at Red Hat. It also lays the foundation for network functions virtualization (NFV) and the recent innovation in the telecommunication service providers space.
Here you can find networking and NFV related session proposals from Red Hat and our partners. To vote, click on the session title below and you will be directed to the voting page. If you are a member of the OpenStack Foundation, just login. If you are not, you are welcome to join now – it is simple and free.
Please make sure to vote before the deadline on Thursday, July 30 2015, at 11:59pm PDT.
OpenStack Kilo, the 11th release of the open source project, was officially released in April, and now is a good time to review some of the changes we saw in the OpenStack Networking (Neutron) community during this cycle, as well as some of the key new networking features introduced in the project.
Scaling the Neutron development community
The Kilo cycle brings two major efforts which are meant to better expand and scale the Neutron development community: core plugin decomposition and advanced services split. These changes should not directly impact OpenStack users but are expected to reduce code footprint, improve feature velocity, and ultimately bring faster innovation speed. Let’s take a look at each individually:
Neutron core plugin decomposition
Neutron, by design, has a pluggable architecture which offers a custom backend implementation of the Networking API. The plugin is a core piece of the deployment and acts as the “glue” between the logical API and the actual implementation. As the project evolves, more and more plugins were introduced, coming from open-source projects and communities (such as Open vSwitch and OpenDaylight), as well as from various vendors in the networking industry (like Cisco, Nuage, Midokura and others). At the beginning of the Kilo cycle, Neutron had dozens of plugins and drivers span from core plugins, ML2 mechanism drivers, L3 service plugins, and L4-L7 service plugins for FWaaS, LBaaS and VPNaaS – the majority of those included directly within the Neutron project repository. The amount of code required to review across those drivers and plugins was growing to the point where it was no longer scaling. The expectation that core Neutron reviewers review code which they had no knowledge of, or could not test due to lack of proper hardware or software setup, was not realistic. This also caused some frustration among the vendors themselves, who sometimes failed to get their plugin code merged on time.
Continue reading “What’s Coming in OpenStack Networking for the Kilo Release”
Red Hat Enterprise Linux OpenStack Platform 6: SR-IOV Networking – Part I: Understanding the Basics
Red Hat Enterprise Linux OpenStack Platform 6 introduces support for single root I/O virtualization (SR-IOV) networking. This is done through a new SR-IOV mechanism driver for the OpenStack Networking (Neutron) Modular Layer 2 (ML2) plugin, as well as necessary enhancements for PCI support in the Compute service (Nova).
In this blog post I would like to provide an overview of SR-IOV, and highlight why SR-IOV networking is an important addition to RHEL OpenStack Platform 6. We will also follow up with a second blog post going into the configuration details, describing the current implementation, and discussing some of the current known limitations and expected enhancements going forward.
Continue reading “Red Hat Enterprise Linux OpenStack Platform 6: SR-IOV Networking – Part I: Understanding the Basics”
This post is the collective work of all the Red Hat Enterprise Linux OpenStack Platform Product Managers who attended the summit.
The 11th Openstack design summit that took place last week for the first time in Europe, brought about 6000 participants of the OpenStack community to Paris to kick off the design for the “Kilo” release.
If 2014 was the year of the “Superuser”, then clearly the year 2015 seems to be about the “Year of the Enterprise“. The big question is: are we ready for enterprise mass adoption?
More than year ago, at the Openstack Havana design summit, it was clear that although interest in deploying OpenStack was growing, most enterprises were still holding back, mainly due to the lack of maturity of the project. This OpenStack summit, the new cool kid in the Open Cloud infrastructure playground is finally starting to show real maturity signs.
An important indicator for this is the increased number of deployments. The Kilo summit showcased about 16 different large organizations using production workloads on OpenStack, including companies such as BBVA Bank, SAP SE (formerly SAP AG) & BMW.
Continue reading “OpenStack 2015 – The Year of the Enterprise?”
Neutron, historically known as Quantum, is the OpenStack project focused on delivering networking as a service. As the Juno development cycle ramps up, now is a good time to review some of the key changes we saw in Neutron during this exciting cycle and have a look at what is coming up in the next upstream major release which is set to debut in October.
Neutron or Nova Network?
The original OpenStack Compute network implementation, also known as Nova Network, assumed a basic model of performing all isolation through Linux VLANs and iptables. These are typically sufficient for small and simple networks, but larger customers are likely to have more sophisticated network requirements. Neutron introduces the concept of a plug-in, which is a back-end implementation of the OpenStack Networking API. A plug-in can use a variety of technologies to implement the logical API requests and offer a rich set of network topologies, including network overlays with protocols like GRE or VXLAN, and network services such as load balancing, virtual private networks or firewalls that plug into OpenStack tenant networks. Neutron also enables third parties to write plug-ins that introduce advanced network capabilities, such as the ability to leverage capabilities from the physical data center network fabric, or use software-defined networking (SDN) approaches with protocols like OpenFlow. One of the main Juno efforts is a plan to enable easier Nova Network to Neutron migration for users that would like to upgrade their networking model for the OpenStack cloud.
Performance Enhancements and Stability
The OpenStack Networking community is actively working on several enhancements to make Neutron a more stable and mature codebase. Among the different enhancements, recent changes to the security-group implementation should result in significant improvement and better scalability of this popular feature. To recall, security groups allows administrators and tenants the ability to specify the type of traffic and direction (ingress/egress) that is allowed to pass through a Neutron port, effectively creating an instance-level firewall filter. You can read this great post by Miguel Angel Ajo, a Red Hat employee who led this effort in the Neutron community, to learn more about the changes.
In addition, there are continuous efforts to improve the upstream testing framework, and to create a better separation between unit tests and functional tests, as well as better testing strategy and coverage for API changes.
Continue reading “What’s Coming in OpenStack Networking for Juno Release”
Today’s datacenter networks contain more devices than ever before; servers, switches, routers, storage systems, dedicated network equipment and security appliances – many of which are further divided into virtual machines and virtual networks. Traditional network management techniques generally fall short of providing a truly scalable, automated approach to managing these next-generation networks. Users expect more control and flexibility with quicker provisioning and monitoring.
OpenStack Networking (Neutron) is a pluggable, scalable and API-driven system for managing networks and IP addresses. Like other aspects of the cloud operating system, it can be used by administrators and users to increase the value of existing datacenter infrastructure. Neutron prevents the network from being the bottleneck or limiting factor in a cloud deployment and gives users real self service over their network configurations.
Starting in the Folsom release, OpenStack Networking, then called Quantum, became a core and supported part of the OpenStack platform, and is considered to be one of the most exicting projects – with great innovation around network virtualization and software-defined networking (SDN). The general availability of Icehouse, the ninth release of OpenStack, is just around the corner, so I would like to highlight some of the key features and enhancements made by the contributors in the community to Neutron.