[OpenSIPS-Users] usrloc restart persistency on seed node

[Alexey Vasilyev]

Hi John,

Next is just my opinion. And I didn’t explore source code OpenSIPS for syncing data.

The problem is little bit deeper. As we have cluster, we potentially have split-brain.
We can disable seed node at all and just let nodes work after disaster/restart. But it means that we can’t guarantee consistency of data. So nodes must show this with «Not in sync» state.  

Usually clusters use quorum to trust on. But for OpenSIPS I think this approach is too expensive. And of course for quorum we need minimum 3 hosts.
For 2 hosts after loosing/restoring interconnection it is impossible to say, which host has consistent data. That’s why OpenSIPS uses seed node as artificial trust point. I think «seed» node doesn’t solve syncing problems, but it simplifies total work.

Let’s imagine 3 nodes A,B,C. A is Active. A and B lost interconnection. C is down. Then C is up and has 2 hosts for syncing. But A already has 200 phones re-registered for some reason. So we have 200 conflicts (on node B the same phones still in memory). Where to sync from? «Seed» host will answer this question in 2 cases (A or B). Of course if C is «seed» so it just will be happy from the start. And I actually don’t know what happens, if we now run «ul_cluster_sync» on C. Will it get all the contacts from A and B or not?

We operate with specific data, which is temporary. So syncing policy can be more relaxed. May be it’s a good idea to connect somehow «seed» node with Active role in the cluster. But again, if Active node restarts and still Active - we will have a problem.

-----
Alexey Vasilyev



> 31 Dec 2018, в 18:04, John Quick <john.quick at smartvox.co.uk> написал(а):
> 
> Hi Alexei,
> 
> Many thanks for your reply to my query about syncing the seed node for
> usrloc registrations.
> I just tried the command you suggested and it does solve the problem. I also
> read the other thread you pointed to.
> 
> I do not really understand the need for the seed node, especially not for
> the case of memory based registrations.
> A seed node makes sense if that node has a superior knowledge of the
> topology or the data than the other nodes. It's view of the universe is to
> be trusted more than the view held by any other node.
> However, in the case of a cluster topology that is pre-defined (no
> auto-discovery) and for full-sharing of usrloc registration data held
> exclusively in memory, then all the nodes are equal - there is no superior
> knowledge that can exist in one node. The one with the most accurate view of
> the world is the one that has been running the longest.
> 
> I am wondering if there is a justifiable case for an option that would
> disable the concept of the seed node and make it so that, on startup, every
> instance will attempt to get the usrloc data from any other running instance
> that has data available. In effect, I can mimic this behaviour by adding the
> command line you suggested just after opensips has started:
> opensipsctl fifo ul_cluster_sync
> 
> Am I missing something here about the concept of the seed node?
> It concerns me that this seed concept is at odds with the concept of true
> horizontal scalability.
> All nodes are equal, but some are more equal than others!
> 
> John Quick
> Smartvox Limited
> Web: www.smartvox.co.uk
> 
>