openstack/openstack-manuals
Code Issues Proposed changes

Clean up tech_considerations_hybrid.xml

Browse Source 
Change-Id: Ib230052311f0f94045b73556aae945ba195137f8
Implements: blueprint arch-guide
This commit is contained in:
Brian Moss 2015-08-14 13:05:08 +10:00
parent 47f1cadeac
commit cedca8d3f0
1 changed files with 112 additions and 237 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -11,311 +11,186 @@
<?dbhtml stop-chunking?> <?dbhtml stop-chunking?>
<title>Technical considerations</title> <title>Technical considerations</title>
<para>A hybrid cloud environment requires inspection and <para>A hybrid cloud environment requires inspection and
understanding of technical issues that are not only outside of understanding of technical issues in external data centers that may
an organization's data center, but potentially outside of an not be in your control. Ideally, select an architecture
organization's control. In many cases, it is necessary to and CMP that are adaptable to changing environments.</para>
ensure that the architecture and CMP chosen are adaptable. <para>Using diverse cloud platforms increases the risk of compatibility
All of these factors influence issues, but clouds using the same version and distribution
and add complexity to the design of the hybrid cloud architecture.</para> of OpenStack are less likely to experience problems.</para>
<para>Incompatibilities with other cloud platforms are inevitable,
however, clouds using the same version and distribution
of OpenStack are unlikely to experience any issues.</para>
<para>Clouds that exclusively use the same versions of OpenStack should <para>Clouds that exclusively use the same versions of OpenStack should
have no issues, regardless of distribution. The newer the distribution in have no issues, regardless of distribution. More recent distributions
question, the less likely it is that there will be are less likely to encounter incompatibility between versions. An
incompatibilities between versions. An OpenStack community initiative defines OpenStack community initiative defines core functions that need to
core functions that need to remain backward compatible between supported remain backward compatible between supported versions. For example, the
versions.</para> DefCore initiative defines basic functions that every distribution must
<note> support in order to use the name <productname>OpenStack</productname>.
<para>For example, the DefCore initiative defines </para>
basic functions that every distribution must support in order
to bear the name <productname>OpenStack</productname>.</para>
</note>
<para>Vendors can add proprietary customization to their distributions. If <para>Vendors can add proprietary customization to their distributions. If
an application or architecture makes use of these features, it will be an application or architecture makes use of these features, it can be
difficult to migrate to or use other types of environments.</para> difficult to migrate to or use other types of environments.</para>
<para>If an environment includes non-OpenStack clouds, it may experience <para>If an environment includes non-OpenStack clouds, it may experience
compatibility problems. CMP tools must account for the differences in the compatibility problems. CMP tools must account for the differences in
handling of operations and implementation of services. Some situations in which these the handling of operations and the implementation of services.</para>
incompatibilities can arise include differences between the way in which a
cloud:</para>
<itemizedlist> <itemizedlist>
<title>Possible cloud incompatibilities</title>
<listitem> <listitem>
<para>Deploys instances</para> <para>Instance deployment</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Manages networks</para> <para>Network management</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Treats applications</para> <para>Application management</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Implements services</para> <para>Services implementation</para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
<section xml:id="capacity-planning-hybrid"> <section xml:id="capacity-planning-hybrid">
<title>Capacity planning</title> <title>Capacity planning</title>
<para>One of the primary reasons many organizations turn to a <para>One of the primary reasons many organizations use a
hybrid cloud system is to increase capacity without having to hybrid cloud is to increase capacity without making large capital
make large capital investments.</para> investments.</para>
<para>Capacity, and the placement of workloads, <para>Capacity and the placement of workloads are key design considerations
accounts for the design of a mostly for hybrid clouds. The long-term capacity plan for these
internally-operated cloud. designs must incorporate growth over time to prevent permanent
The long-term capacity plan for this design must incorporate consumption of more expensive external clouds. To avoid this scenario,
growth over time to prevent permanent consumption of a more account for future applications' capacity requirements and plan growth
expensive external cloud. In order to avoid this scenario, we appropriately.</para>
recommend accounting for the future applications' capacity <para>It is difficult to predict the amount of load a particular
requirements and plan growth appropriately.</para> application might incur if the number of users fluctuates, or the
<para>Unpredictability is a consideration for capacity planning. It is application experiences an unexpected increase in use. It is
difficult to predict the amount of load a particular application possible to define application requirements in terms of vCPU, RAM,
might incur if the number of users fluctuate, or the application bandwidth, or other resources and plan appropriately. However, other
experiences an unexpected increase in popularity. It is possible clouds might not use the same meter or even the same oversubscription
to define application requirements in terms of vCPU, RAM, bandwidth rates.</para>
or other resources and plan appropriately. However, other clouds
might not use the same meter or even the same oversubscription rates.</para>
<para>Oversubscription is a method to emulate more capacity than <para>Oversubscription is a method to emulate more capacity than
may physically be present. For example, a physical may physically be present. For example, a physical
hypervisor node with 32&nbsp;GB RAM may host 24 hypervisor node with 32&nbsp;GB RAM may host 24
instances, each provisioned with 2&nbsp;GB RAM. As long instances, each provisioned with 2&nbsp;GB RAM. As long
as all 24 instances are not concurrently utilizing 2 full as all 24 instances do not concurrently use 2 full
gigabytes, this arrangement is a non-issue. However, some gigabytes, this arrangement works well. However, some
hosts take oversubscription to extremes and, as a result, hosts take oversubscription to extremes and, as a result,
performance can frequently be inconsistent. If at all performance can be inconsistent. If at all
possible, determine what the oversubscription rates of each possible, determine what the oversubscription rates of each
host are and plan capacity accordingly.</para> host are and plan capacity accordingly.</para>
</section> </section>
<section xml:id="security-hybrid">
<title>Security</title>
<para>Security domains are an important distinction when planning for a hybrid
cloud environment and its capabilities. A security domain
comprises users, applications, servers or networks that share
common trust requirements and expectations within a
system.</para>
<para>The security domains are:</para>
<orderedlist>
<listitem>
<para>Public</para>
</listitem>
<listitem>
<para>Guest</para>
</listitem>
<listitem>
<para>Management</para>
</listitem>
<listitem>
<para>Data</para>
</listitem>
</orderedlist>
<para>You can map the security domains individually to the
organization's installation or combine them. For example, some
deployment topologies combine both guest and data domains onto
one physical network, whereas other topologies physically
separate the networks. In each case, the cloud operator
should be aware of the appropriate security concerns. We recommend
mapping security domains against the specific OpenStack
deployment topology. The domains and their trust requirements
depend upon whether the cloud instance is public, private, or
hybrid.</para>
<para>The public security domain is an entirely untrusted area of
the cloud infrastructure. It can refer to the internet as a
whole, or simply to networks over which an organization has no
authority. Do not trust this domain.
For example, in a hybrid cloud deployment, any information traversing
between and beyond the clouds is of the public domain and untrustworthy.</para>
<para>The guest security domain handles compute
data. Instances on the cloud generate the data, but not services that
support the operation of the cloud, such as API calls. We recommend not
to trust this domain if you are a public cloud provider that
uses hybrid cloud configurations, or a private cloud provider who does
not have controls on instance use and allows unrestricted internet access
to instances. Private cloud providers, however, can use this network as
an internally trusted network if controls are in place.</para>
<para>The management security domain is where services interact.
The networks in this domain transport confidential data such as configuration
parameters, user names, and passwords. Trust this domain when it is
behind an organization's firewall in deployments.</para>
<para>The data security domain is concerned primarily with
information pertaining to the storage services within
OpenStack. The data that crosses this network has integrity and
confidentiality requirements. Depending on the type of deployment there
may also be availability requirements. The trust level of this network
is heavily dependent on deployment decisions and does not have a default
level of trust.</para>
<para>When operating or utilizing public or private clouds, consider the management
of the users. The identity service allows for LDAP to be part of the
authentication process. Including these systems in your
OpenStack deployments may ease user management if integrating
into existing systems.</para>
<warning>
<para>Be mindful of consistency when utilizing third party
clouds to explore authentication options.</para>
</warning>
<para>Due to the passing of user names, passwords, and tokens between
client machines and API endpoints, we recommend the placement of API
services behind hardware to perform SSL termination.</para>
<para>The hypervisor also requires a security assessment. In a public cloud,
organizations typically do not have control over the choice of
hypervisor. For example, Amazon uses its own particular version of Xen.
Properly securing your hypervisor is important. Attacks made upon the
unsecured hypervisor are called a "hypervisor breakout".
Hypervisor breakout describes the event of a
compromised or malicious instance breaking out of the resource
controls of the hypervisor and gaining access to the bare
metal operating system and hardware resources.</para>
<para>There is not an issue if the security of instances is not important.
However, enterprises need to avoid vulnerability. The only way to
do this is to avoid the situation where the instances are running
on a public cloud. That does not mean that there is a
need to own all of the infrastructure on which an OpenStack
installation operates; it suggests avoiding situations in which
sharing hardware with others occurs.</para>
<para>There are other services worth considering that provide a
bare metal instance instead of a cloud. In other cases, it is
possible to replicate a second private cloud by integrating
with a private Cloud-as-a-Service deployment. The
organization does not buy the hardware, but also does not share
with other tenants. It is also possible to use a provider that
hosts a bare-metal "public" cloud instance for which the
hardware is dedicated only to one customer, or a provider that
offers private Cloud-as-a-Service.</para>
<para>It is important to realize that each cloud
implements services differently. What keeps data secure in one
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 in the
<link
xlink:href="http://docs.openstack.org/security-guide"><citetitle>OpenStack
Security Guide</citetitle></link>.
</para>
</section>
<section xml:id="utilization-hybrid"> <section xml:id="utilization-hybrid">
<title>Utilization</title> <title>Utilization</title>
<para>When it comes to utilization, it is important that the CMP <para>A CMP must be aware of what workloads are running, where they are
understands what workloads are running, where they are
running, and their preferred utilizations. For example, in running, and their preferred utilizations. For example, in
most cases it is desirable to run as many workloads internally most cases it is desirable to run as many workloads internally
as possible, utilizing other resources only when necessary. On as possible, utilizing other resources only when necessary. On
the other hand, situations exist in which the opposite is the other hand, situations exist in which the opposite is
true. The internal cloud may only be for development and true, such as when an internal cloud is only for development and
stressing it is undesirable. In most cases, a cost model of stressing it is undesirable. A cost model of various scenarios and
various scenarios helps with this decision. However, internal consideration of internal priorities helps with this decision. To
priorities influence this analysis. To improve efficiency, improve efficiency, automate these decisions when possible.</para>
make these decisions programmatically.</para> <para>The Telemetry module (ceilometer) provides information on the usage
<para>The Telemetry module (ceilometer) of various OpenStack components. Note the following:</para>
provides information on the usage of various OpenStack
components. There are two limitations to consider:</para>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para> <para>
If there is to be a large amount of data (for example, if If Telemetry must retain a large amount of data, for
monitoring a large cloud, or a very active one) it is example when monitoring a large or active cloud, we recommend
desirable to use a NoSQL back end for Ceilometer, such as using a NoSQL back end such as MongoDB.</para>
MongoDB.</para>
</listitem> </listitem>
<listitem> <listitem>
<para> <para>
You must monitor connections to non-OpenStack clouds You must monitor connections to non-OpenStack clouds
and report this information to the CMP.</para> and report this information to the CMP.</para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
</section> </section>
<section xml:id="performance-hybrid"> <section xml:id="performance-hybrid">
<title>Performance</title> <title>Performance</title>
<para>Performance is of the upmost importance in the design of a <para>Performance is critical to hybrid cloud deployments, and they are
cloud. When it comes to a hybrid cloud deployment, many of the affected by many of the same issues as multi-site deployments,
same issues for multi-site deployments apply, such as network such as network latency between sites. Also consider the time required
latency between sites. It is also important to think about the to run a workload in different clouds and methods for reducing this
speed at which a workload can be spun up in another cloud, and time. This may require moving data closer to applications
how to reduce the time necessary to accomplish the task. or applications closer to the data they process, and
This may mean moving data closer to applications
or applications closer to the data they process, including a
grouping functionality so that connections that grouping functionality so that connections that
require low latency take place over a single cloud rather than require low latency take place over a single cloud rather than
spanning clouds. This may also mean ensuring that the CMP has spanning clouds. This may also require a CMP that can determine which
the intelligence to know which cloud can most efficiently run cloud can most efficiently run which types of workloads.</para>
which types of workloads.</para> <para>As with utilization, native OpenStack tools help improve performance.
<para>As with utilization, native OpenStack tools are available to For example, you can use Telemetry to measure performance and the
assist. Ceilometer can measure performance and, if necessary, Orchestration module (heat) to react to changes in demand.</para>
the Orchestration (heat) module can
react to changes in demand by spinning up more resources.</para>
<note> <note>
<para>It is important to note, however, that Orchestration requires <para>Orchestration requires special client configurations to integrate
special configurations in the client to enable functioning with Amazon Web Services. For other types of clouds, use CMP
with solution offerings from Amazon Web Services. When dealing features.
with other types of clouds, it is necessary to rely on the
features of the CMP.
</para> </para>
</note> </note>
</section> </section>
<section xml:id="components"> <section xml:id="components">
<title>Components</title> <title>Components</title>
<para>The number and types of native OpenStack components that are <para>Using more than one cloud in any design requires consideration of
available for use is dependent on whether the deployment is four OpenStack tools:</para>
exclusively an OpenStack cloud or not.</para> <variablelist>
<para>Using more than one cloud in any situation requires <varlistentry>
consideration of four OpenStack tools:</para> <term>OpenStack Compute (nova)</term>
<itemizedlist>
<listitem> <listitem>
<para>OpenStack Compute (nova): Regardless of deployment <para>Regardless of deployment location, hypervisor choice has a
location, hypervisor choice has a direct effect on how direct effect on how difficult it is to integrate with
difficult it is to integrate with one or more additional clouds.</para>
additional clouds. For example, integrating a Hyper-V
based OpenStack cloud with Azure has less
compatibility issues than if KVM is used.</para>
</listitem> </listitem>
</varlistentry>
<varlistentry>
<term>Networking (neutron)</term>
<listitem> <listitem>
<para>Networking (neutron): Whether OpenStack Networking <para>Whether using OpenStack Networking (neutron) or legacy
or legacy networking (nova-network) is used, the network is one place networking (nova-network), it is necessary to understand
where understanding integration capabilities is necessary network integration capabilities in order to
in order to connect between clouds.</para> connect between clouds.</para>
</listitem> </listitem>
</varlistentry>
<varlistentry>
<term>Telemetry module (ceilometer)</term>
<listitem> <listitem>
<para>Telemetry module (ceilometer): Use of Telemetry <para>Use of Telemetry depends, in large part, on what the other
depends, in large part, on what the other parts of the parts of the cloud you are using.</para>
cloud are using.</para>
</listitem> </listitem>
</varlistentry>
<varlistentry>
<term>Orchestration module (heat)</term>
<listitem> <listitem>
<para>Orchestration module (heat): Similarly, Orchestration can <para>Orchestration can be a valuable tool in orchestrating tasks a
be a valuable tool in orchestrating tasks a CMP CMP decides are necessary in an OpenStack-based cloud.</para>
decides are necessary in an OpenStack-based
cloud.</para>
</listitem> </listitem>
</itemizedlist> </varlistentry>
</variablelist>
</section> </section>
<section xml:id="special-considerations-hybrid"> <section xml:id="special-considerations-hybrid">
<title>Special considerations</title> <title>Special considerations</title>
<para>Hybrid cloud deployments also involve two more issues that <para>Hybrid cloud deployments require consideration of two issues that
are not common in other situations:</para> are not common in other situations:</para>
<itemizedlist> <variablelist>
<varlistentry>
<term>Image portability</term>
<listitem> <listitem>
<para>Image portability: Note that, as of the Kilo release, <para>As of the Kilo release, there is no common image format that is
there is no single common image format that is usable by all usable by all clouds. Conversion or recreation of images is necessary
clouds. Conversion or the recreation of images is necessary if migrating between clouds. To simplify deployment, use the smallest
if porting between clouds. To make things simpler, and simplest images feasible, install only what is necessary, and
launch the smallest and simplest images feasible, installing use a deployment manager such as Chef or Puppet. Do not use golden
only what is necessary preferably using a deployment manager images to speed up the process unless you repeatedly deploy the same
such as Chef or Puppet. Do not use golden images for speeding up images on the same cloud.</para>
the process. However, if you repeat the deployment of the same
images, we recommend utilizing this technique instead of provisioning
applications on lighter images each time.</para>
</listitem> </listitem>
</varlistentry>
<varlistentry>
<term>API differences</term>
<listitem> <listitem>
<para>API differences: Avoid using a hybrid cloud deployment with more than <para>Avoid using a hybrid cloud deployment with more than just
just OpenStack (or with different versions of OpenStack). OpenStack (or with different versions of OpenStack) as API changes
The APIs need to perform certain functions that are different. can cause compatibility issues.</para>
The CMP needs to know how to handle all necessary
versions. To get around this issue, some implementers build
portals to achieve a hybrid cloud environment, but a heavily
developer-focused organization may benefit more from a hybrid
cloud broker SDK such as jClouds.</para>
</listitem> </listitem>
</itemizedlist> </varlistentry>
</variablelist>
</section> </section>
</section> </section>