Hi Sasmita,
As I have written with bold font in the docs of each cluster parameter:
*This parameter will get overridden if eitherworking_mode_preset
<https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_working_mode_preset>ordb_mode
<https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_db_mode>is
set.*
If you want some low-level configuration for your usrloc cluster (and
not the defaults),
do not set the "working_mode_preset". It's job is to make it easy to
get everything
working.
Regarding 2): the default of "full-sharing-cluster" is to sync from
cluster. That's why
you get no data in MySQL. Just remove "working_mode_preset", and change
the persistency
to "sync-from-sql", so it starts writing the data over there.
An architecture comment regarding 2): you are doing full sharing (any
node should be able
to take over any contact), so make sure your network topology supports
this. A
front-end SIP entity that's balancing traffic to this cluster + SIP path
headers is needed
here before it can logically work, otherwise you'll run into NAT issues
(only the home server
will be able to route back to the phone, rather than any node which has
the data)
Regarding 3): same architectural issue as in 2). You are attempting to
builkd a homogeneous cluster,
yet this is not true, because of all sort of NAT limitations,
restraining traffic to be only
sent from a certain node at a time.
Conclusion: we didn't make these multiple modes just for fun, each of
them serves its purpose :)
And I agree that for your current needs, it seems like the "federated"
clustering is the way to go.
Best regards,
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 25.07.2019 13:05, Sasmita Panda wrote:
I need some clarification on cluster_mode and working_mode_preset
parameter .
modparam("usrloc", "location_cluster", 1)
modparam("usrloc", "working_mode_preset", "federation-cachedb-cluster")
modparam("usrloc", "cluster_mode", "federation-cachedb")
modparam("usrloc", "restart_persistency", "sync-from-cluster")
*1. metadata in mongoDB and exact AOR in opensips memory through which
user is registered . call work fine even when both registered
through different node .*
modparam("usrloc", "working_mode_preset", "full-sharing-cluster")
modparam("usrloc", "cluster_mode", "full-sharing")
modparam("usrloc", "restart_persistency", "sync-from-cluster")
*2. no metadata in mongoDB . AOR of user in opensips memory oly and
synced with each node . So call wont work when 2 user register through
different node . *
modparam("usrloc", "working_mode_preset", "full-sharing-cachedb-cluster")
modparam("usrloc", "cluster_mode", "full-sharing-cachedb")
*3. exact AOR in mongoDB . nothing exist in the opensips memory . This
even wont work when both user registered through different node . *
I was assuming things will work fine in every condition . but its not
working . Am I missing anything in the config so that its not working
for me in 2nd and 3rd scenario ?
In any of above case the data is not getting saved in the mysql DB . I
think it wont even get saved in mysql DB . when we use
working_mode_preset we cant use db_mode .
I think the 1st option is only preferable . Is the 2nd and 3rd option
has this limitations ? Or I have to add something in the config as
well to make this work ?
*/Thanks & Regards/*
/Sasmita Panda/
/Senior Network Testing and Software Engineer/
/3CLogic , ph:07827611765/
On Wed, Jul 24, 2019 at 6:32 PM Liviu Chircu <[email protected]
<mailto:[email protected]>> wrote:
On 24.07.2019 15:33, Sasmita Panda wrote:
Questions :
1. In user location of mongo db , it saves the data of the user
with the node IP . Its not the actual AOR of the user . Where
does the actual AOR get saved ? Is that saved in the memory of
opensips node only?
Correct: the MongoDB only holds metadata, showing where the user
is reachable from to all nodes. The actual AoR is saved
in OpenSIPS memory, which is then sync'ed to the local MySQL
"location" table, for restart persistency purposes. See
the restart_persistency [1] modparam for more details.
2. As the cluster info is in the mysql DB , If 1 node will get
down , then I have to update the DB immediately and restart the
service ? OR that node will be disabled automatically no need of
service restart ?
No need to edit anything. The cluster detects when a node is down
and acts accordingly.
The cluster nodes will keep sending "probing" pings, to detect
when it comes back online.
Regards,
[1]:
https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_restart_persistency
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
<https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_restart_persistency>
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
