13434488d1
changed the term hostin to host in changed firstly to first added "a" between makes and dictionary changed it's to its added space to weightsduring changed some to same Change-Id: I3402950c5207deb8387e2474c43840f4d93ba6ad
205 lines
10 KiB
XML
205 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 nova-compute 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 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="figures/image07.png"/>
|
||
</imageobject>
|
||
</mediaobject>
|
||
</figure>
|
||
<para>In the end Filter Scheduler sorts selected hosts by their
|
||
weight and provisions instances on them.</para>
|
||
</chapter>
|