4 Scheduling options

The scheduling options control how leases are assigned to resources.

1 Scheduling policies

Haizea includes a policy decision module that supports ``pluggable policies'', allowing developers to write their own scheduling policies. This is described in more detail in Chapter , and we describe here only the built-in policies that are included with Haizea.

The first policy is lease admission, which controls what leases are accepted by Haizea. Take into account that this decision takes place before Haizea even attempts to schedule the lease (so, you can think of lease admission as ``eligibility to be scheduled''). The two built-in policies are to accept all leases, and to accept all leases except advance reservations.

[scheduling]
...
policy-admission: accept-all | no-ARs | <custom policy>
...

The next policy is lease preemptability, or what leases can be preempted. The two built-in policies are to not allow any preemptions, and to allow all ARs to preempt other leases.

[scheduling]
...
policy-preemption: no-preemption | ar-preempts-everything | <custom policy>
...

Finally, the host selection policy controls how Haizea chooses what physical hosts to map VMs to. The two built-in policies are to choose nodes arbitrarily (i.e., ``no policy''), or to apply a greedy policy that tries to minimize the number of preemptions. Currently, you should choose the greedy policy unless you really know what you're doing.

[scheduling]
...
policy-host-selection: no-policy | greedy | <custom policy>
...

2 Backfilling algorithms

NOTE: This section assumes that you are familiar with backfilling algorithms. We will try to include a brief, didactic, explanation of backfilling algorithms in future versions of the manual.

Haizea supports both aggressive and conservative backfilling:

[scheduling]
...
backfilling: off | aggressive | conservative
...

An exact number of allowed future reservations can also be specified:

[scheduling]
...
backfilling: intermediate
backfilling-reservations: 4
...

3 Lease suspension and migration

Lease suspension can be allowed for all leases, only for 1-node leases (``serial'' leases), or not allowed at all. Additionally, Haizea can schedule suspensions and resumptions to be locally or globally exclusive:

[scheduling]
...
suspension: none | serial-only | all
...

When suspending or resuming a VM, the VM's memory is dumped to a file on disk. To correctly estimate the time required to suspend a lease with multiple VMs, Haizea makes sure that no two suspensions/resumptions happen at the same time (e.g., if eight memory files were being saved at the same time to disk, the disk's performance would be reduced in a way that is not as easy to estimate as if only one file were being saved at a time).

Depending on whether the files are being saved to/read from a global or local filesystem, this exclusion can be either global or local:

[scheduling]
...
suspendresume-exclusion: local | global
...

When allocating time for suspending or resuming a single virtual machine with MB of memory, and given a rate MB/s of read/write disk throughput, Haizea will estimate the suspension/resumption time to be . The suspendresume-rate option is used to specify :

[simulation]
...
suspendresume-rate: 32
...

Lease migration can be disallowed, allowed, or allowed but without having to transfer any files from one to another:

[scheduling]
...
migration: no | yes | yes-notransfer
...

4 Lease preparation scheduling

Before a lease can start, it may require some preparation, such as transferring a disk image from a repository to the physical node where a VM will be running. When no preparation is necessary (e.g., assuming that all required disk images are predeployed on the physical nodes), the lease-preparation option must be set to unmanaged:

[general]
...
lease-preparation: unmanaged
...

When disk images are located in a disk image repository, Haizea can schedule the file transfers from the repository to the physical nodes to make sure that images arrive on time (when a lease has to start at a specific time) and to minimise the number of transfers (by reusing images on the physical nodes). To do this, lease-preparation option must be set to imagetransfer, we need to specify the network bandwidth of the image repository (in Mbits per second), and specify several options in the [deploy-imagetransfer] section:

[general]
...
lease-preparation: imagetransfer
...

[simulation]
...
imagetransfer-bandwidth: 100
...

[deploy-imagetransfer]
...
\# Image transfer scheduling options
...

1 Transfer mechanisms

The transfer mechanism specifies how the images will be transferred from the repository to the physical nodes. Haizea supports a unicast or a multicast transfer mechanism:

[deploy-imagetransfer]
...
transfer-mechanism: unicast | multicast
...

Whe using a unicast transfer mechanism, one image can only be transferred to one node at a time. When using multicast, it is possible to transfer the same image from the repository node to more than one physical node at the same time.

2 Avoiding redundant transfers

Haizea can take steps to detect and avoid redundant transfers (e.g., if two leases are scheduled on the same node, and they both require the same disk image, don't transfer the image twice; allow one to ``piggyback'' on the other). There is generally no reason to avoid redundant transfers.

[deploy-imagetransfer]
...
avoid-redundant-transfers: True | False
...

3 Disk image reuse

Haizea can create disk image caches on the physical nodes with the goal of reusing frequent disk images and reducing the number of transfers:

[deploy-imagetransfer]
...
diskimage-reuse: image-caches
diskimage-cache-size: 20000
...

5 The scheduling threshold

To avoid thrashing, Haizea will not schedule a lease unless all overheads can be correctly scheduled (which includes image transfers, suspensions, etc.). However, this can still result in situations where a lease is prepared, and then immediately suspended because of a blocking lease in the future. The scheduling threshold factor can be used to specify that a lease must not be scheduled unless it is guaranteed to run for a minimum amount of time (the rationale behind this is that you ideally don't want leases to be scheduled if they're not going to be active for at least as much time as was spent in overheads).

The default value is 1, meaning that the lease will be active for at least as much time as was spent on overheads (e.g., if preparing the lease requires 60 seconds, and we know that it will have to be suspended, requiring 30 seconds, Haizea won't schedule the lease unless it can run for at least 90 minutes). In other words, a scheduling factor of required a minimum duration of . A value of 0 could lead to thrashing, since Haizea could end up with situations where a lease starts and immediately gets suspended.

[scheduling]
...
scheduling-threshold-factor: 1
...