87 lines
4.1 KiB
XML
87 lines
4.1 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. 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.</para>
|
|
|
|
<section xml:id="agility">
|
|
<title>Agility</title>
|
|
<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 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>Enterprise workloads that depend on the
|
|
underlying infrastructure for availability are not designed to
|
|
run on OpenStack. If the application cannot
|
|
tolerate infrastructure failures, it is likely to require
|
|
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 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 quickly.</para>
|
|
</note>
|
|
<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>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>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, providers may differ on how
|
|
infrastructure must be managed and exposed. This can lead to
|
|
delays in root cause analysis where each insists the blame
|
|
lies with the other provider.</para>
|
|
<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
|
|
performance of the overall system.</para>
|
|
</section>
|
|
|
|
<section xml:id="maintainability">
|
|
<title>Maintainability</title>
|
|
<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>
|