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

    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
    <[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





--

BR,
Denys Pozniak



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

Reply via email to