Hi *,
Normally, OpenSER should work just fine with a MySQL Cluster, but I would like to know if anyone has tried this configuration yet.
Are there any configuration settings I should be aware of?
Thanks, Sica.
____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC
-----Original Message----- From: users-bounces@openser.org [mailto:users-bounces@openser.org] On Behalf Of Vasile Zaharia Sent: Tuesday, September 18, 2007 8:11 AM To: users@openser.org Subject: [OpenSER-Users] OpenSER with MySQL Cluster
Hi *,
Normally, OpenSER should work just fine with a MySQL Cluster, but I would like to know if anyone has tried this configuration yet.
Are there any configuration settings I should be aware of?
Thanks, Sica.
I use OpenSER with MySQL Cluster and it works just fine. There are no problems with the normal OpenSER schema. As far as I know (and someone correct me if I'm wrong), there is no way to cause OpenSER to automatically switch away from a failed MySQL node. However, we use UltraMonkey for load balancing and failover of our MySQL nodes and it works fine.
- Brad
Watkins, Bradley writes:
As far as I know (and someone correct me if I'm wrong), there is no way to cause OpenSER to automatically switch away from a failed MySQL node.
is this a big problem if sql node is always co-located with your openser proxy, i.e., that openser always uses mysql server on localhost?
-- juha
Vasile Zaharia wrote:
Hi *,
Normally, OpenSER should work just fine with a MySQL Cluster, but I would like to know if anyone has tried this configuration yet.
Are there any configuration settings I should be aware of?
As Brad mentioned, OpenSER works fine with MySQL Cluster. We are using a two node mysql cluster with our two redundant openser proxies, which provides us with a geo-redundant SIP signaling core.
If you are interested in proxy failover, you may want to consider using usrloc's 'DB only' mode:
modparam("usrloc", "db_mode", 3)
This mode ensures that all SIP registrations are directly written to the 'location' mysql table, without being buffered in a memory cache. Since mysql cluster uses in-memory databases, performance is pretty good even with db_mode 3, at least if you run a cluster data node on the same host as openser.
/Christian
Christian Schlatter writes:
This mode ensures that all SIP registrations are directly written to the 'location' mysql table, without being buffered in a memory cache. Since mysql cluster uses in-memory databases, performance is pretty good even with db_mode 3, at least if you run a cluster data node on the same host as openser.
some of the presence stuff does not work with db_mode=3. what is the disadvantage of using mode 1 or 2 in the proxy that receives register request from user and 0 in others?
-- juha
Juha Heinanen wrote:
Christian Schlatter writes:
This mode ensures that all SIP registrations are directly written to the 'location' mysql table, without being buffered in a memory cache. Since mysql cluster uses in-memory databases, performance is pretty good even with db_mode 3, at least if you run a cluster data node on the same host as openser.
some of the presence stuff does not work with db_mode=3. what is the disadvantage of using mode 1 or 2 in the proxy that receives register request from user and 0 in others?
-- juha
It doesn't matter if you have only one registrar. But if you want to do load-balancing/failover between multiple registrars, those registrars should access the shared mysql cluster tables instead of their local memory cache. If a phone registers with a proxy, the new registration state has to be known to all registrars immediately.
/Christian
Christian Schlatter writes:
It doesn't matter if you have only one registrar. But if you want to do load-balancing/failover between multiple registrars, those registrars should access the shared mysql cluster tables instead of their local memory cache. If a phone registers with a proxy, the new registration state has to be known to all registrars immediately.
if proxy x in the cluster receives registration request from a sip ua, it saves it both in memory and (immediately (mode 1) or after a while (mode 2)) into database, and then forwards the register request to other proxies in the cluster that just save into memory. is that "immediately" enough?
-- juha
Juha Heinanen wrote:
Christian Schlatter writes:
It doesn't matter if you have only one registrar. But if you want to do load-balancing/failover between multiple registrars, those registrars should access the shared mysql cluster tables instead of their local memory cache. If a phone registers with a proxy, the new registration state has to be known to all registrars immediately.
if proxy x in the cluster receives registration request from a sip ua, it saves it both in memory and (immediately (mode 1) or after a while (mode 2)) into database, and then forwards the register request to other proxies in the cluster that just save into memory. is that "immediately" enough?
Yes.
I was referring to an architecture where the mysql cluster is used to share registration state between the proxies. For this, db_mode=3 is required.
What I don't like about replicating registration state through duplicated REGISTER messages, is the fact that a proxy's view of the registration state is not necessarily consistent with the other proxy's views. What if one of the proxies is not reachable for 10 minutes. It will be out of sync at least until all sip UAs who have registered while the proxy isn't reachable have re-registered.
Also if you have to reboot a proxy, it will not learn the correct registration state upon boot as it would do if you would use db_mode=3 together with a distributed DB.
So, yes, you don't need db_mode=3 if you do REGISTER replication, but I'd recommend to use a distributed DB for replicating registration state.
/Christian
Christian Schlatter writes:
What I don't like about replicating registration state through duplicated REGISTER messages, is the fact that a proxy's view of the registration state is not necessarily consistent with the other proxy's views. What if one of the proxies is not reachable for 10 minutes. It will be out of sync at least until all sip UAs who have registered while the proxy isn't reachable have re-registered.
yes, that can happen if another proxy is up, but not reachable. there is no problem if another proxy crashes and gets restarted, because if db_mode=1 is used, db is updated immediately exactly as with db_mode=3.
Also if you have to reboot a proxy, it will not learn the correct registration state upon boot as it would do if you would use db_mode=3 together with a distributed DB.
not true, if mode=1.
So, yes, you don't need db_mode=3 if you do REGISTER replication, but I'd recommend to use a distributed DB for replicating registration state.
unfortunately you then cannot support presence. using another proxy for presence is not a solution either, because same users need both presence and other sip methods.
by the way, looks like presence related requests are by far the most common ones if all sip UAs have presence turned on. it means that presence would also create biggest db activity.
-- juha
Juha Heinanen wrote: ...
unfortunately you then cannot support presence. using another proxy for presence is not a solution either, because same users need both presence and other sip methods.
What exactly prevents me from using a dedicated presence server? And why can't I support presence with db_mode=3?
E.g. if I just want to deploy a simple PA using the PRESENCE module, I don't see any dependencies on USRLOC.
I'm not sure if PUA_USRLOC depends on db_mode<3, but at least the documentation doesn't mention it. And it looks to me like I could use pua_set_publish() from PUA_USRLOC to send a PUBLISH to my dedicated presence server ;-) ... I haven't tried that though.
by the way, looks like presence related requests are by far the most common ones if all sip UAs have presence turned on. it means that presence would also create biggest db activity.
Yes, I know, SIP presence is very chatty.
/Christian
hi i'm curious about this one. we used to run a dual Openser installation with MySQL cluster, but this proved to very unstable (on the cluster side). is this working fine now?
for instance, if one of the mysql cluster nodes was disconnected, this could lead to complete cluster shut down, and nodes didn't handle reconnect very good.
so, we actually switched to the register replication instead...
best regards /Staffan
-----Original Message----- From: users-bounces@openser.org [mailto:users-bounces@openser.org] On Behalf Of Christian Schlatter Sent: den 18 september 2007 23:37 To: Juha Heinanen Cc: users@openser.org Subject: Re: [OpenSER-Users] OpenSER with MySQL Cluster
Juha Heinanen wrote: ...
unfortunately you then cannot support presence. using
another proxy
for presence is not a solution either, because same users need both presence and other sip methods.
What exactly prevents me from using a dedicated presence server? And why can't I support presence with db_mode=3?
E.g. if I just want to deploy a simple PA using the PRESENCE module, I don't see any dependencies on USRLOC.
I'm not sure if PUA_USRLOC depends on db_mode<3, but at least the documentation doesn't mention it. And it looks to me like I could use pua_set_publish() from PUA_USRLOC to send a PUBLISH to my dedicated presence server ;-) ... I haven't tried that though.
by the way, looks like presence related requests are by far the most common ones if all sip UAs have presence turned on. it means that presence would also create biggest db activity.
Yes, I know, SIP presence is very chatty.
/Christian
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Kerker Staffan writes:
i'm curious about this one. we used to run a dual Openser installation with MySQL cluster, but this proved to very unstable (on the cluster side). is this working fine now?
i had exactly the same problem with mysql server 4.1. if i just unplugged ethernet cable on the other ndb node, the whole cluster went down.
i have now been experimenting with mysql server 5.0.32 (or something like that) and things have improved. yesterday i did all kinds of tricks to a two ndb node cluster and didn't manage to break it. sometimes though it took a quite long time to get the cluster initially up starting to count when all processes were running.
also, i think that one still cannot alter ndb tables on the fly so upgrading to next openser version will be a big hassle that no-one would like to have in production environment.
so apart from alter table hassle, perhaps mysql cluster would now be ready for prime time.
-- juha
On Wednesday 19 September 2007, Juha Heinanen wrote:
[..] i have now been experimenting with mysql server 5.0.32 (or something like that) and things have improved. yesterday i did all kinds of tricks to a two ndb node cluster and didn't manage to break it. sometimes though it took a quite long time to get the cluster initially up starting to count when all processes were running.
also, i think that one still cannot alter ndb tables on the fly so upgrading to next openser version will be a big hassle that no-one would like to have in production environment.
so apart from alter table hassle, perhaps mysql cluster would now be ready for prime time.
Hi Juha,
nice to hear that they improved the stability of this stuff.
it seems that in the upcomming 5.1 release online schema updates will be possible.
http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-limitations-resolved.ht...
Cheers,
Henning
Kerker Staffan wrote:
hi i'm curious about this one. we used to run a dual Openser installation with MySQL cluster, but this proved to very unstable (on the cluster side). is this working fine now?
for instance, if one of the mysql cluster nodes was disconnected, this could lead to complete cluster shut down, and nodes didn't handle reconnect very good.
so, we actually switched to the register replication instead...
We're running a mysql 5.0.22 cluster for our two redundant openser proxies. This setup works very stable for about a year now.
In the beginning our cluster was shutting down itself quite regularly e.g. after a network failure. Since then we
- are running the management nodes on hosts that are connected to the data nodes through different network paths (this is essential, a cluster node needs to be able to solve the splitbrain problem)
- have added 'StopOnError = 0' to the data node settings (this causes a data nodes to try to reconnect after it lost communication to its neighbors, per default, a data node just shuts itself down)
- added enough DataMemory and IndexMemory for the data nodes (DataMemory = 1024M, IndexMemory = 64M)
Overall I'm quite pleased with our mysql cluster solution, although I'd prefer a solution where the UAs do register with both of our proxies, so that there is no need to replicate registration state between the proxies.
Our mysql cluster basically only contains the 'location' table since we store all account data on redundant LDAP/H350 directories.
/Christian
best regards /Staffan
-----Original Message----- From: users-bounces@openser.org [mailto:users-bounces@openser.org] On Behalf Of Christian Schlatter Sent: den 18 september 2007 23:37 To: Juha Heinanen Cc: users@openser.org Subject: Re: [OpenSER-Users] OpenSER with MySQL Cluster
Juha Heinanen wrote: ...
unfortunately you then cannot support presence. using
another proxy
for presence is not a solution either, because same users need both presence and other sip methods.
What exactly prevents me from using a dedicated presence server? And why can't I support presence with db_mode=3?
E.g. if I just want to deploy a simple PA using the PRESENCE module, I don't see any dependencies on USRLOC.
I'm not sure if PUA_USRLOC depends on db_mode<3, but at least the documentation doesn't mention it. And it looks to me like I could use pua_set_publish() from PUA_USRLOC to send a PUBLISH to my dedicated presence server ;-) ... I haven't tried that though.
by the way, looks like presence related requests are by far the most common ones if all sip UAs have presence turned on. it means that presence would also create biggest db activity.
Yes, I know, SIP presence is very chatty.
/Christian
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Juha Heinanen schrieb:
Christian Schlatter writes:
This mode ensures that all SIP registrations are directly written to the 'location' mysql table, without being buffered in a memory cache. Since mysql cluster uses in-memory databases, performance is pretty good even with db_mode 3, at least if you run a cluster data node on the same host as openser.
some of the presence stuff does not work with db_mode=3. what is the
Hi Juha! What does "some of the .. stuff" exactly mean?
klaus
Klaus Darilion writes:
Hi Juha! What does "some of the .. stuff" exactly mean?
usrloc module README says:
The lack of memory caching also disable the location watcher registration (in will not work with PA module) and disable the statistics exports.
now when i read it carefully, it mentions PA module, which is the old presence module. so perhaps there are no restrictions with new presence (openser) presence modules. i need to give it a try.
-- juha
ps. do we still need pa module in openser trunk or could it be removed?
Hi Juha,
in my opinion the module is obsolete and I suggest to publicly vote if it should be removed or not (actually if somebody has good reason to keep it).
regards, bogdan
Juha Heinanen wrote:
ps. do we still need pa module in openser trunk or could it be removed?
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-
Bogdan-Andrei Iancu -
Christian Schlatter -
Henning Westerholt -
jh＠tutpro.com -
Kerker Staffan -
Klaus Darilion -
Vasile Zaharia -
Watkins, Bradley