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

Tue, 06 Jun 2023 08:11:30 -0700 

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 <[email protected] <mailto:[email protected]>>: 

    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@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
    [email protected]  <mailto:[email protected]>
    http://lists.opensips.org/cgi-bin/mailman/listinfo/users  
<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>




--

BR,
Denys Pozniak





_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to