nova-orchestration team mailing list archive

[Yun Mao <yunmao@xxxxxxxxx>]

Row-level db locking is an internal mechanism for database to
implement ACID transactions. It's not supposed to be exposed to users
and implementation specific. For example, in MySQL you can only have
it with InnoDB. With MyISAM you can have table-level locking only.
There is no SQL standard that I'm aware of for you to explicitly grab
a lock on a row, but you can use statement like "SELECT xxx FOR
UPDATE" to block other transactions. I think Nova uses this trick to
allocate fixed IP addresses from the pool.

ZooKeeper is different from a database. One typical usage is to use it
as a lock service only. That is the state does not live in ZooKeeper,
but elsewhere.  So you can grab the lock, do whatever processing and
release the lock later without race condition. For instance you can
spawn a VM, take snapshot, etc.. Another usage is that if the state is
relatively small (e.g. within 1MB), you can put it inside on a
ZooKeeper node. ZooKeeper supports atomic node update in the spirit of
compare and swap.

ZooKeeper also differs from a DB from a HA perspective. It is designed
to be distributed and fault tolerant. With 2f+1 nodes running, you can
tolerate f node failures. Databases like MySQL is designed for a
single node. You can use DRBD to replicate to another node but once
there is a network disconnection it's getting tricky to recover.

Thanks,
Yun


On Tue, Nov 8, 2011 at 8:56 AM, Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx> wrote:
> Hi Yun,
>
> Thanks again for the pointer to ZooKeeper. I think it's a very interesting project and looks like a great way to solve the worker sync problem we face with Orchestration.
>
> One thing that wasn't clear to me immediately was the benefit of using something like ZooKeeper vs doing row-level db locking (where the row is the transaction state)?
>
> Perhaps you could elaborate on that a little?
>
> -S
>