openstack/openstack-manuals
Code Issues Proposed changes

Edits to the general purpose arch guide section

Browse Source 
1. Removal of extra examples (prescriptive example
   section covers this content)
2. Grammar/spelling/general edits

Change-Id: I662231a295a2ebe18f93ccb9429f9f8e0a8f9a09
This commit is contained in:
asettle 2015-09-16 12:40:09 +10:00
parent d7123232d6
commit 1137be16ea
2 changed files with 18 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml
View File

@ -11,17 +11,17 @@
factors affect the design choices for a general purpose cloud,
and operations staff are often tasked with the maintenance of
cloud environments for larger installations.</para>
<para>Knowing when and where to implement redundancy and high
availability is directly affected by expectations set by the terms
of the Service Level Agreements (SLAs). SLAs are contractual
<para>Expectations set by the Service Level Agreements (SLAs) directly
affect knowing when and where you should implement redundancy and
high availability. SLAs are contractual
obligations that provide assurances for service availability.
They define the levels of availability that drive the technical
design, often with penalties for not meeting contractual obligations.</para>
<para>SLA terms that will affect the design include:</para>
<para>SLA terms that affect design include:</para>
<itemizedlist>
<listitem>
<para>API availability guarantees implying multiple
infrastructure services, and highly available
infrastructure services and highly available
load balancers.</para>
</listitem>
<listitem>
@ -30,10 +30,11 @@
power.</para>
</listitem>
<listitem>
<para>Network security policies requirements need to be
factored in to deployments.</para>
<para>Factor in networking security policy requirements
in to your deployments.</para>
</listitem>
</itemizedlist>
<section xml:id="support-and-maintainability-general-purpose">
<title>Support and maintainability</title>
<para>To be able to support and maintain an installation, OpenStack
@ -41,17 +42,16 @@
comprehend design architecture content. The operations and engineering
staff skill level, and level of separation, are dependent on size and
purpose of the installation. Large cloud service providers, or telecom
providers, are more likely to be managed by a specially trained, dedicated
operations organization. Smaller implementations are more likely to rely
providers, are more likely to be managed by specially trained, dedicated
operations organizations. Smaller implementations are more likely to rely
on support staff that need to take on combined engineering, design and
operations functions.</para>
<para>Maintaining OpenStack installations requires a
variety of technical skills. For example, if you are to incorporate features
into an architecture and design that reduce the operations burden,
it is advised to automate the operations functions. It may, however,
be beneficial to use third party management companies with special
expertise in managing OpenStack deployment.</para>
variety of technical skills. You may want to consider using a third-party
management company with special expertise in managing
OpenStack deployment.</para>
</section>
<section xml:id="monitoring-general-purpose">
<title>Monitoring</title>
<para>OpenStack clouds require appropriate monitoring platforms to
@ -93,16 +93,8 @@
<para>Resiliency of overall system and individual components are going
to be dictated by the requirements of the SLA, meaning designing
for high availability (HA) can have cost ramifications.</para>
<para>For example, if a compute host failed, this would be an operational
consideration; requiring the restoration of instances from a
snapshot or re-spawning an instance. The overall application design
is impacted, general purpose clouds should not need to provide
abilities to migrate instances from one host to another. Additional
considerations need to be made around supporting instance migration if
the expectation is that the application will be designed to tolerate
failure. Extra support services, including shared storage attached to
compute hosts, might need to be deployed in this example.</para>
</section>
<section xml:id="capacity-planning">
<title>Capacity planning</title>
<para>Capacity constraints for a general purpose cloud environment

17
doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml
View File

@ -40,8 +40,8 @@
<listitem>
<para>The ability to deliver services or products within
a flexible time frame is a common business factor
when building a general purpose cloud. In today's high-speed business world,
the ability to deliver a product in six months instead
when building a general purpose cloud.
Delivering a product in six months instead
of two years is a driving force behind the
decision to build general purpose clouds. General
purpose clouds allow users to self-provision and gain
@ -58,18 +58,7 @@
purpose clouds are built for commercial customer
facing products, but there are alternatives
that might make the general purpose cloud the right
choice. For example, a small cloud service provider (CSP) might
want to build a general purpose cloud rather than a
massively scalable cloud because they do not have the
deep financial resources needed, or because they do
not, or will not, know in advance the purposes for which
their customers are going to use the cloud. For some
users, the advantages cloud itself offers mean an
enhancement of revenue opportunity. For others, the
fact that a general purpose cloud provides only
baseline functionality will be a disincentive for use,
leading to a potential stagnation of potential revenue
opportunities.</para>
choice.</para>
</listitem>
</varlistentry>
</variablelist>