Open Stack

There were some studies done by INFN into how this could work.  See http://indico.cern.ch/event/272791/session/0/contribution/6/material/slides/1.pdf for a description. Two approaches, with a modified scheduler or potentially a blazar lease type.

This is a particular challenge in the research and HPC private clouds where high levels of utilisation are very typical.

Tim

From: Digital Wonk [mailto:digitalwonk at gmail.com]
Sent: 15 September 2014 19:13
To: openstack-operators at lists.openstack.org
Subject: [Openstack-operators] Questions about waitlisting/queuing provisioning requests due to capacity

Hi All,

Hopefully, this is the appropriate group to post these questions.   My organization operates a public cloud which is always at capacity due to the demand, and we're looking at OpenStack approaches to handle the capacity issue.

  *   What successful strategies have other groups used to deal with highly utilized clouds? Obviously, increasing a monetary price for resources is one approach, but barring that, what are other methods?
  *   Are there any existing schedulers, extensions, openstack projects, or any forthcoming blueprints that provide the ability to wait list or queue a request if resources are at capacity until resources are available to satisfy that request.  I'm particularly interested in nova.
  *   Are there any commercial products that provide this wait list or queuing functionality?
I came across Blazar, and it (and the notion of reservations) are somewhat related to waitlists but not precisely:

https://wiki.openstack.org/wiki/Blazar

One particular statement for delayed or scheduled reservations that suggests a mismatch for wait lists or queues is:

"In this reservation type lease is created successfully if Blazar thinks there will be enough resources to process provisioning later (otherwise this request returns failure status)"

What if the cloud is always full?

Thanks in advance for the responses.

Edwin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140915/8ea389d4/attachment.html>