caf4a98f60
Rewords language to distinguish between process, services and components. Updates some technical terminology. Various other small changes throughout. Change-Id: I6d39b7707a0971251974d41636415d73a18b7bf7 Partial-Bug: #1217503
187 lines
9.8 KiB
XML
187 lines
9.8 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's useful to understand the
|
||
Networking services and how they interact with the OpenStack
|
||
components.</para>
|
||
<section xml:id="arch_overview">
|
||
<title>Overview</title>
|
||
<para>Networking is a standalone component in the OpenStack modular
|
||
architecture. It's positioned alongside OpenStack components such
|
||
as Compute, Image service, Identity service, or the Dashboard. Like
|
||
those components, a deployment of Networking often involves
|
||
deploying several services to a variety of hosts.</para>
|
||
<para>The Networking server uses the <systemitem class="service"
|
||
>neutron-server</systemitem> daemon to expose the Networking
|
||
API and enable administration of the configured Networking
|
||
plug-in. 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 to that
|
||
same host. However, Networking is entirely standalone and can be
|
||
deployed to a dedicated host. Depending on your configuration,
|
||
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. Certain 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.
|
||
Required by certain plug-ins.</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. Required
|
||
by certain plug-ins.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><emphasis role="bold">metering agent</emphasis>
|
||
(<literal>neutron-metering-agent</literal>)</td>
|
||
<td>Provides L3 traffic metering 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. In addition, Networking integrates with OpenStack
|
||
components in a number of ways:</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 you to run
|
||
services across multiple physical devices. It is also possible to
|
||
run all service daemons on a single physical host for evaluation
|
||
purposes. Alternatively, you can run each service on a dedicated
|
||
physical host and replicate certain services across multiple hosts
|
||
for redundancy purposes. 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 architectural design includes a cloud controller
|
||
host, a network gateway host, and a number of hypervisors
|
||
for hosting 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 deployment includes one or more of the
|
||
following physical 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>
|