[openstack-dev] [all] Outcome of distributed lock manager discussion @ the summit

Joshua Harlow harlowja at fastmail.com
Tue Nov 10 18:54:11 UTC 2015


Sean Dague wrote:
> On 11/10/2015 05:12 AM, Thierry Carrez wrote:
>> Kevin Carter wrote:
>>>> I believe Clint already linked to
>>>> https://aphyr.com/posts/309-knossos-redis-and-linearizability or
>>>> similar - but 'known for general ease of use and reliability' is uhm,
>>>> a bold claim. Its worth comparing that (and the other redis writeups)
>>>> to this one: https://aphyr.com/posts/291-call-me-maybe-zookeeper. "Use
>>>> zookeeper, its mature".
>>> Those write ups are from 2013 and with general improvements in Redis over the last two years I'd find it hard to believe that they're still relevant, however its worth testing to confirm if Redis is deemed as a viable option.
>>>
>>>> The openjdk is present on the same linux distributions, and has been
>>>> used in both open source and proprietary programs for decades. *what*
>>>> license implications are you speaking of?
>>> The license issues would be related to deployers using Oracle java
> which may or may not be needed by certain deployers for scale and
> performance requirements. While I do not have specific performance
> numbers at my fingertips to illustrate general performance issues using
> zookeeper at scale with OpenJDK, I have, in the past, compared OpenJDK
> to Oracle Java and found that Oracle java was quite a bit more stable
> and packed far more performance capabilities.	I did find [
> http://blog.cloud-benchmarks.org/2015/07/17/cassandra-write-performance-on-gce-and-aws.html
> ] which claims a 32% performance improvement with casandra using Oracle
> Java 8 over OpenJDK on top of the fact that it was less prone to
> crashes but that may not be entirely relevant to this case. Also
> there's no denying that Oracle has a questionable history dealing with
> Opensource projects regarding Java in the past and because performance
> / stability concerns may require the use of Oracle Java which will
> undoubtedly
>>    come wit
>> h questionable license requirements.
>>
>> I can't be suspected of JVM sympathies, and I find that a bit unfair.
>> I'll try to summarize:
>>
>> 1- ZooKeeper is a very good DLM
>>
>> 2- ZooKeeper is totally supported under OpenJDK and is run under this
>> configuration by large users (see Josh's other post for data)
>>
>> 3- /Some/ large Java stacks run faster / better under Oracle's non-free
>> JVM, but (1) there is no evidence that ZooKeeper is one of them and (2)
>> this is less and less true with modern JDKs (which are all built on top
>> of OpenJDK)
>>
>> 4- Still, some shops will prefer to stay out of Java stacks for various
>> reasons and need an alternative
>>
>> I don't think anything in this discussion invalidates the compromise
>> (using tooz) we came up during the session. ZooKeeper can totally be the
>> tooz default in devstack (something has to be). If other tooz drivers
>> reach the same level of maturity one day, they could run in specific
>> tests and/or become the new default ?
>
> And another good datapoint is Nova's had optional Zookeeper support for
> service groups (landed in Folsom/Grizzly), which provides instantaneous
> reporting of compute workers coming / going. That's been used to build a
> lot of HA orchestration bits outside of Nova by a bunch of folks in the
> NFV space.

Are they still using the nova zookeeper support (for service groups), 
from the analysis done by a coworker I'm not sure they can even use it 
anymore.

The following outline the reasons...

https://review.openstack.org/#/c/190322/ (the uberspec)

https://review.openstack.org/#/c/138607 (tooz for service groups) that 
one uncovered the following:

'For example, the Zookeeper driver uses evzookeeper which is no longer 
actively maintained and doesn't work with eventlet >= 0.17.1.'

The following has more details of this investigation:

http://lists.openstack.org/pipermail/openstack-dev/2015-May/063602.html

>
> So it's also not just theory that Zookeeper is keeping up here, many
> OpenStack deploys already are using it quite heavily.

Agreed that people do use it, just they might not be using it for 
service groups (unless they use an older release of nova) due to the 
above issues (which is why those specs were created, to resolve that and 
to fix the service group layer as a whole).

>
> 	-Sean
>



More information about the OpenStack-dev mailing list