<div dir="ltr"><div dir="ltr">Hi everybody,<div><br></div><div>I like the approach, but here are some thoughts.</div><div><br></div><div>I think that X seconds delay should not pause all the opensips work. Just to run asynchronously, allowing to process requests even before syncing data.</div><div>For example, I use for syncyng from systemd "ExecStartPost" script. So it runs, when opensips already started.</div><div>(And, by the way, John, be careful, don't run "ul_cluster_sync" when you are starting "seed" node first, without running any another node. It makes cluster "Not synced')<br></div><div><br></div><div>Lets imagine, "seed" node starts and find 2 nodes (or more), which one to choose for syncing? And if they have different data (they were not synced between each other), what should it do?</div><div><br></div><div>Thanks.</div></div></div><br><div class="gmail_quote"><div dir="ltr">чт, 3 янв. 2019 г. в 11:33, Liviu Chircu <<a href="mailto:liviu@opensips.org">liviu@opensips.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Happy New Year John, Alexey and everyone else!<br>
<br>
I just finished catching up with this thread, and I must admit that I now<br>
concur with John's distaste of the asymmetric nature of cluster node <br>
restarts!<br>
<br>
Although it is correct and gets the job done, the 2.4 "seed" mechanism <br>
forces<br>
the admin to conditionally add a "opensipsctl fifo ul_cluster_sync" command<br>
into the startup script of all "seed" nodes.  I think we can do better :)<br>
<br>
What if we kept the "seed" concept, but tweaked it such that instead of <br>
meaning:<br>
<br>
"following a restart, always start in 'synced' state, with an empty dataset"<br>
<br>
... it would now mean:<br>
<br>
"following a restart or cluster sync command, fall back to a 'synced' state,<br>
with an empty dataset if and only if we are unable to find a suitable sync<br>
candidate within X seconds"<br>
<br>
This solution seems to fit all requirements that I've seen posted so <br>
far.  It is:<br>
<br>
* correct (a cluster with at least 1 "seed" node will still never deadlock)<br>
* symmetric (with the exception of cluster bootstrapping, all node <br>
restarts are identical)<br>
* autonomous (users need not even know about "ul_cluster_sync" anymore!  <br>
Not saying<br>
               this is necessarily good, but it brings down the learning <br>
curve)<br>
<br>
The only downside could be that any cluster bootstrap will now last at <br>
least X seconds.<br>
But that seems such a rare event (in production, at least) that we need <br>
not worry<br>
about it.  Furthermore, the X seconds will be configurable.<br>
<br>
What do you think?<br>
<br>
PS: by "cluster bootstrap" I mean (re)starting all nodes simultaneously.<br>
<br>
Best regards,<br>
<br>
Liviu Chircu<br>
OpenSIPS Developer<br>
<a href="http://www.opensips-solutions.com" rel="noreferrer" target="_blank">http://www.opensips-solutions.com</a><br>
<br>
On 02.01.2019 12:24, John Quick wrote:<br>
> Alexey,<br>
><br>
> Thanks for your feedback. I acknowledge that, in theory, a situation may<br>
> arise where a node is brought online and all the previously running nodes<br>
> were not fully synchronised so it is then a problem for the newly started<br>
> node to know which data set to pull. In addition to the example you give -<br>
> lost interconnection - I can also foresee difficulties when several nodes<br>
> all start at the same time. However, I do not see how arbitrarily setting<br>
> one node as "seed" will help to resolve either of these situations unless<br>
> the seed node has more (or better) information than the others.<br>
><br>
> I am trying to design a multi-node solution that is scalable. I want to be<br>
> able to add and remove nodes according to current load. Also, to be able to<br>
> take one node offline, do some maintenance, then bring it back online. For<br>
> my scenario, the probability of any node being taken offline for maintenance<br>
> during the year is 99.9% whereas I would say the probability of partial loss<br>
> of LAN connectivity (causing the split-brain issue) is less than 0.01%.<br>
><br>
> If possible, I would really like to see an option added to the usrloc module<br>
> to override the "seed" node concept. Something that allows any node<br>
> (including seed) to attempt to pull registration details from another node<br>
> on startup. In my scenario, a newly started node with no usrloc data is a<br>
> major problem - it could take it 40 minutes to get close to having a full<br>
> set of registration data. I would prefer to take the risk of it pulling data<br>
> from the wrong node rather than it not attempting to synchronise at all.<br>
><br>
> Happy New Year to all.<br>
><br>
> John Quick<br>
> Smartvox Limited<br>
><br>
><br>
>> Hi John,<br>
>><br>
>> Next is just my opinion. And I didn't explore source code OpenSIPS for<br>
> syncing data.<br>
>> The problem is little bit deeper. As we have cluster, we potentially have<br>
> split-brain.<br>
>> We can disable seed node at all and just let nodes work after<br>
> disaster/restart. But it means that we can't guarantee consistency of data.<br>
> So nodes must show this with <Not in sync> state.<br>
>> Usually clusters use quorum to trust on. But for OpenSIPS I think this<br>
> approach is too expensive. And of course for quorum we need minimum 3 hosts.<br>
>> For 2 hosts after loosing/restoring interconnection it is impossible to<br>
> say, which host has consistent data. That's why OpenSIPS uses seed node as<br>
> artificial trust point. I think <seed> node doesn't solve syncing problems,<br>
> but it simplifies total work.<br>
>> Let's imagine 3 nodes A,B,C. A is Active. A and B lost interconnection. C<br>
> is down. Then C is up and has 2 hosts for syncing. But A already has 200<br>
> phones re-registered for some reason. So we have 200 conflicts (on node B<br>
> the same phones still in memory). Where to sync from? <Seed> host will<br>
> answer this question in 2 cases (A or B). Of course if C is <seed> so it<br>
> just will be happy from the start. And I actually don't know what happens,<br>
> if we now run <ul_cluster_sync> on C. Will it get all the contacts from A<br>
> and B or not?<br>
>> We operate with specific data, which is temporary. So syncing policy can be<br>
> more relaxed. May be it's a good idea to connect somehow <seed> node with<br>
> Active role in the cluster. But again, if Active node restarts and still<br>
> Active - we will have a problem.<br>
>> -----<br>
>> Alexey Vasilyev<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Best regards<br>Alexey Vasilyev</div>