[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