0043fb7a7c
Many minor edits: Improve markup, follow conventions, add glossary items, fix capitalization,... Change-Id: I85693ef2d2c617327c707d13ffd5f05b4d97d1d7
80 lines
3.9 KiB
XML
80 lines
3.9 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<chapter 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="hybrid">
|
|
<title>Hybrid</title>
|
|
|
|
<para><glossterm baseform="hybrid cloud">Hybrid cloud</glossterm>,
|
|
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).
|
|
<glossterm baseform="bursting">Bursting</glossterm> 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
|
|
(<link xlink:href="http://manageiq.org/">http://manageiq.org</link>),
|
|
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"/>
|
|
<xi:include href="hybrid/section_architecture_hybrid.xml"/>
|
|
<xi:include href="hybrid/section_prescriptive_examples_hybrid.xml"/>
|
|
|
|
</chapter>
|