[infinispan-dev] Use of Inifnispan across data centers

[Bela Ban]

Manik Surtani wrote:
> On 5 Aug 2010, at 08:29, Bela Ban wrote:
>
>> Yes, I know #1 sucks, but until we've implemented the more advanced
>> solutions (e.g. RELAY in JGroups, data center replication in
>> Infinispan), this seems to me a workable solution that could be
>> implemented in a short time.
>
> Would this be usable though? The thing with #1 is that you will force 
> all traffic over a WAN link.

Yes. I know of several customers who have set up and run clusters over 
WAN links. Most of them use TCP, but I know of 2 customers who run IP 
multicasting across data centers over OC-48 fiber.

Until a few years ago, I've always recommened against this (I mean 
clusters across WANs), but it seems it works for folks, and so I'll be 
working on making this a better choice. Some of the things that will 
help are relaying traffic between separate islands (RELAY), daisy 
chaining and optimizing traffic across the WAN link etc.

> So even if you have 4 owners, 2 in each DC, the "local" replication, 
> there will be no way to write to the local backup synchronously and 
> the remote backups asynchronously. I.e., either all comms are sync or 
> all comms are async.

Yes, correct. However, this is something which could be implemented in 
Infinispan, ie. configure a mode (DIST_SYNC_ASYNC ?) where the primary 
owner of a key is updated synchronously and the other(s) asynchronously. 
Apart from data center replication, this might even be a nice feature to 
have in Infinispan proper ?

> Maybe this is something we can add in Infinispan. I.e., with node 
> hints (https://jira.jboss.org/browse/ISPN-180) (*) we could detect 
> which recipients are local and which are remote, and accordingly split 
> the RPC into 2: a sync local RPC and an async remote RPC.

+1

> (*) Node hinting isn't strictly necessary; the naming convention you 
> mentioned earlier would work in this regard as well, although I think 
> these hints is probably a better universal solution since we need this 
> for other things anyway.

+1 again

-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss