Optimized Placement of Windows Instances in OpenStack Havana

Introduction

Microsoft SPLA license requires a cloud provider to license all cores of the physical host running a Windows VM. Since the default scheduling algorithm in OpenStack distributes VMs evenly across all hosts, Windows VMs would be spread randomly, therefore all cores would need to be SPLA licensed. A more cost-efficient and license-optimised placement algorithm for Windows images must be found. The goal is to analyze current OpenStack Havana features for such advanced grouping and placement mechanisms.

OpenStack Placement Options

Some further reasons for segregation or grouping of VMs and workloads can be:

  • geographic placement
  • host capabilities (e.g. all hosts with SSDs)
  • affinity/anti-affinity features (e.g. all VMs within same network on same host)

OpenStack provides multiple ways to segregate or group hosts and workloads:

  • Cells
  • Regions
  • Availability zones
  • Host aggregates
  • Filter Scheduler

Where as cells and regions are used for running the cloud in a discrete distributed fashion, i.e. utilize multiple data centers, availability zones and host aggregates are used for partitioning within a single data center. Filter Scheduler provides a more fine-grained option for VM placement.

Availability Zones

Availability zones are designed for users to be able to choose where to host their virtual machines. In order to utilize a availability zones, the user must use the availability-zone flag when creating an instance, as in:

[bash]$ nova boot –image 1fe4b52c-bda5-11e2-a40b-f23c91aec05e –flavor large –availability-zone berlin windows_vm_1[/bash]

Host Aggregates

Host aggregates are intended as a way to group servers that have a particular quality to them e.g. “all hosts using solid-state drives,” or “all hosts with trusted hardware” (for secure applications). They serve as an intelligent way for schedulers to know where to place VM’s based on some sort of characteristic. In order to utilize this feature:

  1. a host aggregate must be created
  2. metadata must be associated to the aggregate e.g. windows=true
  3. a host must be associated to the aggregate
  4. optional: a new flavor can be created e.g. nova flavor-create windows.large 6 8192 80 4
  5. metadata must be associated to flavor e.g. nova flavor-key set_key –name=windows.large  –key=windows –value=true

Now, when a user requests an instance with the windows.large flavor, the scheduler only considers hosts with the windows=true key-value pair.

Filter Scheduler

The Filter Scheduler (nova.scheduler.filter_scheduler.FilterScheduler) is the default scheduler for scheduling virtual machine instances. It supports filtering and weighting to make informed decisions on where a new instance should be created. When the Filter Scheduler receives a request for a resource, it first applies filters to determine which hosts are eligible for consideration when dispatching a resource. Filters are binary: either a host is accepted by the filter, or it is rejected. Hosts that are accepted by the filter are then processed by a different algorithm to decide which hosts to use for that request, implemented by the weighting feature (see Figure 1).

Filtering and Weighting
Fig.1: Filtering and Weighting (Source: http://docs.openstack.org/havana/config-reference/content/figures/5/a/a/common/figures/filteringWorkflow1.png)

The scheduler_available_filters configuration option in nova.conf provides the Compute service with the list of the filters that are used by the scheduler. The default setting specifies all of the filters that are included with the Compute service:

[bash]scheduler_available_filters=nova.scheduler.filters.all_filters[/bash]

This configuration option can be specified multiple times. For example, if implementing an own custom filter in Python called myfilter.MyFilter and wanting to use both the built-in filters and the custom filter, nova.conf file would contain:

[bash]
scheduler_available_filters=nova.scheduler.filters.all_filters
scheduler_available_filters=myfilter.MyFilter
[/bash]

The scheduler_default_filters configuration option in nova.conf defines the list of filters that are applied by the nova-scheduler service. The default filters are:

[bash]
scheduler_default_filters=AvailabilityZoneFilter,RamFilter,ComputeFilter
[/bash]

The appropriate filter for optimized placement of Windows instances is the IsolatedHostsFilter

IsolatedHostsFilter

The IsolatedHostsFilter allows the admin to define a special (isolated) set of images and a special (isolated) set of hosts, such that the isolated images can only run on the isolated hosts, and the isolated hosts can only run isolated images. The admin must specify the isolated set of images and hosts in the nova.conf file using the isolated_hosts and isolated_images configuration options. For example:

[bash]
isolated_hosts=windows_host_1, windows_host_2
isolated_images=342b492c-128f-4a42-8d3a-c5088cf27d13,ebd267a6-ca86-4d6c-9a0e-bd132d6b7d09
[/bash]

In order not to restrict the isolated hosts to a set of isolated images, the flag “restrict_isolated_hosts_to_isolated_images” can be added to nova.conf. If it’s set to true then the filter acts like the default one, if set to false the isolated hosts can run every image, but isolated images must be run on isolated hosts. By default it is set to true. The correct scheduler_default_filters configuration option in nova.conf would be:

[bash]
scheduler_default_filters=IsolatedHostsFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter
[/bash]