191 lines
8.9 KiB
XML
191 lines
8.9 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-architecture-hybrid">
|
|
<?dbhtml stop-chunking?>
|
|
<title>Architecture</title>
|
|
<para>Map out the dependencies of the expected workloads
|
|
and the cloud infrastructures required to support them to architect a
|
|
solution for the broadest compatibility between cloud platforms,
|
|
minimizing the need to create workarounds and processes to fill
|
|
identified gaps.</para>
|
|
<para>For your chosen cloud management platform, note the relative
|
|
levels of support for both monitoring and orchestration.</para>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata contentwidth="4in"
|
|
fileref="../figures/Multi-Cloud_Priv-AWS4.png"/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
|
|
<section xml:id="image-portability">
|
|
<title>Image portability</title>
|
|
<para>The majority of cloud workloads currently run on instances
|
|
using hypervisor technologies. The challenge is that each of these
|
|
hypervisors uses an image format that may not be compatible with the
|
|
others. When possible, standardize on a single hypervisor and instance
|
|
image format. This may not be possible when using externally-managed
|
|
public clouds.</para>
|
|
<para>Conversion tools exist to address image format compatibility.
|
|
Examples include <link
|
|
xlink:href="http://libguestfs.org/virt-v2v">virt-p2v/virt-v2v</link>
|
|
and <link
|
|
xlink:href="http://libguestfs.org/virt-edit.1.html">
|
|
virt-edit</link>. These tools cannot serve beyond basic cloud instance
|
|
specifications.</para>
|
|
<para>Alternatively, build a thin operating system image as
|
|
the base for new instances. This facilitates rapid creation of cloud
|
|
instances using cloud orchestration or configuration management tools
|
|
for more specific templating. Remember if you intend to use portable
|
|
images for disaster recovery, application diversity, or high
|
|
availability, your users could move the images and instances between
|
|
cloud platforms regularly.</para>
|
|
</section>
|
|
|
|
<section xml:id="upper-layer-services">
|
|
<title>Upper-layer services</title>
|
|
<para>Many clouds offer complementary services beyond the
|
|
basic compute, network, and storage components. These
|
|
additional services often simplify the deployment
|
|
and management of applications on a cloud platform.</para>
|
|
<para>When moving workloads from the source to the destination
|
|
cloud platforms, consider that the destination cloud platform
|
|
may not have comparable services. Implement workloads in a
|
|
different way or by using a different technology.</para>
|
|
<para>For example, moving an application that uses a NoSQL database
|
|
service such as MongoDB could cause difficulties in maintaining
|
|
the application between the platforms.</para>
|
|
<para>There are a number of options that are appropriate for
|
|
the hybrid cloud use case:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Implementing a baseline of upper-layer services
|
|
across all of the cloud platforms. For
|
|
platforms that do not support a given service, create
|
|
a service on top of that platform and apply it to the
|
|
workloads as they are launched on that cloud.</para>
|
|
<para>For example, through the <glossterm>Database service</glossterm>
|
|
for OpenStack (<glossterm>trove</glossterm>),
|
|
OpenStack supports MySQL-as-a-Service but not NoSQL
|
|
databases in production. To move from or run
|
|
alongside AWS, a NoSQL workload must use an automation
|
|
tool, such as the Orchestration service (heat), to
|
|
recreate the NoSQL database on top of OpenStack.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Deploying a <glossterm>Platform-as-a-Service (PaaS)</glossterm>
|
|
technology that abstracts the
|
|
upper-layer services from the underlying cloud
|
|
platform. The unit of application deployment and
|
|
migration is the PaaS. It leverages the services of
|
|
the PaaS and only consumes the base infrastructure
|
|
services of the cloud platform.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Using automation tools to create the required upper-layer services
|
|
that are portable across all cloud platforms.</para>
|
|
<para>For example, instead of using database services that
|
|
are inherent in the cloud platforms, launch cloud
|
|
instances and deploy the databases on those
|
|
instances using scripts or configuration and
|
|
application deployment tools.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
|
|
<section xml:id="network-services">
|
|
<title>Network services</title>
|
|
<para>Network services functionality is a critical component of
|
|
multiple cloud architectures. It is an important factor
|
|
to assess when choosing a CMP and cloud provider.
|
|
Considerations include:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Functionality
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Security
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Scalability
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
High availability (HA)
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>Verify and test critical cloud endpoint features.</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>After selecting the network functionality framework,
|
|
you must confirm the functionality is compatible. This
|
|
ensures testing and functionality persists
|
|
during and after upgrades.</para>
|
|
<note>
|
|
<para>Diverse cloud platforms may de-synchronize
|
|
over time if you do not maintain their mutual compatibility.
|
|
This is a particular issue with APIs.</para>
|
|
</note>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Scalability across multiple cloud providers determines
|
|
your choice of underlying network framework. It is important to
|
|
have the network API functions presented and to verify
|
|
that the desired functionality persists across all
|
|
chosen cloud endpoint.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>High availability implementations vary in
|
|
functionality and design. Examples of some common
|
|
methods are active-hot-standby, active-passive, and
|
|
active-active. Develop your high availability
|
|
implementation and a test framework to understand
|
|
the functionality and limitations of the environment.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>It is imperative to address security considerations.
|
|
For example, addressing how data is secured between client and
|
|
endpoint and any traffic that traverses the multiple clouds.
|
|
Business and regulatory requirements dictate what security
|
|
approach to take. For more information, see the
|
|
<link linkend="security-overview">Security
|
|
Requirements Chapter</link></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
|
|
<section xml:id="data">
|
|
<title>Data</title>
|
|
<para>Traditionally, replication has been the best method of protecting
|
|
object store implementations. A variety of replication methods exist
|
|
in storage architectures, for example synchronous and asynchronous
|
|
mirroring. Most object stores and back-end storage systems implement
|
|
methods for replication at the storage subsystem layer.
|
|
Object stores also tailor replication techniques
|
|
to fit a cloud's requirements.</para>
|
|
<para>Organizations must find the right balance between
|
|
data integrity and data availability. Replication strategy may
|
|
also influence disaster recovery methods.</para>
|
|
<para>Replication across different racks, data centers, and
|
|
geographical regions increases focus on
|
|
determining and ensuring data locality. The ability to
|
|
guarantee data is accessed from the nearest or fastest storage
|
|
can be necessary for applications to perform well.</para>
|
|
<note>
|
|
<para>When running embedded object store methods, ensure that you do
|
|
not instigate extra data replication as this can cause performance
|
|
issues.</para>
|
|
</note>
|
|
</section>
|
|
</section>
|