openstack/openstack-manuals
Code Issues Proposed changes

Arch Design: Move introductory sections up

Browse Source 
Move the introductory sections one level up, removing the separate
section for them. This reads much nicer in HTML now.
There's also no need to name the first paragraphs of a chapter
"Introduction", this is implied.

Change-Id: Ife4275807561dae2ca57dc71b7602240efa94663
This commit is contained in:
Andreas Jaeger 2014-08-01 06:14:57 +02:00
parent d38917d673
commit bfe149fcd2
18 changed files with 510 additions and 584 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
doc/arch-design/ch_compute_focus.xml
View File

@ -6,7 +6,42 @@
xml:id="compute_focus"> xml:id="compute_focus">
<title>Compute focused</title> <title>Compute focused</title>
<xi:include href="compute_focus/section_introduction_compute_focus.xml"/> <para>A compute-focused cloud is a specialized subset of the general purpose
OpenStack cloud architecture. Unlike the general purpose OpenStack
architecture, which is built to host a wide variety of workloads and
applications and does not heavily tax any particular computing aspect,
a compute-focused cloud is built and designed specifically to support
compute intensive workloads. As such, the design must be specifically
tailored to support hosting compute intensive workloads. Compute intensive
workloads may be CPU intensive, RAM intensive, or both. However, they are
not typically storage intensive or network intensive. Compute-focused
workloads may include the following use cases:</para>
<itemizedlist>
<listitem>
<para>High performance computing (HPC)</para>
</listitem>
<listitem>
<para>Big data analytics using Hadoop or other distributed data
stores</para>
</listitem>
<listitem>
<para>Continuous integration/continuous deployment (CI/CD)</para>
</listitem>
<listitem>
<para>Platform-as-a-Service (PaaS)</para>
</listitem>
<listitem>
<para>Signal processing for Network Function Virtualization (NFV)</para>
</listitem>
</itemizedlist>
<para>Based on the use case requirements, such clouds might need to provide
additional services such as a virtual machine disk library, file or object
storage, firewalls, load balancers, IP addresses, and network connectivity
in the form of overlays or virtual Local Area Networks (VLANs). A
compute-focused OpenStack cloud will not typically use raw block storage
services since the applications hosted on a compute-focused OpenStack
cloud generally do not need persistent block storage.</para>
<xi:include href="compute_focus/section_user_requirements_compute_focus.xml"/> <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_tech_considerations_compute_focus.xml"/>
<xi:include href="compute_focus/section_operational_considerations_compute_focus.xml"/> <xi:include href="compute_focus/section_operational_considerations_compute_focus.xml"/>

58
doc/arch-design/ch_generalpurpose.xml
View File

@ -6,7 +6,63 @@
xml:id="generalpurpose"> xml:id="generalpurpose">
<title>General purpose</title> <title>General purpose</title>
<xi:include href="generalpurpose/section_introduction_generalpurpose.xml"/> <para>An OpenStack general purpose cloud is often considered a
starting point for building a cloud deployment. General
purpose clouds, by their nature, balance the components and do
not emphasize (or heavily emphasize) any particular aspect of
the overall computing environment. The expectation is that the
compute, network, and storage components will be given equal
weight in the design. General purpose clouds can be found in
private, public, and hybrid environments. They lend themselves
to many different use cases but, since they are homogeneous
deployments, they are not suited to specialized environments
or edge case situations. Common uses to consider for a general
purpose cloud could be, but are not limited to, providing a
simple database, a web application runtime environment, a
shared application development platform, or lab test bed. In
other words, any use case that would benefit from a scale-out
rather than a scale-up approach is a good candidate for a
general purpose cloud architecture.</para>
<para>A general purpose cloud, by definition, is something that is
designed to have a range of potential uses or functions; not
specialized for a specific use. General purpose architecture
is largely considered a scenario that would address 80% of the
potential use cases. The infrastructure, in itself, is a
specific use case. It is also a good place to start the design
process. As the most basic cloud service model, general
purpose clouds are designed to be platforms suited for general
purpose applications.</para>
<para>General purpose clouds are limited to the most basic
components, but they can include additional resources such
as:</para>
<itemizedlist>
<listitem>
<para>Virtual-machine disk image library</para>
</listitem>
<listitem>
<para>Raw block storage</para>
</listitem>
<listitem>
<para>File or object storage</para>
</listitem>
<listitem>
<para>Firewalls</para>
</listitem>
<listitem>
<para>Load balancers</para>
</listitem>
<listitem>
<para>IP addresses</para>
</listitem>
<listitem>
<para>Network overlays or virtual local area networks
(VLANs)</para>
</listitem>
<listitem>
<para>Software bundles</para>
</listitem>
</itemizedlist>
<xi:include href="generalpurpose/section_user_requirements_general_purpose.xml"/> <xi:include href="generalpurpose/section_user_requirements_general_purpose.xml"/>
<xi:include href="generalpurpose/section_tech_considerations_general_purpose.xml"/> <xi:include href="generalpurpose/section_tech_considerations_general_purpose.xml"/>
<xi:include href="generalpurpose/section_operational_considerations_general_purpose.xml"/> <xi:include href="generalpurpose/section_operational_considerations_general_purpose.xml"/>

63
doc/arch-design/ch_hybrid.xml
View File

@ -6,7 +6,67 @@
xml:id="hybrid"> xml:id="hybrid">
<title>Hybrid</title> <title>Hybrid</title>
<xi:include href="hybrid/section_introduction_hybrid.xml"/> <para>Hybrid cloud, by definition, means that the design spans
more than one cloud. An example of this kind of architecture
may include a situation in which the design involves more than
one OpenStack cloud (for example, an OpenStack-based private
cloud and an OpenStack-based public cloud), or it may be a
situation incorporating an OpenStack cloud and a non-OpenStack
cloud (for example, an OpenStack-based private cloud that
interacts with Amazon Web Services). Bursting into an external
cloud is the practice of creating new instances to alleviate
extra load where there is no available capacity in the private
cloud.</para>
<para>Some situations that could involve hybrid cloud architecture
include:</para>
<itemizedlist>
<listitem>
<para>Bursting from a private cloud to a public
cloud</para>
</listitem>
<listitem>
<para>Disaster recovery</para>
</listitem>
<listitem>
<para>Development and testing</para>
</listitem>
<listitem>
<para>Federated cloud, enabling users to choose resources
from multiple providers</para>
</listitem>
<listitem>
<para>Hybrid clouds built to support legacy systems as
they transition to cloud</para>
</listitem>
</itemizedlist>
<para>As a hybrid cloud design deals with systems that are outside
of the control of the cloud architect or organization, a
hybrid cloud architecture requires considering aspects of the
architecture that might not have otherwise been necessary. For
example, the design may need to deal with hardware, software,
and APIs under the control of a separate organization.</para>
<para>Similarly, the degree to which the architecture is
OpenStack-based will have an effect on the cloud operator or
cloud consumer's ability to accomplish tasks with native
OpenStack tools. By definition, this is a situation in which
no single cloud can provide all of the necessary
functionality. In order to manage the entire system, users,
operators and consumers will need an overarching tool known as
a cloud management platform (CMP). Any organization that is
working with multiple clouds already has a CMP, even if that
CMP is the operator who logs into an external web portal and
launches a public cloud instance.</para>
<para>There are commercially available options, such as
Rightscale, and open source options, such as ManageIQ
(http://manageiq.org/), but there is no single CMP that can
address all needs in all scenarios. Whereas most of the
sections of this book talk about the aspects of OpenStack, an
architect needs to consider when designing an OpenStack
architecture. This section will also discuss the things the
architect must address when choosing or building a CMP to run
a hybrid cloud design, even if the CMP will be a manually
built solution.</para>
<xi:include href="hybrid/section_user_requirements_hybrid.xml"/> <xi:include href="hybrid/section_user_requirements_hybrid.xml"/>
<xi:include href="hybrid/section_tech_considerations_hybrid.xml"/> <xi:include href="hybrid/section_tech_considerations_hybrid.xml"/>
<xi:include href="hybrid/section_operational_considerations_hybrid.xml"/> <xi:include href="hybrid/section_operational_considerations_hybrid.xml"/>
@ -14,4 +74,3 @@
<xi:include href="hybrid/section_prescriptive_examples_hybrid.xml"/> <xi:include href="hybrid/section_prescriptive_examples_hybrid.xml"/>
</chapter> </chapter>

26
doc/arch-design/ch_introduction.xml
View File

@ -6,7 +6,31 @@
xml:id="introduction"> xml:id="introduction">
<title>Introduction</title> <title>Introduction</title>
<xi:include href="introduction/section_introduction_to_openstack_architecture_design_guide.xml"/> <para>OpenStack is a leader in the cloud technology gold rush, as
organizations of all stripes discover the increased
flexibility and speed to market that self-service cloud and
Infrastructure-as-a-Service (IaaS) provides. To truly reap
those benefits, however, the cloud must be designed and
architected properly.</para>
<para>A well-architected cloud provides a stable IT environment
that offers easy access to needed resources, usage-based
expenses, extra capacity on demand, disaster recovery, and a
secure environment, but a well-architected cloud does not
magically build itself. It requires careful consideration of a
multitude of factors, both technical and non-technical.</para>
<para>There is no single architecture that is "right" for an
OpenStack cloud deployment. OpenStack can be used for any
number of different purposes, and each of them has its own
particular requirements and architectural
peculiarities.</para>
<para>This book is designed to look at some of the most common
uses for OpenStack clouds (and even some that are less common,
but provide a good example) and explain what issues need to be
considered and why, along with a wealth of knowledge and
advice to help an organization to design and build a
well-architected OpenStack cloud that will fit its unique
requirements.</para>
<xi:include href="introduction/section_intended_audience.xml"/> <xi:include href="introduction/section_intended_audience.xml"/>
<xi:include href="introduction/section_how_this_book_is_organized.xml"/> <xi:include href="introduction/section_how_this_book_is_organized.xml"/>
<xi:include href="introduction/section_how_this_book_was_written.xml"/> <xi:include href="introduction/section_how_this_book_was_written.xml"/>

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

@ -6,7 +6,74 @@
xml:id="massively_scalable"> xml:id="massively_scalable">
<title>Massively scalable</title> <title>Massively scalable</title>
<xi:include href="massively_scalable/section_introduction_massively_scalable.xml"/> <para>A massively scalable architecture is defined as a cloud
implementation that is either a very large deployment, such as
one that would be built by a commercial service provider, or
one that has the capability to support user requests for large
amounts of cloud resources. An example would be an
infrastructure in which requests to service 500 instances or
more at a time is not uncommon. In a massively scalable
infrastructure, such a request is fulfilled without completely
consuming all of the available cloud infrastructure resources.
While the high capital cost of implementing such a cloud
architecture makes it cost prohibitive and is only spearheaded
by few organizations, many organizations are planning for
massive scalability moving toward the future.</para>
<para>A massively scalable OpenStack cloud design presents a
unique set of challenges and considerations. For the most part
it is similar to a general purpose cloud architecture, as it
is built to address a non-specific range of potential use
cases or functions. Typically, it is rare that massively
scalable clouds are designed or specialized for particular
workloads. Like the general purpose cloud, the massively
scalable cloud is most often built as a platform for a variety
of workloads. Massively scalable OpenStack clouds are
generally built as commercial public cloud offerings since
single private organizations rarely have the resources or need
for this scale.</para>
<para>Services provided by a massively scalable OpenStack cloud
will include:</para>
<itemizedlist>
<listitem>
<para>Virtual-machine disk image library</para>
</listitem>
<listitem>
<para>Raw block storage</para>
</listitem>
<listitem>
<para>File or object storage</para>
</listitem>
<listitem>
<para>Firewall functionality</para>
</listitem>
<listitem>
<para>Load balancing functionality</para>
</listitem>
<listitem>
<para>Private (non-routable) and public (floating) IP
addresses</para>
</listitem>
<listitem>
<para>Virtualized network topologies</para>
</listitem>
<listitem>
<para>Software bundles</para>
</listitem>
<listitem>
<para>Virtual compute resources</para>
</listitem>
</itemizedlist>
<para>Like a general purpose cloud, the instances deployed in a
massively scalable OpenStack cloud will not necessarily use
any specific aspect of the cloud offering (compute, network,
or storage). As the cloud grows in scale, the scale of the
number of workloads can cause stress on all of the cloud
components. Additional stresses are introduced to supporting
infrastructure including databases and message brokers. The
architecture design for such a cloud must account for these
performance pressures without negatively impacting user
experience.</para>
<xi:include href="massively_scalable/section_user_requirements_massively_scalable.xml"/> <xi:include href="massively_scalable/section_user_requirements_massively_scalable.xml"/>
<xi:include href="massively_scalable/section_tech_considerations_massively_scalable.xml"/> <xi:include href="massively_scalable/section_tech_considerations_massively_scalable.xml"/>
<xi:include href="massively_scalable/section_operational_considerations_massively_scalable.xml"/> <xi:include href="massively_scalable/section_operational_considerations_massively_scalable.xml"/>

27
doc/arch-design/ch_multi_site.xml
View File

@ -6,7 +6,32 @@
xml:id="multi_site"> xml:id="multi_site">
<title>Multi-site</title> <title>Multi-site</title>
<xi:include href="multi_site/section_introduction_multi_site.xml"/> <para>A multi-site OpenStack environment is one in which services
located in more than one data center are used to provide the
overall solution. Usage requirements of different multi-site
clouds may vary widely, however they share some common needs.
OpenStack is capable of running in a multi-region
configuration allowing some parts of OpenStack to effectively
manage a grouping of sites as a single cloud. With some
careful planning in the design phase, OpenStack can act as an
excellent multi-site cloud solution for a multitude of
needs.</para>
<para>Some use cases that might indicate a need for a multi-site
deployment of OpenStack include:</para>
<itemizedlist>
<listitem>
<para>An organization with a diverse geographic
footprint.</para>
</listitem>
<listitem>
<para>Geo-location sensitive data.</para>
</listitem>
<listitem>
<para>Data locality, in which specific data or
functionality should be close to users.</para>
</listitem>
</itemizedlist>
<xi:include href="multi_site/section_user_requirements_multi_site.xml"/> <xi:include href="multi_site/section_user_requirements_multi_site.xml"/>
<xi:include href="multi_site/section_tech_considerations_multi_site.xml"/> <xi:include href="multi_site/section_tech_considerations_multi_site.xml"/>
<xi:include href="multi_site/section_operational_considerations_multi_site.xml"/> <xi:include href="multi_site/section_operational_considerations_multi_site.xml"/>

132
doc/arch-design/ch_network_focus.xml
View File

@ -6,7 +6,137 @@
xml:id="network_focus"> xml:id="network_focus">
<title>Network focused</title> <title>Network focused</title>
<xi:include href="network_focus/section_introduction_network_focus.xml"/> <para>All OpenStack deployments are dependent, to some extent, on
network communication in order to function properly due to a
service-based nature. In some cases, however, use cases
dictate that the network is elevated beyond simple
infrastructure. This section is a discussion of architectures
that are more reliant or focused on network services. These
architectures are heavily dependent on the network
infrastructure and need to be architected so that the network
services perform and are reliable in order to satisfy user and
application requirements.</para>
<para>Some possible use cases include:</para>
<itemizedlist>
<listitem>
<para>Content Delivery Network: This could include
streaming video, photographs or any other cloud based
repository of data that is distributed to a large
number of end users. Mass market streaming video will
be very heavily affected by the network configurations
that would affect latency, bandwidth, and the
distribution of instances. Not all video streaming is
consumer focused. For example, multicast videos (used
for media, press conferences, corporate presentations,
web conferencing services, and so on) can also utilize a
content delivery network. Content delivery will be
affected by the location of the video repository and
its relationship to end users. Performance is also
affected by network throughput of the backend systems,
as well as the WAN architecture and the cache
methodology.</para>
</listitem>
<listitem>
<para>Network Management Functions: A cloud that provides
network service functions would be built to support
the delivery of back-end network services such as DNS,
NTP or SNMP and would be used by a company for
internal network management.</para>
</listitem>
<listitem>
<para>Network Service Offerings: A cloud can be used to
run customer facing network tools to support services.
For example, VPNs, MPLS private networks, GRE tunnels
and others.</para>
</listitem>
<listitem>
<para>Web portals / Web Services: Web servers are a common
application for cloud services and it is recommended
to have an understanding of the network requirements.
The network will need to be able to scale out to meet
user demand and deliver webpages with a minimum of
latency. Internal east-west and north-south network
bandwidth must be considered depending on the details
of the portal architecture.</para>
</listitem>
<listitem>
<para>High Speed and High Volume Transactional Systems:
These types of applications are very sensitive to
network configurations. Examples include many
financial systems, credit card transaction
applications, trading and other extremely high volume
systems. These systems are sensitive to network jitter
and latency. They also have a high volume of both
east-west and north-south network traffic that needs
to be balanced to maximize efficiency of the data
delivery. Many of these systems have large high
performance database back ends that need to be
accessed.</para>
</listitem>
<listitem>
<para>High Availability: These types of use cases are
highly dependent on the proper sizing of the network
to maintain replication of data between sites for high
availability. If one site becomes unavailable, the
extra sites will be able to serve the displaced load
until the original site returns to service. It is
important to size network capacity to handle the loads
that are desired.</para>
</listitem>
<listitem>
<para>Big Data: Clouds that will be used for the
management and collection of big data (data ingest)
will have a significant demand on network resources.
Big data often uses partial replicas of the data to
maintain data integrity over large distributed clouds.
Other big data applications that require a large
amount of network resources are Hadoop, Cassandra,
NuoDB, RIAK and other No-SQL and distributed
databases.</para>
</listitem>
<listitem>
<para>Virtual Desktop Infrastructure (VDI): This use case
is very sensitive to network congestion, latency,
jitter and other network characteristics. Like video
streaming, the user experience is very important
however, unlike video streaming, caching is not an
option to offset the network issues. VDI requires both
upstream and downstream traffic and cannot rely on
caching for the delivery of the application to the end
user.</para>
</listitem>
<listitem>
<para>Voice over IP (VoIP): This is extremely sensitive to
network congestion, latency, jitter and other network
characteristics. VoIP has a symmetrical traffic
pattern and it requires network quality of service
(QoS) for best performance. It may also require an
active queue management implementation to ensure
delivery. Users are very sensitive to latency and
jitter fluctuations and can detect them at very low
levels.</para>
</listitem>
<listitem>
<para>Video Conference / Web Conference: This also is
extremely sensitive to network congestion, latency,
jitter and other network flaws. Video Conferencing has
a symmetrical traffic pattern, but unless the network
is on an MPLS private network, it cannot use network
quality of service (QoS) to improve performance.
Similar to VOIP, users will be sensitive to network
performance issues even at low levels.</para>
</listitem>
<listitem>
<para>High Performance Computing (HPC): This is a complex
use case that requires careful consideration of the
traffic flows and usage patterns to address the needs
of cloud clusters. It has high East-West traffic
patterns for distributed computing, but there can be
substantial North-South traffic depending on the
specific application.</para>
</listitem>
</itemizedlist>
<xi:include href="network_focus/section_user_requirements_network_focus.xml"/> <xi:include href="network_focus/section_user_requirements_network_focus.xml"/>
<xi:include href="network_focus/section_tech_considerations_network_focus.xml"/> <xi:include href="network_focus/section_tech_considerations_network_focus.xml"/>
<xi:include href="network_focus/section_operational_considerations_network_focus.xml"/> <xi:include href="network_focus/section_operational_considerations_network_focus.xml"/>

43
doc/arch-design/ch_specialized.xml
View File

@ -6,7 +6,48 @@
xml:id="specialized"> xml:id="specialized">
<title>Specialized cases</title> <title>Specialized cases</title>
<xi:include href="specialized/section_introduction_specialized.xml"/> <para>Although most OpenStack architecture designs fall into one
of the seven major scenarios outlined in other sections
(compute focused, network focused, storage focused, general
purpose, multi-site, hybrid cloud, and massively scalable),
there are a few other use cases that are unique enough they
can't be neatly categorized into one of the other major
sections. This section discusses some of these unique use
cases with some additional details and design considerations
for each use case:</para>
<itemizedlist>
<listitem>
<para>Specialized Networking: This describes running
networking-oriented software that may involve reading
packets directly from the wire or participating in
routing protocols.</para>
</listitem>
<listitem>
<para>Software-Defined Networking: This use case details
both running an SDN controller from within OpenStack
as well as participating in a software-defined
network.</para>
</listitem>
<listitem>
<para>Desktop-as-a-Service: This is for organizations that
want to run a virtualized desktop environment on a
cloud. This can apply to private or public
clouds.</para>
</listitem>
<listitem>
<para>OpenStack on OpenStack: Some organizations are
finding that it makes technical sense to build a
multi-tiered cloud by running OpenStack on top of an
OpenStack installation.</para>
</listitem>
<listitem>
<para>Specialized Hardware: Some highly specialized
situations will require the use of specialized
hardware devices from within the OpenStack
environment.</para>
</listitem>
</itemizedlist>
<xi:include href="specialized/section_multi_hypervisor_specialized.xml"/> <xi:include href="specialized/section_multi_hypervisor_specialized.xml"/>
<xi:include href="specialized/section_networking_specialized.xml"/> <xi:include href="specialized/section_networking_specialized.xml"/>
<xi:include href="specialized/section_software_defined_networking_specialized.xml"/> <xi:include href="specialized/section_software_defined_networking_specialized.xml"/>

65
doc/arch-design/ch_storage_focus.xml
View File

@ -6,7 +6,70 @@
xml:id="storage_focus"> xml:id="storage_focus">
<title>Storage focused</title> <title>Storage focused</title>
<xi:include href="storage_focus/section_introduction_storage_focus.xml"/> <para>Cloud storage is a model of data storage where digital data
is stored in logical pools and physical storage that spans
across multiple servers and locations. Cloud storage commonly
refers to a hosted object storage service, however the term
has extended to include other types of data storage that are
available as a service, for example block storage.</para>
<para>Cloud storage is based on virtualized infrastructure and
resembles broader cloud computing in terms of accessible
interfaces, elasticity, scalability, multi-tenancy, and
metered resources. Cloud storage services can be utilized from
an off-premises service or deployed on-premises.</para>
<para>Cloud storage is made up of many distributed, yet still
synonymous resources, and is often referred to as integrated
storage clouds. Cloud storage is highly fault tolerant through
redundancy and the distribution of data. It is highly durable
through the creation of versioned copies, and can be
consistent with regard to data replicas.</para>
<para>At a certain scale, management of data operations can become
a resource intensive process to an organization. Hierarchical
storage management (HSM) systems and data grids can help
annotate and report a baseline data valuation to make
intelligent decisions and automate data decisions. HSM allows
for automating tiering and movement, as well as orchestration
of data operations. A data grid is an architecture, or set of
services evolving technology, that brings together sets of
services allowing users to manage large data sets.</para>
<para>Examples of applications that can be deployed with cloud
storage characteristics are:</para>
<itemizedlist>
<listitem>
<para>Active archive, backups and hierarchical storage
management.</para>
</listitem>
<listitem>
<para>General content storage and synchronization. An
example of this is private dropbox.</para>
</listitem>
<listitem>
<para>Data analytics with parallel file systems.</para>
</listitem>
<listitem>
<para>Unstructured data store for services. For example,
social media back-end storage.</para>
</listitem>
<listitem>
<para>Persistent block storage.</para>
</listitem>
<listitem>
<para>Operating system and application image store.</para>
</listitem>
<listitem>
<para>Media streaming.</para>
</listitem>
<listitem>
<para>Databases.</para>
</listitem>
<listitem>
<para>Content distribution.</para>
</listitem>
<listitem>
<para>Cloud storage peering.</para>
</listitem>
</itemizedlist>
<xi:include href="storage_focus/section_user_requirements_storage_focus.xml"/> <xi:include href="storage_focus/section_user_requirements_storage_focus.xml"/>
<xi:include href="storage_focus/section_tech_considerations_storage_focus.xml"/> <xi:include href="storage_focus/section_tech_considerations_storage_focus.xml"/>
<xi:include href="storage_focus/section_operational_considerations_storage_focus.xml"/> <xi:include href="storage_focus/section_operational_considerations_storage_focus.xml"/>

43
doc/arch-design/compute_focus/section_introduction_compute_focus.xml
View File

@ -1,43 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<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="arch-guide-intro-compute-focus">
<title>Introduction</title>
<para>A compute-focused cloud is a specialized subset of the general purpose
OpenStack cloud architecture. Unlike the general purpose OpenStack
architecture, which is built to host a wide variety of workloads and
applications and does not heavily tax any particular computing aspect,
a compute-focused cloud is built and designed specifically to support
compute intensive workloads. As such, the design must be specifically
tailored to support hosting compute intensive workloads. Compute intensive
workloads may be CPU intensive, RAM intensive, or both. However, they are
not typically storage intensive or network intensive. Compute-focused
workloads may include the following use cases:</para>
<itemizedlist>
<listitem>
<para>High performance computing (HPC)</para>
</listitem>
<listitem>
<para>Big data analytics using Hadoop or other distributed data
stores</para>
</listitem>
<listitem>
<para>Continuous integration/continuous deployment (CI/CD)</para>
</listitem>
<listitem>
<para>Platform-as-a-Service (PaaS)</para>
</listitem>
<listitem>
<para>Signal processing for Network Function Virtualization (NFV)</para>
</listitem>
</itemizedlist>
<para>Based on the use case requirements, such clouds might need to provide
additional services such as a virtual machine disk library, file or object
storage, firewalls, load balancers, IP addresses, and network connectivity
in the form of overlays or virtual Local Area Networks (VLANs). A
compute-focused OpenStack cloud will not typically use raw block storage
services since the applications hosted on a compute-focused OpenStack
cloud generally do not need persistent block storage.</para>
</section>

64
doc/arch-design/generalpurpose/section_introduction_generalpurpose.xml
View File

@ -1,64 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<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="arch-guide-intro-general-purpose">
<title>Introduction</title>
<para>An OpenStack general purpose cloud is often considered a
starting point for building a cloud deployment. General
purpose clouds, by their nature, balance the components and do
not emphasize (or heavily emphasize) any particular aspect of
the overall computing environment. The expectation is that the
compute, network, and storage components will be given equal
weight in the design. General purpose clouds can be found in
private, public, and hybrid environments. They lend themselves
to many different use cases but, since they are homogeneous
deployments, they are not suited to specialized environments
or edge case situations. Common uses to consider for a general
purpose cloud could be, but are not limited to, providing a
simple database, a web application runtime environment, a
shared application development platform, or lab test bed. In
other words, any use case that would benefit from a scale-out
rather than a scale-up approach is a good candidate for a
general purpose cloud architecture.</para>
<para>A general purpose cloud, by definition, is something that is
designed to have a range of potential uses or functions; not
specialized for a specific use. General purpose architecture
is largely considered a scenario that would address 80% of the
potential use cases. The infrastructure, in itself, is a
specific use case. It is also a good place to start the design
process. As the most basic cloud service model, general
purpose clouds are designed to be platforms suited for general
purpose applications.</para>
<para>General purpose clouds are limited to the most basic
components, but they can include additional resources such
as:</para>
<itemizedlist>
<listitem>
<para>Virtual-machine disk image library</para>
</listitem>
<listitem>
<para>Raw block storage</para>
</listitem>
<listitem>
<para>File or object storage</para>
</listitem>
<listitem>
<para>Firewalls</para>
</listitem>
<listitem>
<para>Load balancers</para>
</listitem>
<listitem>
<para>IP addresses</para>
</listitem>
<listitem>
<para>Network overlays or virtual local area networks
(VLANs)</para>
</listitem>
<listitem>
<para>Software bundles</para>
</listitem>
</itemizedlist>
</section>

68
doc/arch-design/hybrid/section_introduction_hybrid.xml
View File

@ -1,68 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<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="arch-guide-intro-hybrid">
<title>Introduction</title>
<para>Hybrid cloud, by definition, means that the design spans
more than one cloud. An example of this kind of architecture
may include a situation in which the design involves more than
one OpenStack cloud (for example, an OpenStack-based private
cloud and an OpenStack-based public cloud), or it may be a
situation incorporating an OpenStack cloud and a non-OpenStack
cloud (for example, an OpenStack-based private cloud that
interacts with Amazon Web Services). Bursting into an external
cloud is the practice of creating new instances to alleviate
extra load where there is no available capacity in the private
cloud.</para>
<para>Some situations that could involve hybrid cloud architecture
include:</para>
<itemizedlist>
<listitem>
<para>Bursting from a private cloud to a public
cloud</para>
</listitem>
<listitem>
<para>Disaster recovery</para>
</listitem>
<listitem>
<para>Development and testing</para>
</listitem>
<listitem>
<para>Federated cloud, enabling users to choose resources
from multiple providers</para>
</listitem>
<listitem>
<para>Hybrid clouds built to support legacy systems as
they transition to cloud</para>
</listitem>
</itemizedlist>
<para>As a hybrid cloud design deals with systems that are outside
of the control of the cloud architect or organization, a
hybrid cloud architecture requires considering aspects of the
architecture that might not have otherwise been necessary. For
example, the design may need to deal with hardware, software,
and APIs under the control of a separate organization.</para>
<para>Similarly, the degree to which the architecture is
OpenStack-based will have an effect on the cloud operator or
cloud consumer's ability to accomplish tasks with native
OpenStack tools. By definition, this is a situation in which
no single cloud can provide all of the necessary
functionality. In order to manage the entire system, users,
operators and consumers will need an overarching tool known as
a cloud management platform (CMP). Any organization that is
working with multiple clouds already has a CMP, even if that
CMP is the operator who logs into an external web portal and
launches a public cloud instance.</para>
<para>There are commercially available options, such as
Rightscale, and open source options, such as ManageIQ
(http://manageiq.org/), but there is no single CMP that can
address all needs in all scenarios. Whereas most of the
sections of this book talk about the aspects of OpenStack, an
architect needs to consider when designing an OpenStack
architecture. This section will also discuss the things the
architect must address when choosing or building a CMP to run
a hybrid cloud design, even if the CMP will be a manually
built solution.</para>
</section>

33
doc/arch-design/introduction/section_introduction_to_openstack_architecture_design_guide.xml
View File

@ -1,33 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<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="arch-guide-intro-to-openstack-arch-design-guide">
<title>Introduction to the OpenStack Architecture Design
Guide</title>
<para>OpenStack is a leader in the cloud technology gold rush, as
organizations of all stripes discover the increased
flexibility and speed to market that self-service cloud and
Infrastructure-as-a-Service (IaaS) provides. To truly reap
those benefits, however, the cloud must be designed and
architected properly.</para>
<para>A well-architected cloud provides a stable IT environment
that offers easy access to needed resources, usage-based
expenses, extra capacity on demand, disaster recovery, and a
secure environment, but a well-architected cloud does not
magically build itself. It requires careful consideration of a
multitude of factors, both technical and non-technical.</para>
<para>There is no single architecture that is "right" for an
OpenStack cloud deployment. OpenStack can be used for any
number of different purposes, and each of them has its own
particular requirements and architectural
peculiarities.</para>
<para>This book is designed to look at some of the most common
uses for OpenStack clouds (and even some that are less common,
but provide a good example) and explain what issues need to be
considered and why, along with a wealth of knowledge and
advice to help an organization to design and build a
well-architected OpenStack cloud that will fit its unique
requirements.</para>
</section>

75
doc/arch-design/massively_scalable/section_introduction_massively_scalable.xml
View File

@ -1,75 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<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="arch-guide-intro-massive-scale">
<title>Introduction</title>
<para>A massively scalable architecture is defined as a cloud
implementation that is either a very large deployment, such as
one that would be built by a commercial service provider, or
one that has the capability to support user requests for large
amounts of cloud resources. An example would be an
infrastructure in which requests to service 500 instances or
more at a time is not uncommon. In a massively scalable
infrastructure, such a request is fulfilled without completely
consuming all of the available cloud infrastructure resources.
While the high capital cost of implementing such a cloud
architecture makes it cost prohibitive and is only spearheaded
by few organizations, many organizations are planning for
massive scalability moving toward the future.</para>
<para>A massively scalable OpenStack cloud design presents a
unique set of challenges and considerations. For the most part
it is similar to a general purpose cloud architecture, as it
is built to address a non-specific range of potential use
cases or functions. Typically, it is rare that massively
scalable clouds are designed or specialized for particular
workloads. Like the general purpose cloud, the massively
scalable cloud is most often built as a platform for a variety
of workloads. Massively scalable OpenStack clouds are
generally built as commercial public cloud offerings since
single private organizations rarely have the resources or need
for this scale.</para>
<para>Services provided by a massively scalable OpenStack cloud
will include:</para>
<itemizedlist>
<listitem>
<para>Virtual-machine disk image library</para>
</listitem>
<listitem>
<para>Raw block storage</para>
</listitem>
<listitem>
<para>File or object storage</para>
</listitem>
<listitem>
<para>Firewall functionality</para>
</listitem>
<listitem>
<para>Load balancing functionality</para>
</listitem>
<listitem>
<para>Private (non-routable) and public (floating) IP
addresses</para>
</listitem>
<listitem>
<para>Virtualized network topologies</para>
</listitem>
<listitem>
<para>Software bundles</para>
</listitem>
<listitem>
<para>Virtual compute resources</para>
</listitem>
</itemizedlist>
<para>Like a general purpose cloud, the instances deployed in a
massively scalable OpenStack cloud will not necessarily use
any specific aspect of the cloud offering (compute, network,
or storage). As the cloud grows in scale, the scale of the
number of workloads can cause stress on all of the cloud
components. Additional stresses are introduced to supporting
infrastructure including databases and message brokers. The
architecture design for such a cloud must account for these
performance pressures without negatively impacting user
experience.</para>
</section>

33
doc/arch-design/multi_site/section_introduction_multi_site.xml
View File

@ -1,33 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<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="arch-guide-intro-multi">
<title>Introduction</title>
<para>A multi-site OpenStack environment is one in which services
located in more than one data center are used to provide the
overall solution. Usage requirements of different multi-site
clouds may vary widely, however they share some common needs.
OpenStack is capable of running in a multi-region
configuration allowing some parts of OpenStack to effectively
manage a grouping of sites as a single cloud. With some
careful planning in the design phase, OpenStack can act as an
excellent multi-site cloud solution for a multitude of
needs.</para>
<para>Some use cases that might indicate a need for a multi-site
deployment of OpenStack include:</para>
<itemizedlist>
<listitem>
<para>An organization with a diverse geographic
footprint.</para>
</listitem>
<listitem>
<para>Geo-location sensitive data.</para>
</listitem>
<listitem>
<para>Data locality, in which specific data or
functionality should be close to users.</para>
</listitem>
</itemizedlist>
</section>

138
doc/arch-design/network_focus/section_introduction_network_focus.xml
View File

@ -1,138 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<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="arch-guide-intro-network-focus">
<title>Introduction</title>
<para>All OpenStack deployments are dependent, to some extent, on
network communication in order to function properly due to a
service-based nature. In some cases, however, use cases
dictate that the network is elevated beyond simple
infrastructure. This section is a discussion of architectures
that are more reliant or focused on network services. These
architectures are heavily dependent on the network
infrastructure and need to be architected so that the network
services perform and are reliable in order to satisfy user and
application requirements.</para>
<para>Some possible use cases include:</para>
<itemizedlist>
<listitem>
<para>Content Delivery Network: This could include
streaming video, photographs or any other cloud based
repository of data that is distributed to a large
number of end users. Mass market streaming video will
be very heavily affected by the network configurations
that would affect latency, bandwidth, and the
distribution of instances. Not all video streaming is
consumer focused. For example, multicast videos (used
for media, press conferences, corporate presentations,
web conferencing services, and so on) can also utilize a
content delivery network. Content delivery will be
affected by the location of the video repository and
its relationship to end users. Performance is also
affected by network throughput of the backend systems,
as well as the WAN architecture and the cache
methodology.</para>
</listitem>
<listitem>
<para>Network Management Functions: A cloud that provides
network service functions would be built to support
the delivery of back-end network services such as DNS,
NTP or SNMP and would be used by a company for
internal network management.</para>
</listitem>
<listitem>
<para>Network Service Offerings: A cloud can be used to
run customer facing network tools to support services.
For example, VPNs, MPLS private networks, GRE tunnels
and others.</para>
</listitem>
<listitem>
<para>Web portals / Web Services: Web servers are a common
application for cloud services and it is recommended
to have an understanding of the network requirements.
The network will need to be able to scale out to meet
user demand and deliver webpages with a minimum of
latency. Internal east-west and north-south network
bandwidth must be considered depending on the details
of the portal architecture.</para>
</listitem>
<listitem>
<para>High Speed and High Volume Transactional Systems:
These types of applications are very sensitive to
network configurations. Examples include many
financial systems, credit card transaction
applications, trading and other extremely high volume
systems. These systems are sensitive to network jitter
and latency. They also have a high volume of both
east-west and north-south network traffic that needs
to be balanced to maximize efficiency of the data
delivery. Many of these systems have large high
performance database back ends that need to be
accessed.</para>
</listitem>
<listitem>
<para>High Availability: These types of use cases are
highly dependent on the proper sizing of the network
to maintain replication of data between sites for high
availability. If one site becomes unavailable, the
extra sites will be able to serve the displaced load
until the original site returns to service. It is
important to size network capacity to handle the loads
that are desired.</para>
</listitem>
<listitem>
<para>Big Data: Clouds that will be used for the
management and collection of big data (data ingest)
will have a significant demand on network resources.
Big data often uses partial replicas of the data to
maintain data integrity over large distributed clouds.
Other big data applications that require a large
amount of network resources are Hadoop, Cassandra,
NuoDB, RIAK and other No-SQL and distributed
databases.</para>
</listitem>
<listitem>
<para>Virtual Desktop Infrastructure (VDI): This use case
is very sensitive to network congestion, latency,
jitter and other network characteristics. Like video
streaming, the user experience is very important
however, unlike video streaming, caching is not an
option to offset the network issues. VDI requires both
upstream and downstream traffic and cannot rely on
caching for the delivery of the application to the end
user.</para>
</listitem>
<listitem>
<para>Voice over IP (VoIP): This is extremely sensitive to
network congestion, latency, jitter and other network
characteristics. VoIP has a symmetrical traffic
pattern and it requires network quality of service
(QoS) for best performance. It may also require an
active queue management implementation to ensure
delivery. Users are very sensitive to latency and
jitter fluctuations and can detect them at very low
levels.</para>
</listitem>
<listitem>
<para>Video Conference / Web Conference: This also is
extremely sensitive to network congestion, latency,
jitter and other network flaws. Video Conferencing has
a symmetrical traffic pattern, but unless the network
is on an MPLS private network, it cannot use network
quality of service (QoS) to improve performance.
Similar to VOIP, users will be sensitive to network
performance issues even at low levels.</para>
</listitem>
<listitem>
<para>High Performance Computing (HPC): This is a complex
use case that requires careful consideration of the
traffic flows and usage patterns to address the needs
of cloud clusters. It has high East-West traffic
patterns for distributed computing, but there can be
substantial North-South traffic depending on the
specific application.</para>
</listitem>
</itemizedlist>
</section>

49
doc/arch-design/specialized/section_introduction_specialized.xml
View File

@ -1,49 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<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="arch-guide-intro-other-specialties">
<title>Introduction</title>
<para>Although most OpenStack architecture designs fall into one
of the seven major scenarios outlined in other sections
(compute focused, network focused, storage focused, general
purpose, multi-site, hybrid cloud, and massively scalable),
there are a few other use cases that are unique enough they
can't be neatly categorized into one of the other major
sections. This section discusses some of these unique use
cases with some additional details and design considerations
for each use case:</para>
<itemizedlist>
<listitem>
<para>Specialized Networking: This describes running
networking-oriented software that may involve reading
packets directly from the wire or participating in
routing protocols.</para>
</listitem>
<listitem>
<para>Software-Defined Networking: This use case details
both running an SDN controller from within OpenStack
as well as participating in a software-defined
network.</para>
</listitem>
<listitem>
<para>Desktop-as-a-Service: This is for organizations that
want to run a virtualized desktop environment on a
cloud. This can apply to private or public
clouds.</para>
</listitem>
<listitem>
<para>OpenStack on OpenStack: Some organizations are
finding that it makes technical sense to build a
multi-tiered cloud by running OpenStack on top of an
OpenStack installation.</para>
</listitem>
<listitem>
<para>Specialized Hardware: Some highly specialized
situations will require the use of specialized
hardware devices from within the OpenStack
environment.</para>
</listitem>
</itemizedlist>
</section>

71
doc/arch-design/storage_focus/section_introduction_storage_focus.xml
View File

@ -1,71 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<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="arch-guide-intro-storage-focus">
<title>Introduction</title>
<para>Cloud storage is a model of data storage where digital data
is stored in logical pools and physical storage that spans
across multiple servers and locations. Cloud storage commonly
refers to a hosted object storage service, however the term
has extended to include other types of data storage that are
available as a service, for example block storage.</para>
<para>Cloud storage is based on virtualized infrastructure and
resembles broader cloud computing in terms of accessible
interfaces, elasticity, scalability, multi-tenancy, and
metered resources. Cloud storage services can be utilized from
an off-premises service or deployed on-premises.</para>
<para>Cloud storage is made up of many distributed, yet still
synonymous resources, and is often referred to as integrated
storage clouds. Cloud storage is highly fault tolerant through
redundancy and the distribution of data. It is highly durable
through the creation of versioned copies, and can be
consistent with regard to data replicas.</para>
<para>At a certain scale, management of data operations can become
a resource intensive process to an organization. Hierarchical
storage management (HSM) systems and data grids can help
annotate and report a baseline data valuation to make
intelligent decisions and automate data decisions. HSM allows
for automating tiering and movement, as well as orchestration
of data operations. A data grid is an architecture, or set of
services evolving technology, that brings together sets of
services allowing users to manage large data sets.</para>
<para>Examples of applications that can be deployed with cloud
storage characteristics are:</para>
<itemizedlist>
<listitem>
<para>Active archive, backups and hierarchical storage
management.</para>
</listitem>
<listitem>
<para>General content storage and synchronization. An
example of this is private dropbox.</para>
</listitem>
<listitem>
<para>Data analytics with parallel file systems.</para>
</listitem>
<listitem>
<para>Unstructured data store for services. For example,
social media back-end storage.</para>
</listitem>
<listitem>
<para>Persistent block storage.</para>
</listitem>
<listitem>
<para>Operating system and application image store.</para>
</listitem>
<listitem>
<para>Media streaming.</para>
</listitem>
<listitem>
<para>Databases.</para>
</listitem>
<listitem>
<para>Content distribution.</para>
</listitem>
<listitem>
<para>Cloud storage peering.</para>
</listitem>
</itemizedlist>
</section>