69 lines
3.4 KiB
XML
69 lines
3.4 KiB
XML
<?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>
|