[openstack-dev] [heat][mistral] EventScheduler vs Mistral scheduling
zbitter at redhat.com
Thu Nov 14 14:46:36 UTC 2013
On 14/11/13 12:26, Renat Akhmerov wrote:
> On 14 Nov 2013, at 18:03, Zane Bitter <zbitter at redhat.com
> <mailto:zbitter at redhat.com>> wrote:
>> What might be a downside is that sharing a back-end may not be
>> technically convenient - one thing we have been reminded of in Heat is
>> that a service with timed tasks has to be scaled out in a completely
>> different way to a service that avoids them. This may or may not be an
>> issue for Mistral, but it could be resolved by having different
>> back-end services that communicate over RPC. The front-end API can
>> remain shared though.
> Not sure I’m 100% following here. Could you please provide more details
> on this? Seems to be an important topic to me. Particularly, what did
> you mean when you said “sharing a back-end”? Sharing by which components?
If you have a service that is stateless and only responds to user
requests, then scaling it out is easy (just stick it behind a load
balancer). If it has state (i.e. a database), things become a whole lot
more complicated to maintain consistency. And if the application has
timed tasks as well as incoming requests, that also adds another layer
Basically you need to ensure that a task is triggered exactly once, in a
highly-available distributed system (and, per a previous thread, you're
not allowed to use Zookeeper ;). Your scaling strategy will be more or
less dictated by this, possibly to the detriment of the rest of your
service - though in Mistral it may well be the case that you have this
constraint already. If not then one possible solution to this is to run
two binaries and have different scaling strategies for each.
None of this should take away from the fact that the two features should
be part of the same API (this is what I meant by "sharing a front-end").
Hopefully that clarifies things :)
More information about the OpenStack-dev