[OpenSIPS-Users] Dispatcher state exchange in an anycast clusterer

Mon Jun 12 14:19:06 UTC 2023

Judging by the documentation, the activation of the tag of a non-working
node in the context of dialogs should be handled by an external system. So
it won't happen automatically, right?

  "If node 1 fails, the monitoring system (also responsible for the Anycast
management and BGP updates) will pick one of the remaining node in the
anycast group and it will activate the “node_1” tag on it.
   So, this new node will became owner and responsible for the calls
created on former node 1."

пн, 12 июн. 2023 г. в 13:37, Denys Pozniak <denys.pozniak at gmail.com>:

> Hello!
> Thank you for your help!
>
> >2) you can use the same sharing tag for multiple modules, as time as
> from logical perspective, the switching of the tags fits all the cases. For
> dialogs, you may need one tag per node (to remember which node created the
> dialog), so you may not be able to reuse here.
> Do I understand correctly that when creating a dialog on a node, an active
> tag will be attached to it.
> And if this node falls out of the cluster, then this tag will be
> automatically activated like some other node and all the dialog information
> (variables) will be available on it?
>
> There is also a question about transactions. How will the response be
> handled if the owner of the transaction is not available?
>
>
> пн, 12 июн. 2023 г. в 10:30, Bogdan-Andrei Iancu <bogdan at opensips.org>:
>
>> Hi Denys,
>>
>> 1) yes
>>
>> 2) you can use the same sharing tag for multiple modules, as time as from
>> logical perspective, the switching of the tags fits all the cases. For
>> dialogs, you may need one tag per node (to remember which node created the
>> dialog), so you may not be able to reuse here.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   https://www.opensips-solutions.com
>>   https://www.siphub.com
>>
>> On 6/9/23 1:30 PM, Denys Pozniak wrote:
>>
>> Hello!
>> Thank you! The mechanism with a single tag for the dispatcher works as it
>> should.
>>
>> But I still have a number of questions on related topics:
>> 1)  Should I declare this common dispatcher tag in the parameters of the
>> clusterer module?
>> Then, after the start, the tag on the active node will be set by an
>> external script.
>>
>>  modparam("clusterer", "sharing_tag", "dispatcher/1=backup")
>>  modparam("dispatcher", "cluster_sharing_tag", "dispatcher")
>>
>> 2) I also want to replicate transactions and dialogs, so should I declare
>> own tags for each cluster node?
>> Or like with a dispatcher do I need one common?
>>
>> modparam("clusterer", "sharing_tag", "anycast1/1=active")
>> modparam("clusterer", "sharing_tag", "anycast2/1=backup")
>> modparam("clusterer", "sharing_tag", "anycast3/1=backup")
>> modparam("clusterer", "sharing_tag", "anycast4/1=backup")
>> modparam("dialog", "dialog_replication_cluster", 1)
>> modparam("tm", "tm_replication_cluster", 1)
>> modparam("dispatcher", "cluster_sharing_tag", "dispatcher")
>>
>> вт, 6 июн. 2023 г. в 18:08, Bogdan-Andrei Iancu <bogdan at opensips.org>:
>>
>>> Hi Denys,
>>>
>>> Even better if you have only one active opensips instance - in this case
>>> you can use only one sharing-tag across all nodes/servers in the dispatcher
>>> cluster, tag to point to the active instance. So, whenever you point the
>>> traffic to a certain opensips instance, be sure to make the tag active on
>>> that instance too.
>>>
>>> https://opensips.org/html/docs/modules/3.2.x/clusterer.html#mi_clusterer_shtag_set_active
>>>
>>> Best regards,
>>>
>>> Bogdan-Andrei Iancu
>>>
>>> OpenSIPS Founder and Developer
>>>   https://www.opensips-solutions.com
>>>   https://www.siphub.com
>>>
>>> On 6/6/23 4:11 PM, Denys Pozniak wrote:
>>>
>>> Hello!
>>>
>>> >So, in the dispatcher cluster you have some active nodes, but also some
>>> stand-by, right ?
>>> All cluster nodes have the same dynamic routing protocol metric, so only
>>> one random node can receive traffic from the network point of view.
>>> Well, accordingly, only the "active" node can accept replays to SIP
>>> OPTIONS from the dispatcher. And all other nodes see the dispatcher peers
>>> as not alive.
>>> It's more a question of how to make other nodes believe the status from
>>> the "active" node and not influence it.
>>>
>>> >And I see you did not set the this cluster_sharing_tag modparam
>>> I have this option set, you probably didn't notice in the initial thread.
>>> modparam("dispatcher", "cluster_sharing_tag", "anycast1")
>>>
>>>
>>> вт, 6 июн. 2023 г. в 11:37, Bogdan-Andrei Iancu <bogdan at opensips.org>:
>>>
>>>> Hi Denys,
>>>>
>>>> So, in the dispatcher cluster you have some active nodes, but also some
>>>> stand-by, right ?
>>>>
>>>> And I see you did not set the this cluster_sharing_tag modparam [1] -
>>>> check it out, it may help you in deciding which nodes may broadcast the
>>>> state inside the cluster (for dispatcher)
>>>>
>>>> [1]
>>>> https://opensips.org/html/docs/modules/3.3.x/dispatcher.html#param_cluster_sharing_tag
>>>>
>>>> Regards,
>>>>
>>>> Bogdan-Andrei Iancu
>>>>
>>>> OpenSIPS Founder and Developer
>>>>   https://www.opensips-solutions.com
>>>>   https://www.siphub.com
>>>>
>>>> On 6/2/23 5:39 PM, Denys Pozniak wrote:
>>>>
>>>> Hello!
>>>>
>>>> I need advice on how best to implement the anycast + clusterer +
>>>> dispatcher scheme.
>>>> In short, we want to build an additional upper layer in front of our
>>>> sip legacy servers, on which traffic balancing will take place.
>>>> Most likely it will look like several nodes of the same clusterer with
>>>> a single public anycast address, from which traffic will also go to the
>>>> public interfaces of the legacy sip servers (via the dispatcher list).
>>>> During testing, it turned out that if we include the dispatcher module
>>>> in the clusterer, then the inactive nodes of the cluster begin to affect
>>>> the general state of the legacy sip servers on active node, since replays
>>>> to SIP OPTIONS reach only one active node, though all nodes ping.
>>>>
>>>> Thus, the sip server status is constantly flapping on active node.
>>>> Is it possible to somehow make all other nodes believe the active node
>>>> at a given time and inherit its dispatcher state?
>>>>
>>>> *node1:*
>>>> modparam("clusterer", "sharing_tag", "anycast1/1=active")
>>>> modparam("clusterer", "sharing_tag", "anycast2/1=backup")
>>>> modparam("clusterer", "sharing_tag", "anycast3/1=backup")
>>>> modparam("clusterer", "sharing_tag", "anycast4/1=backup")
>>>>
>>>> modparam("dispatcher", "cluster_sharing_tag", "anycast1")
>>>>
>>>> modparam("dispatcher", "db_url", "text:///etc/opensips/dbtext")
>>>> modparam("dispatcher", "attrs_avp", "$avp(dsp_attrs_avp)")
>>>> modparam("dispatcher", "script_attrs_avp", "$avp(dsp_script_attrs_avp)")
>>>> modparam("dispatcher", "hash_pvar", "$avp(dsp_hash_pvar)")
>>>> modparam("dispatcher", "ds_ping_method", "OPTIONS")
>>>> modparam("dispatcher", "ds_ping_from", "sip:ping at dispatcher")
>>>> modparam("dispatcher", "ds_ping_interval", 10)
>>>> modparam("dispatcher", "ds_probing_threshold", 2)
>>>> modparam("dispatcher", "ds_probing_mode", 1)
>>>> modparam("dispatcher", "options_reply_codes", "501,403,404,400,200")
>>>> modparam("dispatcher", "dst_avp", "$avp(dsp_dst_avp)")
>>>> modparam("dispatcher", "grp_avp", "$avp(dsp_grp_avp)")
>>>> modparam("dispatcher", "cnt_avp", "$avp(dsp_cnt_avp)")
>>>> modparam("dispatcher", "persistent_state", 1)
>>>> modparam("dispatcher", "cluster_id", 1)
>>>> modparam("dispatcher", "cluster_probing_mode", "by-shtag")
>>>>
>>>> *dispatcher:*
>>>> id(int,auto) setid(int) destination(string) socket(string,null)
>>>> state(int) probe_mode(int) weight(string) priority(int) attrs(string)
>>>> description(string)
>>>> 0:1:sip\:1.1.1.1\:5060;transport=udp::2:1:1:1:'':''
>>>> 1:1:sip\:2.2.2.2\:5060;transport=udp::2:1:1:1:'':''
>>>> 2:1:sip\:3.3.3.3\:5060;transport=udp::2:1:1:1:'':''
>>>>
>>>> Sure, it is possible to attach an additional public address to each
>>>> node and do not share dispatcher state, but still I would like to somehow
>>>> find a solution for the current scheme
>>>>
>>>> --
>>>>
>>>> BR,
>>>> Denys Pozniak
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>>
>>>
>>> --
>>>
>>> BR,
>>> Denys Pozniak
>>>
>>>
>>>
>>>
>>
>> --
>>
>> BR,
>> Denys Pozniak
>>
>>
>>
>>
>
> --
>
> BR,
> Denys Pozniak
>
>
>

-- 

BR,
Denys Pozniak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20230612/331093f8/attachment-0001.html>