Judging by the documentation, the activation of the tag of a non-working node in the context of dialogs should be handled by an external system. So it won't happen automatically, right?
"If node 1 fails, the monitoring system (also responsible for the Anycast management and BGP updates) will pick one of the remaining node in the anycast group and it will activate the “node_1” tag on it. So, this new node will became owner and responsible for the calls created on former node 1." пн, 12 июн. 2023 г. в 13:37, Denys Pozniak <[email protected]>: > 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 <[email protected]>: > >> 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]>: >> >>> 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]>: >>> >>>> 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 >>>> >>>> Regards, >>>> >>>> Bogdan-Andrei Iancu >>>> >>>> OpenSIPS Founder and Developer >>>> https://www.opensips-solutions.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 >>>> [email protected]http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>>> >>> >>> -- >>> >>> BR, >>> Denys Pozniak >>> >>> >>> >>> >> >> -- >> >> BR, >> Denys Pozniak >> >> >> >> > > -- > > BR, > Denys Pozniak > > > -- BR, Denys Pozniak
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
