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

[Bogdan-Andrei Iancu]

:+1:

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
  https://www.siphub.com

On 6/12/23 5:19 PM, Denys Pozniak wrote:
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 >:


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
mailto:bog...@opensips.org>>:

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
mailto:bog...@opensips.org>>:

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 "a

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

[Bogdan-Andrei Iancu]

Hi,

It  is up to you, at cfg level, to decide which tag to use for a new 
dialog. And the status of the tag is irrelevant there (from the 
assignment perspective).


And the status of the tags must be managed by you, from outside OpenSIPS 
- opensips itself will do nothing from this perspective (of switching 
the status of the tags) - the only thing it does with the tags is to be 
sure a tag is active on a single node.


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
  https://www.siphub.com

On 6/12/23 1:37 PM, Denys Pozniak wrote:

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


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
mailto:bog...@opensips.org>>:

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
mailto:bog...@opensips.org>>:

Hi Denys,

So, in the dispatcher cluster you have some acti

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

[Denys Pozniak]

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 :

> 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 :
>
>> 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 :
>>
>>> 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 :
>>>
 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-solu

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

[Denys Pozniak]

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 :

> 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 :
>
>> 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 :
>>
>>> 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 i

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

[Bogdan-Andrei Iancu]

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


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
mailto:bog...@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



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 al

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

[Denys Pozniak]

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 :

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

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

[Bogdan-Andrei Iancu]

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


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

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

[Denys Pozniak]

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 :

> 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 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>

-- 

BR,
Denys Pozniak
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

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

[Bogdan-Andrei Iancu]

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 list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

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

[Denys Pozniak]

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
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users