Open Stack

Le 30/05/2014 14:44, CARVER, PAUL a écrit :
>
> Mathieu Rohon wrote:
>
>  
>
> >I'm also very interested in scheduling VMs with Network requirement.
> This seems to be in the scope of NFV workgroup >[1].
>
> >For instance, I think that scheduling should take into account
> bandwith/QoS requirement for a VM, or specific Nic
>
> This falls in my area of interest as well. We're working on making
> network quality of service guarantees by means of a combination of
> DSCP marking with a reservation database and separate hardware queues
> in physical network switches in order to ensure that the reservations
> granted don't exceed the wire speed of the switches. Right now the
> only option if the total of requested reservations would exceed the
> wire speed of the switches is to deny reservations on the basis of
> "first come, first served" and "last come, doesn't get served", in
> other words simply issuing a failure response at reservation time to
> any tenants who attempt to make reservations after a particular switch
> port is maxed out (from a reservation perspective, not necessarily
> maxed out from an actual utilization perspective at any given moment.)
>

Hi Paul,

I don't exactly know your needs, neither your current state of work
regarding the implementation of a reservation database, but please note
that there is a Stackforge project aiming to provide this for OpenStack
natively :

http://wiki.openstack.org/wiki/Blazar (formerly Climate).


During last Juno summit, some discussions in Nova were related to having
a reservation system in place, and the agreement was to take a look at
Climate/Blazar to see if it's a good fit.

I think it would be valuable for both you and Climate folks (whose I'm
in as core reviewer) to see if we can join efforts to address your
requirements with Blazar so you wouldn't have to do all the things.

There is a weekly meeting today at 3pm UTC in #openstack-meeting for
Blazar team. If you have time, just jump in and address your questions
here, that would be a good starting point.



> However, with the element of chance in VM scheduling to compute node,
> it's possible that a tenant could get a deny response from the
> reservation server because their VM landed on a particularly
> reservation heavy rack. If their VM happened to land on a compute node
> in a different rack then there might well be plenty of excess
> bandwidth on that rack's uplink. But our current implementation has no
> way to tell Nova or the tenant that a reservation that was denied
> could have been granted if the VM were relocated to a less network
> overloaded rack.
>

IMHO, this strategy requires both a reservation system (in my opinion,
Blazar), a resource placement system (Gantt) and possibly some AMQP
notifications which would go thru the queue.
That's something I also have in my scope, we can discuss that whenever
you want.

-Sylvain


>  
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140530/c3bb53d8/attachment.html>