openstack/openstack-manuals
Code Issues Proposed changes

Clean up prescriptive_examples_hybrid.xml

Browse Source 
Change-Id: Ic8fda5cd75bd587d7157beff661e8ce7eb911d55
Implements: blueprint arch-guide
This commit is contained in:
Brian Moss 2015-08-14 15:43:44 +10:00
parent edd448785b
commit 1b69ebaf7d
1 changed files with 57 additions and 67 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

124
doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml
View File

@ -6,7 +6,7 @@
xml:id="prescriptive-examples-multi-cloud">
<?dbhtml stop-chunking?>
<title>Prescriptive examples</title>
<para>Multi-cloud environments are designed for
<para>Hybrid cloud environments are designed for
these use cases:</para>
<itemizedlist>
<listitem>
@ -22,26 +22,24 @@
diversity)</para>
</listitem>
</itemizedlist>
<para>This chapter discusses examples of environments
<para>This chapter provides 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
<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
organisation, Company A decided to use
resources in the public cloud.</para>
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
will direct requests to the appropriate cloud, depending on
the local capacity.</para>
<note>
<para>This is a custom in-house application written for
directs requests to the appropriate cloud, depending on
the local capacity. This is a custom in-house application written for
this specific purpose.</para>
</note>
<para>This solution is described in the figure
below.</para>
<para>This solution is depicted in the figure below:</para>
<mediaobject>
<imageobject>
<imagedata contentwidth="4in"
@ -49,18 +47,14 @@
/>
</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>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 provided by the Telemetry module. The Telemetry module
captures the load increase, and the CMP processes the information.
controller and at least one compute node. It includes
metering using 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.
@ -68,19 +62,19 @@
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>
<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 looks into bursting workloads from the
<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 scale applications.</para>
<para>For an OpenStack-to-AWS hybrid cloud, the architecture looks
similar to the figure below:</para>
and to scale applications.</para>
<para>The following diagram demonstrates an OpenStack-to-AWS hybrid
cloud:</para>
<mediaobject>
<imageobject>
<imagedata contentwidth="4in"
@ -88,40 +82,38 @@
/>
</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
<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.
That IP can then be added to HAProxy in the private cloud.
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. This includes
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/disaster recovery</title>
<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 is designed
to support the failure of large components of the system, yet
ensuring that the system will continue to deliver services.
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 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>
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"
@ -133,24 +125,24 @@
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
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. 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
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. The
disaster recovery is configured for Block Storage for
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
@ -163,21 +155,19 @@
</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>
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
was not an option. It was decided not to store the data on
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 just as any
OpenStack Block Storage volume and backing it up like any
other Block Storage.</para>
</section>
</section>