Hello Everyone,
Dispatcher in cluster causing destinations goes down
unexpectedly.
Scenario:
Two nodes with last ip octet 61 and 41.
Freeswitch stats to calculate weight.
Issue:
61 is set to ping all destinations and report to the 41 the
status via cluster, the issue that 41 bring down all
destinations into Inactive state after cluster update message
until ds_reload issued again.
Attempt to fix:
I tried set limit on which groups which node can ping, but seems
like in cluster it should be relevant, because 61 should get
status of all groups and send to 41.
Relevant Config:
Node 61:
#### Dispatcher
loadmodule "dispatcher.so"
modparam("dispatcher", "db_url", "postgres://")
modparam("dispatcher", "table_name", "dispatcher")
modparam("dispatcher", "setid_col", "setid")
modparam("dispatcher", "priority_col", "priority")
modparam("dispatcher", "destination_col", "destination")
modparam("dispatcher", "cnt_avp", "$avp(274)")
modparam("dispatcher", "grp_avp", "$avp(275)")
modparam("dispatcher", "hash_pvar", "$avp(273)")
modparam("dispatcher", "dst_avp", "$avp(271)")
modparam("dispatcher", "sock_avp", "$avp(276)")
modparam("dispatcher", "ds_ping_from", "sip:proxy@10.30.100.61")
modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_ping_interval", 45)
modparam("dispatcher", "ds_probing_mode", 1)
modparam("dispatcher", "ds_probing_threshold", 5)
modparam("dispatcher", "ds_probing_list", "2,3,4")
modparam("dispatcher", "fetch_freeswitch_stats", 1)
modparam("dispatcher", "options_reply_codes", "501,403,404,400,200")
modparam("dispatcher", "cluster_id", 1)
Node 41:
#### Dispatcher
loadmodule "dispatcher.so"
modparam("dispatcher", "")
modparam("dispatcher", "table_name", "dispatcher")
modparam("dispatcher", "setid_col", "setid")
modparam("dispatcher", "priority_col", "priority")
modparam("dispatcher", "destination_col", "destination")
modparam("dispatcher", "cnt_avp", "$avp(274)")
modparam("dispatcher", "grp_avp", "$avp(275)")
modparam("dispatcher", "hash_pvar", "$avp(273)")
modparam("dispatcher", "dst_avp", "$avp(271)")
modparam("dispatcher", "sock_avp", "$avp(276)")
modparam("dispatcher", "ds_ping_from", "sip:proxy@10.30.100.41")
modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_ping_interval", 45)
modparam("dispatcher", "ds_probing_mode", 1)
modparam("dispatcher", "ds_probing_threshold", 5)
modparam("dispatcher", "fetch_freeswitch_stats", 1)
modparam("dispatcher", "options_reply_codes", "501,403,404,400,200")
modparam("dispatcher", "ds_probing_list", "1")
modparam("dispatcher", "cluster_id", 1)
modparam("dispatcher", "cluster_sharing_tag", "vip")
Comments:
I think in cluster 41 should not do any operation or decisions regard node states and it should rely on 61 only
Log:
41 node
[root@vprx00 ~]# grep EVENT /var/log/opensips/opensips.log
Feb 1 12:44:57 vprx00 /usr/sbin/opensips[250547]: [EVENT_ROUTE] [DISPATCHER] received group=0 ~> address=sip:10.30.100.57:5160 ~> status=inactive
Feb 1 12:50:54 vprx00 /usr/sbin/opensips[250545]: [EVENT_ROUTE] [DISPATCHER] received group=0 ~> address=sip:10.30.100.48:5160 ~> status=inactive
Feb 1 12:52:15 vprx00 /usr/sbin/opensips[250538]: [EVENT_ROUTE] [DISPATCHER] received group=0 ~> address=sip:10.30.100.49:5160 ~> status=inactive
41 node
Feb 1 14:24:49 vprx00 /usr/sbin/opensips[250540]:
DBG:dispatcher:w_ds_select: ds_select: 1 1 1000 1
Feb 1 14:24:49 vprx00 /usr/sbin/opensips[250540]:
DBG:dispatcher:ds_select_dst: no active destinations in set [1] !
volga629.
