openstack/openstack-manuals
Code Issues Proposed changes

Merge "[arch-design] Convert hybrid architecture to RST"

Browse Source
This commit is contained in:
Jenkins 2015-11-07 17:11:14 +00:00 committed by Gerrit Code Review
commit 3efde2ba41
2 changed files with 150 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
doc/arch-design-rst/source/hybrid.rst
View File

@ -5,4 +5,5 @@ Hybrid
.. toctree::
:maxdepth: 2
hybrid/architecture-hybrid.rst
hybrid/prescriptive-examples-hybrid.rst

149
doc/arch-design-rst/source/hybrid/architecture-hybrid.rst Normal file
View File

@ -0,0 +1,149 @@
============
Architecture
============
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.
For your chosen cloud management platform, note the relative
levels of support for both monitoring and orchestration.
.. figure:: ../figures/Multi-Cloud_Priv-AWS4.png
:width: 100%
Image portability
~~~~~~~~~~~~~~~~~
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.
Conversion tools exist to address image format compatibility.
Examples include `virt-p2v/virt-v2v <http://libguestfs.org/virt-v2v>`_
and `virt-edit <http://libguestfs.org/virt-edit.1.html>`_.
These tools cannot serve beyond basic cloud instance specifications.
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.
Upper-layer services
~~~~~~~~~~~~~~~~~~~~
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.
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.
For example, moving an application that uses a NoSQL database
service such as MongoDB could cause difficulties in maintaining
the application between the platforms.
There are a number of options that are appropriate for
the hybrid cloud use case:
* 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.
* For example, through the :term:`Database service` for OpenStack
(:term:`trove`), 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.
* Deploying a :term:`Platform-as-a-Service (PaaS)` 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.
* Using automation tools to create the required upper-layer services
that are portable across all cloud platforms.
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.
Network services
~~~~~~~~~~~~~~~~
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:
* Functionality
* Security
* Scalability
* High availability (HA)
Verify and test critical cloud endpoint features.
* After selecting the network functionality framework,
you must confirm the functionality is compatible.
This ensures testing and functionality persists
during and after upgrades.
.. note::
Diverse cloud platforms may de-synchronize over time
if you do not maintain their mutual compatibility.
This is a particular issue with APIs.
* 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.
* 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.
* 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
:ref:`Security Requirements Chapter <security>`
Data
~~~~
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.
Organizations must find the right balance between
data integrity and data availability. Replication strategy may
also influence disaster recovery methods.
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.
.. note::
When running embedded object store methods, ensure that you do not
instigate extra data replication as this can cause performance issues.