openstack-manuals/doc/training-guides/module001-ch009-vm-placement.xml
Summer Long 7fcd56c116 Updated Weighting section
Put in tables of relevant weighting options for both hosts
and cells. Updated intro. Added graphic from training
guides (moved into common and relinked in training guide).

Closes-bug: #1261521

Change-Id: Ic9fd323e31016040dbbf18be4969ff829d4edf1e
2014-04-17 14:14:42 +10:00

206 lines
10 KiB
XML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<?xml version="1.0" encoding="utf-8"?>
<chapter 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="module001-ch009-vm-placement">
<title>VM Placement</title>
<para>Compute uses the nova-scheduler service to determine how to
dispatch compute and volume requests. For example, the
nova-scheduler service determines which host a VM should launch
on. The term host in the context of filters means a physical node
that has a <systemitem class="service">nova-compute</systemitem>
service running on it. You can configure the scheduler through a
variety of options.</para>
<figure>
<title>Nova</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/image29.png"/>
</imageobject>
</mediaobject>
</figure>
<para>Just as shown by above figure, nova-scheduler interacts with
other components through queue and central database repo. For
scheduling, queue is the essential communications hub.</para>
<para>All compute nodes (also known as hosts in terms of OpenStack)
periodically publish their status, resources available and
hardware capabilities to nova-scheduler through the queue.
nova-scheduler then collects this data and uses it to make
decisions when a request comes in.</para>
<para>By default, the compute scheduler is configured as a filter
scheduler, as described in the next section. In the default
configuration, this scheduler considers hosts that meet all the
following criteria:</para>
<itemizedlist>
<listitem>
<para>Are in the requested availability zone
(AvailabilityZoneFilter).</para>
</listitem>
<listitem>
<para>Have sufficient RAM available (RamFilter).</para>
</listitem>
<listitem>
<para>Are capable of servicing the request
(ComputeFilter).</para>
</listitem>
</itemizedlist>
<para><guilabel>Filter Scheduler</guilabel></para>
<para>The Filter Scheduler supports filtering and weighting to
make informed decisions on where a new instance should be created.
This Scheduler supports only working with Compute Nodes.</para>
<para><guilabel>Filtering</guilabel></para>
<figure>
<title>Filtering</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/image27.png"/>
</imageobject>
</mediaobject>
</figure>
<para>During its work, Filter Scheduler first makes a dictionary
of unfiltered hosts, then filters them using filter properties
and finally chooses hosts for the requested number of
instances (each time it chooses the most weighed host and
appends it to the list of selected hosts).</para>
<para>If it turns up, that it cant find candidates for the next
instance, it means that there are no more appropriate hosts
where the instance could be scheduled.</para>
<para>If we speak about filtering and weighting, their work is
quite flexible in the Filter Scheduler. There are a lot of
filtering strategies for the Scheduler to support. Also you
can even implement your own algorithm of filtering.</para>
<para>There are some standard filter classes to use
(nova.scheduler.filters):</para>
<itemizedlist>
<listitem>
<para>AllHostsFilter - frankly speaking, this filter does no
operation. It passes all the available hosts.</para>
</listitem>
<listitem>
<para>ImagePropertiesFilter - filters hosts based on
properties defined on the instances image. It passes
hosts that can support the specified image properties
contained in the instance.</para>
</listitem>
<listitem>
<para>AvailabilityZoneFilter - filters hosts by availability
zone. It passes hosts matching the availability zone
specified in the instance properties.</para>
</listitem>
<listitem>
<para>ComputeCapabilitiesFilter - checks that the
capabilities provided by the host Compute service satisfy
any extra specifications associated with the instance
type. It passes hosts that can create the specified
instance type.</para>
</listitem>
<listitem>
<para>The extra specifications can have a scope at the
beginning of the key string of a key/value pair. The scope
format is scope:key and can be nested, i.e. key_string :=
scope:key_string. Example like capabilities:cpu_info:
features is valid scope format. A key string without any :
is non-scope format. Each filter defines its valid scope,
and not all filters accept non-scope format.</para>
</listitem>
<listitem>
<para>The extra specifications can have an operator at the
beginning of the value string of a key/value pair. If
there is no operator specified, then a default operator of
s== is used. Valid operators are:</para>
</listitem>
</itemizedlist>
<para>* = (equal to or greater than as a number; same as vcpus
case)* == (equal to as a number)* != (not equal to as a
number)* &gt;= (greater than or equal to as a number)* &lt;=
(less than or equal to as a number)* s== (equal to as a
string)* s!= (not equal to as a string)* s&gt;= (greater than
or equal to as a string)* s&gt; (greater than as a string)*
s&lt;= (less than or equal to as a string)* s&lt; (less than
as a string)* &lt;in&gt; (substring)* &lt;or&gt; (find one of
these)Examples are: "&gt;= 5", "s== 2.1.0", "&lt;in&gt; gcc",
and "&lt;or&gt; fpu &lt;or&gt; gpu"</para>
<programlisting>class RamFilter(filters.BaseHostFilter):
"""Ram Filter with over subscription flag"""
def host_passes(self, host_state, filter_properties):
"""Only return hosts with sufficient available RAM."""
instance_type = filter_properties.get('instance_type')
requested_ram = instance_type['memory_mb']
free_ram_mb = host_state.free_ram_mb
total_usable_ram_mb = host_state.total_usable_ram_mb
used_ram_mb = total_usable_ram_mb - free_ram_mb
return total_usable_ram_mb * FLAGS.ram_allocation_ratio - used_ram_mb >= requested_ram</programlisting>
<para>Here ram_allocation_ratio means the virtual RAM to
physical RAM allocation ratio (it is 1.5 by default). Really,
nice and simple.</para>
<para>Next standard filter to describe is AvailabilityZoneFilter
and it isnt difficult too. This filter just looks at the
availability zone of compute node and availability zone from
the properties of the request. Each Compute service has its
own availability zone. So deployment engineers have an option
to run scheduler with availability zones support and can
configure availability zones on each compute host. This
classes method host_passes returns True if availability zone
mentioned in request is the same on the current compute
host.</para>
<para>The ImagePropertiesFilter filters hosts based on the
architecture, hypervisor type, and virtual machine mode
specified in the instance. E.g., an instance might require a
host that supports the arm architecture on a qemu compute
host. The ImagePropertiesFilter will only pass hosts that can
satisfy this request. These instance properties are populated
from properties define on the instances image. E.g. an image
can be decorated with these properties using glance
image-update img-uuid --property architecture=arm --property
hypervisor_type=qemu Only hosts that satisfy these
requirements will pass the ImagePropertiesFilter.</para>
<para>ComputeCapabilitiesFilter checks if the host satisfies any
extra_specs specified on the instance type. The extra_specs
can contain key/value pairs. The key for the filter is either
non-scope format (i.e. no : contained), or scope format in
capabilities scope (i.e. capabilities:xxx:yyy). One example of
capabilities scope is capabilities:cpu_info:features, which
will match hosts cpu features capabilities. The
ComputeCapabilitiesFilter will only pass hosts whose
capabilities satisfy the requested specifications. All hosts
are passed if no extra_specs are specified.</para>
<para>ComputeFilter is quite simple and passes any host whose
Compute service is enabled and operational.</para>
<para>Now we are going to IsolatedHostsFilter. There can be some
special hosts reserved for specific images. These hosts are
called isolated. So the images to run on the isolated hosts
are also called isolated. This Scheduler checks if
image_isolated flag named in instance specifications is the
same that the host has.</para>
<para><guilabel>Weights</guilabel></para>
<para>Filter Scheduler uses so-called weights during its
work.</para>
<para>The Filter Scheduler weights hosts based on the config
option scheduler_weight_classes, this defaults to
nova.scheduler.weights.all_weighers, which selects the only
weigher available the RamWeigher. Hosts are then weighted and
sorted with the largest weight winning.</para>
<para>Filter Scheduler finds local list of acceptable hosts by
repeated filtering and weighing. Each time it chooses a host, it
virtually consumes resources on it, so subsequent selections can
adjust accordingly. It is useful if the customer asks for the
same large amount of instances, because weight is computed for
each instance requested.</para>
<figure>
<title>Weights</title>
<mediaobject>
<imageobject>
<imagedata fileref="../common/figures/nova-weighting-hosts.png"/>
</imageobject>
</mediaobject>
</figure>
<para>In the end Filter Scheduler sorts selected hosts by their
weight and provisions instances on them.</para>
</chapter>