[OpenSIPS-Users] Dispatcher state exchange in an anycast clusterer
Bogdan-Andrei Iancu
bogdan at opensips.org
Tue Jun 13 07:50:05 UTC 2023
:+1:
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 6/12/23 5:19 PM, Denys Pozniak wrote:
> 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
> <mailto: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 <mailto: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.opensips-solutions.com>
> https://www.siphub.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 <mailto: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
>> <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.opensips-solutions.com>
>> https://www.siphub.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 <mailto: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
>>> <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.opensips-solutions.com>
>>> https://www.siphub.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 list
>>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users <http://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/20230613/71b337c2/attachment-0001.html>
More information about the Users
mailing list