SchedulingInOpenstack CCR May2014
SchedulingInOpenstack CCR May2014
●
Nova-scheduler is the component responsible to decide which
compute node should be used when a VM instance is to be lunched
●
it interacts with other components through queue
●
for scheduling, queue is the essential communications hub
●
nova-scheduler makes decisions by collecting information about
compute resources
●
it has a number of configuration options that can be accessed and
modified in the configuration file “nova.conf”
●
FilterScheduler is the default
●
User requests are processed sequentially (FIFO scheduling)
➢
nova-scheduler doesn't provide any dynamic priority strategy algorithm
●
User requests not satisfied (e.g. resource not available) fails and will be
lost
➢
on that scenario, nova-scheduler doesn't provide queuing of the requests
●
OpenStack simply provides a partitioning of resources among more
projects / experiments (use of quotas)
➢
if a project has free quota (underutilized its resources), and another project
instead has consumed its quota, the only solution is to change the related
quotas by the Cloud Administrator
Nova-scheduler is mainly missing of:
✔
queuing of the requests
✔
fair-share algorithm in the resources provisioning
The priority is an integer and the larger the number, the higher the job will be
positioned in the queue, and the sooner the job will be scheduled
The fair-share is a component of the job's priority that influences the order in
which a user's queued jobs are scheduled to run
It guarantees the usage of the resources is equally distributed among users
and groups by considering the portion of the resources allocated to them (i.e.
share) and the resources they already consumed
●
historical resource utilization information is incorporated into priority decisions
●
all user requests will be inserted in a (persistent) priority queue and then
processed asynchronously by the dedicated process (filtering + weighting
phase) when compute resources are available
●
From the client point of view the queued requests remain in “Scheduling”
state till the compute resources are available
●
No new states added: this prevents any possible interaction issue with the
Openstack clients
●
User requests are dequeued by a pool of WorkerThreads (configurable)
➢
no sequential processing of the requests
●
the failed requests at filtering + weighting phase may be inserted again in
the queue for n-times (configurable)
●
the priority of the queued requests will be recalculated periodically (see
age_factor)
FairShareScheduler
0 nova.conf
2
AMQP
AMQPclient
client
3
4
PriorityQueue
PriorityQueue FairShare
FairShare
6 Manager 5 Manager
Manager Manager
7
PQueue
PQueue ...
nova,
nova,keystone
keystone
1 8
9 filtering
filtering++weighting
weightingphases
phases
AMQP
AMQP
user req.
(nova api)
10
nova-compute
nova-compute
The previous scheduled request goes Running (assigned both host and ip address).
●
FairShareScheduler source code (for HAVANA) available in github:
➢
https://github.com/CloudPadovana/openstack-fairshare-scheduler
➢
Authors: Eric Frizziero (INFN-PD), Lisa Zangrando (INFN-PD)
●
Testing in progress in Bari's Cloud Testbed
●
Installation of the FairShareScheduler in the “Cloud Area Padovana”
●
Started the integration process of the FairShareScheduler in IceHouse
Openstack release
●
Evaluate how to integrate this scheduler in the official OpenStack
distribution
●
FairshareScheduler's live demo at coffee break area
Questions?