In today's data centers, networks are composed of more devices than ever before. Servers, switches, routers, storage systems, and security appliances now exist as virtual machines and virtual network appliances. These devices place a large strain on traditional network management systems, as they are unable to provide a scalable, automated approach to managing next-generation networks. Users now expect more control and flexibility of the infrastructure with quicker provisioning, all of which OpenStack promises to deliver.
This chapter will introduce many features that OpenStack Networking provides as well as various network architectures supported by OpenStack.
OpenStack Networking is a pluggable, scalable, and API-driven system to manage networks and IP addresses in an OpenStack-based cloud. Like other core OpenStack components, OpenStack Networking can be used by administrators and users to increase the value and maximize the utilization of existing data center resources.
Neutron, the code name of OpenStack Networking, is a standalone service that can be installed independently of other OpenStack services such as Nova (compute service), Glance (image service), Keystone (identity service), Cinder (block storage), and Horizon (dashboard). OpenStack Networking services can be split among multiple hosts to provide resiliency and redundancy, or they can be configured to operate on a single node.
OpenStack Networking exposes an application programmable interface, or API, to users and passes requests to the configured network plugins for additional processing. Users are able to define network connectivity in the cloud, and cloud operators are allowed to leverage different networking technologies to enhance and power the cloud.
Like many other OpenStack services, Neutron requires access to a database for persistent storage of the network configuration.
OpenStack Networking includes many technologies one would find in a data center, including switching, routing, load balancing, firewalling, and virtual private networks. These features can be configured to leverage open source or commercial software, and provide a cloud operator with all the tools necessary to build a functional and self-contained cloud. OpenStack Networking also provides a framework for third-party vendors to build on and enhance the capabilities of the cloud.
A virtual switch is defined as a software application that connects virtual machines to virtual networks at layer 2, or the data-link layer, of the OSI model. Neutron supports multiple virtual switching platforms, including Linux bridges provided by the bridge kernel module and Open vSwitch. Open vSwitch, also known as OVS, is an open source virtual switch that supports standard management interfaces and protocols, including NetFlow, SPAN, RSPAN, LACP, and 802.1q VLAN tagging. However, many of these features are not exposed to the user through the OpenStack API. In addition to VLAN tagging, users can build overlay networks in software using L2-in-L3 tunneling protocols, such as GRE or VXLAN. Open vSwitch can be used to facilitate communication between instances and devices outside the control of OpenStack, which include hardware switches, network firewalls, storage devices, dedicated servers, and more. Additional information on the use of Linux bridges and Open vSwitch as switching platforms for OpenStack can be found in Chapter 4, Building a Virtual Switching Infrastructure.
OpenStack Networking provides routing and NAT capabilities through the use of IP forwarding, iptables, and network namespaces. Inside a network namespace, we can find sockets, bound ports, and interfaces that were created in the namespace. Each network namespace has its own routing table, interfaces, and iptables processes that provide filtering and network address translation. By leveraging network namespaces to separate networks, there is no concern of overlapping subnets between networks created by tenants. Configuring a router within Neutron enables instances to interact and communicate with outside networks or other networks in the cloud. Router namespaces are also leveraged by the advanced networking services Firewall as a Service and Virtual Private Network as a Service, which will be discussed later in this book. More information on routing within OpenStack can be found in Chapter 7, Creating Standalone Routers with Neutron; Chapter 8, Router Redundancy Using VRRP; and Chapter 9, Distributed Virtual Routers.
First introduced in the Grizzly release of OpenStack, Load Balancing as a Service, also known as LBaaS, provides users with the ability to distribute client requests across multiple instances or servers. Users can create monitors, set connection limits, and apply persistence profiles to traffic traversing a virtual load balancer. The Kilo release of OpenStack introduced version 2 of the LBaaS API in an experimental status. The v2 API is a vast improvement over version 1, and by the Liberty release, it should be stable. OpenStack Networking is equipped with a plugin for LBaaS that utilizes HAProxy in the open source reference implementation. More information on the use of load balancers within Neutron can be found in Chapter 10, Load Balancing Traffic to Instances.
In the current release of OpenStack, there are two methods of providing security to instances: security groups and firewalls. When using security groups, instances are placed into groups that share common functionality and rule sets. Iptables rules are configured on compute nodes and filter traffic in and out of Linux bridges connected to each instance. In a reference implementation, when using virtual firewalls provided by Firewall as a Service, also known as FWaaS, security is handled at the edge of the network on a Neutron router rather than at the compute node. Through the Liberty release of OpenStack, the FWaaS API remains in an experimental status with no guaranteed backward compatibility in future releases. More information on securing instances can be found in Chapter 6, Managing Security Groups, and Chapter 11, Firewall as a Service.
A virtual private network, or VPN, extends a private network across a public network such as the Internet. A VPN enables a computer to send and receive data across public networks as if it were directly connected to the private network. Neutron provides a set of APIs to allow users to create IPSec-based VPN tunnels from Neutron routers to remote gateways when using the open source reference implementation. More information on creating and managing virtual private networks can be found in Chapter 12, Virtual Private Network as a Service.
Network functions virtualization, or NFV, is a network architecture concept that proposes using traditional virtualization techniques to replace standalone network appliances used for various network functions. These functions include intrusion detection, caching, gateways, WAN accelerators, firewalls, and more. Support for NFV within OpenStack is growing, but requires a major shift in the current design model to support features such as VLAN trunking directly to virtualized instances, unaddressed interfaces, and others that may be required by network devices. In Juno, support for SR-IOV, also known as single root I/O virtualization, was introduced. Using SR-IOV, instances are no longer required to use para-virtualized drivers or to be connected to virtual bridges within the host. Instead, the instance is attached to an SR-IOV port that is associated with a virtual function (VF) in the NIC, allowing the instance to access the NIC hardware directly. Explaining how to configure support for SR-IOV is outside the scope of this book, but more information can be found on the OpenStack Wiki at https://wiki.openstack.org/.
When architecting the network, it is important to first determine how the cloud will be used. Is a highly scalable environment with multiple levels of network, hardware, and service redundancy required? Or, are your needs less complex, requiring nothing more than a sandbox for application development, with little concern given to the resiliency of the network or compute platform? Are all of the advanced networking features that OpenStack Networking has to offer in terms of routing, firewalling, and load balancing required? Or, are you looking to leverage existing physical hardware in the data center to accomplish those tasks?
OpenStack Networking can serve many roles within different clouds but is better at some technologies than others. The purpose of the cloud itself, along with security requirements and available hardware, will play a big part in determining the architecture of the network and OpenStack's role in the network.
The official OpenStack website (www.openstack.org) provides reference architectures for OpenStack clouds leveraging Neutron networking that involves a combination of one or more of the following nodes:
Controller node
Network node
Compute node
Before the installation of OpenStack can begin, the physical network infrastructure must be configured to support the networks needed for an operational cloud. In the following diagram, I have highlighted the area of responsibility for the network administrator:
Figure 1.1
The physical network infrastructure must be configured to support OpenStack Networking, which can include a dedicated management interface, a network dedicated to overlay network traffic, and one or more networks that provide external connectivity to instances. As shown in the preceding diagram, the configuration of interfaces and networks represented in the top half of the diagram are the responsibility of the network or system administrator. These responsibilities include the configuration of physical switches, firewalls, or routers as well as interfaces on the servers themselves. The bottom half of the diagram represents interfaces and devices such as virtual switches and virtual machines that will be configured automatically by OpenStack.
In the next few chapters, I will define networks and VLANs that will be used throughout the book to demonstrate the various components of OpenStack Networking. Generic information on the configuration of switch ports, routers, or firewalls can be found in the upcoming chapters as well.
The reference architecture for OpenStack Networking defines at least four distinct types of traffic that will be seen on the network:
Management
API
External
Guest
Although I have taken the liberty of splitting out the network traffic into dedicated interfaces in this book, it is not necessary to do so to create an operational OpenStack cloud. In fact, many administrators and distributions choose to collapse multiple traffic types onto single or bonded interfaces using VLAN tagging. Depending on the chosen deployment model, the administrator may spread networking services across multiple nodes or collapse them onto a single node. The security requirements of the enterprise deploying the cloud will often dictate how the cloud is built. The various network and service configurations will be discussed in the upcoming sections.
The management network, also referred to as the internal network in some distributions, is used for internal communication between hosts for services such as the messaging service and database service. All hosts will communicate with each other over this network. In many cases, this same interface may be used to facilitate Glance image transfers between hosts or some other bandwidth-intensive traffic. The management network can be configured as an isolated network on a dedicated interface or combined with another network, as described in the following section.
The API network is used to expose OpenStack APIs to users of the cloud and services within the cloud. Endpoint addresses for services, such as Keystone, Neutron, Glance, and Horizon, are procured from the API network.
It is a common practice to utilize a single interface and IP address for API endpoints and management access to the host itself over SSH. A diagram of this configuration is provided later in this chapter.
An external network provides Neutron routers with network access. Once a router has been configured and attached to the external network, the network becomes the source of floating IP addresses for instances and other network resources. IP addresses in an external network are expected to be routable and reachable by clients on a corporate network or the Internet.
The guest network is a network dedicated to instance traffic. Options for guest networks include local networks restricted to a particular node, flat or VLAN-tagged networks, or virtual overlay networks made possible with GRE or VXLAN encapsulation. For more information on guest networks, refer to Chapter 5, Creating Networks with Neutron.
The physical interfaces used for external and guest networks can be dedicated interfaces or ones that are shared with other types of traffic. Each approach has its benefits and drawbacks, and they are described in more detail later in the chapter.
The number of interfaces needed per host is dependent on the purpose of the cloud, the security and performance requirements of the organization, and the availability of hardware.
A single interface per server that results in a combined control and data plane is all that is needed for a fully operational OpenStack cloud. Many organizations choose to deploy their cloud this way, especially when port density is at a premium. Collapsed networking may also be used when the environment is simply used for testing, or network failure at the node level is a non-impacting event. It is my recommendation, however, that you split control and data traffic across multiple interfaces whenever possible.
For hosts using a single interface, all traffic to and from instances as well as internal OpenStack, SSH management, and API traffic traverse the same interface. This configuration can result in severe performance degradation, as a guest can create a denial of service attack against its host by consuming all available bandwidth.
The following diagram demonstrates the use of a single physical interface for all traffic when using the Open vSwitch driver. On the controller node, a single interface is connected to a bridge and handles external, guest, management, and API service traffic. On the compute node, a single interface handles guest and management traffic:
Figure 1.2
In the preceding diagram, all OpenStack service and management traffic traverses the same physical interface as guest traffic.
To reduce the likelihood of guest network bandwidth consumption impacting management traffic and to maintain a more robust security posture, segregation of traffic between multiple physical interfaces is recommended. At a minimum, two interfaces should be used: one that serves as a dedicated interface for management and API traffic and another that serves as a dedicated interface for external and guest traffic. Additional interfaces can be used to further segregate traffic. The following diagram demonstrates traffic split across two physical interfaces when using the Open vSwitch driver:
Figure 1.3
In the preceding diagram, a dedicated physical interface on the controller node handles OpenStack API and management traffic. Another interface is connected to a bridge that handles external and overlay traffic to and from Neutron routers and other network resources. On the compute node, a dedicated physical interface is used for management traffic and another for overlay traffic to and from instances.
In this book, the environment will be built using three interfaces: one for management and API traffic, one for external or VLAN tenant network traffic, and another for overlay network traffic:
Figure 1.4
In the preceding diagram, a dedicated interface on the controller node handles OpenStack API and management traffic. Another dedicated interface handles overlay traffic, and another is connected to a bridge that handles external traffic. On the compute node, a dedicated interface is used for management traffic, another dedicated interface handles overlay traffic, and another is connected to a bridge that handles VLAN traffic when VLAN tenant networks are in use.
NIC bonding offers users the ability to multiply available bandwidth by aggregating links. Two or more physical interfaces can be combined to create a single virtual interface, or bond, which can then be placed in a bridge or used as a regular interface. The technology used to accomplish this is known as IEEE 802.1ad Link Aggregation Control Protocol, or LACP. The physical switching infrastructure must be capable of supporting this type of bond. Legacy switching devices required the multiple links of a bond to be connected to the same switch. Modern devices support technology such as vPC and MLAG. They allow links of a bond to be connected to two switches, providing hardware redundancy between switches while allowing users the full bandwidth of the bond in normal operating conditions, with no changes to the server configuration necessary.
In addition to aggregating interfaces, bonding can also refer to the ability to create redundant links in an active/passive manner. Both links are simultaneously cabled to a switch or pair of switches, but only one interface is active at any given time. Both types of bonds can be created within the operating system when the appropriate kernel module is installed. Bonding can be configured in Open vSwitch if desired, but is outside the scope of OpenStack and this book.
Bonding interfaces can be an inexpensive way to provide hardware-level network redundancy to the cloud infrastructure. If you are interested in configuring NIC bonding on your hosts, refer to the Ubuntu bonding page at https://help.ubuntu.com/community/UbuntuBonding.
Like other OpenStack services, cloud operators can split OpenStack Networking services across multiple nodes. Small deployments may use a single node to host all services, including networking, compute, database, and messaging. Others might find benefit in using a dedicated compute node and a dedicated network node to handle guest traffic routed through software routers and to offload Neutron DHCP and metadata services. The following sections describe a few common service deployment models.
In an environment consisting of a single controller and one or more compute nodes, the controller will likely handle all networking services and other OpenStack services, while the compute nodes strictly provide compute resources.
The following diagram demonstrates a controller node hosting all OpenStack management and networking services where the Neutron layer 3 agent is not utilized. Two physical interfaces are used to separate management and instance network traffic:
Figure 1.5
The preceding diagram reflects the use of a single combined controller/network node and one or more compute nodes, with Neutron providing only layer 2 connectivity between instances and external gateway devices. An external router is needed to handle routing between network segments.
The following diagram demonstrates a controller node hosting all OpenStack management and networking services, including the Neutron L3 agent. Three physical interfaces are used to provide separate control and data planes:
Figure 1.6
The preceding diagram reflects the use of a single combined controller/network node and one or more compute nodes in a network configuration that utilizes the Neutron L3 agent. Software routers created with Neutron reside on the controller node and handle routing between connected tenant networks and external provider networks.
The environment built out in this book will be composed of a single controller node running all OpenStack network services and two compute nodes running Nova compute services.
A network node is dedicated to handling most or all the OpenStack Networking services, including the L3 agent, DHCP agent, metadata agent, and more. The use of a dedicated network node provides additional security and resilience, as the controller node will be at less risk of network and resource saturation. Some Neutron services, such as the L3 and DHCP agents and the Neutron API service, can be scaled out across multiple nodes for redundancy and increased performance.
The following diagram demonstrates a network node hosting all OpenStack Networking services, including the Neutron L3, DHCP, metadata, and LBaaS agents. The Neutron API service, however, remains installed on the controller node. Three physical interfaces are used where necessary to provide separate control and data planes:
Figure 1.7
The preceding diagram reflects the use of a dedicated network node in a network configuration that utilizes the Neutron L3 agent. Software routers created with the Neutron API reside on the network node and handle routing between connected tenant networks and external provider networks. The neutron-server Neutron API service remains on the controller node.
OpenStack Networking offers the ability to create and manage different technologies found in a data center in a virtualized and programmable manner. If the built-in features and reference implementations are not enough, the pluggable architecture of OpenStack Networking allows for additional functionality to be provided by third-party commercial and open-source vendors. The security requirements of the organization building the cloud as well as the use cases of the cloud will ultimately dictate the physical layout and separation of services across the infrastructure nodes.
Throughout this book, you will learn how to build a functional OpenStack cloud utilizing advanced Neutron networking features available as of the Kilo release. In the next chapter, we will begin a package-based installation of OpenStack on the Ubuntu 14.04 LTS operating system. Topics covered include the installation, configuration, and verification of the database; messaging; and OpenStack identity, image, compute, and dashboard services. The installation and configuration of base OpenStack Networking services, including the Neutron API, can be found in Chapter 3, Installing Neutron.
