Arch Design: Move introductory sections up
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
parent
d38917d673
commit
bfe149fcd2
@ -6,7 +6,42 @@
|
||||
xml:id="compute_focus">
|
||||
<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_tech_considerations_compute_focus.xml"/>
|
||||
<xi:include href="compute_focus/section_operational_considerations_compute_focus.xml"/>
|
||||
|
||||
@ -6,7 +6,63 @@
|
||||
xml:id="generalpurpose">
|
||||
<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_tech_considerations_general_purpose.xml"/>
|
||||
<xi:include href="generalpurpose/section_operational_considerations_general_purpose.xml"/>
|
||||
|
||||
@ -6,7 +6,67 @@
|
||||
xml:id="hybrid">
|
||||
<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_tech_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"/>
|
||||
|
||||
</chapter>
|
||||
|
||||
|
||||
@ -6,7 +6,31 @@
|
||||
xml:id="introduction">
|
||||
<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_how_this_book_is_organized.xml"/>
|
||||
<xi:include href="introduction/section_how_this_book_was_written.xml"/>
|
||||
|
||||
@ -6,7 +6,74 @@
|
||||
xml:id="massively_scalable">
|
||||
<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_tech_considerations_massively_scalable.xml"/>
|
||||
<xi:include href="massively_scalable/section_operational_considerations_massively_scalable.xml"/>
|
||||
|
||||
@ -6,7 +6,32 @@
|
||||
xml:id="multi_site">
|
||||
<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_tech_considerations_multi_site.xml"/>
|
||||
<xi:include href="multi_site/section_operational_considerations_multi_site.xml"/>
|
||||
|
||||
@ -6,7 +6,137 @@
|
||||
xml:id="network_focus">
|
||||
<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_tech_considerations_network_focus.xml"/>
|
||||
<xi:include href="network_focus/section_operational_considerations_network_focus.xml"/>
|
||||
|
||||
@ -6,7 +6,48 @@
|
||||
xml:id="specialized">
|
||||
<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_networking_specialized.xml"/>
|
||||
<xi:include href="specialized/section_software_defined_networking_specialized.xml"/>
|
||||
|
||||
@ -6,7 +6,70 @@
|
||||
xml:id="storage_focus">
|
||||
<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_tech_considerations_storage_focus.xml"/>
|
||||
<xi:include href="storage_focus/section_operational_considerations_storage_focus.xml"/>
|
||||
|
||||
@ -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>
|
||||
@ -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>
|
||||
@ -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>
|
||||
@ -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>
|
||||
@ -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>
|
||||
@ -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>
|
||||
@ -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>
|
||||
@ -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>
|
||||
@ -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>
|
||||
Loading…
Reference in New Issue
Block a user