39,59 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Fachliteratur
- Sprache: Englisch
OpenStack Neutron is an OpenStack component that provides networking as a service for other OpenStack services to architect networks and create virtual machines through its API. This API lets you define network connectivity in order to leverage network capabilities to cloud deployments.
Through this practical book, you will build a strong foundational knowledge of Neutron, and will architect and build an OpenStack cloud using advanced networking features.
We start with an introduction to OpenStack Neutron and its various components, including virtual switching, routing, FWaaS, VPNaaS, and LBaaS. You’ll also get hands-on by installing OpenStack and Neutron and its components, and use agents and plugins to orchestrate network connectivity and build a virtual switching infrastructure.
Moving on, you’ll get to grips with the HA routing capabilities utilizing VRRP and distributed virtual routers in Neutron. You’ll also discover load balancing fundamentals, including the difference between nodes, pools, pool members, and virtual IPs. You’ll discover the purpose of security groups and learn how to apply the security concept to your cloud/tenant/instance.
Finally, you' ll configure virtual private networks that will allow you to avoid the use of SNAT and floating IPs when connecting to remote networks.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 417
Veröffentlichungsjahr: 2015
Ähnliche
Table of Contents
Learning OpenStack Networking (Neutron) Second Edition
Learning OpenStack Networking (Neutron) Second Edition
Copyright © 2015 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: October 2014
Second edition: November 2015
Production reference: 1251115
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham B3 2PB, UK.
ISBN 978-1-78528-772-5
www.packtpub.com
Credits
Author
James Denton
Reviewers
Will Foster
Mostafa A. Hamid
Kevin Jackson
Commissioning Editor
Kartikey Pandey
Acquisition Editor
Reshma Raman
Content Development Editor
Shweta Pant
Technical Editor
Humera Shaikh
Copy Editors
Shruti Iyer
Karuna Narayanan
Project Coordinator
Shipra Chawhan
Proofreader
Safis Editing
Indexer
Mariammal Chettiyar
Production Coordinator
Conidon Miranda
Cover Work
Conidon Miranda
About the Author
James Denton lives with his beautiful wife, Amanda, and son, Wyatt, in San Antonio, Texas. He is an experienced IT professional with extensive experience in application networking technologies and OpenStack Networking. James is a principal architect at Rackspace and currently supports OpenStack Networking for customers of the Rackspace Private Cloud product. He can be found on Twitter as @jimmdenton and on Freenode IRC as busterswt.
I'd like to thank my wife, Amanda, for providing encouragement and patience throughout the writing of this book and its predecessor. I would also like to thank my team and managers at Rackspace for reviewing many rough drafts and providing excellent feedback.
Without NASA, Rackspace, and the ever-growing OpenStack community, the opportunity to write this book would not have been possible. I would like to extend thanks to everyone involved, in the past and present, in making OpenStack what it is today.
About the Reviewers
Will Foster is originally from Raleigh, North Carolina. He attended The Citadel, The Military College of South Carolina, in 1996, where he pursued a degree in English. Will was a performing member of The Summerall Guards, an elite close-order Prussian drill unit, as well as a cadet officer within Tango Company, class of 2000. He also holds a degree in technical writing from Appalachian State University and is a Red Hat Certified Engineer.
Since 2000, Will has worked as a UNIX/Linux systems administrator involved in mission-critical customer-facing production business environments. A lifelong skateboard enthusiast, he had a brief stint as a snowboarding instructor during the years 2000-2001.
Will has worked at Red Hat since 2007 as a senior systems administrator / DevOps engineer managing enterprise IT storage and core infrastructure. Currently, he works in the OpenStack deployment team. His team designs, architects, and builds labs and infrastructure to test and vet real-world customer deployments and cloud scenarios. They also collaborate with the upstream development community and partners to improve and build upon the OpenStack platform.
Will currently resides in Dublin, Ireland, and in his free time, he performs stand-up comedy, travels, and blogs at http://hobo.house. Will can be found on Twitter as @sadsfae.
Mostafa A. Hamid is an information systems engineer from Potsdam, The State University of New York (SUNY). He has completed certifications such as CISSP, CEH, and LPIC as well as in IBM RUP architecture. Besides these, Mostafa is also certified in JavaScript, PHP, Backbone.js, Java, and XML from Potsdam. He has a bachelor's degree from Modern Academy for Computer Science and Management Technology.
Mostafa has worked with Hilton Worldwide as an internet support engineer, with United Systems as a technical support engineer, and with Media Plans as an IT manager/architect. He has also worked with MOIS as an IT manager/teacher and is currently working as a software developer at Wassaq.
Mostafa has also reviewed OpenStack Essentials, Packt Publishing.
I would like to thank Manon Niazi, the Deutschlander I met in college; my family; and Shipra Chawhan, the project coordinator. Of course, much thanks go to the author, James Denton.
Kevin Jackson is married and has three children. He is an experienced IT professional working with business and enterprises of all sizes at Rackspace as a principal OpenStack engineer. Kevin has been working with OpenStack since early 2011 and has extensive experience of various flavors of Linux, Unix, and hosting environments. Kevin can be found on twitter @itarchitectkev.
Kevin authored the first edition, and coauthored the second and recently published third editions of the OpenStack Cloud Computing Cookbook by Packt Publishing. Kevin also co-authored the OpenStack Foundation's OpenStack Architecture Design Guide during a 5-day book sprint in California.
www.PacktPub.com
Support files, eBooks, discount offers, and more
For support files and downloads related to your book, please visit www.PacktPub.com.
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at <[email protected]> for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
https://www2.packtpub.com/books/subscription/packtlib
Do you need instant solutions to your IT questions? PacktLib is Packt's online digital book library. Here, you can search, access, and read Packt's entire library of books.
Why subscribe?
Free access for Packt account holders
If you have an account with Packt at www.PacktPub.com, you can use this to access PacktLib today and view 9 entirely free books. Simply use your login credentials for immediate access.
Preface
In the fall of 2015, the OpenStack Foundation released the 12th version of OpenStack, code-named Liberty, to the public. Since its introduction as an open source project in 2010 by NASA and Rackspace, OpenStack has undergone significant improvements in its features and functionality and has matured into production-ready cloud software that powers workloads of all sizes throughout the world.
In 2012, the Folsom release of OpenStack introduced a standalone networking component, known then as Quantum. Now known as Neutron, the networking component of OpenStack provides cloud operators and users with an API to create and manage networks in the cloud. Neutron's extensible framework allows for third-party plugins and additional network services, such as load balancers, firewalls, and virtual private networks, to be deployed and managed.
As an architect and operator of hundreds of OpenStack-based private clouds since 2012, I have seen much of what OpenStack has to offer in terms of networking capabilities, and I have condensed what I feel are its most valuable and production-ready features to date into this book. Throughout this book, we will take a look at a few common network and service architectures and lay a foundation for deploying and managing OpenStack Networking, which will help you develop and sharpen your skills as an OpenStack cloud operator.
What this book covers
Chapter 1, Preparing the Network for OpenStack, provides an introduction to OpenStack Networking, including supported networking technologies and examples of how to architect the physical network to support an OpenStack cloud.
Chapter 2, Installing OpenStack, provides instructions to install the core components of the Kilo release of OpenStack on the Ubuntu 14.04 LTS operating system.
Chapter 3, Installing Neutron, explains how to install the Neutron networking components of OpenStack. We will also cover the internal architecture of Neutron, including the use of agents and plugins to orchestrate network connectivity.
Chapter 4, Building a Virtual Switching Infrastructure, helps you to install and configure the ML2 plugin to support both the LinuxBridge and Open vSwitch drivers and agents. We will also cover the architectural differences between the LinuxBridge and Open vSwitch drivers and agents and how they connect instances to the network.
Chapter 5, Creating Networks with Neutron, walks you through creating networks and subnets in the cloud, booting and attaching instances to networks, and exploring the process of obtaining DHCP leases and metadata.
Chapter 6, Managing Security Groups, examines the use of iptables to secure instance traffic at the compute node and walks you through creating and managing security groups and associated rules.
Chapter 7, Creating Standalone Routers with Neutron, walks you through creating standalone virtual routers and attaching them to networks, applying floating IPs to instances, and following the flow of traffic through a router to an instance.
Chapter 8, Router Redundancy Using VRRP, explores Virtual Routing Redundancy Protocol and its use in providing highly-available virtual routers.
Chapter 9, Distributed Virtual Routers, walks you through creating and managing virtual routers that are distributed across multiple nodes.
Chapter 10, Load Balancing Traffic to Instances, explores the fundamental components of a load balancer in Neutron, including virtual IPs, pools, pool members, and monitors, and walks you through creating and integrating a virtual load balancer into the network.
Chapter 11, Firewall as a Service, covers the creation and management of virtual firewalls, their associated policies and rules, and the integration of virtual firewalls in the network.
Chapter 12, Virtual Private Network as a Service, examines the fundamental concepts of IPSec-based virtual private networks and walks you through configuring and managing VPN connections that connect tenant networks to remote networks.
Appendix A, Additional Neutron Commands, briefly covers additional Neutron functionality that is outside the scope of this book, including commands related to Cisco 1000V, VMware NSX, and more.
Appendix B, Virtualizing the Environment, describes the process of deploying OpenStack across multiple virtual machines using VirtualBox virtualization software in case physical servers are not available to the reader. Examples are limited to VirtualBox 5 on Mac OS but can be adapted to other operating systems and releases if necessary.
What you need for this book
This book assumes a moderate level of networking experience, including experience with Linux networking configurations as well as physical switch and router configurations. While this book walks the reader through a basic installation of OpenStack, little time is spent on services other than Neutron. Therefore, it is important that the reader has a basic understanding of OpenStack and its general configuration prior to configuring OpenStack Networking.
In this book, the following is required:
Ubuntu 14.04 LTS
The following software is needed:
Internet connectivity is required to install OpenStack packages and to make use of the example architectures in the book. While virtualization software, such as VirtualBox or VMware, can be used to simulate servers and the network infrastructure, this book assumes that OpenStack is installed on physical hardware and that a physical network infrastructure is in place.
Major OpenStack releases occur every six months, and after the M- or N-release, Kilo repositories may no longer be available. In the event that the OpenStack installation procedure documented in this book no longer functions properly, refer to the installation guide at docs.openstack.org for instructions on installing the latest version of OpenStack.
Who this book is for
This book is geared towards OpenStack cloud administrators or operators with a novice to intermediate level of experience in managing OpenStack-based clouds who are looking to build or enhance their cloud using the networking service known as Neutron. By laying down a basic installation of OpenStack based on the installation guide found at docs.openstack.org, the reader should be able to follow the examples laid out in the book to obtain a functional understanding of the various components of OpenStack Networking using open-source reference architectures.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of.
To send us general feedback, simply e-mail <[email protected]>, and mention the book's title in the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the example code
You can download the example code files from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
Downloading the color images of this book
We also provide you with a PDF file that has color images of the screenshots/diagrams used in this book. The color images will help you better understand the changes in the output. You can download this file from: https://www.packtpub.com/sites/default/files/downloads/7225OS_Graphics.pdf.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the ErrataSubmissionForm link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors and our ability to bring you valuable content.
Questions
If you have a problem with any aspect of this book, you can contact us at <[email protected]>, and we will do our best to address the problem.
Chapter 1. Preparing the Network for OpenStack
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.
What is OpenStack Networking?
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.
Features of OpenStack Networking
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.
Switching
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.
Routing
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.
Load balancing
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.
Firewalling
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.
Virtual private networks
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
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/.
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:
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:
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.
Physical server connections
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.
Single interface
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.
Multiple interfaces
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.
Bonding
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.
Note
Bonding configurations vary greatly between Linux distributions. Refer to the respective documentation of your Linux distribution for assistance in configuring bonding.
Separating services across nodes
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.
Using a single controller node
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.
Using a dedicated network node
A network node is dedicated to handling most
