openstack/openstack-manuals
Code Issues Proposed changes

Merge "[arch-design] Convert massively scalable to RST"

Browse Source
This commit is contained in:
Jenkins 2015-11-12 14:18:12 +00:00 committed by Gerrit Code Review
commit b4f036ec34
2 changed files with 97 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
doc/arch-design-rst/source/massively-scalable.rst
View File

@ -2,6 +2,11 @@
Massively scalable
==================
.. toctree::
:maxdepth: 2
user-requirements-massively-scalable.rst
A massively scalable architecture is a cloud implementation
that is either a very large deployment, such as a commercial
service provider might build, or one that has the capability

92
doc/arch-design-rst/source/user-requirements-massively-scalable.rst Normal file
View File

@ -0,0 +1,92 @@
User requirements
~~~~~~~~~~~~~~~~~
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.
Massively scalable OpenStack clouds have the following user requirements:
* The cloud user expects repeatable, dependable, and deterministic processes
for launching and deploying cloud resources. You could deliver this through
a web-based interface or publicly available API endpoints. All appropriate
options for requesting cloud resources must be available through some type
of user interface, a command-line interface (CLI), or API endpoints.
* Cloud users expect a fully self-service and on-demand consumption model.
When an OpenStack cloud reaches the massively scalable size, expect
consumption as a service in each and every way.
* For a user of a massively scalable OpenStack public cloud, there are no
expectations for control over 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.
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.
Operator requirements
---------------------
While the cloud user can be completely unaware of the underlying
infrastructure of the cloud and its attributes, the operator must build and
support the infrastructure for operating at scale. This presents a very
demanding set of requirements for building such a cloud from the operator's
perspective:
* 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.
* The cloud operator requires that capital expenditure (CapEx) is minimized at
all layers of the stack. Operators of massively scalable OpenStack clouds
require the use of dependable commodity hardware and freely available open
source software components to reduce deployment costs and operational
expenses. Initiatives like OpenCompute (more information available at
http://www.opencompute.org) provide additional information and pointers. To
cut costs, many operators sacrifice redundancy. For example, using redundant
power supplies, network connections, and rack switches.
* Companies operating a massively scalable OpenStack cloud also require that
operational expenditures (OpEx) be minimized as much as possible. We
recommend using cloud-optimized hardware when managing operational overhead.
Some of the factors to consider include power, cooling, and the physical
design of the chassis. Through customization, it is possible to optimize the
hardware and systems for this type of workload because of the scale of these
implementations.
* Massively scalable OpenStack clouds require extensive metering and
monitoring functionality to maximize the operational efficiency by keeping
the operator informed about the status and state of the infrastructure. This
includes full scale metering of the hardware and software status. A
corresponding framework of logging and alerting is also required to store
and enable operations to act on the meters provided by the metering and
monitoring solutions. The cloud operator also needs a solution that uses the
data provided by the metering and monitoring solution to provide capacity
planning and capacity trending analysis.
* Invariably, massively scalable OpenStack clouds extend over several sites.
Therefore, the user-operator requirements for a multi-site OpenStack
architecture design are also applicable here. This includes various legal
requirements; other jurisdictional legal or compliance requirements; image
consistency-availability; storage replication and availability (both block
and file/object storage); and authentication, authorization, and auditing
(AAA). See Multi-site for more details on requirements and considerations
for multi-site OpenStack clouds.
.. TODO (MZ) Add a link to the sentence above (See Multi-site).
* 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 usage
efficiency (PUE), and physical security.