3336a7a5a3
Removal of passive voice from section_operational_considerations Change-Id: I4bdcd925e2829ed59de802c2b1c840ca5f9bec83 Partial-bug: #1429696
111 lines
5.6 KiB
XML
111 lines
5.6 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<section xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
version="5.0"
|
|
xml:id="arch-guide-hybrid-operational-considerations">
|
|
<?dbhtml stop-chunking?>
|
|
<title>Operational considerations</title>
|
|
<para>Hybrid cloud deployments present complex operational
|
|
challenges. There are several factors to consider that affect
|
|
the way each cloud is deployed and how users and operators
|
|
will interact with each cloud. Each cloud provider implements
|
|
infrastructure components differently. This can lead to incompatible
|
|
interactions with workloads, or a specific Cloud Management
|
|
Platform (CMP). Different cloud providers may
|
|
also offer different levels of integration with competing
|
|
cloud offerings.</para>
|
|
<para>Monitoring is an important aspect to consider when selecting
|
|
a CMP. Gaining valuable insight into each
|
|
cloud is critical to gaining a holistic view of all involved
|
|
clouds. It is vital to determine whether an existing CMP supports
|
|
monitoring of all the clouds involved, or if compatible APIs
|
|
are available to be queried for necessary information.
|
|
Gather all the information about each cloud, you can now take
|
|
appropriate actions on the offline data to avoid impacting workloads.</para>
|
|
|
|
<section xml:id="agility">
|
|
<title>Agility</title>
|
|
<para>The implemention of a hybrid cloud solution provides application
|
|
availability across different cloud environments and
|
|
technologies. This availability enables the deployment to
|
|
survive disaster in any single cloud environment.
|
|
Each cloud should provide the means to quickly spin up new
|
|
instances in the case of capacity issues or complete
|
|
unavailability of a single cloud installation.</para>
|
|
</section>
|
|
|
|
<section xml:id="application-readiness-hybrid">
|
|
<title>Application readiness</title>
|
|
<para>It is important to understand the type of application
|
|
workload that is to be deployed across a hybrid cloud environment.
|
|
Enterprise workloads that depend on the
|
|
underlying infrastructure for availability are not designed to
|
|
run on OpenStack. Although these types of applications can run
|
|
on an OpenStack cloud, if the application is not able to
|
|
tolerate infrastructure failures, it is likely to require
|
|
significant operator intervention to recover. However, cloud
|
|
workloads are designed to handle fault tolerance. The SLA
|
|
of the application is not tied to the underlying
|
|
infrastructure. Ideally, cloud applications are designed
|
|
to recover when entire racks and even data centers full of
|
|
infrastructure experience an outage.</para>
|
|
</section>
|
|
|
|
<section xml:id="upgrades">
|
|
<title>Upgrades</title>
|
|
<para>If the deployment includes a public cloud, predicting
|
|
upgrades may not be possible. Examine the advertised SLA for
|
|
any public cloud provider being used.</para>
|
|
<note>
|
|
<para>At massive scale, even when
|
|
dealing with a cloud that offers an SLA with a high percentage
|
|
of uptime, workloads must be able to recover at short
|
|
notice.</para>
|
|
</note>
|
|
<para>When upgrading private cloud deployments, care
|
|
must be taken to minimize disruption by making incremental
|
|
changes and providing a facility to either rollback or
|
|
continue to roll forward when using a continuous delivery
|
|
model.</para>
|
|
<para>Upgrades to the CMP may need to be completed in coordination
|
|
with any of the hybrid cloud upgrades. This is necessary
|
|
whenever API changes are made.</para>
|
|
</section>
|
|
|
|
<section xml:id="network-operation-center-noc">
|
|
<title>Network Operation Center</title>
|
|
<para>It is important to recognize control over infrastructure particulates
|
|
when planning the Network Operation Center (NOC)
|
|
for a hybrid cloud environment. If a significant
|
|
portion of the cloud is on externally managed systems,
|
|
prepare for situations where it may not be possible to
|
|
make changes.
|
|
Additionally, situations of conflict may arise in which
|
|
multiple providers have differing points of view on the way
|
|
infrastructure must be managed and exposed. This can lead to
|
|
delays in root cause and analysis where each insists the blame
|
|
lies with the other provider.</para>
|
|
<para>It is important to ensure that the structure put in place
|
|
enables connection of the networking of both clouds to form an
|
|
integrated system, keeping in mind the state of handoffs.
|
|
These handoffs must both be as reliable as possible and
|
|
include as little latency as possible to ensure the best
|
|
performance of the overall system.</para>
|
|
</section>
|
|
|
|
<section xml:id="maintainability">
|
|
<title>Maintainability</title>
|
|
<para>Operating hybrid clouds is a situation in which there is a
|
|
greater reliance on third party systems and processes. As a
|
|
result of a lack of control of various pieces of a hybrid
|
|
cloud environment, it is not possible to guarantee
|
|
proper maintenance of the overall system. Instead, the user
|
|
must be prepared to abandon workloads and spin them up again
|
|
in an improved state. Having a hybrid cloud deployment does,
|
|
however, provide agility for these situations by allowing the
|
|
migration of workloads to alternative clouds in response to
|
|
cloud-specific issues.</para>
|
|
</section>
|
|
</section>
|