174 lines
9.0 KiB
XML
174 lines
9.0 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="prescriptive-examples-multi-cloud">
|
|
<?dbhtml stop-chunking?>
|
|
<title>Prescriptive examples</title>
|
|
<para>Hybrid cloud environments are designed for
|
|
these use cases:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Bursting workloads from private to public OpenStack
|
|
clouds</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Bursting workloads from private to public
|
|
non-OpenStack clouds</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>High availability across clouds (for technical
|
|
diversity)</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>This chapter provides examples of environments
|
|
that address each of these use cases.</para>
|
|
<section xml:id="bursting-to-public-openstack-cloud">
|
|
<title>Bursting to a public OpenStack cloud</title>
|
|
<para>Company A's data center is running low on
|
|
capacity. It is not possible to expand the data center in the
|
|
foreseeable future. In order to accommodate
|
|
the continuously growing need for development resources in the
|
|
organization, Company A decides to use resources in the public
|
|
cloud.</para>
|
|
<para>Company A has an established data
|
|
center with a substantial amount of hardware. Migrating the
|
|
workloads to a public cloud is not feasible.</para>
|
|
<para>The company has an internal cloud management platform that
|
|
directs requests to the appropriate cloud, depending on
|
|
the local capacity. This is a custom in-house application written for
|
|
this specific purpose.</para>
|
|
<para>This solution is depicted in the figure below:</para>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata contentwidth="4in"
|
|
fileref="../figures/Multi-Cloud_Priv-Pub3.png"
|
|
/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
<para>This example shows two clouds with a Cloud Management
|
|
Platform (CMP) connecting them. This guide does not
|
|
discuss a specific CMP, but describes how the Orchestration and
|
|
Telemetry services handle, manage, and control workloads.</para>
|
|
<para>The private OpenStack cloud has at least one
|
|
controller and at least one compute node. It includes
|
|
metering using the Telemetry service. The Telemetry service
|
|
captures the load increase and the CMP processes the information.
|
|
If there is available capacity, the CMP uses the
|
|
OpenStack API to call the Orchestration service. This creates
|
|
instances on the private cloud in response to user requests.
|
|
When capacity is not available on the private cloud,
|
|
the CMP issues a request to the Orchestration service API of
|
|
the public cloud. This creates the instance on the public
|
|
cloud.</para>
|
|
<para>In this example, Company A does not direct the deployments to an
|
|
external public cloud due to concerns regarding resource control,
|
|
security, and increased operational expense</para>
|
|
</section>
|
|
|
|
<section xml:id="bursting-to-public-nonopenstack-cloud">
|
|
<title>Bursting to a public non-OpenStack cloud</title>
|
|
<para>The second example examines bursting workloads from the
|
|
private cloud into a non-OpenStack public cloud using Amazon
|
|
Web Services (AWS) to take advantage of additional capacity
|
|
and to scale applications.</para>
|
|
<para>The following diagram demonstrates an OpenStack-to-AWS hybrid
|
|
cloud:</para>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata contentwidth="4in"
|
|
fileref="../figures/Multi-Cloud_Priv-AWS4.png"
|
|
/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
<para>Company B states that its developers are already using AWS and
|
|
do not want to change to a different provider.</para>
|
|
<para>If the CMP is capable of connecting to an external
|
|
cloud provider with an appropriate API, the workflow process
|
|
remains the same as the previous scenario. The actions the
|
|
CMP takes, such as monitoring loads and creating new instances,
|
|
stay the same. However, the CMP performs actions in the
|
|
public cloud using applicable API calls.</para>
|
|
<para>If the public cloud is AWS, the CMP would use the
|
|
EC2 API to create a new instance and assign an Elastic IP.
|
|
It can then add that IP to HAProxy in the private cloud.
|
|
The CMP can also reference AWS-specific
|
|
tools such as CloudWatch and CloudFormation.</para>
|
|
<para>Several open source tool kits for building CMPs are
|
|
available and can handle this kind of translation. Examples include
|
|
ManageIQ, jClouds, and JumpGate.</para>
|
|
</section>
|
|
|
|
<section xml:id="high-availability-disaster-recovery">
|
|
<title>High availability and disaster recovery</title>
|
|
<para>Company C requires their local data center
|
|
to be able to recover from failure. Some of the
|
|
workloads currently in use are running on their private
|
|
OpenStack cloud. Protecting the data involves Block Storage,
|
|
Object Storage, and a database. The architecture
|
|
supports the failure of large components of the system while
|
|
ensuring that the system continues to deliver services.
|
|
While the services remain available to users, the failed
|
|
components are restored in the background based on standard
|
|
best practice data replication policies. To achieve these objectives,
|
|
Company C replicates data to a second cloud in a geographically distant
|
|
location. The following diagram describes this system:</para>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata contentwidth="4in"
|
|
fileref="../figures/Multi-Cloud_failover2.png"
|
|
/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
<para>This example includes two private OpenStack clouds connected
|
|
with a CMP. The source cloud,
|
|
OpenStack Cloud 1, includes a controller and at least one
|
|
instance running MySQL. It also includes at least one Block
|
|
Storage volume and one Object Storage volume. This means that data
|
|
is available to the users at all times. The details of the
|
|
method for protecting each of these sources of data
|
|
differs.</para>
|
|
<para>Object Storage relies on the replication capabilities of
|
|
the Object Storage provider. Company C enables OpenStack Object Storage
|
|
so that it creates geographically separated replicas
|
|
that take advantage of this feature. The company configures storage
|
|
so that at least one replica exists in each cloud. In order to make
|
|
this work, the company configures a single array spanning both clouds
|
|
with OpenStack Identity. Using Federated Identity, the array talks
|
|
to both clouds, communicating with OpenStack Object Storage
|
|
through the Swift proxy.</para>
|
|
<para>For Block Storage, the replication is a little more
|
|
difficult, and involves tools outside of OpenStack itself. The
|
|
OpenStack Block Storage volume is not set as the drive itself
|
|
but as a logical object that points to a physical back end. Disaster
|
|
recovery is configured for Block Storage for
|
|
synchronous backup for the highest level of data protection,
|
|
but asynchronous backup could have been set as an alternative
|
|
that is not as latency sensitive. For asynchronous backup, the
|
|
Block Storage API makes it possible to export the data and also the
|
|
metadata of a particular volume, so that it can be moved and
|
|
replicated elsewhere. More information can be found here:
|
|
<link
|
|
xlink:href="https://blueprints.launchpad.net/cinder/+spec/cinder-backup-volume-metadata-support">
|
|
https://blueprints.launchpad.net/cinder/+spec/cinder-backup-volume-metadata-support</link>.
|
|
</para>
|
|
<para>The synchronous backups create an identical volume in both
|
|
clouds and chooses the appropriate flavor so that each cloud
|
|
has an identical back end. This is done by creating volumes
|
|
through the CMP. After this is configured, a solution
|
|
involving DRDB synchronizes the physical drives.</para>
|
|
<para>The database component is backed up using synchronous
|
|
backups. MySQL does not support geographically diverse
|
|
replication, so disaster recovery is provided by replicating
|
|
the file itself. As it is not possible to use Object Storage
|
|
as the back end of a database like MySQL, Swift replication
|
|
is not an option. Company C decides not to store the data on
|
|
another geo-tiered storage system, such as Ceph, as Block
|
|
Storage. This would have given another layer of protection.
|
|
Another option would have been to store the database on an
|
|
OpenStack Block Storage volume and backing it up like any
|
|
other Block Storage.</para>
|
|
</section>
|
|
</section>
|