Preparing the physical infrastructure

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.

Types of network traffic

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.

Management network

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.

API network

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.

Tip

It is recommended, though not required, that you physically separate management and API traffic from other traffic types, such as storage traffic, to avoid issues with network congestion that may affect operational stability.

External network

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.

Guest network

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.