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

Greger V. Teigre wrote: 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. Also a possible approach, maybe we should think about something like that. 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. 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) 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. 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. 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. 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