[infinispan-dev] XSite Hot Rod client failover wiki

[Radim Vansa]

On 09/09/2015 04:00 PM, Galder Zamarreno wrote:
>
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
> ----- Original Message -----
>> 1) Is it really desired to keep the site list in client configuration?
> Not sure if it was totally clear but the entire site list would not be required. The client must contain at least 1 node's address in that site, so that it can then get the topology of the rest.

OK, I've eventually convinced myself that it's not that bad idea to keep 
the addresses there. The mechanism of updating site list on the client 
can be out of scope for Infinispan.

>
>> It has always seemed to me great that I can provide only single hotrod
>> server address to the client and it will figure out all the other nodes.
>> I can imagine a configuration with one or few well-known nodes (possibly
>> with capacity factor 0), and the heavy lifting to be done by an elastic
>> cluster. Especially in AWS or GCE like environments it simplifies the
>> configuration. The same could hold for the backup sites, though I
>> understand that this has two downsides:
>> a) If x-site interface is different from the interface accessible by
>> clients, we need a mechanism to publish the external-host:external-port
>> information
> ^ A server can define it's external host and port, but we call them proxyHost and proxyPort.

Not that it would matter, but [1] says that its configured as 
'external-host'

[1] 
https://github.com/infinispan/infinispan/blob/master/server/integration/endpoint/src/main/resources/schema/jboss-infinispan-endpoint_8_0.xsd#L147

>
>> b) if this information is per-client, it's easy to set up the order of
>> backup sites (according to geographical location, to keep the cluster as
>> close as possible). If that's server based, it may not be possible to
>> declare that accurately.
> ^ Not sure I understand what you mean by that.

You need to declare priority of sites to which the client should 
connect. If we keep the current configuration, the main site is obvious, 
but to which sites should it connect when the site BRQ fails, LON or SFO?

>
>> 2) There should be a way to tell the clients that the original site is
>> back online, without bringing down the backup site.
> ^ That's easy to do, simply put the backup site offline and the client should bounce back to original site.

-1 That's what I meant by 'without bringing down the backup site'. You 
can have active-active setup with one set of clients in the main site 
and another set of clients connected to the backup site (when both sites 
are online). When one site fails, the clients will be transferred to the 
backup site (from their POV), so all clients would connect to single 
site. But when you bring the failed site back online, you don't want to 
disrupt the other set of clients, and ping pong them between the sites - 
you want to use both.

Radim

>
>> However, that puts
>> us back to point 1b) - how should the client know that the another
>> online site is actually closer, if it does not have it on the list.
>> Maybe, having an optional list that would declare the priority, with
>> site names, would be beneficial (client would have
>> foo.bar.sites=BRQ,LON,SFO but wouldn't have to care about IP addresses).
> ^ I'm not sure about the real usability of that.
>
>> Radim
>>
>> On 09/07/2015 06:26 PM, Galder Zamarreno wrote:
>>> Hi all,
>>>
>>> I've written a wiki describing how XSite Hot Rod client failover could work
>>> [1].
>>>
>>> If you have any comments/doubts/question, please reply :)
>>>
>>> Cheers,
>>>
>>> [1]
>>> https://github.com/infinispan/infinispan/wiki/XSite-Failover-for-Hot-Rod-clients
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Radim Vansa <rvansa at redhat.com>
>> JBoss Performance Team
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team