[Openstack-operators] [scientific] Resource reservation requirements (Blazar) - Forum session
vondra at homeatcloud.cz
Tue Apr 4 07:48:10 UTC 2017
Did someone mention automation changing the spot instance capacity? I did an article in 2013 that proposes exactly that. The model forecasts the workload curve of the majority traffic, which is presumed to be interactive, and the rest may be used for batch traffic. The forecast used is SARIMA and is usable up to a few days in advance. Would anybody be interested in trying the forecast on data from their cloud?
Tomas Vondra, dept. of Cybernetics, CTU FEE
From: Blair Bethwaite [mailto:blair.bethwaite at gmail.com]
Sent: Tuesday, April 04, 2017 12:08 AM
To: Jay Pipes
Subject: Re: [Openstack-operators] [scientific] Resource reservation requirements (Blazar) - Forum session
On 4 April 2017 at 00:20, Jay Pipes <jaypipes at gmail.com> wrote:
> However, implementing the above in any useful fashion requires that
> Blazar be placed *above* Nova and essentially that the cloud operator
> turns off access to Nova's POST /servers API call for regular users.
> Because if not, the information that Blazar acts upon can be simply
> circumvented by any user at any time.
That's something of an oversimplification. A reservation system outside of Nova could manipulate Nova host-aggregates to "cordon off"
infrastructure from on-demand access (I believe Blazar already uses this approach), and it's not much of a jump to imagine operators being able to twiddle the available reserved capacity in a finite cloud so that reserved capacity can be offered to the subset of users/projects that need (or perhaps have paid for) it. Such a reservation system would even be able to backfill capacity between reservations. At the end of the reservation the system cleans-up any remaining instances and preps for the next reservation.
The are a couple of problems with putting this outside of Nova though.
The main issue is that pre-emptible/spot type instances can't be accommodated within the on-demand cloud capacity. You could have the reservation system implementing this feature, but that would then put other scheduling constraints on the cloud in order to be effective (e.g., there would need to be automation changing the size of the on-demand capacity so that the maximum pre-emptible capacity was always available). The other issue (admittedly minor, but still a
consideration) is that it's another service - personally I'd love to see Nova support these advanced use-cases directly.
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org
More information about the OpenStack-operators