openstack team mailing list archive

[Monty Taylor <mordred@xxxxxxxxxxxx>]

On 09/24/2011 10:50 AM, Brian Lamar wrote:
> Hey Josh,
> 
>>> Has there been any thought on having a nova-db service that
>>> responds to requests for information from the db (or something
>>> like a db).
> 
> No plans that I'm aware of, there is a Database-as-a-Service project
> called 'Red Dwarf' which might fit this bill however. I honestly
> haven't looked too much into it.
> 
>>> This could be useful for companies that don't necessarily want to
>>> have a limiting factor being a database. Since when u scale past
>>> a certain number of compute nodes the database connections
>>> themselves may become a bottleneck (especially the heartbeat 
>>> mechanism which updates a table every X seconds).
> 
> Not sure what you mean by this. Currently the OpenStack architecture
> was built to allow hundreds and thousands (maybe?) of compute nodes
> in the same environment. The keys is to group compute nodes into
> clusters as outlined here:
> 
> http://wiki.openstack.org/MultiClusterZones
> 
> Long story short the database isn't being shared between all compute
> clusters, but instead a hierarchy of clusters is formed (something I,
> in a pinch, would consider akin to a distributed Map/Reduce model of
> data sharing).

What are the actual scaling concerns? Have you seen scaling problems, or
are you just concerned that they might be hit? I'm not seeing any
mention of numbers here that would even come close to exceeding the
MySQL-scales-that-far-without-breaking-a-sweat range of things... so I'd
love to try and help address specific problems rather than re-architect
something before we even know what the problem we're trying to solve are.

> Does something like this help out with your scaling concerns? I do
> know that personally I'd be interested in a CouchDB/NoSQL alternative
> to the Nova database layer...but what we have right now seems to
> conceptual work for scaling out to many hundreds of compute nodes.

Again - to what end? What is it that the current db setup isn't
providing that CouchDB would do a better job of?

>>> It would be interesting if these types of request could go to the
>>> message queue instead
> 
> 110% agree. Hopefully this is something we can talk about at the
> upcoming conference in Boston. :)

I will definitely agree that message queues can be a way of adding
scalability (async systems are often able to provide for interesting
parallelism) ... but at the end of the day the unit of work still has to
get accomplished, and if the request for data to the underlying message
store is still slow (sql or nosql, whatever) - under extremely high load
if your disk and/or cpu are saturated on the db infrastructure, async or
sync is going to make a flips work of difference. So I'm going to be
really annoying and again ask: to solve what actual problem? Example
queries and/or any logging/capturing of system information during
scaling issues would be a great start ... we can take a stab at solving
any current problems that are there - and as part of solving those
problems we can of course discuss approaches such as async message
queues or nosql alternatives.

Monty

> 
> -----Original Message----- From: "Joshua Harlow"
> <harlowja@xxxxxxxxxxxxx> Sent: Friday, September 23, 2011 5:40pm To:
> "openstack" <openstack@xxxxxxxxxxxxxxxxxxx> Subject: [Openstack]
> Database replacement?
> 
> _______________________________________________ Mailing list:
> https://launchpad.net/~openstack Post to     :
> openstack@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> https://launchpad.net/~openstack More help   :
> https://help.launchpad.net/ListHelp This email may include
> confidential information. If you received it in error, please delete
> it. Howdy all, congrats on the diablo release!
> 
> Has there been any thought on having a nova-db service that responds
> to requests for information from the db (or something like a db).
> 
> This could be useful for companies that don't necessarily want to
> have a limiting factor being a database. Since when u scale past a
> certain number of compute nodes the database connections themselves
> may become a bottleneck (especially the heartbeat mechanism which
> updates a table every X seconds). It would be interesting if these
> types of request could go to the message queue instead and then the
> db backing could be swapped out with something more scalable (or
> still use mysql/sqlite...).
> 
> Any thoughts?
> 
> -Josh
> 
> 
> 
> _______________________________________________ Mailing list:
> https://launchpad.net/~openstack Post to     :
> openstack@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> https://launchpad.net/~openstack More help   :
> https://help.launchpad.net/ListHelp
>