openstack/openstack-manuals
Code Issues Proposed changes

Arch Design: Edits on hybrid

Browse Source 
General edits, especially:
Add links, fix capitalization, improve markup.

Change-Id: Ifda431c0f7e986d96e72bf5be996235039e3df71
This commit is contained in:
Andreas Jaeger 2014-08-01 20:32:53 +02:00
parent 665cbe55bf
commit 831bdec5fd
5 changed files with 100 additions and 56 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
doc/arch-design/hybrid/section_architecture_hybrid.xml
View File

@ -16,8 +16,8 @@
the need to create workarounds and processes to fill
identified gaps. Note the evaluation of the monitoring and
orchestration APIs available on each cloud platform and the
relative levels of support for them in the chosen Cloud
Management Platform.</para>
relative levels of support for them in the chosen cloud
management platform.</para>
<mediaobject>
<imageobject>
<imagedata contentwidth="4in"
@ -38,20 +38,24 @@
is a public cloud that is outside of the control of the
designers.</para>
<para>There are conversion tools such as virt-v2v
(http://libguestfs.org/virt-v2v/) and virt-edit
(http://libguestfs.org/virt-edit.1.html) that can be used in
those scenarios but they are often not suitable beyond very
basic cloud instance specifications. An alternative is to
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,
driven by the CMP, for more specific templating. Another more
expensive option is to use a commercial image migration tool.
The issue of image portability is not just for a one time
migration. If the intention is to use the multiple cloud for
disaster recovery, application diversity or high availability,
the images and instances are likely to be moved between the
different cloud platforms regularly.</para></section>
(<link
xlink:href="http://libguestfs.org/virt-v2v">http://libguestfs.org/virt-v2</link>)
and virt-edit (<link
xlink:href="http://libguestfs.org/virt-edit.1.html">http://libguestfs.org/virt-edit.1.html</link>)
that can be used in those scenarios but they are often not
suitable beyond very basic cloud instance specifications. An
alternative is to 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, driven by the CMP, for more specific
templating. Another more expensive option is to use a
commercial image migration tool. The issue of image
portability is not just for a one time migration. If the
intention is to use the multiple cloud for disaster recovery,
application diversity or high availability, the images and
instances are likely to be moved between the different cloud
platforms regularly.</para></section>
<section xml:id="upper-layer-services">
<title>Upper-layer services</title>
<para>Many clouds offer complementary services over and above the
@ -116,7 +120,7 @@
multiple cloud architectures. It could be an important factor
to assess when choosing a CMP and cloud provider.
Considerations are: functionality, security, scalability and
High availability (HA). Verification and ongoing testing of
high availability (HA). Verification and ongoing testing of
the critical features of the cloud endpoint used by the
architecture are important tasks.</para>
<itemizedlist>
@ -142,8 +146,8 @@
<listitem>
<para>High availability (HA) implementations vary in
functionality and design. Examples of some common
methods are Active-Hot-Standby, Active-Passive and
Active-Active. High availability and a test framework
methods are active-hot-standby, active-passive and
active-active. High availability and a test framework
need to be developed to insure that the functionality
and limitations are well understood.</para>
</listitem>

4
doc/arch-design/hybrid/section_operational_considerations_hybrid.xml
View File

@ -70,8 +70,8 @@
in one of the cloud solutions in use to support the new
functionality.</para></section>
<section xml:id="network-operation-center-noc">
<title>Network Operation Center (NOC)</title>
<para>When planning the Network Operation Center for a hybrid
<title>Network Operation Center</title>
<para>When planning the Network Operation Center (NOC) for a hybrid
cloud environment, it is important to recognize where control
over each piece of infrastructure resides. If a significant
portion of the cloud is on externally managed systems, be

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

@ -18,7 +18,7 @@
non-OpenStack clouds</para>
</listitem>
<listitem>
<para>High Availability across clouds (for technical
<para>High availability across clouds (for technical
diversity)</para>
</listitem>
</itemizedlist>
@ -84,7 +84,7 @@
/>
</imageobject>
</mediaobject>
<para>In this scenario CompanyA has an additional requirement in
<para>In this scenario company A has an additional requirement in
that the developers were already using AWS for some of their
work and did not want to change the cloud provider. Primarily
due to excessive overhead with network firewall rules that
@ -152,10 +152,12 @@
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
Cinder API makes it possible to export the data and also 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:
https://blueprints.launchpad.net/cinder/+spec/cinder-backup-volume-metadata-support.</para>
<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

28
doc/arch-design/hybrid/section_tech_considerations_hybrid.xml
View File

@ -1,4 +1,8 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE section [
<!ENTITY % openstack SYSTEM "../../common/entities/openstack.ent">
%openstack;
]>
<section xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
@ -91,8 +95,8 @@
rates.</para>
<para>Oversubscription is a method to emulate more capacity than
they may physically be present. For example, a physical
hypervisor node with 32 gigabytes of RAM may host 24
instances, each provisioned with 2 gigabytes of RAM. As long
hypervisor node with 32&nbsp;GB RAM may host 24
instances, each provisioned with 2&nbsp;GB RAM. As long
as all 24 of them are not concurrently utilizing 2 full
gigabytes, this arrangement is a non-issue. However, some
hosts take oversubscription to extremes and, as a result,
@ -161,7 +165,7 @@
parameters, user names, and passwords. In deployments behind an
organization's firewall, this domain is considered trusted. In
a public cloud model which could be part of an architecture,
this would have to be assessed with the Public Cloud provider
this would have to be assessed with the public cloud provider
to understand the controls in place.</para>
<para>The data security domain is concerned primarily with
information pertaining to the storage services within
@ -216,8 +220,12 @@
cloud may not do the same in another. Be sure to know the
security requirements of every cloud that handles the
organization's data or workloads.</para>
<para>More information on OpenStack Security can be found at
http://docs.openstack.org/security-guide/</para></section>
<para>More information on OpenStack Security can be found in the
<link
xlink:href="http://docs.openstack.org/security-guide"><citetitle>OpenStack
Security Guide</citetitle></link>.
</para>
</section>
<section xml:id="utilization-hybrid">
<title>Utilization</title>
<para>When it comes to utilization, it is important that the CMP
@ -279,7 +287,7 @@
considered:</para>
<itemizedlist>
<listitem>
<para>OpenStack Compute (Nova): Regardless of deployment
<para>OpenStack Compute (nova): Regardless of deployment
location, hypervisor choice has a direct effect on how
difficult it is to integrate with one or more
additional clouds. For example, integrating a Hyper-V
@ -287,18 +295,18 @@
compatibility issues than if KVM is used.</para>
</listitem>
<listitem>
<para>Networking: Whether OpenStack Networking (Neutron)
or Nova-network is used, the network is one place
<para>Networking: Whether OpenStack Networking (neutron)
or nova-network is used, the network is one place
where integration capabilities need to be understood
in order to connect between clouds.</para>
</listitem>
<listitem>
<para>Telemetry module (Ceilometer): Use of Telemetery
<para>Telemetry module (ceilometer): Use of Telemetery
depends, in large part, on what the other parts of the
cloud are using.</para>
</listitem>
<listitem>
<para>Orchestration module (Heat): Similarly, Orchestration can
<para>Orchestration module (heat): Similarly, Orchestration can
be a valuable tool in orchestrating tasks a CMP
decides are necessary in an OpenStack-based
cloud.</para>

72
doc/arch-design/hybrid/section_user_requirements_hybrid.xml
View File

@ -14,9 +14,11 @@
risks.</para>
<para>Business considerations to make when designing a hybrid
cloud deployment include:</para>
<itemizedlist>
<variablelist>
<varlistentry>
<term>Cost</term>
<listitem>
<para>Cost: A hybrid cloud architecture involves multiple
<para>A hybrid cloud architecture involves multiple
vendors and technical architectures. These
architectures may be more expensive to deploy and
maintain. Operational costs can be higher because of
@ -26,8 +28,11 @@
virtue of using a cloud brokerage tool to deploy the
workloads to the most cost effective platform.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Revenue opportunity</term>
<listitem>
<para>Revenue opportunity: Revenue opportunities vary
<para>Revenue opportunities vary
greatly based on the intent and use case of the cloud.
If it is being built as a commercial customer-facing
product, consider the drivers for building it over
@ -36,8 +41,11 @@
customers, thus enhancing the revenue
opportunity.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Time to market</term>
<listitem>
<para>Time to Market: One of the most common reasons to
<para>One of the most common reasons to
use cloud platforms is to speed the time to market of
a new product or application. A business requirement
to use multiple cloud platforms may be because there
@ -46,23 +54,30 @@
migrating components and refactoring to a single
platform.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Business or technical diversity</term>
<listitem>
<para>Business or technical diversity: Organizations
<para>Organizations
already leveraging cloud-based services may wish to
embrace business diversity and utilize a hybrid cloud
design to spread their workloads across multiple cloud
providers so that no application is hosted in a single
cloud provider.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Application momentum</term>
<listitem>
<para>Application momentum: A business with existing
<para>A business with existing
applications that are already in production on
multiple cloud environments may find that it is more
cost effective to integrate the applications on
multiple cloud platforms rather than migrate them to a
single platform.</para>
</listitem>
</itemizedlist>
</varlistentry>
</variablelist>
<section xml:id="legal-requirements-hybrid">
<title>Legal requirements</title>
<para>Many jurisdictions have legislative and regulatory
@ -91,12 +106,14 @@
</listitem>
</itemizedlist>
<para>Examples of such legal frameworks include the data
protection framework of the European Union
(http://ec.europa.eu/justice/data-protection/) and the
requirements of the Financial Industry Regulatory Authority
(http://www.finra.org/Industry/Regulation/FINRARules/) in the
United States. Consult a local regulatory body for more
information.</para></section>
protection framework of the European Union (<link
xlink:href="http://ec.europa.eu/justice/data-protection/">http://ec.europa.eu/justice/data-protection/</link>)
and the requirements of the Financial Industry Regulatory
Authority (<link
xlink:href="http://ec.europa.eu/justice/data-protection/">http://www.finra.org/Industry/Regulation/FINRARules/</link>)
in the United States. Consult a local regulatory body for more
information.</para>
</section>
<section xml:id="workload-considerations">
<title>Workload considerations</title>
<para>Defining what the word "workload" means in the context of a
@ -246,8 +263,8 @@
<listitem>
<para>High availability implementations vary in
functionality and design. Examples of some common
methods are Active-Hot-Standby, Active-Passive and
Active-Active. High availability and a test framework
methods are active-hot-standby, active-passive and
active-active. High availability and a test framework
needs to be developed to insure that the functionality
and limitations are well understood.</para>
</listitem>
@ -269,9 +286,11 @@
could remain operational.</para>
<para>Risks that will be heightened by using a hybrid cloud
architecture include:</para>
<itemizedlist>
<variablelist>
<varlistentry>
<term>Provider availability or implementation details</term>
<listitem>
<para>Provider availability or implementation details:
<para>
This can range from the company going out of business
to the company changing how it delivers its services.
Cloud architectures are inherently designed to be
@ -279,8 +298,11 @@
both perceived to be rock solid and ever flexible at
the same time.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Differing SLAs</term>
<listitem>
<para>Differing SLAs: Users of hybrid cloud environments
<para>Users of hybrid cloud environments
potentially encounter some losses through differences
in service level agreements. A hybrid cloud design
needs to accommodate the different SLAs provided by
@ -288,8 +310,11 @@
address the actual enforceability of the providers'
SLAs.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Security levels</term>
<listitem>
<para>Security levels: Securing multiple cloud
<para>Securing multiple cloud
environments is more complex than securing a single
cloud environment. Concerns need to be addressed at,
but not limited to, the application, network, and
@ -300,8 +325,11 @@
uses a relatively simple model that relies on user
privilege combined with firewalls.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Provider API changes</term>
<listitem>
<para>Provider API changes: APIs are crucial in a hybrid
<para>APIs are crucial in a hybrid
cloud environment. As a consumer of a provider's cloud
services, an organization will rarely have any control
over provider changes to APIs. Cloud services that
@ -315,5 +343,7 @@
common and basic APIs to minimize potential
conflicts.</para>
</listitem>
</itemizedlist></section>
</varlistentry>
</variablelist>
</section>
</section>