Edits to ch_compute.xml
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
parent
4ea6f57651
commit
7bfa107ac1
@ -37,7 +37,6 @@
|
||||
persistent block storage.</para>
|
||||
</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_operational_considerations_compute_focus.xml"/>
|
||||
<xi:include href="compute_focus/section_architecture_compute_focus.xml"/>
|
||||
|
||||
@ -6,8 +6,8 @@
|
||||
xml:id="operational-considerations-compute-focus">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Operational considerations</title>
|
||||
<para>Operationally, there are a number of considerations that affect the
|
||||
design of compute-focused OpenStack clouds. Some examples include:</para>
|
||||
<para>There are a number of operational considerations that affect the
|
||||
design of compute-focused OpenStack clouds, including:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
@ -29,50 +29,18 @@
|
||||
ensure the availability of a service. When designing an OpenStack cloud,
|
||||
factoring in promises of availability implies a certain level of
|
||||
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">
|
||||
<title>Monitoring</title>
|
||||
<para>OpenStack clouds require appropriate monitoring platforms that
|
||||
help to catch and manage errors adequately. Consider leveraging any
|
||||
existing monitoring systems to see if they are able to
|
||||
effectively monitor an OpenStack environment. Specific meters that
|
||||
are critically important to capture include:</para>
|
||||
<para>OpenStack clouds require appropriate monitoring platforms
|
||||
to catch and manage errors.</para>
|
||||
<note>
|
||||
<para>We recommend leveraging existing monitoring systems
|
||||
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>
|
||||
<listitem>
|
||||
<para>Image disk utilization</para>
|
||||
@ -83,31 +51,12 @@
|
||||
</itemizedlist>
|
||||
</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">
|
||||
<title>Capacity planning</title>
|
||||
<para>Adding extra capacity to an OpenStack cloud is a
|
||||
horizontally scaling process.</para>
|
||||
<note>
|
||||
<para>Be mindful, however, of additional work to place the nodes into
|
||||
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
|
||||
<para>We recommend similar (or the same) CPUs
|
||||
when adding extra nodes to the environment. This reduces
|
||||
the chance of breaking live-migration features if they are
|
||||
present. Scaling out hypervisor hosts also has a direct effect
|
||||
on network and other data center resources. We recommend you
|
||||
@ -120,11 +69,13 @@
|
||||
capacity for running applications.</para>
|
||||
<para>Another option is to assess the average workloads and
|
||||
increase the number of instances that can run within the
|
||||
compute environment by adjusting the overcommit ratio. While
|
||||
only appropriate in some environments, it's important to
|
||||
remember that changing the CPU overcommit ratio can have a
|
||||
detrimental effect and cause a potential increase in a noisy
|
||||
neighbor. The added risk of increasing the overcommit ratio is that
|
||||
compute environment by adjusting the overcommit ratio.</para>
|
||||
<note>
|
||||
<para>It is important to remember that changing the CPU
|
||||
overcommit ratio can have a detrimental effect and cause
|
||||
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
|
||||
that you increase the CPU overcommit ratio in compute-focused
|
||||
OpenStack design architecture, as it can increase the potential
|
||||
|
||||
@ -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>
|
||||
Loading…
Reference in New Issue
Block a user