openstack/operations-guide
Code Issues Proposed changes

Address editor comments for Network Design chapter

Browse Source 
* Add definitions where needed
* Fixes table

Change-Id: If2a79c12ec2bc2f8c6553c8dcad5ef43e5180d4c
This commit is contained in:
Tom Fifield 2014-01-23 17:06:27 -05:00 committed by Andreas Jaeger
parent aab12198af
commit f0ae6e1741
1 changed files with 22 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
doc/openstack-ops/ch_arch_network_design.xml
View File

@ -30,14 +30,18 @@
<section xml:id="mgmt_network">
<title>Management Network</title>
<para>A management network, typically consisting of a separate
switch and separate NICs, is a recommended option. This
switch and separate NICs (Network Interface Cards), is a
recommended option. This
segregation prevents system administration and monitoring
system access from being disrupted by traffic generated by
the guests themselves.</para>
the guests.</para>
<para>Consider creating other private networks for
communication between internal components of OpenStack,
such as the Message Queue and OpenStack Compute. VLANs are
great for these scenarios.</para>
such as the Message Queue and OpenStack Compute. Using a
Virtual Local Area Network (VLAN)
works well for these scenarios because it provides
a method for creating multiple virtual networks on a
physical network.</para>
</section>
<section xml:id="public_addressing">
<title>Public Addressing Options</title>
@ -64,7 +68,8 @@
<section xml:id="ip_address_planning">
<title>IP Address Planning</title>
<para>An OpenStack installation can potentially have many
subnets, and different types of services in each. An IP
subnets (ranges of IP addresses), and different types of
services in each. An IP
address plan can assist with a shared understanding of
network partition purposes and scalability. Control
services can have public and private IP addresses, and as
@ -75,14 +80,14 @@
<informaltable rules="all">
<tbody>
<tr>
<td><para>subnet router</para></td>
<td><para><emphasis role="bold">subnet router</emphasis></para></td>
<td><para>Packets leaving the subnet go via this
address, which could be a dedicated router
or a nova-network service.</para></td>
</tr>
<tr>
<td><para>control services public
interfaces</para></td>
<td><para><emphasis role="bold">control services public
interfaces</emphasis></para></td>
<td><para>Public access to
<code>swift-proxy</code>,
<code>nova-api</code>,
@ -92,29 +97,29 @@
at individual machines.</para></td>
</tr>
<tr>
<td><para>Object Storage cluster internal
communications</para></td>
<td><para><emphasis role="bold">Object Storage cluster internal
communications</emphasis></para></td>
<td><para>Traffic amongst object/account/container
servers and between these and the proxy
server's internal interface uses this
private network.</para></td>
</tr>
<tr>
<td><para>compute and storage
communications</para></td>
<td><para><emphasis role="bold">compute and storage
communications</emphasis></para></td>
<td><para>If ephemeral or block storage is
external to the compute node, this network
is used.</para></td>
</tr>
<tr>
<td><para>out-of-band remote
management</para></td>
<td><para><emphasis role="bold">out-of-band remote
management</emphasis></para></td>
<td><para>If a dedicated remote access controller
chip is included in servers, often these
are on a separate network.</para></td>
</tr>
<tr>
<td><para>in-band remote management</para></td>
<td><para><emphasis role="bold">in-band remote management</emphasis></para></td>
<td><para>Often, an extra (such as, 1 GB)
interface on compute or storage nodes is
used for system administrators or
@ -123,8 +128,8 @@
interface.</para></td>
</tr>
<tr>
<td><para>spare space for future
growth</para></td>
<td><para><emphasis role="bold">spare space for future
growth</emphasis></para></td>
<td><para>Adding more public-facing control
services, or guest instance IPs should
always be part of your plan.</para></td>