50dc3e2167
Neutron Metering Agent has been introduced in Havana release. This patch adds the agent in Neutron Diagram and explains the process to install the agent on the network nodes. Change-Id: Id8f16aab44af18141a63fa873d9f856f83f444a4 backport: havana Signed-off-by: Emilien Macchi <emilien.macchi@enovance.com>
198 lines
10 KiB
XML
198 lines
10 KiB
XML
<section xml:id="section_networking-arch" 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">
|
||
<title>Networking architecture</title>
|
||
<para>Before you deploy Networking, it helps to understand the
|
||
Networking components and how these components interact
|
||
with each other and other OpenStack services.</para>
|
||
<section xml:id="arch_overview">
|
||
<title>Overview</title>
|
||
<para>Networking is a standalone service, just like other
|
||
OpenStack services such as Compute, Image service,
|
||
Identity service, or the Dashboard. Like those
|
||
services, a deployment of Networking often involves
|
||
deploying several processes on a variety of
|
||
hosts.</para>
|
||
<para>The Networking server uses the <systemitem
|
||
class="service">neutron-server</systemitem> daemon
|
||
to expose the Networking API and to pass user requests
|
||
to the configured Networking plug-in for additional
|
||
processing. Typically, the plug-in 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
|
||
Compute components, you can deploy the Networking server on that
|
||
same host. However, Networking is entirely standalone and can be
|
||
deployed on its own host as well. Depending on your deployment,
|
||
Networking can also include the following agents.</para>
|
||
<para>
|
||
<table rules="all">
|
||
<caption>Networking agents</caption>
|
||
<col width="30%"/>
|
||
<col width="70%"/>
|
||
<thead>
|
||
<tr>
|
||
<th>Agent</th>
|
||
<th>Description</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td><emphasis role="bold">plug-in
|
||
agent</emphasis>
|
||
(<literal>neutron-*-agent</literal>)</td>
|
||
<td>Runs on each hypervisor to perform
|
||
local vswitch configuration. The agent
|
||
that runs depends on the plug-in that
|
||
you use, and some plug-ins do not
|
||
require an agent.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><emphasis role="bold">dhcp
|
||
agent</emphasis>
|
||
(<literal>neutron-dhcp-agent</literal>)</td>
|
||
<td>Provides DHCP services to tenant
|
||
networks. Some plug-ins use this
|
||
agent.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><emphasis role="bold">l3
|
||
agent</emphasis>
|
||
(<literal>neutron-l3-agent</literal>)</td>
|
||
<td>Provides L3/NAT forwarding to provide
|
||
external network access for VMs on
|
||
tenant networks. Some plug-ins use
|
||
this agent.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><emphasis role="bold">metering agent</emphasis>
|
||
(<literal>neutron-metering-agent</literal>)</td>
|
||
<td>Provides L3 traffic measurements for tenant networks.</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</para>
|
||
<para>These agents interact with the main neutron process
|
||
through RPC (for example, rabbitmq or qpid) or through
|
||
the standard Networking API. Further:</para>
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Networking relies on the Identity service
|
||
(Keystone) for the authentication and
|
||
authorization of all API requests.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Compute (Nova) interacts with Networking
|
||
through calls to its standard API. As part of
|
||
creating a VM, the <systemitem class="service"
|
||
>nova-compute</systemitem> service
|
||
communicates with the Networking API to plug
|
||
each virtual NIC on the VM into a particular
|
||
network. </para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>The Dashboard (Horizon) integrates with the
|
||
Networking API, enabling administrators and
|
||
tenant users to create and manage network
|
||
services through a web-based GUI.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</section>
|
||
<section xml:id="networking-services">
|
||
<title>Place services on physical hosts</title>
|
||
<para>Like other OpenStack services, Networking enables
|
||
cloud administrators to run one or more services on
|
||
one or more physical devices. At one extreme, the
|
||
cloud administrator can run all service daemons on a
|
||
single physical host for evaluation purposes.
|
||
Alternatively the cloud administrator can run each
|
||
service on its own physical host and, in some cases,
|
||
can replicate services across multiple hosts for
|
||
redundancy. For more information, see the <citetitle
|
||
xmlns:svg="http://www.w3.org/2000/svg"
|
||
xmlns:html="http://www.w3.org/1999/xhtml"
|
||
>OpenStack Configuration
|
||
Reference</citetitle>.</para>
|
||
<para>A standard architecture includes a cloud controller
|
||
host, a network gateway host, and a set of hypervisors
|
||
that run virtual machines. The cloud controller and
|
||
network gateway can be on the same host. However, if
|
||
you expect VMs to send significant traffic to or from
|
||
the Internet, a dedicated network gateway host helps
|
||
avoid CPU contention between the <systemitem
|
||
class="service">neutron-l3-agent</systemitem> and
|
||
other OpenStack services that forward packets.</para>
|
||
</section>
|
||
<section xml:id="network-connectivity">
|
||
<title>Network connectivity for physical hosts</title>
|
||
<mediaobject>
|
||
<imageobject>
|
||
<imagedata scale="50"
|
||
fileref="../common/figures/Neutron-PhysNet-Diagram.png"
|
||
/>
|
||
</imageobject>
|
||
</mediaobject>
|
||
<para>A standard Networking set up has one or more of the
|
||
following distinct physical data center
|
||
networks.</para>
|
||
|
||
<para>
|
||
<table rules="all">
|
||
<caption>General distinct physical data center
|
||
networks</caption>
|
||
<col width="20%"/>
|
||
<col width="80%"/>
|
||
<thead>
|
||
<tr>
|
||
<th>Network</th>
|
||
<th>Description</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td><emphasis role="bold">Management
|
||
network</emphasis></td>
|
||
<td>Provides internal communication
|
||
between OpenStack Components. IP
|
||
addresses on this network should be
|
||
reachable only within the data
|
||
center.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><emphasis role="bold">Data
|
||
network</emphasis></td>
|
||
<td>Provides VM data communication within
|
||
the cloud deployment. The IP
|
||
addressing requirements of this
|
||
network depend on the Networking
|
||
plug-in that is used.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><emphasis role="bold">External
|
||
network</emphasis></td>
|
||
<td>Provides VMs with Internet access in
|
||
some deployment scenarios. Anyone on
|
||
the Internet can reach IP addresses on
|
||
this network.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><emphasis role="bold">API
|
||
network</emphasis></td>
|
||
<td>Exposes all OpenStack APIs, including
|
||
the Networking API, to tenants. IP
|
||
addresses on this network should be
|
||
reachable by anyone on the
|
||
Internet. The API network might 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.</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</para>
|
||
</section>
|
||
</section>
|