[OpenSIPS-Users] Dispatcher state exchange in an anycast clusterer
Bogdan-Andrei Iancu
bogdan at opensips.org
Tue Jun 6 15:07:51 UTC 2023
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
> <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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20230606/2d8a27b8/attachment-0001.html>
More information about the Users
mailing list