85 lines
3.4 KiB
XML
85 lines
3.4 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="operational-considerations-compute-focus">
|
|
<?dbhtml stop-chunking?>
|
|
<title>Operational considerations</title>
|
|
<para>There are a number of operational considerations that affect the
|
|
design of compute-focused OpenStack clouds, including:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Enforcing strict API availability requirements
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Understanding and dealing with failure scenarios
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Managing host maintenance schedules
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>Service-level agreements (SLAs) are contractual obligations that
|
|
ensure the availability of a service. When designing an OpenStack cloud,
|
|
factoring in promises of availability implies a certain level of
|
|
redundancy and resiliency.</para>
|
|
|
|
<section xml:id="montioring-compute-focus">
|
|
<title>Monitoring</title>
|
|
<para>OpenStack clouds require appropriate monitoring platforms
|
|
to catch and manage errors.</para>
|
|
<note>
|
|
<para>We recommend leveraging existing monitoring systems
|
|
to see if they are able to effectively monitor an
|
|
OpenStack environment.</para>
|
|
</note>
|
|
<para>Specific meters that are critically important to capture
|
|
include:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Image disk utilization</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Response time to the Compute API</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
|
|
<section xml:id="capacity-planning-operational">
|
|
<title>Capacity planning</title>
|
|
<para>Adding extra capacity to an OpenStack cloud is a
|
|
horizontally scaling process.</para>
|
|
<para>We recommend similar (or the same) CPUs
|
|
when adding extra nodes to the environment. This reduces
|
|
the chance of breaking live-migration features if they are
|
|
present. Scaling out hypervisor hosts also has a direct effect
|
|
on network and other data center resources. We recommend you
|
|
factor in this increase when reaching rack capacity or when requiring
|
|
extra network switches.</para>
|
|
<para>Changing the internal components of a Compute host to account for
|
|
increases in demand is a process known as vertical scaling.
|
|
Swapping a CPU for one with more cores, or
|
|
increasing the memory in a server, can help add extra
|
|
capacity for running applications.</para>
|
|
<para>Another option is to assess the average workloads and
|
|
increase the number of instances that can run within the
|
|
compute environment by adjusting the overcommit ratio.</para>
|
|
<note>
|
|
<para>It is important to remember that changing the CPU
|
|
overcommit ratio can have a detrimental effect and cause
|
|
a potential increase in a noisy neighbor.</para>
|
|
</note>
|
|
<para>The added risk of increasing the overcommit ratio is that
|
|
more instances fail when a compute host fails. We do not recommend
|
|
that you increase the CPU overcommit ratio in compute-focused
|
|
OpenStack design architecture, as it can increase the potential
|
|
for noisy neighbor issues.</para>
|
|
</section>
|
|
</section>
|