openstack/openstack-manuals
Code Issues Proposed changes

Merge "Edited ch_massively_scalable.xml"

Browse Source
This commit is contained in:
Jenkins 2015-08-14 05:30:37 +00:00 committed by Gerrit Code Review
commit 90f73d08b6
4 changed files with 50 additions and 91 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
doc/arch-design/ch_massively_scalable.xml
View File

@ -10,13 +10,13 @@
implementation that is either a very large deployment, such as
a commercial service provider might build, or
one that has the capability to support user requests for large
amounts of cloud resources. An example is an
infrastructure in which requests to service 500 or more instances
at a time is common. A massively scalable infrastructure
fulfills such a request without exhausting the available
cloud infrastructure resources. While the high capital cost
of implementing such a cloud architecture means that it is
currently in limited use, many organizations are planning
amounts of cloud resources.</para>
<para>An example is an infrastructure in which requests to service
500 or more instances at a time is common. A massively scalable
infrastructure fulfills such a request without exhausting the
available cloud infrastructure resources. While the high capital
cost of implementing such a cloud architecture means that it
is currently in limited use, many organizations are planning
for massive scalability in the future.</para>
<para>A massively scalable OpenStack cloud design presents a
unique set of challenges and considerations. For the most part
@ -24,11 +24,11 @@
is built to address a non-specific range of potential use
cases or functions. Typically, it is rare that particular
workloads determine the design or configuration of massively
scalable clouds. Like the general purpose cloud, the massively
scalable cloud is most often built as a platform for a variety
of workloads. Because private organizations rarely require
or have the resources for them, massively scalable OpenStack clouds
are generally built as commercial, public cloud offerings.</para>
scalable clouds. The massively scalable cloud is most often
built as a platform for a variety of workloads. Because private
organizations rarely require or have the resources for them,
massively scalable OpenStack clouds are generally built as
commercial, public cloud offerings.</para>
<para>Services provided by a massively scalable OpenStack cloud
include:</para>
<itemizedlist>

10
doc/arch-design/massively_scalable/section_operational_considerations_massively_scalable.xml
View File

@ -14,8 +14,8 @@
human intervention is required and who should act. The
objective is to increase the ratio of operational staff to
running systems as much as possible in order to reduce maintenance
costs. In a massively scaled environment, it is impossible for
staff to give each system individual care.</para>
costs. In a massively scaled environment, it is very difficult
for staff to give each system individual care.</para>
<para>Configuration management tools such as Puppet and Chef enable
operations staff to categorize systems into groups based on
their roles and thus create configurations and system states
@ -27,14 +27,14 @@
systems is far greater than the cost of
replacement. It is more economical to replace the failed
system with a new system, provisioning and configuring it
automatically then quickly adding it to the
pool of active nodes. By automating tasks that are labor-intensive,
automatically and adding it to the pool of active nodes.
By automating tasks that are labor-intensive,
repetitive, and critical to operations, cloud operations
teams can work more
efficiently because fewer resources are required for these
common tasks. Administrators are then free to tackle
tasks that are not easy to automate and that have longer-term
impacts on the business, for example capacity planning.</para>
impacts on the business, for example, capacity planning.</para>
<section xml:id="the-bleeding-edge">
<title>The bleeding edge</title>
<para>Running OpenStack at massive scale requires striking a

10
doc/arch-design/massively_scalable/section_tech_considerations_massively_scalable.xml
View File

@ -36,14 +36,14 @@
environments. In the quest for massive scale, however, you must
take additional steps to relieve the performance
pressure on these components in order to prevent them from negatively
impacting the overall performance of the environment. Ensure
that all the components are in balance so that if the massively
impacting the overall performance of the environment. Ensure that
all the components are in balance so that if the massively
scalable environment fails, all the components are near maximum
capacity.</para>
capacity and a single component is not causing the failure.</para>
<para>Regions segregate completely independent
installations linked only by an Identity and Dashboard
(optional) installation. Services have separate
API endpoints for each region, an include separate database
API endpoints for each region, and include separate database
and queue installations. This exposes some awareness of the
environment's fault domains to users and gives them the
ability to ensure some degree of application resiliency while
@ -111,7 +111,7 @@
connections. Users can target exposed availability zones; however,
this is not a requirement. An alternative approach is to set a default
availability zone to schedule instances to a non-default availability
zone of nova.</para></section>
zone of <literal>nova</literal>.</para></section>
<section xml:id="segregation-example">
<title>Segregation example</title>
<para>In this example the cloud is divided into two regions, one

97
doc/arch-design/massively_scalable/section_user_requirements_massively_scalable.xml
View File

@ -6,50 +6,13 @@
xml:id="user-requirements-massive-scale-overview">
<?dbhtml stop-chunking?>
<title>User requirements</title>
<para>More so than other scenarios, defining user requirements for
a massively scalable OpenStack design architecture dictates
approaching the design from two different, yet sometimes
opposing, perspectives: the cloud user, and the cloud
operator. The expectations and perceptions of the consumption
and management of resources of a massively scalable OpenStack
cloud from the user point of view is distinctly different from
that of the cloud operator.</para>
<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 policies governing certain types of
information needs 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 xml:id="user-requirements-massive-scale">
<title>User requirements</title>
<para>Defining user requirements for a massively scalable OpenStack
design architecture dictates approaching the design from two
different, yet sometimes opposing, perspectives: the cloud
user, and the cloud operator. The expectations and perceptions
of the consumption and management of resources of a massively
scalable OpenStack cloud from these two perspectives are
distinctly different.</para>
<para>Massively scalable OpenStack clouds have the following user
requirements:</para>
<itemizedlist>
@ -76,20 +39,19 @@
security, performance, or availability. Users expect
only SLAs related to uptime of API services, and
very basic SLAs for services offered. It is the user's
responsibility to address
these issues on their own. The exception to this
expectation is the rare case of a massively scalable
cloud infrastructure built for a private or government
organization that has specific requirements.</para>
responsibility to address these issues on their own.
The exception to this expectation is the rare case of
a massively scalable cloud infrastructure built for
a private or government organization that has
specific requirements.</para>
</listitem>
</itemizedlist>
<para>The cloud user's requirements and expectations that determine
the cloud design focus on the
consumption model. The user expects to consume cloud resources
in an automated and deterministic way,
without any need for knowledge of the capacity, scalability,
or other attributes of the cloud's underlying
infrastructure.</para></section>
the cloud design focus on the consumption model. The user
expects to consume cloud resources in an automated and
deterministic way, without any need for knowledge of the
capacity, scalability, or other attributes of the cloud's
underlying infrastructure.</para>
<section xml:id="operator-requirements-massive-scale">
<title>Operator requirements</title>
<para>While the cloud user can be completely unaware of the
@ -99,14 +61,12 @@
for building such a cloud from the operator's perspective:</para>
<itemizedlist>
<listitem>
<para>First and foremost, everything must be capable of
automation. From the deployment of new hardware,
compute hardware, storage hardware, or networking
hardware, to the installation and configuration of the
supporting software, everything must be capable of
automation. Manual processes are impractical in
a massively scalable OpenStack design
architecture.</para>
<para>Everything must be capable of automation. For example,
everything from compute hardware, storage hardware,
networking hardware, to the installation and
configuration of the supporting software. Manual
processes are impractical in a massively scalable
OpenStack design architecture.</para>
</listitem>
<listitem>
<para>The cloud operator requires that capital expenditure
@ -120,8 +80,8 @@
xlink:href="http://www.opencompute.org">http://www.opencompute.org</link>)
provide additional information and pointers. To cut
costs, many operators sacrifice redundancy. For
example, redundant power supplies, redundant network
connections, and redundant rack switches.</para>
example, using redundant power supplies, network
connections, and rack switches.</para>
</listitem>
<listitem>
<para>Companies operating a massively scalable OpenStack
@ -155,8 +115,7 @@
over several sites. Therefore, the user-operator
requirements for a multi-site OpenStack architecture
design are also applicable here. This includes various
legal requirements for data storage, data placement,
and data retention; other jurisdictional legal or
legal requirements; other jurisdictional legal or
compliance requirements; image
consistency-availability; storage replication and
availability (both block and file/object storage); and
@ -168,8 +127,8 @@
<listitem>
<para>The design architecture of a massively scalable OpenStack
cloud must address considerations around physical
facilities such as space, floor weight, rack height and type,
environmental considerations, power usage and power
facilities such as space, floor weight, rack height and
type, environmental considerations, power usage and power
usage efficiency (PUE), and physical security.</para>
</listitem>
</itemizedlist></section>