Multi-DC CMB cluster

[Andras Szerdahelyi]

Hello cmb-users,

i'm evaluating CMB for deployment over our existing global Cassandra ring, and i noticed the multi-dc example setup in README covers an active/passive failover scenario. Now, i'm sure Cassandra being the persistence layer here ( a master-master replicated data store.. ) the only supported use case for a multi-dc deployment cant possibly be for active/passive failover only.. However, there are a couple things l i could not wrap my head around ( and i'm yet to dive in to the repo ) with regards to multi-dc use :

- how is the Redis cluster of data center B updated with an item received in to a queue in data center A ? I assume its not - doing this in all data centers would put an unnecessary read burden on the Cassandra cluster, and predicting where the item might be consumed is out of scope for the project ? :-) How else can these items be accessed through the CMB endpoint in data center B if they are not available in the local Redis cluster?

- are CMB deployments over the same Cassandra ring aware of each other and their local subscribers? If not, how are callbacks executed in a multi-dc environment? For example, will a callback for a message produced in data center A be executed from data center A, when the subscription was made in data center B ( because the consumer is local to that data center ) ? 

I can't imagine a message intended for a set top box in California has to be retrieved/received cross-country, from the originating data center, say, in Georgia ? Or worse, cross atlantic ..

thanks!

Andras

[boriwo]

You are correct that Redis is the only element in the current design standing in the way of running CMB across data centers in "active-active" or "hot-hot" mode. This is why we currently recommend the active/passive fail-over mode for multi-DC deployments. Obviously operating CMB in true active-active mode would be appealing to a number of applications and there is ongoing debate on how this could be achieved. One idea is to use Redis Cluster when/if it becomes available. Another suggestion is to introduce the concept of a Cassandra-only queue (possibly based on some new Cassandra 2.0 features). Also note that you can run the current version of CMB in pseudo-active-active mode: You can have clients in data center A and B both writing to and reading from the same queue Q. The net effect is that messages will not travel across data center boundaries as the local Redis instances are blind to any other data center's messages. As long as you have redundant clients in both data centers this approach works for some applications.

[Andras Szerdahelyi]

I appreciate the explanation.

If you have, or planning to have a write up / presentation on which 2.0 features you see as viable to implement an all-cassandra message broker with, please do let us know :-)

I was under the impression the active/active clustering was a byproduct of building on top of C* . That is, until i started thinking about how Redis fits in there.

thanks,

Andras