Hi,
We avoided on purpose an unset command, as in such case it will be
impossible to decide which remaining node should take over the tag -
keep in mind that the fundamental idea is that a sharing tag MUST be
active on some node. By allowing only setting the tag as active, we (1)
are sure we have an active node all the time and (b) we are sure that
only one is active (as all other will step down upon broadcast).
Of course, if you have some scenarios which do not fit with this
philosophy, I am open to discussions and patches.
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 20.06.2025 16:01, Wadii wrote:
hello
I had a similar setup, you can avoid the split brain issue by not
hardcoding the sharing_tag active state in clusterer module config
Either set both servers to start with 'backup' state / 'none' by
removing the param entirely, then few seconds after startup via
startup_route each server checks if it actually has the VIP and only
then sets itself active if needed.
startup_route {
launch(exec("sleep 10 && /path/check_vip.py",, $var(out), $var(err)),
vip_check_route);
}
This way reality determines who's active, not config files
Le ven. 20 juin 2025 à 13:48, Alexey <slackway...@gmail.com> a écrit :
Hi list, hi Team,
I would like to know if it is possible to add one more
MI command for the clusterer module, which will be
the opposite for the 'clusterer_shtag_set_active' command.
E.g. 'clusterer_shtag_set_inactive'.
It could be very useful in some scenarios.
We have an active/standby cluster based on Keepalived.
And Keepalived is configured with the ability to be switched
manually from active to standby. I mean that the keepalived.conf
on both nodes has these two not default options:
state BACKUP # both must be BACKUP for nopreempt to work
nopreempt
And keepalived is configured to execute the script when the node
becomes active (or 'master' in keepalived terminology):
...
vrrp_instance voip {
notify_master "/etc/keepalived/master-backup.sh MASTER"
notify_backup "/etc/keepalived/master-backup.sh BACKUP"
notify_stop "/etc/keepalived/master-backup.sh STOP"
notify_fault "/etc/keepalived/master-backup.sh FAULT"
...
And this script runs MI command:
...
/usr/bin/opensips-cli -x mi clusterer_shtag_set_active vip/1
...
Keepalived works well.
One OpenSIPS node has the following configuration
of the clusterer module and sharing_tags:
...
modparam("clusterer", "sharing_tag", "vip/1=active")
...
The other one - the following:
...
modparam("clusterer", "sharing_tag", "vip/1=backup")
...
So, if the state of nodes changes, we can run MI command
'clusterer_shtag_set_active' triggered by Keepalived state change,
and we do it.
But if the first node is rebooted, OpenSIPS starts with the
configured options -
modparam("clusterer", "sharing_tag", "vip/1=active") .
But because of 'nopreempt' option in keepalived.conf the state
of the nodes remains unchanged (I configured it on purpose,
it's convenient for me to be able to switch nodes manually and
to decide which one will be active - I copied the behavior of
AcmePacket SBC
with these options).
So, in some cases the situation bacomes as follows:
the second node became active (either manually or because of some
problems on the first node) and remains in active state.
But after rebooting the first node OpenSIPS on it starts with
modparam("clusterer", "sharing_tag", "vip/1=active") parameters.
So, since that, both nodes are sure that each of them should have
active sharing_tags.
At the same time, keepalived on the first node enters backup state,
because it sees that the second node is already in master state
(nopreempt option works).
If such a command existed, I could use it in keepalived config/script
and run it during switching to backup, something like -
/usr/bin/opensips-cli -x mi clusterer_shtag_set_INactive vip/1
--
best regards, Alexey
https://alexeyka.zantsev.com/
_______________________________________________
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
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
