[OpenSIPS-Users] Dispatcher state exchange in an anycast clusterer
Bogdan-Andrei Iancu
bogdan at opensips.org
Tue Jun 13 07:49:49 UTC 2023
Hi,
It is up to you, at cfg level, to decide which tag to use for a new
dialog. And the status of the tag is irrelevant there (from the
assignment perspective).
And the status of the tags must be managed by you, from outside OpenSIPS
- opensips itself will do nothing from this perspective (of switching
the status of the tags) - the only thing it does with the tags is to be
sure a tag is active on a single node.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 6/12/23 1:37 PM, Denys Pozniak wrote:
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20230613/25943ac5/attachment-0001.html>
More information about the Users
mailing list