| Hi Simon, It is not entirely clear to me what you need zookeeper for in this case. Are blocks replicated and you need to guarantee that the updates are consistent across replicas? On your observations, I'm quite sure people will have an opinion, so here are my thoughts, which might not be representative of the whole community : 1- You're right, we do not recommended to use ZooKeeper directly as the data store. ZooKeeper servers keep their state in memory. 2- Cassandra already provides replication. Are you trying to strengthen the guarantees of Cassandra? I don't get it... 3- Sound right that you could use BK as a journal, but it is not clear which element is writing to the journal. Are you assuming a metadata manager such as the namenode of HDFS? 4- I'm not sure what this option means. Are you proposing ZooKeeper to manage the metadata of the file system? If so, I don't find it entirely unrealistic, since metadata updates are supposed to be small and the performance of ZooKeeper should be good enough for your case, but it might be awkward to have your block storage clients talking directly to ZooKeeper. Changes to metadata management would imply in this case rolling out a new version of the client application instead of just having the changes implemented on the service side. -Flavio On Jul 13, 2011, at 12:02 PM, Simon Felix wrote:
flavio junqueira research scientist [email protected] direct +34 93-183-8828 avinguda diagonal 177, 8th floor, barcelona, 08018, es phone (408) 349 3300 fax (408) 349 3301 |
- Shared block storage via ZooKepper Simon Felix
- Re: Shared block storage via ZooKepper Flavio Junqueira
- RE: Shared block storage via ZooKepper Simon Felix
- Re: Shared block storage via ZooKepper Ted Dunning
- RE: Shared block storage via ZooKepper Simon Felix
- Re: Shared block storage via ZooKep... Scott Fines
- Re: Shared block storage via ZooKepper Yang
- Re: Shared block storage via ZooKepper Yang
- Re: Shared block storage via ZooKepper Ted Dunning
- RE: Shared block storage via ZooKepper Simon Felix
