Updated networking content

I updated the networking content as follows:

1) Reordered example architectures to place the 3-node neutron
   architecture before the 2-node nova-network architecture which
   agrees with the order presented in other portions of the
   installation guide.
2) Changed network service naming to agree with conventions.
3) Permanently unlinked the Open vSwitch (OVS) plug-in sections from
   the Networking chapter. However, I will refrain from deleting
   the associated files in case we need to restore them.
4) Temporarily unlinked the Open vSwitch (OVS) portion of the Neutron
   concepts section until we can update it to reflect the Modular
   Layer 2 (ML2) plug-in.
5) Addressed other minor issues.

Change-Id: I7c285fcabaab65237477e8241f406dac28190344
Closes-Bug: #1309636
This commit is contained in:
Matt Kassawara 2014-04-18 12:58:17 -06:00
parent 2e16bb18b6
commit 03cff88d61
13 changed files with 100 additions and 177 deletions

View File

@ -3,10 +3,6 @@
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="ch_basics">
<?dbhtml-stop-chunking?>
<title>Basic environment configuration</title>
<warning>
<para>We are updating this material for Icehouse. You may find structure
and/or content issues during this process.</para>
</warning>
<para>This chapter explains how to configure each node in the
<link linkend="architecture_example-architectures">example architectures</link>
including the <link linkend="example-architecture-with-legacy-networking">

View File

@ -13,8 +13,10 @@
xlink:href="http://docs.openstack.org/user-guide/content/ch_dashboard.html">
<citetitle>OpenStack User Guide</citetitle></link>.</para>
<para>Launch an instance using
<link linkend="launch-instance-neutron">Networking (neutron)</link> or
<link linkend="launch-instance-nova">legacy networking (nova-network)</link>. For more
<link linkend="launch-instance-neutron">OpenStack Networking (neutron)
</link> or
<link linkend="launch-instance-nova">legacy networking (nova-network)
</link>. For more
information, see the
<link
xlink:href="http://docs.openstack.org/user-guide/content/cli_launch_instances.html">

View File

@ -4,19 +4,6 @@
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="ch_networking">
<title>Add a networking service</title>
<!-- FIXME Temporarily replacing this warning.
<warning>
<para>This chapter is a bit more adventurous than we would
like. We are working on cleanup and improvements to it.
Like for the rest of the Installation Guide, feedback
through bug reports and patches to improve it are
welcome.</para>
</warning>
-->
<warning>
<para>We are updating this material for Icehouse. You may find
structure and/or content issues during this process.</para>
</warning>
<para>Configuring networking in OpenStack can be a bewildering
experience. This guide provides step-by-step instructions for both
OpenStack Networking (neutron) and the legacy networking (nova-network)
@ -30,34 +17,18 @@
>Networking</link> chapter of the <citetitle>OpenStack Cloud
Administrator Guide</citetitle> for more information.</para>
<section xml:id="section_neutron-networking">
<title>Networking (neutron)</title>
<title>OpenStack Networking (neutron)</title>
<xi:include href="section_neutron-concepts.xml"/>
<section xml:id="section_neutron-networking-ml2">
<title>Modular Layer 2 (ML2) plug-in</title>
<note>
<para>We primarily tested the Modular Layer 2 (ML2) plug-in on
Icehouse and suggest that you implement it instead of the
traditional Open vSwitch (OVS) plug-in.</para>
</note>
<xi:include href="section_neutron-ml2-controller-node.xml"/>
<xi:include href="section_neutron-ml2-network-node.xml"/>
<xi:include href="section_neutron-ml2-compute-node.xml"/>
<xi:include href="section_neutron-initial-networks.xml"/>
</section>
<section xml:id="section_neutron-networking-ovs">
<title>Open vSwitch (OVS) plug-in</title>
<warning>
<para>We suggest that you implement the Modular Layer 2 (ML2) plug-in
on Icehouse until we completely test the traditional Open vSwitch
(OVS) plug-in.</para>
</warning>
<xi:include href="section_neutron-ovs-controller-node.xml"/>
<xi:include href="section_neutron-ovs-network-node.xml"/>
<xi:include href="section_neutron-ovs-compute-node.xml"/>
</section>
<xi:include href="section_neutron-initial-networks.xml"/>
</section>
<section xml:id="section_nova-networking">
<title>Legacy networking</title>
<title>Legacy networking (nova-network)</title>
<xi:include href="section_nova-networking-controller-node.xml"/>
<xi:include href="section_nova-networking-compute-node.xml"/>
<xi:include href="section_nova-networking-initial-network.xml"/>

View File

@ -45,55 +45,6 @@
optional services. This guide uses the following example
architectures:</para>
<itemizedlist>
<listitem>
<para>Two-node architecture with legacy networking. See <xref linkend="example-architecture-with-legacy-networking"/>.</para>
<itemizedlist>
<listitem>
<para>The basic
<glossterm baseform="cloud controller node">controller node</glossterm>
runs the Identity service, Image Service, management portion of
Compute, and the dashboard necessary to launch a simple instance.
It also includes supporting services such as MySQL,
<glossterm>AMQP</glossterm>, and
<glossterm>NTP</glossterm>.</para>
<para>Optionally, the controller node also runs portions of
Block Storage, Object Storage, Database Service, Orchestration,
and Telemetry. These components provide additional features for
your environment.</para>
</listitem>
<listitem>
<para>The basic <glossterm>compute node</glossterm> runs the
<glossterm>hypervisor</glossterm> portion of Compute,
which operates <glossterm>tenant</glossterm>
<glossterm baseform="virtual machine (VM)">virtual machines</glossterm>
or instances. By default, Compute uses
<glossterm baseform="kernel-based VM (KVM)">KVM</glossterm>
as the <glossterm>hypervisor</glossterm>. Compute also
provisions and operates tenant networks and implements
<glossterm baseform="security group">security groups</glossterm>.
You can run more than one compute node.</para>
<para>Optionally, the compute node also runs the Telemetry
agent. This component provides additional features for
your environment.</para>
</listitem>
</itemizedlist>
<note>
<para>When you implement this architecture, skip
<xref linkend="section_neutron-networking" /> in
<xref linkend="ch_networking" />. To use optional services, you
might need to install additional nodes, as described in
subsequent chapters.</para>
</note>
<figure xml:id="example-architecture-with-legacy-networking">
<title>Two-node architecture with legacy networking</title>
<mediaobject>
<imageobject>
<imagedata contentwidth="6in"
fileref="figures/installguide_arch-nova.png"/>
</imageobject>
</mediaobject>
</figure>
</listitem>
<listitem>
<para>Three-node architecture with OpenStack Networking (neutron). See <xref linkend="example-architecture-with-neutron-networking"/>.</para>
<itemizedlist>
@ -101,7 +52,10 @@
<para>The basic controller node runs the Identity service, Image
Service, management portions of Compute and Networking,
Networking plug-in, and the dashboard. It also includes
supporting services such as MySQL, AMQP, and NTP.</para>
supporting services such as a database,
<glossterm>message broker</glossterm>, and
<glossterm>Network Time Protocol (NTP)</glossterm>.
</para>
<para>Optionally, the controller node also runs portions of
Block Storage, Object Storage, Database Service, Orchestration,
and Telemetry. These components provide additional features for
@ -146,6 +100,55 @@
</mediaobject>
</figure>
</listitem>
<listitem>
<para>Two-node architecture with legacy networking (nova-network). See
<xref linkend="example-architecture-with-legacy-networking"/>.</para>
<itemizedlist>
<listitem>
<para>The basic
<glossterm baseform="cloud controller node">controller node</glossterm>
runs the Identity service, Image Service, management portion of
Compute, and the dashboard necessary to launch a simple instance.
It also includes supporting services such as a database, message
broker, and NTP.</para>
<para>Optionally, the controller node also runs portions of
Block Storage, Object Storage, Database Service, Orchestration,
and Telemetry. These components provide additional features for
your environment.</para>
</listitem>
<listitem>
<para>The basic <glossterm>compute node</glossterm> runs the
<glossterm>hypervisor</glossterm> portion of Compute,
which operates <glossterm>tenant</glossterm>
<glossterm baseform="virtual machine (VM)">virtual machines</glossterm>
or instances. By default, Compute uses
<glossterm baseform="kernel-based VM (KVM)">KVM</glossterm>
as the <glossterm>hypervisor</glossterm>. Compute also
provisions and operates tenant networks and implements
<glossterm baseform="security group">security groups</glossterm>.
You can run more than one compute node.</para>
<para>Optionally, the compute node also runs the Telemetry
agent. This component provides additional features for
your environment.</para>
</listitem>
</itemizedlist>
<note>
<para>When you implement this architecture, skip
<xref linkend="section_neutron-networking" /> in
<xref linkend="ch_networking" />. To use optional services, you
might need to install additional nodes, as described in
subsequent chapters.</para>
</note>
<figure xml:id="example-architecture-with-legacy-networking">
<title>Two-node architecture with legacy networking (nova-network)</title>
<mediaobject>
<imageobject>
<imagedata contentwidth="6in"
fileref="figures/installguide_arch-nova.png"/>
</imageobject>
</mediaobject>
</figure>
</listitem>
</itemizedlist>
</section>
</chapter>

View File

@ -3,7 +3,7 @@
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="basics-networking-neutron">
<?dbhtml-stop-chunking?>
<title>OpenStack Networking</title>
<title>OpenStack Networking (neutron)</title>
<para>The example architecture with OpenStack Networking (neutron) requires
one controller node, one network node, and at least one compute node.
The controller node contains one network interface on the
@ -14,7 +14,7 @@
one network interface on the management network and one on the
instance tunnels network.</para>
<figure>
<title>Three-node architecture with OpenStack Networking</title>
<title>Three-node architecture with OpenStack Networking (neutron)</title>
<mediaobject>
<imageobject>
<imagedata contentwidth="6in"

View File

@ -3,15 +3,15 @@
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="basics-networking-nova">
<?dbhtml-stop-chunking?>
<title>Legacy networking</title>
<para>The example architecture with legacy networking (nova) requires one
controller node and at least one compute node. The controller node
contains one network interface on the
<title>Legacy networking (nova-network)</title>
<para>The example architecture with legacy networking (nova-network)
requires a controller node and at least one compute node. The controller
node contains one network interface on the
<glossterm>management network</glossterm>. The compute node contains
one network interface on the management network and one on the
<glossterm>external network</glossterm>.</para>
<figure>
<title>Two-node architecture with legacy networking</title>
<title>Two-node architecture with legacy networking (nova-network)</title>
<mediaobject>
<imageobject>
<imagedata contentwidth="6in"

View File

@ -73,9 +73,9 @@
</step>
</procedure>
<para>Proceed to network configuration for the example
<link linkend="basics-networking-neutron">OpenStack Networking
<link linkend="basics-networking-neutron">OpenStack Networking (neutron)
</link> or <link linkend="basics-networking-nova">legacy
networking</link> architecture.</para>
networking (nova-network)</link> architecture.</para>
<xi:include href="section_basics-networking-neutron.xml"/>
<xi:include href="section_basics-networking-nova.xml"/>
</section>

View File

@ -3,7 +3,7 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="launch-instance-neutron">
<title>Launch an instance with Networking (neutron)</title>
<title>Launch an instance with OpenStack Networking (neutron)</title>
<procedure>
<title>To generate a keypair</title>
<para>Most cloud images support

View File

@ -1,28 +1,33 @@
<?xml version="1.0" encoding="UTF-8"?>
<section xml:id="install-neutron"
<section xml:id="neutron-concepts"
xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:html="http://www.w3.org/1999/xhtml" version="5.0">
<title>Neutron concepts</title>
<para>Like Nova Networking, Neutron manages software-defined
networking for your OpenStack installation. However, unlike Nova
Networking, you can configure Neutron for advanced virtual network
topologies, such as per-tenant private networks and more.</para>
<para>Neutron has the following object abstractions: networks,
<title>Networking concepts</title>
<para>OpenStack Networking (neutron) manages all of the networking facets for
the Virtual Networking Infrastructure (VNI) and the access layer aspects
of the Physical Networking Infrastructure (PNI) in your OpenStack
environment. OpenStack Networking allows tenants to create advanced virtual
network topologies including services such as
<glossterm baseform="firewall">firewalls</glossterm>,
<glossterm baseform="load balancer">load balancers</glossterm>, and
<glossterm baseform="virtual private network (VPN)">
virtual private networks (VPNs)</glossterm>.</para>
<para>Networking provides the following object abstractions: networks,
subnets, and routers. Each has functionality that mimics its
physical counterpart: networks contain subnets, and routers route
traffic between different subnet and networks.</para>
<para>Any given Neutron set up has at least one external network.
<para>Any given Networking set up has at least one external network.
This network, unlike the other networks, is not merely a virtually
defined network. Instead, it represents the view into a slice of
the external network that is accessible outside the OpenStack
installation. IP addresses on the Neutron external network are
installation. IP addresses on the Networking external network are
accessible by anybody physically on the outside network. Because
this network merely represents a slice of the outside network,
DHCP is disabled on this network.</para>
<para>In addition to external networks, any Neutron set up has one
<para>In addition to external networks, any Networking set up has one
or more internal networks. These software-defined networks connect
directly to the VMs. Only the VMs on any given internal network,
or those on subnets connected through interfaces to a similar
@ -39,70 +44,16 @@
connected to a subnet, that connection is called a port. You can
associate external network IP addresses with ports to VMs. This
way, entities on the outside network can access VMs.</para>
<para>Neutron also supports <emphasis role="italic">security
<para>Networking also supports <emphasis role="italic">security
groups</emphasis>. Security groups enable administrators to
define firewall rules in groups. A VM can belong to one or more
security groups, and Neutron applies the rules in those security
security groups, and Networking applies the rules in those security
groups to block or unblock ports, port ranges, or traffic types
for that VM.</para>
<para>Each plug-in that Neutron uses has its own concepts. While not
vital to operating Neutron, understanding these concepts can help
you set up Neutron. All Neutron installations use a core plug-in
<para>Each plug-in that Networking uses has its own concepts. While not
vital to operating Networking, understanding these concepts can help
you set up Networking. All Networking installations use a core plug-in
and a security group plug-in (or just the No-Op security group
plug-in). Additionally, Firewall-as-a-service (FWaaS) and
Load-balancing-as-a-service (LBaaS) plug-ins are available.</para>
<section xml:id="concepts-neutron.openvswitch">
<title>Open vSwitch concepts</title>
<para>The Open vSwitch plug-in is one of the most popular core
plug-ins. Open vSwitch configurations consists of bridges and
ports. Ports represent connections to other things, such as
physical interfaces and patch cables. Packets from any given
port on a bridge are shared with all other ports on that bridge.
Bridges can be connected through Open vSwitch virtual patch
cables or through Linux virtual Ethernet cables
(<literal>veth</literal>). Additionally, bridges appear as
network interfaces to Linux, so you can assign IP addresses to
them.</para>
<para>In Neutron, the integration bridge, called
<literal>br-int</literal>, connects directly to the VMs and
associated services. The external bridge, called
<literal>br-ex</literal>, connects to the external network.
Finally, the VLAN configuration of the Open vSwitch plug-in uses
bridges associated with each physical network.</para>
<para>In addition to defining bridges, Open vSwitch has OpenFlow,
which enables you to define networking flow rules. Certain
configurations use these rules to transfer packets between
VLANs.</para>
<para>Finally, some configurations of Open vSwitch use network
namespaces that enable Linux to group adapters into unique
namespaces that are not visible to other namespaces, which
allows the same network node to manage multiple Neutron
routers.</para>
<para>With Open vSwitch, you can use two different technologies to
create the virtual networks: GRE or VLANs.</para>
<para>Generic Routing Encapsulation (GRE) is the technology used
in many VPNs. It wraps IP packets to create entirely new packets
with different routing information. When the new packet reaches
its destination, it is unwrapped, and the underlying packet is
routed. To use GRE with Open vSwitch, Neutron creates GRE
tunnels. These tunnels are ports on a bridge and enable bridges
on different systems to act as though they were one bridge,
which allows the compute and network nodes to act as one for the
purposes of routing.</para>
<para>Virtual LANs (VLANs), on the other hand, use a special
modification to the Ethernet header. They add a 4-byte VLAN tag
that ranges from 1 to 4094 (the 0 tag is special, and the 4095
tag, made of all ones, is equivalent to an untagged packet).
Special NICs, switches, and routers know how to interpret the
VLAN tags, as does Open vSwitch. Packets tagged for one VLAN are
only shared with other devices configured to be on that VLAN,
even though all devices are on the same physical
network.</para>
<para>The most common security group driver used with Open vSwitch
is the Hybrid IPTables/Open vSwitch plug-in. It uses a
combination for IPTables and OpenFlow rules. Use the IPTables
tool to create firewalls and set up NATs on Linux. This tool
uses a complex rule system and chains of rules to accommodate
the complex rules required by Neutron security groups.</para>
</section>
</section>

View File

@ -8,8 +8,8 @@
<title>Configure compute node</title>
<procedure>
<title>Prerequisites</title>
<para>Before you configure Networking, you must enable certain kernel
networking functions.</para>
<para>Before you configure OpenStack Networking, you must enable certain
kernel networking functions.</para>
<step>
<para>Edit <filename>/etc/sysctl.conf</filename> to contain the
following:</para>
@ -284,7 +284,7 @@ enable_security_group = True</programlisting>
<title>To configure Compute to use Networking</title>
<para>By default, most distributions configure Compute to use legacy
networking. You must reconfigure Compute to manage networks through
OpenStack Networking.</para>
Networking.</para>
<step os="rhel;centos;fedora;sles;opensuse">
<para>Run the following commands:</para>
<para>Replace <replaceable>NEUTRON_PASS</replaceable> with the

View File

@ -8,8 +8,8 @@
<title>Configure controller node</title>
<procedure os="ubuntu;rhel;centos;fedora;sles;opensuse">
<title>Prerequisites</title>
<para>Before you configure Networking, you must create a
database and Identity service credentials including a user and
<para>Before you configure OpenStack Networking (neutron), you must create
a database and Identity service credentials including a user and
service.</para>
<step>
<para>Connect to the database as the root user, create the
@ -340,7 +340,7 @@ enable_security_group = True</programlisting>
<title>To configure Compute to use Networking</title>
<para>By default, most distributions configure Compute to use legacy
networking. You must reconfigure Compute to manage networks through
OpenStack Networking.</para>
Networking.</para>
<step os="rhel;centos;fedora;sles;opensuse">
<para>Run the following commands:</para>
<para>Replace <replaceable>NEUTRON_PASS</replaceable> with the

View File

@ -8,8 +8,8 @@
<title>Configure network node</title>
<procedure>
<title>Prerequisites</title>
<para>Before you configure Networking, you must enable certain kernel
networking functions.</para>
<para>Before you configure OpenStack Networking, you must enable certain
kernel networking functions.</para>
<step>
<para>Edit <filename>/etc/sysctl.conf</filename> to contain the
following:</para>

View File

@ -34,7 +34,7 @@
<xref linkend="basics-neutron-networking-compute-node"/>
</para>
<para>
If you run legacy networking (nova-compute), do not
If you run legacy networking (nova-network), do not
configure <literal>eth1</literal> with a static IP
address. The networking component of OpenStack assigns
and configures an IP address. For details, see the
@ -76,7 +76,7 @@
<note os="debian">
<para>To use the meta-packages and install other components on
your compute node, such as OVS Networking and Ceilometer
your compute node, such as OpenStack Networking and Ceilometer
agents, run this command:</para>
<screen><prompt>#</prompt> <userinput>apt-get install openstack-compute-node</userinput></screen>
<para>The controller node has the