207 lines
10 KiB
XML
207 lines
10 KiB
XML
<?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" contentwidth="7in"/>
|
||
</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" contentwidth="7in"/>
|
||
</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 can’t 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 instance’s 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)* >= (greater than or equal to as a number)* <=
|
||
(less than or equal to as a number)* s== (equal to as a
|
||
string)* s!= (not equal to as a string)* s>= (greater than
|
||
or equal to as a string)* s> (greater than as a string)*
|
||
s<= (less than or equal to as a string)* s< (less than
|
||
as a string)* <in> (substring)* <or> (find one of
|
||
these)Examples are: ">= 5", "s== 2.1.0", "<in> gcc",
|
||
and "<or> fpu <or> 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 isn’t 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 instance’s 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 host’s 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"
|
||
contentwidth="7in"/>
|
||
</imageobject>
|
||
</mediaobject>
|
||
</figure>
|
||
<para>In the end Filter Scheduler sorts selected hosts by their
|
||
weight and provisions instances on them.</para>
|
||
</chapter>
|