openstack/openstack-manuals
Code Issues Proposed changes

Removal of passive voice from chap 1, arch guide

Browse Source 
Removal of passive voice from section_prescriptive_examples,
and section_user_requirements

Change-Id: I5559946ec14fee7dc9fdbeae399d493ebd87e51b
Partial-bug: #1400550
This commit is contained in:
Alexandra Settle 2014-12-15 09:40:18 +10:00
parent 502901f11e
commit 88c00d3611
2 changed files with 76 additions and 87 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

68
doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml
View File

@ -7,13 +7,12 @@
<?dbhtml stop-chunking?>
<title>Prescriptive example</title>
<para>An online classified advertising company wants to run web applications
consisting of Tomcat, Nginx and MariaDB in a private cloud. In order to
meet policy requirements, the cloud infrastructure will run in their own
data center. They have predictable load requirements but require an
element of scaling to cope with nightly increases in demand. Their
current environment is not flexible enough to align with their goal of
running an open source API driven environment. Their current environment
consists of the following:</para>
consisting of Tomcat, Nginx and MariaDB in a private cloud. To be able
to meet policy requirements, the cloud infrastructure will run in their
own data center. The company has predictable load requirements, but requires
scaling to cope with nightly increases in demand. Their current environment
does not have the flexibility to align with their goal of running an open
source API environment. The current environment consists of the following:</para>
<itemizedlist>
<listitem>
<para>Between 120 and 140 installations of Nginx and
@ -25,10 +24,9 @@
</listitem>
</itemizedlist>
<para>The company runs hardware load balancers and multiple web
applications serving the sites. The company orchestrates their
environment using a combination of scripts and Puppet. The
websites generate a large amount of log data each day that
needs to be archived.</para>
applications serving their websites, and orchestrates environments
using combinations of scripts and Puppet. The website generates large amounts of
log data daily that requires archiving.</para>
<para>The solution would consist of the following OpenStack
components:</para>
<itemizedlist>
@ -37,24 +35,23 @@
public facing network connections.</para>
</listitem>
<listitem>
<para>OpenStack Controller services running Image,
Identity, Networking and supporting services such as
MariaDB and RabbitMQ. The controllers will run in a
highly available configuration on at least three
controller nodes.</para>
<para>OpenStack Controller service running Image,
Identity, Networking, combined with support services such as
MariaDB and RabbitMQ, configured for high availability on at
least three controller nodes.</para>
</listitem>
<listitem>
<para>OpenStack Compute nodes running the KVM
hypervisor.</para>
</listitem>
<listitem>
<para>OpenStack Block Storage for use by compute instances
that require persistent storage such as databases for
dynamic sites.</para>
<para>OpenStack Block Storage for use by compute instances,
requiring persistent storage (such as databases for
dynamic sites).</para>
</listitem>
<listitem>
<para>OpenStack Object Storage for serving static objects
such as images.</para>
(such as images).</para>
</listitem>
</itemizedlist>
<mediaobject><imageobject><imagedata contentwidth="4in"
@ -76,27 +73,28 @@
re-attached to another instance and rejoined to the Galera
cluster.</para>
<para>Logs from the web application servers are shipped to
OpenStack Object Storage for later processing and
OpenStack Object Storage for processing and
archiving.</para>
<para>In this scenario, additional capabilities can be realized by
<para>Additional capabilities can be realized by
moving static web content to be served from OpenStack Object
Storage containers, and backing the OpenStack Image Service
with OpenStack Object Storage. Note that an increase in
OpenStack Object Storage means that network bandwidth needs to
be taken in to consideration. It is best to run OpenStack
Object Storage with network connections offering 10 GbE or
better connectivity.</para>
<para>There is also a potential to leverage the Orchestration and
Telemetry modules to provide an auto-scaling,
orchestrated web application environment. Defining the web
applications in <glossterm
with OpenStack Object Storage.</para>
<note>
<para>
Increasing OpenStack Object Storage means network bandwidth
needs to be taken into consideration. Running OpenStack Object
Storage with network connections offering 10 GbE or better connectivity
is advised.
</para>
</note>
<para>Leveraging Orchestration and Telemetry modules is also a potential issue when
providing auto-scaling, orchestrated web application environments.
Defining the web applications in <glossterm
baseform="Heat Orchestration Template (HOT)">Heat Orchestration Templates (HOT)</glossterm>
would
negate the reliance on the scripted Puppet solution currently
employed.</para>
negates the reliance on the current scripted Puppet solution.</para>
<para>OpenStack Networking can be used to control hardware load
balancers through the use of plug-ins and the Networking API.
This would allow a user to control hardware load balance pools
This allows users to control hardware load balance pools
and instances as members in these pools, but their use in
production environments must be carefully weighed against
current stability.</para>

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

@ -6,32 +6,30 @@
xml:id="user-requirements-general-purpose">
<?dbhtml stop-chunking?>
<title>User requirements</title>
<para>The general purpose cloud is built following the
<para>When building a general purpose cloud, you should follow the
<glossterm baseform="IaaS">Infrastructure-as-a-Service (IaaS)</glossterm>
model; as a platform best
suited for use cases with simple requirements. The general
purpose cloud user requirements themselves are typically not
complex. However, it is still important to capture them even
if the project has minimum business and technical requirements
such as a proof of concept (PoC) or a small lab
platform.</para>
<para>These user considerations are written from the perspective
of the organization that is building the cloud, not from the
perspective of the end-users who will consume cloud services
provided by this design.
</para>
model; a platform best suited for use cases with simple requirements.
General purpose cloud user requirements are not complex.
However, it is important to capture them even
if the project has minimum business and technical requirements, such as a
proof of concept (PoC), or a small lab platform.</para>
<note>
<para>
The following user considerations are written from the perspective of
the cloud builder, not from the perspective of the end user.
</para>
</note>
<variablelist>
<varlistentry>
<term>Cost</term>
<listitem>
<para>Financial factors are a primary concern for
any organization. Since general purpose clouds are
considered the baseline from which all other cloud
architecture environments derive, cost will commonly
be an important criteria. This type of cloud, however,
does not always provide the most cost-effective
environment for a specialized application or
situation. Unless razor-thin margins and costs have
any organization. Cost is an important criterion
as general purpose clouds are considered the baseline
from which all other cloud architecture environments
derive. General purpose cloud do not always provide
the most cost-effective environment for specialized
applications or situations. Unless razor-thin margins and costs have
been mandated as a critical factor, cost should not be
the sole consideration when choosing or designing a
general purpose architecture.</para>
@ -40,40 +38,31 @@
<varlistentry>
<term>Time to market</term>
<listitem>
<para>Another common business factor in
building a general purpose cloud is the ability to
deliver a service or product more quickly and
flexibly. In the modern hyper-fast business world,
being able to deliver a product in six months instead
of two years is often a major driving force behind the
decision to build a general purpose cloud. General
<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
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
access to compute, network, and storage resources
on-demand thus decreasing time to market. It may
potentially make more sense to build a general purpose
PoC as opposed to waiting to finalize the ultimate use
case for the system. The tradeoff with taking this
approach is the risk that the general purpose cloud is
not optimized for the actual final workloads. The
final decision on which approach to take will be
dependent on the specifics of the business objectives
and time frame for the project.</para>
on-demand thus decreasing time to market.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Revenue opportunity</term>
<listitem>
<para>The revenue opportunity for a
given cloud will vary greatly based on the intended
<para>Revenue opportunities for a
cloud will vary greatly based on the intended
use case of that particular cloud. Some general
purpose clouds are built for commercial customer
facing products, but there are plenty of other reasons
facing products, but there are alternatives
that might make the general purpose cloud the right
choice. A small cloud service provider (CSP) might
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
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
@ -106,8 +95,8 @@
</listitem>
<listitem>
<para>Data compliance policies governing certain types of
information need to reside in certain locations due to
regular issues - and more important cannot reside in
information needing to reside in certain locations due to
regular issues - and more importantly, cannot reside in
other locations for the same reason.</para>
</listitem>
</itemizedlist>
@ -170,7 +159,7 @@
<para>For a company interested in building a
commercial public cloud offering based on OpenStack,
the general purpose architecture model might be the
best choice because the designers are not going to
best choice. Designers are not always going to
know the purposes or workloads for which the end users
will use the cloud.</para>
</listitem>
@ -178,18 +167,20 @@
<varlistentry>
<term>Internal consumption (private) cloud</term>
<listitem>
<para>Organizations
need to determine if it makes the most sense to create
their own clouds internally. The main advantage of a
private cloud is that it allows the organization to
maintain complete control over all the architecture
and the cloud components. One caution is to think
about the possibility that users will want to combine
<para>Organizations need to determine if it is logical to
create their own clouds internally. Using private cloud,
organizations are able to maintain complete control over
the architectural and cloud components.</para>
<note>
<para>Users will want to combine
using the internal cloud with access to an external
cloud. If that case is likely, it might be worth
exploring the possibility of taking a multi-cloud
approach with regard to at least some of the
architectural elements. Designs that incorporate the
architectural elements.
</para>
</note>
<para>Designs that incorporate the
use of multiple clouds, such as a private cloud and a
public cloud offering, are described in the
"Multi-Cloud" scenario, see <xref linkend="multi_site"/>.