Merge "Arch Design: Improve usage of project names"
This commit is contained in:
commit
1d7370ce75
@ -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">
|
||||
|
@ -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
|
||||
|
@ -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:
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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>
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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>
|
||||
|
@ -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
|
||||
|
@ -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>
|
||||
|
@ -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
|
||||
|
Loading…
x
Reference in New Issue
Block a user