openstack/openstack-manuals
Code Issues Proposed changes

Merge "Arch Design: Improve usage of project names"

Browse Source
This commit is contained in:
Jenkins 2014-07-31 21:13:56 +00:00 committed by Gerrit Code Review
commit 1d7370ce75
13 changed files with 50 additions and 51 deletions

30
doc/arch-design/compute_focus/section_architecture_compute_focus.xml

@ -671,7 +671,7 @@
example) yet there are other services
that might not need to be
present. For example, a certain
design may not require OpenStack Heat.
design may not require the Orchestration module.
Omitting Heat would not
typically have a significant impact on the
overall design.
@ -721,22 +721,18 @@
dictates that a
block storage component be used to improve data I-O.
</para>
<para>The exclusion of certain OpenStack components might also
limit or
constrain the functionality of other components. If a
design opts to
include Heat but exclude Ceilometer, then the
design will not be able
to take advantage of Heat's
auto scaling functionality (which relies
on information from
Ceilometer). Due to the fact that you can use Heat
to spin up
a large number of instances to perform the
compute-intensive
processing, including Heat in a compute-focused
architecture
design is strongly recommended.
<para>
The exclusion of certain OpenStack components might
also limit or constrain the functionality of other
components. If a design opts to include the
Orchestration module but exclude the Telemetry
module, then the design will not be able to take
advantage of Orchestration's auto scaling functionality
(which relies on information from Telemetry). Due
to the fact that you can use Orchestration to spin up a large
number of instances to perform the compute-intensive
processing, including Orchestration in a compute-focused
architecture design is strongly recommended.
</para>
</section>
<section xml:id="supplemental-software">

4
doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml

@ -120,11 +120,11 @@
<para>A small set of "golden" Scientific Linux 5 and 6 images are
maintained which applications can in turn be placed on using
orchestration tools. Puppet is used for instance configuration
management and customization but Heat deployment is
management and customization but Orchestration deployment is
expected.</para></section>
<section xml:id="monitoring">
<title>Monitoring</title>
<para>Although direct billing is not required, OpenStack Telemetry
<para>Although direct billing is not required, the Telemetry module
is used to perform metering for the purposes of adjusting
project quotas. A sharded, replicated, MongoDB back end is
used. To spread API load, instances of the nova-api service

16
doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml

@ -376,25 +376,25 @@
<para>Also consider several specialized components:</para>
<itemizedlist>
<listitem>
<para>OpenStack Orchestration Engine (Heat)</para>
<para>Orchestration module (heat)</para>
</listitem>
</itemizedlist>
<para>It is safe to assume that, given the nature of the
applications involved in this scenario, these will be heavily
automated deployments. Making use of Heat will be highly
automated deployments. Making use of Orchestration will be highly
beneficial in this case. Deploying a batch of instances and
running an automated set of tests can be scripted, however it
makes sense to use the OpenStack Orchestration Engine (Heat)
makes sense to use the Orchestration module
to handle all these actions.</para>
<itemizedlist>
<listitem>
<para>OpenStack Telemetry (Ceilometer)</para>
<para>Telemetry module (ceilometer)</para>
</listitem>
</itemizedlist>
<para>OpenStack Telemetry and the alarms it generates are required
to support autoscaling of instances using OpenStack
Orchestration. Users that are not using OpenStack
Orchestration do not need to deploy OpenStack Telemetry and
<para>Telemetry and the alarms it generates are required
to support autoscaling of instances using
Orchestration. Users that are not using the
Orchestration module do not need to deploy the Telemetry module and
may choose to use other external solutions to fulfill their
metering and monitoring requirements.</para>
<para>See also:

2
doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml

@ -87,7 +87,7 @@
Object Storage with network connections offering 10 GbE or
better connectivity.</para>
<para>There is also a potential to leverage the Orchestration and
Telemetry OpenStack modules to provide an auto-scaling,
Telemetry modules to provide an auto-scaling,
orchestrated web application environment. Defining the web
applications in Heat Orchestration Templates (HOT) would
negate the reliance on the scripted Puppet solution currently

7
doc/arch-design/hybrid/section_architecture_hybrid.xml

@ -78,13 +78,14 @@
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 Trove, supports MySQL as a
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 OpenStack Orchestration
(Heat).</para>
using a tool such as the Orchestration module
(heat).</para>
</listitem>
<listitem>
<para>Deploy a Platform-as-a-Service (PaaS) technology

2
doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml

@ -53,7 +53,7 @@
CMP.</para>
<para>The private cloud is an OpenStack cloud with one or more
controllers and one or more compute nodes. It includes
metering provided by OpenStack Telemetry. As load increases
metering provided by the Telemetry module. As load increases
Telemetry captures this and the information is in turn
processed by the CMP. As long as capacity is available, the
CMP uses the OpenStack API to call the Orchestration service

8
doc/arch-design/hybrid/section_tech_considerations_hybrid.xml

@ -232,7 +232,7 @@
analysis is heavily influenced by internal priorities. The
important thing is the ability to efficiently make those
decisions on a programmatic basis.</para>
<para>The OpenStack Telemetry (Ceilometer) project is designed to
<para>The Telemetry module (ceilometer) is designed to
provide information on the usage of various OpenStack
components. There are two limitations to consider: first, if
there is to be a large amount of data (for example, if
@ -258,7 +258,7 @@
which types of workloads.</para>
<para>As with utilization, native OpenStack tools are available to
assist. Ceilometer can measure performance and, if necessary,
OpenStack Orchestration via the Heat project can be used to
the Orchestration module can be used to
react to changes in demand by spinning up more resources. It
is important to note, however, that Orchestration requires
special configurations in the client to enable functioning
@ -293,12 +293,12 @@
in order to connect between clouds.</para>
</listitem>
<listitem>
<para>OpenStack Telemetry (Ceilometer): Use of Ceilometer
<para>Telemetry module (Ceilometer): Use of Telemetery
depends, in large part, on what the other parts of the
cloud are using.</para>
</listitem>
<listitem>
<para>Orchestration module (Heat): Similarly, Heat can
<para>Orchestration module (Heat): Similarly, Orchestration can
be a valuable tool in orchestrating tasks a CMP
decides are necessary in an OpenStack-based
cloud.</para>

7
doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml

@ -106,7 +106,8 @@
<para>OpenStack Controller services running, Networking,
Horizon, Cinder and Nova compute running locally in
each of the three regions. The other services,
Keystone, Heat Ceilometer, Glance and Swift will be
Identity, Orchestration, Telemetry, Image Service and
Block Storage will be
installed centrally - with nodes in each of the region
providing a redundant OpenStack Controller plane
throughout the globe.</para>
@ -159,11 +160,11 @@
the fear of having abnormal load on a single region in the
event of a failure. Two data center would have been sufficient
had the requirements been met.</para>
<para>Heat is used because of the built-in functionality of
<para>Orchestration is used because of the built-in functionality of
autoscaling and auto healing in the event of increased load.
Additional configuration management tools, such as Puppet or
Chef could also have been used in this scenario, but were not
chosen due to the fact that Heat had the appropriate built-in
chosen due to the fact that Orchestration had the appropriate built-in
hooks into the OpenStack cloud - whereas the other tools were
external and not native to OpenStack. In addition - since this
deployment scenario was relatively straight forward - the

2
doc/arch-design/multi_site/section_tech_considerations_multi_site.xml

@ -187,7 +187,7 @@
facilitates using DNS as a mechanism for determining which
region would be selected for certain applications.</para>
<para>Another useful tool for managing a multi-site installation
is Heat. Heat allows the use of templates to define a set of
is Orchestration. Heat allows the use of templates to define a set of
instances to be launched together or for scaling existing
sets. It can also be used to setup matching or differentiated
groupings based on regions. For instance, if an application

4
doc/arch-design/network_focus/section_architecture_network_focus.xml

@ -60,12 +60,12 @@
external router will be required to provide layer 3
connectivity to outside systems.</para>
<para>Interaction with orchestration services is inevitable in
larger-scale deployments. Heat is capable of allocating
larger-scale deployments. The Orchestration module is capable of allocating
network resource defined in templates to map to tenant
networks and for port creation, as well as allocating floating
IPs. If there is a requirement to define and manage network
resources in using orchestration, it is recommended that the
design include OpenStack Orchestration to meet the demands of
design include the Orchestration module to meet the demands of
users.</para>
<section xml:id="design-impacts">
<title>Design impacts</title>

4
doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml

@ -60,10 +60,10 @@
<para>OpenStack Object Storage</para>
</listitem>
<listitem>
<para>OpenStack Orchestration</para>
<para>Orchestration module</para>
</listitem>
<listitem>
<para>OpenStack Telemetry</para>
<para>Telemetry module</para>
</listitem>
</itemizedlist>
<para>Beyond the normal Keystone, Nova, Glance and Swift

6
doc/arch-design/storage_focus/section_architecture_storage_focus.xml

@ -515,13 +515,13 @@
components that will always be present, (Nova and Glance, for
example) there are other services that may not need to be
present. As an example, a certain design may not require
OpenStack Heat. Omitting Heat would not typically have a
the Orchestration module. Omitting Orchestration would not typically have a
significant impact on the overall design however, if the
architecture uses a replacement for OpenStack Swift for its
architecture uses a replacement for OpenStack Object Storage for its
storage component, this could potentially have significant
impacts on the rest of the design.</para>
<para>A storage-focused design might require the ability to use
Heat to launch instances with Cinder volumes to perform
Orchestration to launch instances with Cinder volumes to perform
storage-intensive processing.</para>
<para>For a storage-focused OpenStack design architecture, the
following components would typically be used:</para>

9
doc/arch-design/storage_focus/section_prescriptive_examples_storage_focus.xml

@ -62,7 +62,8 @@
implement a 3rd-party caching layer to achieve suitable
performance.</para></note>
<section xml:id="compute-analytics-with-sahara">
<title>Compute analytics with sahara</title>
<title>Compute analytics with Data processing service for
OpenStack</title>
<para>Analytics of large data sets can be highly dependent on the
performance of the storage system. Some clouds using storage
systems such as HDFS have inefficiencies which can cause
@ -73,8 +74,8 @@
for large scale performance-oriented systems.</para>
<para>This example discusses an OpenStack Object Store with a high
performance requirement. OpenStack has integration with Hadoop
through the Sahara project, which is leveraged to manage the
Hadoop cluster within the cloud.
through the Data processing project (sahara), which is leveraged
to manage the Hadoop cluster within the cloud.
<mediaobject>
<imageobject>
<imagedata contentwidth="4in"
@ -89,7 +90,7 @@
connecting a caching pool to allow for acceleration of the
presented pool.</para></section>
<section xml:id="high-performance-database-with-trove">
<title>High performance database with trove</title>
<title>High performance database with Database service for OpenStack</title>
<para>Databases are a common workload that can greatly benefit
from a high performance storage back end. Although enterprise
storage is not a requirement, many environments have existing