23c74e9879
Removal of passive voice from section_prescriptive_examples Change-Id: I279b1ed884b8f7cad046410bff7f6b36f413175b Partial-bug: #1429696
184 lines
9.2 KiB
XML
184 lines
9.2 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>Multi-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 discusses examples of environments
|
|
that address each of these use cases.</para>
|
|
<para>Company A's data center is running dangerously low on
|
|
capacity. The option of expanding the data center will not be
|
|
possible in the foreseeable future. In order to accommodate
|
|
the continuously growing need for development resources in the
|
|
organisation, Company A decided 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
|
|
will direct requests to the appropriate cloud, depending on
|
|
the local capacity.</para>
|
|
<note>
|
|
<para>This is a custom in-house application written for
|
|
this specific purpose.</para>
|
|
</note>
|
|
<para>This solution is described 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.</para>
|
|
<note>
|
|
<para>This guide does not attempt to
|
|
cover a specific CMP, but describes how the Orchestration and
|
|
Telemetry services handle, manage, and control workloads. This is
|
|
shown in the diagram above.</para>
|
|
</note>
|
|
<para>The private OpenStack cloud has at least one
|
|
controller, and at least one compute node. It includes
|
|
metering provided by the Telemetry module. The Telemetry module
|
|
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" decided
|
|
not to direct the deployment to an external public cloud
|
|
over concerns regarding resource control, security, and
|
|
increase operational expense</para>
|
|
|
|
<section xml:id="bursting-to-public-nonopenstack-cloud">
|
|
<title>Bursting to a public non-OpenStack cloud</title>
|
|
<para>The second example looks into bursting workloads from the
|
|
private cloud into a non-OpenStack public cloud using Amazon
|
|
Web Services (AWS) to take advantage of additional capacity
|
|
and scale applications.</para>
|
|
<para>For an OpenStack-to-AWS hybrid cloud, the architecture looks
|
|
similar to the figure below:</para>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata contentwidth="4in"
|
|
fileref="../figures/Multi-Cloud_Priv-AWS4.png"
|
|
/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
<para>Company B states that the
|
|
developers were already using AWS and did not want to change
|
|
the cloud provider.</para>
|
|
<para>If the CMP is capable of connecting an external
|
|
cloud provider with the appropriate API, the workflow process
|
|
will remain 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 will perform 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.
|
|
That IP can then be added 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. This includes
|
|
ManageIQ, jClouds, and JumpGate.</para>
|
|
</section>
|
|
|
|
<section xml:id="high-availability-disaster-recovery">
|
|
<title>High availability/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 is designed
|
|
to support the failure of large components of the system, yet
|
|
ensuring that the system will continue to deliver services.
|
|
While the services remain available to users, the failed
|
|
components are restored in the background based on standard
|
|
best practice DR policies. To achieve the objectives, data is
|
|
replicated to a second cloud, in a geographically distant
|
|
location. The logical diagram of the system is described in
|
|
the figure below:</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 is so that the 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. OpenStack Object Storage is
|
|
enabled so that it creates geographically separated replicas
|
|
that take advantage of this feature. It is configured so that
|
|
at least one replica exists in each cloud. In order to make
|
|
this work, a single array spanning both clouds is configured
|
|
with OpenStack Identity. Using Federated Identity, it 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. The
|
|
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 was done by creating volumes
|
|
through the CMP. The CMP knows to create identical
|
|
volumes in both clouds. Once this is configured, a solution,
|
|
involving DRDB, is used to synchronize the actual 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
|
|
was not an option. It was decided 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 just as any
|
|
other Block Storage.</para>
|
|
</section>
|
|
</section>
|