openstack-manuals/doc/security-guide/ch031_neutron-architecture.xml
Diane Fleming 64b6c9261e Folder rename, file rename, flattening of directories
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
2013-09-08 15:15:50 -07:00

60 lines
6.0 KiB
XML
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<?xml version="1.0" encoding="UTF-8"?>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://docbook.org/ns/docbook" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch031_neutron-architecture"><?dbhtml stop-chunking?>
<title>Networking Architecture</title>
<para>OpenStack Networking is a standalone service that often involves deploying several processes across a number of nodes. These processes interact with each other and with other OpenStack services. The main process of the OpenStack Networking service is neutron-server, a Python daemon that exposes the OpenStack Networking API and passes tenant requests to a suite of plugins for additional processing.</para>
<para>OpenStack Networking components encompasses the following elements:</para>
<itemizedlist><listitem>
<para><emphasis role="bold">neutron server</emphasis> (<literal>neutron-server</literal> and <literal>neutron-*-plugin</literal>): This service runs on the network node to service the Networking API and its extensions. It also enforces the network model and IP addressing of each port. The neutron-server and plugin agents require access to a database for persistent storage and access to a message queue for inter-communication.</para>
</listitem>
<listitem>
<para><emphasis role="bold">plugin agent</emphasis> (<literal>neutron-*-agent</literal>): Runs on each Nova compute node to manage local virtual switch (vswitch) configuration. The agents to be run will depend on which plugin you are using. This service requires message queue access. <emphasis>Optional depending on plugin.</emphasis></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 across all plugins and is responsible for maintaining DHCP configuration. The neutron-dhcp-agent requires message queue access.</para>
</listitem>
<listitem>
<para><emphasis role="bold">l3 agent</emphasis> (<literal>neutron-l3-agent</literal>): Provides L3/NAT forwarding for external network access of VMs on tenant networks. Requires message queue access. <emphasis>Optional depending on plugin.</emphasis></para>
</listitem>
<listitem>
<para><emphasis role="bold">network provider services</emphasis> (SDN server/services). Provide additional networking services that are provided to tenant networks. These SDN services may interact with the neutron-server, neutron-plugin, and/or plugin-agents via REST APIs or other communication channels.</para>
</listitem>
</itemizedlist>
<para>The figure that follows provides an architectural and networking flow diagram of the OpenStack Networking components:</para>
<para><inlinemediaobject><imageobject role="html">
<imagedata contentdepth="319" contentwidth="536" fileref="static/sdn-connections.png" format="PNG" scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%" fileref="static/sdn-connections.png" format="PNG" scalefit="1" width="100%"/>
</imageobject>
</inlinemediaobject></para>
<section xml:id="ch031_neutron-architecture-idp61360">
<title>OS Networking Service placement on Physical Servers</title>
<para>In this guide, we focus primarily on a standard architecture that includes a <emphasis>cloud controller</emphasis> host, a <emphasis>network</emphasis> host, and a set of <emphasis>compute</emphasis> hypervisors for running VMs.</para>
<section xml:id="ch031_neutron-architecture-idp63888">
<title>Network Connectivity of Physical Servers</title>
<para><inlinemediaobject><imageobject role="html">
<imagedata contentdepth="364" contentwidth="536" fileref="static/1aa-network-domains-diagram.png" format="PNG" scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%" fileref="static/1aa-network-domains-diagram.png" format="PNG" scalefit="1" width="100%"/>
</imageobject>
</inlinemediaobject></para>
<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 and is considered the Management Security Domain.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Guest network</emphasis> Used for VM data communication within the cloud deployment. The IP addressing requirements of this network depend on the OpenStack Networking plugin in use and the network configuration choices of the virtual networks made by the tenant. This network is considered the Guest Security Domain.</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 and is considered to be in the Public Security Domain.</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. This network is considered the Public Security Domain.</para>
</listitem>
</itemizedlist>
<para>For additional information see the <link xlink:href="http://docs.openstack.org/grizzly/openstack-network/admin/content/arch_overview.html"><citetitle>OpenStack Networking Administration Guide</citetitle></link>.</para>
</section>
</section>
</chapter>