64b6c9261e
Current folder name New folder name Book title ---------------------------------------------------------- basic-install DELETE cli-guide DELETE common common NEW admin-guide-cloud Cloud Administrators Guide docbkx-example DELETE openstack-block-storage-admin DELETE openstack-compute-admin DELETE openstack-config config-reference OpenStack Configuration Reference openstack-ha high-availability-guide OpenStack High Availabilty Guide openstack-image image-guide OpenStack Virtual Machine Image Guide openstack-install install-guide OpenStack Installation Guide openstack-network-connectivity-admin admin-guide-network OpenStack Networking Administration Guide openstack-object-storage-admin DELETE openstack-security security-guide OpenStack Security Guide openstack-training training-guide OpenStack Training Guide openstack-user user-guide OpenStack End User Guide openstack-user-admin user-guide-admin OpenStack Admin User Guide glossary NEW OpenStack Glossary bug: #1220407 Change-Id: Id5ffc774b966ba7b9a591743a877aa10ab3094c7 author: diane fleming
624 lines
32 KiB
XML
624 lines
32 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="ch_overview">
|
||
<title>Overview</title>
|
||
<para>This chapter describes the high-level concepts and
|
||
components of an OpenStack Networking deployment.</para>
|
||
<section xml:id="WhatIsNeutron">
|
||
<title>What is OpenStack Networking?</title>
|
||
<para>The OpenStack Networking project was created to provide a rich
|
||
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. </para>
|
||
<para>For a detailed description of the OpenStack Networking API
|
||
abstractions and their attributes, see the <link
|
||
xlink:href="http://docs.openstack.org/api/openstack-network/2.0/content/"
|
||
xmlns:svg="http://www.w3.org/2000/svg"
|
||
xmlns:m="http://www.w3.org/1998/Math/MathML"
|
||
xmlns:html="http://www.w3.org/1999/xhtml"
|
||
xmlns:db="http://docbook.org/ns/docbook"
|
||
><citetitle>OpenStack Networking API Guide
|
||
(v2.0)</citetitle></link>.</para>
|
||
<section xml:id="rich_network">
|
||
<title>OpenStack Networking API: Rich Control over Network Functionality</title>
|
||
<para>OpenStack Networking 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. </para>
|
||
<para>The OpenStack Compute API has a virtual server
|
||
abstraction to describe computing resources. Similarly,
|
||
the OpenStack Networking API has virtual network, subnet, and port
|
||
abstractions to describe networking resources. In more
|
||
detail: <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>
|
||
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). The OpenStack Networking service:
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Enables 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>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
Offers flexibility for the cloud administrator
|
||
to customized network offerings.
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Provides a mechanism that lets
|
||
cloud administrators expose additional API
|
||
capabilities through API extensions. Commonly, new
|
||
capabilities are first introduced as an API extension,
|
||
and over time become part of the core OpenStack Networking API.
|
||
</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</para>
|
||
</section>
|
||
<!-- <?hard-pagebreak?> -->
|
||
<section xml:id="flexibility">
|
||
<title>Plugin Architecture: Flexibility to Choose Different Network
|
||
Technologies</title>
|
||
<para>Enhancing traditional networking solutions to
|
||
provide rich cloud networking is challenging.
|
||
Traditional networking is not designed to scale to
|
||
cloud proportions nor to handle automatic configuration.</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 <emphasis role="italic"
|
||
>plugin</emphasis>, which is a back-end
|
||
implementation of the OpenStack Networking API. A plugin can use a
|
||
variety of technologies to implement the logical API
|
||
requests. Some OpenStack Networking plugins 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 following plugins are currently included in the OpenStack Networking distribution: <itemizedlist>
|
||
<listitem>
|
||
<para><emphasis role="bold">Big Switch Plugin (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>.
|
||
<link
|
||
xlink:href="https://github.com/brocade/brocade"
|
||
>https://github.com/brocade/brocade</link>
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis role="bold">Cisco</emphasis>.
|
||
<link
|
||
xlink:href="http://wiki.openstack.org/cisco-neutron"
|
||
>http://wiki.openstack.org/cisco-neutron</link>
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis role="bold">Cloudbase Hyper-V Plugin</emphasis>.
|
||
<link xlink:href="http://www.cloudbase.it/quantum-hyper-v-plugin/"
|
||
>http://www.cloudbase.it/quantum-hyper-v-plugin/</link>
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis role="bold">Linux Bridge Plugin</emphasis>.
|
||
Documentation included in this guide and at
|
||
<link
|
||
xlink:href="http://wiki.openstack.org/Quantum-Linux-Bridge-Plugin"
|
||
>http://wiki.openstack.org/Neutron-Linux-Bridge-Plugin</link>
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis role="bold">Mellanox Plugin</emphasis>. <link
|
||
xlink:href="https://wiki.openstack.org/wiki/Mellanox-Neutron/">
|
||
https://wiki.openstack.org/wiki/Mellanox-Neutron/</link>
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis role="bold">Midonet Plugin</emphasis>.
|
||
<link
|
||
xlink:href="http://www.midokura.com/">
|
||
http://www.midokura.com/</link>
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis role="bold">NEC OpenFlow Plugin</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">Nicira NVP Plugin</emphasis>.
|
||
Documentation include in this guide,
|
||
<link
|
||
xlink:href="http://www.vmware.com/products/datacenter-virtualization/nicira.html">
|
||
NVP Product Overview </link>, and
|
||
<link
|
||
xlink:href="http://www.nicira.com/support"
|
||
>NVP Product Support</link>.
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis role="bold">Open vSwitch Plugin</emphasis>.
|
||
Documentation included in this guide.
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis role="bold">PLUMgrid</emphasis>.
|
||
<link
|
||
xlink:href="https://wiki.openstack.org/wiki/PLUMgrid-Neutron"
|
||
>https://https://wiki.openstack.org/wiki/PLUMgrid-Neutron</link>
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis role="bold">Ryu Plugin</emphasis>.
|
||
<link
|
||
xlink:href="https://github.com/osrg/ryu/wiki/OpenStack"
|
||
>https://github.com/osrg/ryu/wiki/OpenStack</link>
|
||
</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</para>
|
||
<para>Plugins can have different properties for hardware requirements, features, performance,
|
||
scale, or operator tools. Because OpenStack Networking supports a large number of plugins,
|
||
the cloud administrator is able to weigh different options and decide which networking
|
||
technology is right for the deployment.
|
||
</para>
|
||
<?hard-pagebreak?>
|
||
<para>Not all OpenStack networking plugins are compatible with all possible OpenStack compute drivers:</para>
|
||
|
||
<table rules="all">
|
||
<caption>Plugin Compatability with OpenStack Compute Drivers</caption>
|
||
<col/>
|
||
<col/>
|
||
<col/>
|
||
<col/>
|
||
<col/>
|
||
<col/>
|
||
<col/>
|
||
<thead>
|
||
<tr>
|
||
<th></th>
|
||
<th>Libvirt (KVM/QEMU)</th>
|
||
<th>XenServer</th>
|
||
<th>VMware</th>
|
||
<th>Hyper-V</th>
|
||
<th>Bare-metal</th>
|
||
<th>PowerVM</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>Bigswitch / Floodlight</td>
|
||
<td>Yes</td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
</tr>
|
||
<tr>
|
||
<td>Brocade</td>
|
||
<td>Yes</td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
</tr>
|
||
<tr>
|
||
<td>Cisco</td>
|
||
<td>Yes</td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
</tr>
|
||
<tr>
|
||
<td>Cloudbase Hyper-V</td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
<td>Yes</td>
|
||
<td></td>
|
||
<td></td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td>Linux Bridge</td>
|
||
<td>Yes</td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
</tr>
|
||
<tr>
|
||
<td>Mellanox</td>
|
||
<td>Yes</td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
</tr>
|
||
<tr>
|
||
<td>Midonet</td>
|
||
<td>Yes</td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
</tr>
|
||
<tr>
|
||
<td>NEC OpenFlow</td>
|
||
<td>Yes</td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
</tr>
|
||
<tr>
|
||
<td>Nicira NVP</td>
|
||
<td>Yes</td>
|
||
<td>Yes</td>
|
||
<td>Yes</td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
</tr>
|
||
<tr>
|
||
<td>Open vSwitch</td>
|
||
<td>Yes</td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
</tr>
|
||
<tr>
|
||
<td>Plumgrid</td>
|
||
<td>Yes</td>
|
||
<td></td>
|
||
<td>Yes</td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
</tr>
|
||
<tr>
|
||
<td>Ryu</td>
|
||
<td>Yes</td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
<td></td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</section>
|
||
</section>
|
||
<section xml:id="Architecture">
|
||
<title>OpenStack Networking Architecture</title>
|
||
<para>This section describes the high-level components of an
|
||
OpenStack Networking deployment. Before you deploy OpenStack Networking, it is useful to
|
||
understand the different components that make up the
|
||
solution, and how these components interact with each
|
||
other and with other OpenStack services.</para>
|
||
<section xml:id="arch_overview">
|
||
<title>Overview</title>
|
||
|
||
<para>OpenStack Networking is a standalone service, just
|
||
like other OpenStack services such as OpenStack
|
||
Compute, OpenStack Image service, OpenStack Identity
|
||
service, or 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
|
||
<literal>neutron-server</literal>, which is a
|
||
Python daemon that exposes the OpenStack Networking API and passes
|
||
user requests to the configured OpenStack Networking plugin for
|
||
additional processing. Typically, the plugin requires
|
||
access to a database for persistent storage (also 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 host as
|
||
well. OpenStack Networking also includes additional agents that
|
||
might be required, depending on your deployment: <itemizedlist>
|
||
<listitem>
|
||
<para><emphasis role="bold">plugin agent</emphasis>
|
||
(<literal>neutron-*-agent</literal>).
|
||
Runs on each hypervisor to perform local
|
||
vswitch configuration. The agent to be run will
|
||
depend on which plugin you are using, because
|
||
some plugins do not actually require an agent.
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis role="bold">dhcp agent</emphasis>
|
||
(<literal>neutron-dhcp-agent</literal>).
|
||
Provides DHCP services to tenant networks.
|
||
This agent is the same for all plugins.
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis role="bold">l3
|
||
agent</emphasis>
|
||
<literal>(neutron-l3-agent</literal>).
|
||
Provides L3/NAT forwarding to provide
|
||
external network access for VMs on tenant
|
||
networks. This agent is the same for all plugins.
|
||
</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</para>
|
||
<para>The above agents interact with the main Neutron process through RPC (for example,
|
||
rabbitmq or qpid) or through the standard OpenStack Networking API. Further:
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>OpenStack Networking relies on the OpenStack
|
||
Identity service (keystone) for the authentication and
|
||
authorization of all API request. </para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>OpenStack Compute (nova) interacts with OpenStack Networking through calls
|
||
to its standard API. As part of creating a VM, the
|
||
<systemitem class="service">nova-compute</systemitem> service communicates with the OpenStack Networking API to plug
|
||
each virtual NIC on the VM into a particular network.
|
||
</para>
|
||
</listitem>
|
||
<listitem><para>The OpenStack Dashboard (horizon) integrates with the OpenStack Networking
|
||
API, allowing administrators and tenant users to create and manage network services
|
||
through the Dashboard GUI.</para></listitem>
|
||
</itemizedlist>
|
||
</para>
|
||
</section>
|
||
<section xml:id="services">
|
||
<title>Place Services on Physical Hosts</title>
|
||
<para>Like other OpenStack services, OpenStack Networking provides cloud administrators with
|
||
significant flexibility in deciding which individual services should run on
|
||
which physical devices. At one extreme, all service daemons can be run on a
|
||
single physical host for evaluation purposes. At the other, each service could
|
||
have its own physical hosts and, in some cases, be replicated across multiple hosts for
|
||
redundancy. For more information, see the chapter on <link linkend="ch_high_avail">high availability</link>.</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. However, if you expect VMs to send significant amounts of
|
||
traffic to or from the Internet, a dedicated network gateway host is recommended
|
||
to avoid potential CPU contention between packet forwarding performed by
|
||
the <literal>neutron-l3-agent</literal> and other OpenStack services.</para>
|
||
</section>
|
||
<section xml:id="connectivity">
|
||
<title>Network Connectivity for Physical Hosts</title>
|
||
<mediaobject>
|
||
<imageobject>
|
||
<imagedata scale="60" fileref="../common/figures/Neutron-PhysNet-Diagram.png"/>
|
||
</imageobject>
|
||
</mediaobject>
|
||
<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.
|
||
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 plugin being used. </para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis role="bold">External
|
||
network</emphasis>. Used to provide VMs
|
||
with Internet access in some deployment
|
||
scenarios. 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. IP addresses on this network
|
||
should be reachable by anyone on the
|
||
Internet. The API network may be the same as
|
||
the external network, because it is possible to create
|
||
an external-network subnet that is allocated
|
||
IP ranges that use less than the full
|
||
range of IP addresses in an IP block.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</section>
|
||
</section>
|
||
<?hard-pagebreak?>
|
||
<section xml:id="use_cases">
|
||
<title>OpenStack Networking Deployment Use Cases</title>
|
||
<para>
|
||
The following common-use cases for OpenStack Networking are
|
||
not exhaustive, but can be combined to create more complex use cases.
|
||
</para>
|
||
<section xml:id="use_cases_single_flat">
|
||
<title>Use Case: Single Flat Network</title>
|
||
<para>In the simplest use case, a single OpenStack Networking network is created. This is a
|
||
"shared" network, meaning it is visible to all tenants via the OpenStack Networking
|
||
API. Tenant VMs have a single NIC, and receive
|
||
a fixed IP address from the subnet(s) associated with that network.
|
||
This use case essentially maps to the FlatManager
|
||
and FlatDHCPManager models provided by OpenStack Compute. Floating IPs are not
|
||
supported.</para>
|
||
<para>This network type is often created by the OpenStack administrator
|
||
to map directly to an existing physical network in the data center (called a
|
||
"provider network"). This allows the provider to use a physical
|
||
router on that data center network as the gateway for VMs to reach
|
||
the outside world. For each subnet on an external network, the gateway
|
||
configuration on the physical router must be manually configured
|
||
outside of OpenStack.</para>
|
||
<para>
|
||
<mediaobject>
|
||
<imageobject>
|
||
<imagedata scale="80" fileref="figures/UseCase-SingleFlat.png"/>
|
||
</imageobject>
|
||
</mediaobject>
|
||
<!--Image source link: https://docs.google.com/a/nicira.com/drawings/d/1Jb6iSoBo4G7fv7i2EMpYTMTxesLPmEPKIbI7sVbhhqY/edit -->
|
||
</para>
|
||
</section>
|
||
<?hard-pagebreak?>
|
||
<section xml:id="use_cases_multi_flat">
|
||
<title>Use Case: Multiple Flat Network</title>
|
||
<para>
|
||
This use case is similar to the above Single Flat Network use case,
|
||
except that tenants can see multiple shared networks via the OpenStack Networking API
|
||
and can choose which network (or networks) to plug into.
|
||
</para>
|
||
<para>
|
||
<mediaobject>
|
||
<imageobject>
|
||
<imagedata scale="60" fileref="figures/UseCase-MultiFlat.png"/>
|
||
</imageobject>
|
||
</mediaobject>
|
||
<!--Image source link: https://docs.google.com/a/nicira.com/drawings/d/14ayGsyunW_P-wvY8OiueE407f7540JD3VsWUH18KHvU/edit -->
|
||
</para>
|
||
</section>
|
||
<?hard-pagebreak?>
|
||
<section xml:id="use_cases_mixed">
|
||
<title>Use Case: Mixed Flat and Private Network</title>
|
||
<para>
|
||
This use case is an extension of the above Flat Network use cases.
|
||
In addition to being able to see one or more shared networks via
|
||
the OpenStack Networking API, tenants can also have access to private per-tenant
|
||
networks (only visible to tenant users).
|
||
</para>
|
||
<para>
|
||
Created VMs can have NICs on any of the shared networks and/or any of the private networks
|
||
belonging to the tenant. This enables the creation of "multi-tier"
|
||
topologies using VMs with multiple NICs. It also supports a model where
|
||
a VM acting as a gateway can provide services such as routing, NAT, or
|
||
load balancing.
|
||
</para>
|
||
<para>
|
||
<mediaobject>
|
||
<imageobject>
|
||
<imagedata scale="55" fileref="figures/UseCase-MixedFlatPrivate.png"/>
|
||
</imageobject>
|
||
</mediaobject>
|
||
<!--Image source link: https://docs.google.com/a/nicira.com/drawings/d/1efSqR6KA2gv-OKl5Rl-oV_zwgYP8mgQHFP2DsBj5Fqo/edit -->
|
||
</para>
|
||
</section>
|
||
<?hard-pagebreak?>
|
||
<section xml:id="use_cases_single_router">
|
||
<title>Use Case: Provider Router with Private Networks</title>
|
||
<para>
|
||
This use case provides each tenant with one or more private networks, which
|
||
connect to the outside world via an OpenStack Networking router.
|
||
When each tenant gets exactly one network, this architecture maps to the same
|
||
logical topology as the VlanManager in OpenStack Compute (although of course, OpenStack Networking doesn't
|
||
require VLANs). Using the OpenStack Networking API, the tenant can only see a
|
||
network for each private network assigned to that tenant. The router
|
||
object in the API is created and owned by the cloud administrator.
|
||
</para>
|
||
<para>
|
||
This model supports giving VMs public addresses using
|
||
"floating IPs", in which the router maps public addresses from the
|
||
external network to fixed IPs on private networks. Hosts without floating
|
||
IPs can still create outbound connections to the external network, because
|
||
the provider router performs SNAT to the router's external IP. The
|
||
IP address of the physical router is used as the <literal>gateway_ip</literal> of the
|
||
external network subnet, so the provider has a default router for
|
||
Internet traffic.
|
||
</para>
|
||
<para>
|
||
The router provides L3 connectivity between private networks, meaning
|
||
that different tenants can reach each other's instances unless additional
|
||
filtering is used (for example, security groups). Because there is only a single
|
||
router, tenant networks cannot use overlapping IPs. Thus, it is likely
|
||
that the administrator would create the private networks on behalf of the tenants.
|
||
</para>
|
||
<para>
|
||
<mediaobject>
|
||
<imageobject>
|
||
<imagedata scale="55" fileref="figures/UseCase-SingleRouter.png"/>
|
||
</imageobject>
|
||
</mediaobject>
|
||
<!--Image source link: https://docs.google.com/a/nicira.com/drawings/d/1DKxeZZXml_fNZHRoGPKkC7sGdkPJZCtWytYZqHIp_ZE/edit -->
|
||
</para>
|
||
</section>
|
||
<?hard-pagebreak?>
|
||
<section xml:id="use_cases_tenant_router">
|
||
<title>Use Case: Per-tenant Routers with Private Networks</title>
|
||
<para>
|
||
This use case represents a more advanced router scenario in which each tenant gets
|
||
at least one router, and potentially has access to the OpenStack Networking API to
|
||
create additional routers. The tenant can create their own networks,
|
||
potentially uplinking those networks to a router. This model enables
|
||
tenant-defined, multi-tier applications, with
|
||
each tier being a separate network behind the router. Since there are
|
||
multiple routers, tenant subnets can overlap without conflicting,
|
||
since access to external networks all happens via SNAT or Floating IPs.
|
||
Each router uplink and floating IP is allocated from the external network
|
||
subnet.
|
||
</para>
|
||
<para>
|
||
<mediaobject>
|
||
<imageobject>
|
||
<imagedata scale="55"
|
||
fileref="figures/UseCase-MultiRouter.png" align="left"/>
|
||
</imageobject>
|
||
</mediaobject>
|
||
|
||
<!--Image source link: https://docs.google.com/a/nicira.com/drawings/d/1mmQc8cBUoTEfEns-ehIyQSTvOrjUdl5xeGDv9suVyAY/edit -->
|
||
</para>
|
||
</section>
|
||
</section>
|
||
</chapter>
|