Clean up operational_considerations_hybrid.xml
Change-Id: I1584c11470e7525baa7159e560dc13957bdf5509 Implements: blueprint arch-guide
This commit is contained in:
parent
edd448785b
commit
d9104644bd
@ -7,87 +7,69 @@
|
||||
<?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
|
||||
challenges. Differences between provider clouds can cause
|
||||
incompatibilities with workloads or Cloud Management
|
||||
Platforms (CMP). Cloud providers may also offer different levels of
|
||||
integration with competing cloud offerings.</para>
|
||||
<para>Monitoring is critical to maintaining a hybrid cloud, and it is
|
||||
important to determine if a 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>
|
||||
are available to be queried for necessary information.</para>
|
||||
|
||||
<section xml:id="agility">
|
||||
<title>Agility</title>
|
||||
<para>The implemention of a hybrid cloud solution provides application
|
||||
<para>Hybrid clouds provide 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>
|
||||
Each cloud should provide the means to create instances quickly
|
||||
in response to capacity issues or failure elsewhere in the hybrid
|
||||
cloud.</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
|
||||
<para>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
|
||||
run on OpenStack. If the application cannot
|
||||
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>
|
||||
significant operator intervention to recover. Applications for
|
||||
hybrid clouds must be fault tolerant, with an SLA that is not tied
|
||||
to the underlying infrastructure. Ideally, cloud applications should be
|
||||
able to recover when entire racks and data centers 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>
|
||||
<para>If a deployment includes a public cloud, predicting
|
||||
upgrades may not be possible. Carefully examine provider SLAs.</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>
|
||||
of uptime, workloads must be able to recover quickly.</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
|
||||
<para>When upgrading private cloud deployments, 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>
|
||||
<para>You may need to coordinate CMP upgrades with hybrid cloud upgrades if
|
||||
there are API changes.</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="network-operation-center-noc">
|
||||
<title>Network Operation Center</title>
|
||||
<para>It is important to recognize control over infrastructure particulates
|
||||
<para>Consider infrastructure control
|
||||
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
|
||||
Additionally, providers may differ on how
|
||||
infrastructure must be managed and exposed. This can lead to
|
||||
delays in root cause and analysis where each insists the blame
|
||||
delays in root cause 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
|
||||
<para>Ensure that the network structure connects all clouds to form
|
||||
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
|
||||
@ -96,15 +78,9 @@
|
||||
|
||||
<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>
|
||||
<para>Hybrid clouds rely on third party systems and processes. As a
|
||||
result, it is not possible to guarantee
|
||||
proper maintenance of the overall system. Instead, be prepared to
|
||||
abandon workloads and recreate them in an improved state.</para>
|
||||
</section>
|
||||
</section>
|
||||
|
Loading…
Reference in New Issue
Block a user