Removal of passive voice from chapter 7, arch guide
Removal of passive voice from section_tech_considerations Change-Id: Ib49cef77eeb5e9870a1a9fa3d75f325ad090b0b7 Partial-bug: #1429696
This commit is contained in:
parent
53cc503ed0
commit
7d20231a82
@ -14,45 +14,38 @@
|
||||
understanding of technical issues that are not only outside of
|
||||
an organization's data center, but potentially outside of an
|
||||
organization's control. In many cases, it is necessary to
|
||||
ensure that the architecture and CMP chosen can adapt to, not
|
||||
only to different environments, but also to the possibility of
|
||||
change. In this situation, applications are crossing diverse
|
||||
platforms and are likely to be located in diverse locations.
|
||||
All of these factors will influence and add complexity to the
|
||||
design of a hybrid cloud architecture.</para>
|
||||
<para>The only situation where cloud platform incompatibilities
|
||||
are not going to be an issue is when working with clouds that
|
||||
are based on the same version and the same distribution of
|
||||
OpenStack. Otherwise incompatibilities are virtually
|
||||
inevitable.</para>
|
||||
<para>Incompatibility should be less of an issue for clouds that
|
||||
exclusively use the same version of OpenStack, even if they
|
||||
use different distributions. The newer the distribution in
|
||||
ensure that the architecture and CMP chosen are adaptable.
|
||||
All of these factors influence
|
||||
and add complexity to the design of the hybrid cloud architecture.</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
|
||||
have no issues, regardless of distribution. The newer the distribution in
|
||||
question, the less likely it is that there will be
|
||||
incompatibilities between version. This is due to the fact
|
||||
that the OpenStack community has established an initiative to
|
||||
define core functions that need to remain backward compatible
|
||||
between supported versions. The DefCore initiative defines
|
||||
basic functions that every distribution must support in order
|
||||
to bear the name "OpenStack".</para>
|
||||
<para>Some vendors, however, add proprietary customizations to
|
||||
their distributions. If an application or architecture makes
|
||||
use of these features, it will be difficult to migrate to or
|
||||
use other types of environments. Anyone considering
|
||||
incorporating older versions of OpenStack prior to Havana
|
||||
should consider carefully before attempting to incorporate
|
||||
functionality between versions. Internal differences in older
|
||||
versions may be so great that the best approach might be to
|
||||
consider the versions to be essentially diverse platforms, as
|
||||
different as OpenStack and Amazon Web Services or Microsoft
|
||||
Azure.</para>
|
||||
<para>The situation is more predictable if using different cloud
|
||||
platforms is incorporated from inception. If the other clouds
|
||||
are not based on OpenStack, then all pretense of compatibility
|
||||
vanishes, and CMP tools must account for the myriad of
|
||||
differences in the way operations are handled and services are
|
||||
implemented. Some situations in which these incompatibilities
|
||||
can arise include differences between the way in which a
|
||||
incompatibilities between versions. An OpenStack community initiative defines
|
||||
core functions that need to remain backward compatible between supported
|
||||
versions.</para>
|
||||
<note>
|
||||
<para>For example, the DefCore initiative defines
|
||||
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
|
||||
an application or architecture makes use of these features, it will be
|
||||
difficult to migrate to or use other types of environments.</para>
|
||||
<warning>
|
||||
<para>Anyone planning to use older versions of OpenStack prior
|
||||
to Havana should consider carefully before attempting to incorporate
|
||||
functionality between versions. Internal differences in older
|
||||
versions may be so great that the best approach might be to
|
||||
consider the versions to be essentially diverse platforms, as
|
||||
different as OpenStack is from Amazon Web Services or Microsoft Azure.</para>
|
||||
</warning>
|
||||
<para>If an environment includes non-OpenStack clouds, it may experience
|
||||
compatibility problems. CMP tools must account for the differences in the
|
||||
handling of operations and implementation of services. Some situations in which these
|
||||
incompatibilities can arise include differences between the way in which a
|
||||
cloud:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
@ -68,48 +61,42 @@
|
||||
<para>Implements services</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<section xml:id="capacity-planning-hybrid">
|
||||
<title>Capacity planning</title>
|
||||
<para>One of the primary reasons many organizations turn to a
|
||||
hybrid cloud system is to increase capacity without having to
|
||||
make large capital investments. However, capacity planning is
|
||||
still necessary when designing an OpenStack installation even
|
||||
if it is augmented with external clouds.</para>
|
||||
<para>Specifically, overall capacity and placement of workloads
|
||||
need to be accounted for when designing for a mostly
|
||||
internally-operated cloud with the occasional capacity burs.
|
||||
The long-term capacity plan for such a design needs to
|
||||
incorporate growth over time to prevent the need to
|
||||
permanently burst into, and occupy, a potentially more
|
||||
expensive external cloud. In order to avoid this scenario,
|
||||
account for the future applications and capacity requirements
|
||||
and plan growth appropriately.</para>
|
||||
<para>One of the drawbacks of capacity planning is
|
||||
unpredictability. It is difficult to predict the amount of
|
||||
load a particular application might incur if the number of
|
||||
users fluctuates or the application experiences an unexpected
|
||||
increase in popularity. It is possible to define application
|
||||
requirements in terms of vCPU, RAM, bandwidth or other
|
||||
resources and plan appropriately, but other clouds may not use
|
||||
the same metric or even the same oversubscription
|
||||
rates.</para>
|
||||
make large capital investments.</para>
|
||||
<para>Capacity, and the placement of workloads,
|
||||
accounts for the design of a mostly
|
||||
internally-operated cloud.
|
||||
The long-term capacity plan for this design must incorporate
|
||||
growth over time to prevent permanent consumption of a more
|
||||
expensive external cloud. In order to avoid this scenario, we
|
||||
recommend accounting for the future applications' capacity
|
||||
requirements and plan growth appropriately.</para>
|
||||
<para>Unpredictability is a consideration for capacity planning. It is
|
||||
difficult to predict the amount of load a particular application
|
||||
might incur if the number of users fluctuate, or the application
|
||||
experiences an unexpected increase in popularity. It is possible
|
||||
to define application requirements in terms of vCPU, RAM, bandwidth
|
||||
or other resources and plan appropriately. However, other clouds
|
||||
might not use the same metric or even the same oversubscription rates.</para>
|
||||
<para>Oversubscription is a method to emulate more capacity than
|
||||
they may physically be present. For example, a physical
|
||||
may physically be present. For example, a physical
|
||||
hypervisor node with 32 GB RAM may host 24
|
||||
instances, each provisioned with 2 GB RAM. As long
|
||||
as all 24 of them are not concurrently utilizing 2 full
|
||||
as all 24 instances are not concurrently utilizing 2 full
|
||||
gigabytes, this arrangement is a non-issue. However, some
|
||||
hosts take oversubscription to extremes and, as a result,
|
||||
performance can frequently be inconsistent. If at all
|
||||
possible, determine what the oversubscription rates of each
|
||||
host are and plan capacity accordingly.</para></section>
|
||||
host are and plan capacity accordingly.</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="security-hybrid">
|
||||
<title>Security</title>
|
||||
<para>The nature of a hybrid cloud environment removes complete
|
||||
control over the infrastructure. Security becomes a stronger
|
||||
requirement because data or applications may exist in a cloud
|
||||
that is outside of an organization's control. Security domains
|
||||
become an important distinction when planning for a hybrid
|
||||
<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
|
||||
@ -129,93 +116,79 @@
|
||||
<para>Data</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
<para>These security domains can be mapped individually to the
|
||||
organization's installation or combined. For example, some
|
||||
<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 may physically
|
||||
separate these networks. In each case, the cloud operator
|
||||
should be aware of the appropriate security concerns. Security
|
||||
domains should be mapped out against the specific OpenStack
|
||||
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. This domain should always be considered untrusted.
|
||||
When considering hybrid cloud deployments, any traffic
|
||||
traversing beyond and between the multiple clouds should
|
||||
always be considered to reside in this security domain and is
|
||||
therefore untrusted.</para>
|
||||
<para>Typically used for instance-to-instance traffic within a
|
||||
single data center, the guest security domain handles compute
|
||||
data generated by instances on the cloud but not services that
|
||||
support the operation of the cloud such as API calls. Public
|
||||
cloud providers that are used in a hybrid cloud configuration
|
||||
which an organization does not control and private cloud
|
||||
providers who do not have stringent controls on instance use
|
||||
or who allow unrestricted Internet access to instances should
|
||||
consider this domain to be untrusted. Private cloud providers
|
||||
may consider this network as internal and therefore trusted
|
||||
only if there are controls in place to assert that instances
|
||||
and tenants are trusted.</para>
|
||||
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.
|
||||
Sometimes referred to as the "control plane", the networks in
|
||||
this domain transport confidential data such as configuration
|
||||
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
|
||||
to understand the controls in place.</para>
|
||||
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. Much of the data that crosses this network has high
|
||||
integrity and confidentiality requirements and depending on
|
||||
the type of deployment there may also be strong availability
|
||||
requirements. The trust level of this network is heavily
|
||||
dependent on deployment decisions and as such this is not
|
||||
assigned a default level of trust.</para>
|
||||
<para>Consideration must be taken when managing the users of the
|
||||
system, whether operating or utilizing public or private
|
||||
clouds. The identity service allows for LDAP to be part of the
|
||||
authentication process. Including such systems in your
|
||||
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. Be mindful when utilizing 3rd party
|
||||
clouds to explore authentication options applicable to the
|
||||
installation to help manage and keep user authentication
|
||||
consistent.</para>
|
||||
<para>Due to the process of passing user names, passwords, and
|
||||
generated tokens between client machines and API endpoints,
|
||||
placing API services behind hardware that performs SSL
|
||||
termination is strongly recommended.</para>
|
||||
<para>Within cloud components themselves, another component that
|
||||
needs security scrutiny is the hypervisor. In a public cloud,
|
||||
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. (Amazon uses its own particular version of Xen,
|
||||
for example.) In some cases, hypervisors may be vulnerable to
|
||||
a type of attack called "hypervisor breakout" if they are not
|
||||
properly secured. Hypervisor breakout describes the event of a
|
||||
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>If the security of instances is not considered important,
|
||||
there may not be an issue. In most cases, however, enterprises
|
||||
need to avoid this kind of vulnerability, and the only way to
|
||||
do that is to avoid a situation in which the instances are
|
||||
running on a public cloud. That does not mean that there is a
|
||||
<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 hardware may be shared with others.</para>
|
||||
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, in which an
|
||||
organization does not buy hardware, but also does not share it
|
||||
with other tenants. It is also possible use a provider that
|
||||
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>Finally, it is important to realize that each cloud
|
||||
<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
|
||||
@ -226,6 +199,7 @@
|
||||
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
|
||||
@ -236,68 +210,77 @@
|
||||
the other hand, situations exist in which the opposite is
|
||||
true. The internal cloud may only be for development and
|
||||
stressing it is undesirable. In most cases, a cost model of
|
||||
various scenarios helps with this decision, however this
|
||||
analysis is heavily influenced by internal priorities. The
|
||||
important thing is the ability to efficiently make those
|
||||
decisions on a programmatic basis.</para>
|
||||
<para>The Telemetry module (ceilometer) is designed to
|
||||
provide information on the usage of various OpenStack
|
||||
components. There are two limitations to consider: first, if
|
||||
there is to be a large amount of data (for example, if
|
||||
various scenarios helps with this decision. However, internal
|
||||
priorities influence this analysis. To improve efficiency,
|
||||
make these decisions programmatically.</para>
|
||||
<para>The Telemetry module (ceilometer)
|
||||
provides information on the usage of various OpenStack
|
||||
components. There are two limitations to consider:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
If there is to be a large amount of data (for example, if
|
||||
monitoring a large cloud, or a very active one) it is
|
||||
desirable to use a NoSQL back end for Ceilometer, such as
|
||||
MongoDB. Second, when connecting to a non-OpenStack cloud,
|
||||
there will need to be a way to monitor that usage and to
|
||||
provide that monitoring data back to the CMP.</para></section>
|
||||
MongoDB.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
You must monitor connections to non-OpenStack clouds
|
||||
and report this information to the CMP.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<section xml:id="performance-hybrid">
|
||||
<title>Performance</title>
|
||||
<para>Performance is of primary importance in the design of a
|
||||
<para>Performance is of the upmost importance in the design of a
|
||||
cloud. When it comes to a hybrid cloud deployment, many of the
|
||||
same issues for multi-site deployments apply, such as network
|
||||
latency between sites. It is also important to think about the
|
||||
speed at which a workload can be spun up in another cloud, and
|
||||
what can be done to reduce the time necessary to accomplish
|
||||
that task. That may mean moving data closer to applications,
|
||||
or conversely, applications closer to the data they process.
|
||||
It may mean grouping functionality so that connections that
|
||||
how to reduce the time necessary to accomplish the task.
|
||||
This may mean moving data closer to applications
|
||||
or applications closer to the data they process, including a
|
||||
grouping functionality so that connections that
|
||||
require low latency take place over a single cloud rather than
|
||||
spanning clouds. That may also mean ensuring that the CMP has
|
||||
spanning clouds. This may also mean ensuring that the CMP has
|
||||
the intelligence to know which cloud can most efficiently run
|
||||
which types of workloads.</para>
|
||||
<para>As with utilization, native OpenStack tools are available to
|
||||
assist. Ceilometer can measure performance and, if necessary,
|
||||
the Orchestration module can be used to
|
||||
react to changes in demand by spinning up more resources. It
|
||||
is important to note, however, that Orchestration requires
|
||||
the Orchestration (heat) module can
|
||||
react to changes in demand by spinning up more resources.</para>
|
||||
<note>
|
||||
<para>It is important to note, however, that Orchestration requires
|
||||
special configurations in the client to enable functioning
|
||||
with solution offerings from Amazon Web Services. When dealing
|
||||
with other types of clouds, it is necessary to rely on the
|
||||
features of the CMP.</para></section>
|
||||
features of the CMP.
|
||||
</para>
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<section xml:id="components">
|
||||
<title>Components</title>
|
||||
<para>The number and types of native OpenStack components that are
|
||||
available for use is dependent on whether the deployment is
|
||||
exclusively an OpenStack cloud or not. If so, all of the
|
||||
OpenStack components will be available for use, and in many
|
||||
ways the issues that need to be considered will be similar to
|
||||
those that need to be considered for a multi-site
|
||||
deployment.</para>
|
||||
<para>That said, in any situation in which more than one cloud is
|
||||
being used, at least four OpenStack tools will be
|
||||
considered:</para>
|
||||
exclusively an OpenStack cloud or not.</para>
|
||||
<para>Using more than one cloud in any situation requires
|
||||
consideration of four OpenStack tools:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<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
|
||||
based OpenStack cloud with Azure will have less
|
||||
based OpenStack cloud with Azure has less
|
||||
compatibility issues than if KVM is used.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Networking: Whether OpenStack Networking (neutron)
|
||||
<para>Networking (neutron): Whether OpenStack Networking
|
||||
or legacy networking (nova-network) is used, the network is one place
|
||||
where integration capabilities need to be understood
|
||||
where understanding integration capabilities is necessary
|
||||
in order to connect between clouds.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -311,29 +294,36 @@
|
||||
decides are necessary in an OpenStack-based
|
||||
cloud.</para>
|
||||
</listitem>
|
||||
</itemizedlist></section>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<section xml:id="special-considerations-hybrid">
|
||||
<title>Special considerations</title>
|
||||
<para>Hybrid cloud deployments also involve two more issues that
|
||||
are not common in other situations:</para>
|
||||
<para>Image portability: Note that, as of the Icehouse release,
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Image portability: Note that, as of the Icehouse release,
|
||||
there is no single common image format that is usable by all
|
||||
clouds. This means that images will need to be converted or
|
||||
recreated when porting between clouds. To make things simpler,
|
||||
clouds. Conversion or the recreation of images is necessary
|
||||
if porting between clouds. To make things simpler,
|
||||
launch the smallest and simplest images feasible, installing
|
||||
only what is necessary preferably using a deployment manager
|
||||
such as Chef or Puppet. That means not to use golden images
|
||||
for speeding up the process, however if the same images are
|
||||
being repeatedly deployed it may make more sense to utilize
|
||||
this technique instead of provisioning applications on lighter
|
||||
images each time.</para>
|
||||
<para>API differences: The most profound issue that cannot be
|
||||
avoided when using a hybrid cloud deployment with more than
|
||||
just OpenStack (or with different versions of OpenStack) is
|
||||
that the APIs needed to perform certain functions are
|
||||
different. The CMP needs to know how to handle all necessary
|
||||
such as Chef or Puppet. Do not use golden images for speeding up
|
||||
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>
|
||||
<para>API differences: Avoid using a hybrid cloud deployment with more than
|
||||
just OpenStack (or with different versions of OpenStack).
|
||||
The APIs need to perform certain functions that are different.
|
||||
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 will get more use out of a
|
||||
hybrid cloud broker SDK such as jClouds.</para></section>
|
||||
developer-focused organization may benefit more from a hybrid
|
||||
cloud broker SDK such as jClouds.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</section>
|
||||
|
Loading…
Reference in New Issue
Block a user