a3d8ad2e5f
A lot of images are very large in PDF output, follow our documented conventions to add contentwidth="7in" everywhere. The Training Guides use landscape mode - thus we use "7in" instead of the usual "6in". Change-Id: I74052b864f65ed2a1199e5008a62b9a95cac9968 Closes-Bug: #1294054
271 lines
14 KiB
XML
271 lines
14 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
|
<chapter xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
version="5.0"
|
|
xml:id="module002-ch001-networking-in-openstack">
|
|
<title>Networking in OpenStack</title>
|
|
<para><guilabel>Networking in OpenStack</guilabel></para>
|
|
<para>OpenStack Networking provides a rich tenant-facing API
|
|
for defining network connectivity and addressing in the
|
|
cloud. The OpenStack Networking project gives operators
|
|
the ability to leverage different networking technologies
|
|
to power their cloud networking. It is a virtual network
|
|
service that provides a powerful API to define the network
|
|
connectivity and addressing used by devices from other
|
|
services, such as OpenStack Compute. It has a rich API
|
|
which consists of the following components.</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><emphasis role="bold">Network:</emphasis> An
|
|
isolated L2 segment, analogous to VLAN in the physical
|
|
networking world.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">Subnet:</emphasis> A block
|
|
of v4 or v6 IP addresses and associated configuration
|
|
state.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">Port:</emphasis> A
|
|
connection point for attaching a single device, such
|
|
as the NIC of a virtual server, to a virtual network.
|
|
Also describes the associated network configuration,
|
|
such as the MAC and IP addresses to be used on that
|
|
port.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>You can configure rich network topologies by creating
|
|
and configuring networks and subnets, and then instructing
|
|
other OpenStack services like OpenStack Compute to attach
|
|
virtual devices to ports on these networks. In
|
|
particular, OpenStack Networking supports each tenant
|
|
having multiple private networks, and allows tenants to
|
|
choose their own IP addressing scheme, even if those IP
|
|
addresses overlap with those used by other tenants. This
|
|
enables very advanced cloud networking use cases, such as
|
|
building multi-tiered web applications and allowing
|
|
applications to be migrated to the cloud without changing
|
|
IP addresses.</para>
|
|
<para><guilabel>Plugin Architecture: Flexibility to Choose
|
|
Different Network Technologies</guilabel></para>
|
|
<para>Enhancing traditional networking solutions to provide rich
|
|
cloud networking is challenging. Traditional networking is not
|
|
designed to scale to cloud proportions or to configure
|
|
automatically.</para>
|
|
<para>The original OpenStack Compute network implementation
|
|
assumed a very basic model of performing all isolation through
|
|
Linux VLANs and IP tables. OpenStack Networking introduces the
|
|
concept of a plug-in, which is a pluggable back-end
|
|
implementation of the OpenStack Networking API. A plug-in can
|
|
use a variety of technologies to implement the logical API
|
|
requests. Some OpenStack Networking plug-ins might use basic
|
|
Linux VLANs and IP tables, while others might use more
|
|
advanced technologies, such as L2-in-L3 tunneling or OpenFlow,
|
|
to provide similar benefits.</para>
|
|
<para>The current set of plug-ins include:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><emphasis role="bold">Big Switch, Floodlight REST
|
|
Proxy:</emphasis>
|
|
<link
|
|
xlink:href="http://www.openflowhub.org/display/floodlightcontroller/Quantum+REST+Proxy+Plugin"
|
|
>http://www.openflowhub.org/display/floodlightcontroller/Quantum+REST+Proxy+Plugin</link></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">Brocade
|
|
Plugin</emphasis></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">Cisco:</emphasis> Documented
|
|
externally at: <link
|
|
xlink:href="http://wiki.openstack.org/cisco-quantum"
|
|
>http://wiki.openstack.org/cisco-quantum</link></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">Hyper-V
|
|
Plugin</emphasis></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">Linux Bridge:</emphasis>
|
|
Documentation included in this guide and <link
|
|
xlink:href="http://wiki.openstack.org/Quantum-Linux-Bridge-Plugin"
|
|
>http://wiki.openstack.org/Quantum-Linux-Bridge-Plugin</link>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">Midonet
|
|
Plugin</emphasis></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">NEC OpenFlow:</emphasis>
|
|
<link
|
|
xlink:href="http://wiki.openstack.org/Quantum-NEC-OpenFlow-Plugin"
|
|
>http://wiki.openstack.org/Quantum-NEC-OpenFlow-Plugin</link></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">Open vSwitch:</emphasis>
|
|
Documentation included in this guide.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">PLUMgrid:</emphasis>
|
|
<link
|
|
xlink:href="https://wiki.openstack.org/wiki/Plumgrid-quantum"
|
|
>https://wiki.openstack.org/wiki/Plumgrid-quantum</link></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">Ryu:</emphasis>
|
|
<link
|
|
xlink:href="https://github.com/osrg/ryu/wiki/OpenStack"
|
|
>https://github.com/osrg/ryu/wiki/OpenStack</link></para>
|
|
</listitem>
|
|
<listitem>
|
|
<!-- TODO: Update support link, when available -->
|
|
<para><emphasis role="bold">VMware NSX:</emphasis>
|
|
Documentation include in this guide, <link
|
|
xlink:href="http://www.vmware.com/products/nsx"
|
|
>NSX Product Overview </link>, and <link
|
|
xlink:href="http://www.nicira.com/support">NSX
|
|
Product Support</link>.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>Plugins can have different properties in terms of hardware
|
|
requirements, features, performance, scale, operator tools,
|
|
etc. Supporting many plug-ins enables the cloud administrator
|
|
to weigh different options and decide which networking
|
|
technology is right for the deployment.</para>
|
|
<para>Components of OpenStack Networking</para>
|
|
<para>To deploy OpenStack Networking, it is useful to understand
|
|
the different components that make up the solution and how
|
|
those components interact with each other and with other
|
|
OpenStack services.</para>
|
|
<para>OpenStack Networking is a standalone service, just like
|
|
other OpenStack services such as OpenStack Compute, OpenStack
|
|
Image Service, OpenStack Identity service, and the OpenStack
|
|
Dashboard. Like those services, a deployment of OpenStack
|
|
Networking often involves deploying several processes on a
|
|
variety of hosts.</para>
|
|
<para>The main process of the OpenStack Networking server is
|
|
quantum-server, which is a Python daemon that exposes the
|
|
OpenStack Networking API and passes user requests to the
|
|
configured OpenStack Networking plug-in for additional
|
|
processing. Typically, the plug-in requires access to a
|
|
database for persistent storage, similar to other OpenStack
|
|
services.</para>
|
|
<para>If your deployment uses a controller host to run centralized
|
|
OpenStack Compute components, you can deploy the OpenStack
|
|
Networking server on that same host. However, OpenStack
|
|
Networking is entirely standalone and can be deployed on its
|
|
own server as well. OpenStack Networking also includes
|
|
additional agents that might be required depending on your
|
|
deployment:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><emphasis role="bold">plugin agent
|
|
(quantum-*-agent):</emphasis>Runs on each
|
|
hypervisor to perform local vswitch configuration.
|
|
Agent to be run depends on which plug-in you are using,
|
|
as some plug-ins do not require an agent.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">dhcp agent
|
|
(quantum-dhcp-agent):</emphasis>Provides DHCP
|
|
services to tenant networks. This agent is the same
|
|
across all plug-ins.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">l3 agent
|
|
(quantum-l3-agent):</emphasis>Provides L3/NAT
|
|
forwarding to provide external network access for VMs
|
|
on tenant networks. This agent is the same across all
|
|
plug-ins.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>These agents interact with the main quantum-server process
|
|
in the following ways:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Through RPC. For example, rabbitmq or qpid.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Through the standard OpenStack Networking
|
|
API.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>OpenStack Networking relies on the OpenStack Identity
|
|
Project (Keystone) for authentication and authorization of all
|
|
API request.</para>
|
|
<para>OpenStack Compute interacts with OpenStack Networking
|
|
through calls to its standard API. As part of creating a VM,
|
|
nova-compute communicates with the OpenStack Networking API to
|
|
plug each virtual NIC on the VM into a particular
|
|
network.</para>
|
|
<para>The OpenStack Dashboard (Horizon) has integration with the
|
|
OpenStack Networking API, allowing administrators and tenant
|
|
users, to create and manage network services through the
|
|
Horizon GUI.</para>
|
|
<para><emphasis role="bold">Place Services on Physical
|
|
Hosts</emphasis></para>
|
|
<para>Like other OpenStack services, OpenStack Networking provides
|
|
cloud administrators with significant flexibility in deciding
|
|
which individual services should run on which physical
|
|
devices. On one extreme, all service daemons can be run on a
|
|
single physical host for evaluation purposes. On the other,
|
|
each service could have its own physical hosts, and some cases
|
|
be replicated across multiple hosts for redundancy.</para>
|
|
<para>In this guide, we focus primarily on a standard architecture
|
|
that includes a “cloud controller” host, a “network gateway”
|
|
host, and a set of hypervisors for running VMs. The "cloud
|
|
controller" and "network gateway" can be combined in simple
|
|
deployments, though if you expect VMs to send significant
|
|
amounts of traffic to or from the Internet, a dedicated
|
|
network gateway host is suggested to avoid potential CPU
|
|
contention between packet forwarding performed by the
|
|
quantum-l3-agent and other OpenStack services.</para>
|
|
<para><emphasis role="bold">Network Connectivity for Physical
|
|
Hosts</emphasis></para>
|
|
<figure>
|
|
<title>Network Diagram</title>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="figures/image33.png" contentwidth="7in"/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
<para>A standard OpenStack Networking setup has up to four
|
|
distinct physical data center networks:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><emphasis role="bold">Management
|
|
network:</emphasis>Used for internal communication
|
|
between OpenStack Components. The IP addresses on this
|
|
network should be reachable only within the data
|
|
center.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">Data network:</emphasis>Used
|
|
for VM data communication within the cloud deployment.
|
|
The IP addressing requirements of this network depend
|
|
on the OpenStack Networking plug-in in use.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">External
|
|
network:</emphasis>Used to provide VMs with Internet
|
|
access in some deployment scenarios. The IP addresses
|
|
on this network should be reachable by anyone on the
|
|
Internet.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">API network:</emphasis>Exposes
|
|
all OpenStack APIs, including the OpenStack Networking
|
|
API, to tenants. The IP addresses on this network
|
|
should be reachable by anyone on the Internet. This
|
|
may be the same network as the external network, as it
|
|
is possible to create a subnet for the external
|
|
network that uses IP allocation ranges to use only
|
|
less than the full range of IP addresses in an IP
|
|
block.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</chapter>
|