18 Sep
2007
18 Sep
'07
3:10 p.m.
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
18 Sep
18 Sep
3:27 p.m.
-----Original Message-----
From: users-bounces(a)openser.org
[mailto:users-bounces@openser.org] On Behalf Of Vasile Zaharia
Sent: Tuesday, September 18, 2007 8:11 AM
To: users(a)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
19 Sep
19 Sep
9:57 a.m.
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
18 Sep
18 Sep
4:14 p.m.
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
4:22 p.m.
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
7:53 p.m.
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.
/Christian
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
8:02 p.m.
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
8:43 p.m.
Juha Heinanen wrote:
Christian Schlatter writes:
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
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?
8:54 p.m.
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
19 Sep
19 Sep
12:37 a.m.
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
9:06 a.m.
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(a)openser.org
[mailto:users-bounces@openser.org] On Behalf Of Christian Schlatter
Sent: den 18 september 2007 23:37
To: Juha Heinanen
Cc: users(a)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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
9:31 a.m.
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
12:13 p.m.
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.h…
Cheers,
Henning
4:42 p.m.
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(a)openser.org
> [mailto:users-bounces@openser.org] On Behalf Of Christian Schlatter
> Sent: den 18 september 2007 23:37
> To: Juha Heinanen
> Cc: users(a)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(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
9:13 a.m.
Juha Heinanen schrieb:
Christian Schlatter writes:
Hi Juha! What does "some of the .. stuff" exactly mean?
klaus
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
9:42 a.m.
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?
5:02 p.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6278
days inactive
6279
days old
16 comments
8 participants
participants (8)
-
Bogdan-Andrei Iancu -
Christian Schlatter -
Henning Westerholt -
jh＠tutpro.com -
Kerker Staffan -
Klaus Darilion -
Vasile Zaharia -
Watkins, Bradley