openstack/openstack-manuals
Code Issues Proposed changes

Add glossary entries for Arch Design

Browse Source 
Add new entries: north-south traffic, east-west traffic and TripleO.

Add entries for these terms to the Arch Design Guide. Use consistent
spelling for these entries.
Include some edits for improved wording.

Change-Id: Ic241664a44c0e41e3961206b626eef2acb0c5b31
This commit is contained in:
Andreas Jaeger
2014-08-13 20:44:32 +02:00
parent a65403c009
commit 589069caff
4 changed files with 103 additions and 46 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
doc/arch-design/hybrid/section_architecture_hybrid.xml
View File

@@ -81,15 +81,15 @@
implemented across all of the cloud platforms. For
platforms that do not support a given service, create
a service on top of that platform and apply it to the
workloads as they are launched on that cloud. For
example, OpenStack, via the Database service for OpenStack
(trove), supports MySQL as a
service but not NoSQL databases in production. To move
from or to run alongside on AWS a NoSQL workload would
require recreating the NoSQL database on top of
OpenStack and automate the process of implementing it
using a tool such as the Orchestration module
(heat).</para>
workloads as they are launched on that cloud.
For example, through the <glossterm>Database Service</glossterm>
for OpenStack (<glossterm>trove</glossterm>),
OpenStack supports MySQL as a service but not NoSQL
databases in production. To either move from or run
alongside AWS, a NoSQL workload must use an automation
tool, such as the Orchestration module (heat), to
recreate the NoSQL database on top of OpenStack.
</para>
</listitem>
<listitem>
<para>Deploy a <glossterm>Platform-as-a-Service (PaaS)</glossterm>

82
doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml
View File

@@ -145,34 +145,50 @@
queuing algorithms.</para></section>
<section xml:id="cloud-storage">
<title>Cloud storage</title>
<para>Another common use case for OpenStack environments is to
provide a cloud based file storage and sharing service. While
this may initially be considered to be a storage focused use
case there are also major requirements on the network side
that place it in the realm of requiring a network focused
architecture. An example for this application is cloud
backup.</para>
<para>There are two specific behaviors of this workload that have
major and different impacts on the network. Since this is both
an externally facing service and internally replicating
application there are both North-South and East-West traffic
considerations.</para>
<para>North-South traffic is primarily user facing. This means
that when a user uploads content for storage it will be coming
into the OpenStack installation. Users who download this
content will be drawing traffic from the OpenStack
installation. Since the service is intended primarily as a
backup the majority of the traffic will be southbound into the
environment. In this case it is beneficial to configure a
network to be asymmetric downstream as the traffic entering
the OpenStack installation will be greater than traffic
leaving.</para>
<para>East-West traffic is likely to be fully symmetric. Since
replication will originate from any node and may target
multiple other nodes algorithmically, it is less likely for
this traffic to have a larger volume in any specific
direction. However this traffic may interfere with north-south
traffic.</para>
<para>
Another common use case for OpenStack environments is to provide
a cloud-based file storage and sharing service. You might
consider this a storage-focused use case, but its network-side
requirements make it a network-focused use case.</para>
<para>
For example, consider a cloud backup application. This workload
has two specific behaviors that impact the network. Because this
workload is an externally-facing service and an
internally-replicating application, it has both <glossterm
baseform="north-south traffic">north-south</glossterm> and
<glossterm>east-west traffic</glossterm>
considerations, as follows:
</para>
<variablelist>
<varlistentry>
<term>north-south traffic</term>
<listitem>
<para>
When a user uploads and stores content, that content moves
into the OpenStack installation. When users download this
content, the content moves from the OpenStack
installation. Because this service is intended primarily
as a backup, most of the traffic moves southbound into the
environment. In this situation, it benefits you to
configure a network to be asymmetrically downstream
because the traffic that enters the OpenStack installation
is greater than the traffic that leaves the installation.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>east-west traffic</term>
<listitem>
<para>
Likely to be fully symmetric. Because replication
originates from any node and might target multiple other
nodes algorithmically, it is less likely for this traffic
to have a larger volume in any specific direction. However
this traffic might interfere with north-south traffic.
</para>
</listitem>
</varlistentry>
</variablelist>
<mediaobject>
<imageobject>
<imagedata contentwidth="4in"
@@ -180,11 +196,11 @@
/>
</imageobject>
</mediaobject>
<para>This application will prioritize the North-South traffic
over East-West traffic as it is the customer-facing data. QoS
is implemented on East-West traffic to be a lower priority
Class Selector, while North-South traffic requires a higher
level in the priority queue because of this.</para>
<para>
This application prioritizes the north-south traffic over
east-west traffic: the north-south traffic involves
customer-facing data.
</para>
<para>The network design in this case is less dependant on
availability and more dependant on being able to handle high
bandwidth. As a direct result, it is beneficial to forego

8
doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml
View File

@@ -49,10 +49,10 @@
management system. Once the Heat template is created,
deploying additional stacks will be a trivial thing and can be
performed in an automated fashion.</para>
<para>The OpenStack-On-OpenStack project (TripleO) is addressing
this issue&mdash;although at the current time the project does
not provide comprehensive coverage for the nested stacks. More
information can be found at <link
<para>The OpenStack-on-OpenStack project (<glossterm>TripleO</glossterm>)
addresses this issue&mdash;currently, however, the project does
not completely cover nested stacks. For more information, see
<link
xlink:href="https://wiki.openstack.org/wiki/TripleO">
https://wiki.openstack.org/wiki/TripleO</link>.
</para>

41
doc/glossary/glossary-terms.xml
View File

@@ -2730,6 +2730,19 @@
<glossdiv>
<title>E</title>
<glossentry>
<glossterm>east-west traffic</glossterm>
<indexterm class="singular">
<primary>east-west traffic</primary>
</indexterm>
<glossdef>
<para>
Network traffic between servers in the same cloud or data center.
See also north-south traffic.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>EBS boot volume</glossterm>
<indexterm class="singular">
@@ -5496,6 +5509,20 @@
</glossdef>
</glossentry>
<glossentry>
<glossterm>north-south traffic</glossterm>
<indexterm class="singular">
<primary>north-south traffic</primary>
</indexterm>
<glossdef>
<para>
Network traffic between a user or client (north) and a
server (south), or traffic into the cloud (south) and
out of the cloud (north). See also east-west traffic.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>nova</glossterm>
@@ -8054,6 +8081,20 @@
</glossdef>
</glossentry>
<glossentry>
<glossterm>TripleO</glossterm>
<indexterm class="singular">
<primary>TripleO</primary>
</indexterm>
<glossdef>
<para>
OpenStack-on-OpenStack program. The code name for the
OpenStack Deployment program.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>trove</glossterm>
<indexterm class="singular">