[Serusers] SER-Redundancy by Master/Slave-Location-DB

[Andreas Granig]

Greger V. Teigre wrote:
> Yes, I did a quick look at the usrloc module code and can see that 
> resync from DB should be possible, but will probably take some time and 
> I don't think that is a good path.

Yes, either you'll lose the fast memory access if always looking up the 
DB or you synch back from the DB periodically which would mean that it 
could be the case that a location isn't up to date or has expired on a node.

> possible. I think Paul mentioned that his approach was to use the FIFO 
> queue with a TCP/IP wrapper.  An ul_add FIFO command to each server 
> should probably do the trick.

Also a possible approach, maybe we should think about something like that.

>  I assume that the sql synchronization 
> will not take less bandwidth?!

A rough estimate shows that it's at least less then sending a SIP 
message. In fact it's more or less the sql statement that has to be 
transmitted.

But basically in my case I don't see the network as bottleneck since all 
our equipment is located in a 100MBit LAN.

> A SOAP wrapper comes to mind as a solution 
> to the network exchange, but maybe even the SOAP exhange will add too 
> much overhead? 

We currently handle call forwards (conditional and unconditional) with 
location databases too, and here a cronjob runs every minute for 
inserting the CFC and CFUC locations by calling serctl (so it's related 
to Paul's approach of location handling, we just don't use the FIFO 
directly).

But it's planned to use SOAP for realtime provisioning of this stuff, so 
thanks for the hint, maybe this could be done with the location database 
too. For this a kind of soap module would be great to prevent exec_msg 
calls for each registration.
Of course also just thinking loud ;o)

> Do you do load 
> balancing with DNS SRV or Vovida load balancer or similar?

It's currently DNS SRV, but I'd like to set up some kind of load 
balancer (maybe based on 
http://www.linuxvirtualserver.org/software/ipvs.html), just because so 
much UACs don't get the SRV handling right, and it's always a fight to 
get potential new UAC vendors to fix it.

>  Is the MySQL 
> cluster networked or in the same physical location? (I don't know much 
> about mySQL clusters...)

It will be in the same VLAN. MySQL clustering is still beta, so a first 
step would a simple replication (let the SERs write their locations into 
the master database and lookup the location in the local slave 
databases), because replication works well with MySQL. The master 
database could be secured by a heartbeat cluster.

The advantage of the MySQL cluster would be that the SERs could write 
also into their local database. But maybe it would generally be a good 
idea to move the databases to own dedicated machines. We'll see.

>    Paul claimed voicemail to be their single, biggest problem, citing 
> sems to be the most promising. We don't even offer voicemail, but have 
> looked at voicemail solutions from the PSTN domain :-(   How have you 
> solved voicemail?

We use Asterisk for voicemail. The asterisk instances run on the same 
machine as the SERs, and a SER always redirects voicemail calls to the 
local Asterisk, with a failure route to a second one. Not that redundant 
and scaleable, but I don't see voicemail as operation critical as normal 
call routing.
The voicemail storage is shared via NFS by the way.

>    And of course RTP proxy :-)  I like rtpproxy because its simple, you 
> have good control and it's written in C.  However, it has no load 
> balancing and you don't really have control over sessions (stats). It 
> looks like most large installation have chosen python-based mediaproxy 
> due to these two things (as well as video-stream support).  Any thoughts?

We use mediaproxy here, because it's scalable via DNS SRV and it 
supports T.38 (I sent a patch to the serdev list some months ago to 
handle reinvites, and the guys at AG Projects thought about implementing 
something like that, but I haven't heard anything about that since then).

Cheers,
Andy