openstack/openstack-manuals
Code Issues Proposed changes

Edits to ch_compute.xml

Browse Source 
1. Removing the user_requirements file (unnecessary or duplicated
   content)
2. Edits to operational_considerations
3. Updating ch_compute_focus file

Change-Id: I32d10c507bd82008d4bda4c6f02b0fc3d02d31bf
Implements: blueprint arch-guide
This commit is contained in:
asettle 2015-08-13 15:09:51 +10:00
parent 4ea6f57651
commit 7bfa107ac1
3 changed files with 20 additions and 245 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
doc/arch-design/ch_compute_focus.xml
View File

@ -37,7 +37,6 @@
persistent block storage.</para> persistent block storage.</para>
</note> </note>
<xi:include href="compute_focus/section_user_requirements_compute_focus.xml"/>
<xi:include href="compute_focus/section_tech_considerations_compute_focus.xml"/> <xi:include href="compute_focus/section_tech_considerations_compute_focus.xml"/>
<xi:include href="compute_focus/section_operational_considerations_compute_focus.xml"/> <xi:include href="compute_focus/section_operational_considerations_compute_focus.xml"/>
<xi:include href="compute_focus/section_architecture_compute_focus.xml"/> <xi:include href="compute_focus/section_architecture_compute_focus.xml"/>

89
doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml
View File

@ -6,8 +6,8 @@
xml:id="operational-considerations-compute-focus"> xml:id="operational-considerations-compute-focus">
<?dbhtml stop-chunking?> <?dbhtml stop-chunking?>
<title>Operational considerations</title> <title>Operational considerations</title>
<para>Operationally, there are a number of considerations that affect the <para>There are a number of operational considerations that affect the
design of compute-focused OpenStack clouds. Some examples include:</para> design of compute-focused OpenStack clouds, including:</para>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para> <para>
@ -29,50 +29,18 @@
ensure the availability of a service. When designing an OpenStack cloud, ensure the availability of a service. When designing an OpenStack cloud,
factoring in promises of availability implies a certain level of factoring in promises of availability implies a certain level of
redundancy and resiliency.</para> redundancy and resiliency.</para>
<itemizedlist>
<listitem>
<para>Guarantees for API availability imply multiple infrastructure
services combined with appropriate, highly available load
balancers.</para>
</listitem>
<listitem>
<para>Network uptime guarantees affect the switch design and might
require redundant switching and power.</para>
</listitem>
<listitem>
<para>Factoring of network security policy requirements in to deployments.</para>
</listitem>
</itemizedlist>
<section xml:id="support-and-maintainability-compute-focus">
<title>Support and maintainability</title>
<para>OpenStack cloud management requires a certain level of
understanding and comprehension of design architecture. Specially trained,
dedicated operations organizations are more likely to manage larger
cloud service providers or telecom providers. Smaller implementations
are more inclined to rely on smaller support teams that need
to combine the engineering, design, and operation roles.</para>
<para>The maintenance of OpenStack installations requires a variety
of technical skills. To ease the operational burden, consider
incorporating features into the architecture and
design. Some examples include:</para>
<itemizedlist>
<listitem>
<para>Automating the operations functions</para>
</listitem>
<listitem>
<para>Utilizing a third party management company</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="montioring-compute-focus"> <section xml:id="montioring-compute-focus">
<title>Monitoring</title> <title>Monitoring</title>
<para>OpenStack clouds require appropriate monitoring platforms that <para>OpenStack clouds require appropriate monitoring platforms
help to catch and manage errors adequately. Consider leveraging any to catch and manage errors.</para>
existing monitoring systems to see if they are able to <note>
effectively monitor an OpenStack environment. Specific meters that <para>We recommend leveraging existing monitoring systems
are critically important to capture include:</para> to see if they are able to effectively monitor an
OpenStack environment.</para>
</note>
<para>Specific meters that are critically important to capture
include:</para>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para>Image disk utilization</para> <para>Image disk utilization</para>
@ -83,31 +51,12 @@
</itemizedlist> </itemizedlist>
</section> </section>
<section xml:id="expected-unexpected-server-downtime">
<title>Expected and unexpected server downtime</title>
<para>Unexpected server downtime is inevitable, and SLAs can
address how long it takes to recover from failure.
Recovery of a failed host means restoring instances from a snapshot, or
respawning that instance on another available host.</para>
<para>It is acceptable to design a compute-focused cloud
without the ability to migrate instances from one host to
another. The expectation is that the application
developer must handle failure within the application itself.
However, provisioning a compute-focused cloud
provides extra resilience. In this scenario, the
developer deploys extra support services.</para>
</section>
<section xml:id="capacity-planning-operational"> <section xml:id="capacity-planning-operational">
<title>Capacity planning</title> <title>Capacity planning</title>
<para>Adding extra capacity to an OpenStack cloud is a <para>Adding extra capacity to an OpenStack cloud is a
horizontally scaling process.</para> horizontally scaling process.</para>
<note> <para>We recommend similar (or the same) CPUs
<para>Be mindful, however, of additional work to place the nodes into when adding extra nodes to the environment. This reduces
appropriate Availability Zones and Host Aggregates.</para>
</note>
<para>We recommend the same or very similar CPUs
when adding extra nodes to the environment because they reduce
the chance of breaking live-migration features if they are the chance of breaking live-migration features if they are
present. Scaling out hypervisor hosts also has a direct effect present. Scaling out hypervisor hosts also has a direct effect
on network and other data center resources. We recommend you on network and other data center resources. We recommend you
@ -120,11 +69,13 @@
capacity for running applications.</para> capacity for running applications.</para>
<para>Another option is to assess the average workloads and <para>Another option is to assess the average workloads and
increase the number of instances that can run within the increase the number of instances that can run within the
compute environment by adjusting the overcommit ratio. While compute environment by adjusting the overcommit ratio.</para>
only appropriate in some environments, it's important to <note>
remember that changing the CPU overcommit ratio can have a <para>It is important to remember that changing the CPU
detrimental effect and cause a potential increase in a noisy overcommit ratio can have a detrimental effect and cause
neighbor. The added risk of increasing the overcommit ratio is that a potential increase in a noisy neighbor.</para>
</note>
<para>The added risk of increasing the overcommit ratio is that
more instances fail when a compute host fails. We do not recommend more instances fail when a compute host fails. We do not recommend
that you increase the CPU overcommit ratio in compute-focused that you increase the CPU overcommit ratio in compute-focused
OpenStack design architecture, as it can increase the potential OpenStack design architecture, as it can increase the potential

175
doc/arch-design/compute_focus/section_user_requirements_compute_focus.xml
View File

@ -1,175 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE section [
<!ENTITY % openstack SYSTEM "../../common/entities/openstack.ent">
%openstack;
]>
<section xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0"
xml:id="user-requirements-compute-focus">
<?dbhtml stop-chunking?>
<title>User requirements</title>
<para>High utilization of CPU, RAM, or both defines compute
intensive workloads. User requirements determine the performance
demands for the cloud.
</para>
<variablelist>
<varlistentry>
<term>Cost</term>
<listitem>
<para>Cost is not generally a primary concern for a
compute-focused cloud, however some organizations
might be concerned with cost avoidance. Repurposing
existing resources to tackle compute-intensive tasks
instead of acquiring additional resources may
offer cost reduction opportunities.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Time to market</term>
<listitem>
<para>Compute-focused clouds can deliver products more quickly,
for example by speeding up a company's software development
life cycle (SDLC) for building products and applications.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Revenue opportunity</term>
<listitem>
<para>Companies that want to build services or products that
rely on the power of compute resources benefit from a
compute-focused cloud. Examples include the analysis
of large data sets (via Hadoop or Cassandra) or
completing computational intensive tasks such as
rendering, scientific computation, or
simulations.</para>
</listitem>
</varlistentry>
</variablelist>
<section xml:id="legal-requirements-compute-focus">
<title>Legal requirements</title>
<para>Many jurisdictions have legislative and regulatory
requirements governing the storage and management of data in
cloud environments. Common areas of regulation include:</para>
<itemizedlist>
<listitem>
<para>Data retention policies ensuring storage of
persistent data and records management to meet data
archival requirements.</para>
</listitem>
<listitem>
<para>Data ownership policies governing the possession and
responsibility for data.</para>
</listitem>
<listitem>
<para>Data sovereignty policies governing the storage of
data in foreign countries or otherwise separate
jurisdictions.</para>
</listitem>
<listitem>
<para>Data compliance: certain types of information need
to reside in certain locations due to regular issues and,
more importantly, cannot reside in other locations
for the same reason.</para>
</listitem>
</itemizedlist>
<para>
Examples of such legal frameworks include the <link
xlink:href="http://ec.europa.eu/justice/data-protection/">data
protection framework</link> of the European Union and the
requirements of the <link
xlink:href="http://www.finra.org/Industry/Regulation/FINRARules/">Financial
Industry Regulatory Authority</link> in the United
States. Consult a local regulatory body for more
information.</para></section>
<section xml:id="technical-considerations-compute-focus-user">
<title>Technical considerations</title>
<para>The following are some technical requirements you must consider
in the architecture design:
</para>
<variablelist>
<varlistentry>
<term>Performance</term>
<listitem>
<para>If a primary technical concern is to deliver high performance
capability, then a compute-focused design is an
obvious choice because it is specifically designed to
host compute-intensive workloads.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Workload persistence</term>
<listitem>
<para>Workloads can be either
short-lived or long-running. Short-lived workloads
can include continuous integration and continuous
deployment (CI-CD) jobs, which create large numbers of
compute instances simultaneously to
perform a set of compute-intensive tasks. The environment then
copies the results or artifacts from each instance into
long-term storage before destroying the instance.
Long-running workloads, like a Hadoop or
high-performance computing (HPC) cluster, typically
ingest large data sets, perform the computational work
on those data sets, then push the results into long-term
storage. When the computational work finishes, the instances
remain idle until they receive another job. Environments
for long-running workloads are often larger and more complex,
but you can offset the cost of building them by keeping them
active between jobs. Another example of long-running
workloads is legacy applications that are
persistent over time.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Storage</term>
<listitem>
<para>Workloads targeted for a compute-focused
OpenStack cloud generally do not require any
persistent block storage, although some uses of
Hadoop with HDFS may require persistent
block storage. A shared filesystem or object store
maintains the initial data sets and serves as the
destination for saving the computational results. By
avoiding the input-output (IO) overhead, you can significantly
enhance workload performance. Depending on
the size of the data sets, it may be necessary to
scale the object store or shared file system to match
the storage demand.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>User interface</term>
<listitem>
<para>Like any other cloud architecture, a
compute-focused OpenStack cloud requires an on-demand
and self-service user interface. End users must be
able to provision computing power, storage, networks,
and software simply and flexibly. This includes
scaling the infrastructure up to a substantial level
without disrupting host operations.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Security</term>
<listitem>
<para>Security is highly dependent
on business requirements. For example, a
computationally intense drug discovery application
has much higher security requirements
than a cloud for processing market
data for a retailer. As a general rule, the security
recommendations and guidelines provided in the
OpenStack Security Guide are applicable.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="operational-considerations-compute-focus-user">
<title>Operational considerations</title>
<para>From an operational perspective, a compute intensive cloud
is similar to a general-purpose cloud. See the general-purpose
design section for more details on operational requirements.</para>
</section>
</section>