[Users] how to refresh REGISTER state when restarting redundant proxy

Christian Schlatter cs at unc.edu
Mon Apr 23 02:32:48 CEST 2007


Alan,

Alan Crosswell wrote:
> One option being discussed here is running mysql replicated.  This
> brings up the concern that the independent proxies are not aware that
> they are talking to a single database instance.  Will there be issues
> involved such as:
> - deadlocks
> - inconsistency of in-memory and in-database data structures
>   (e.g. usrloc, presence)
> - collisions of per-proxy unique keys that are inserted into
>   tables
> Personally, I think mysql replication violates KISS if I am trying to
> have my redundant servers as independent and survivable as possible.

With mysql master-slave replication only one proxy could write to the 
database, so you'd need master-master replication which is possible but 
doesn't offer ACID as mysql cluster does.

I agree that using DB replication violates KISS as would also do the 
application layer state replication solutions you're describing below. 
For me the best solution would be to have endpoints registering with all 
redundant proxies in parallel. This would also be in-line with SIP's 
redundancy in the previous hop. The newest firmware release for the 
Polycom SIP phones does support that, though I haven't tested it yet. 
Are there other endpoints implementing this feature?

Christian


> 
> Some approaches we've talked about here that don't use mysql
> replication are:
> - in /etc/init.d/openser start, add a step to copy registrations
>   from the other server(s) that would have normally been learned
>   by t_replicate().  Basically select * from location | insert....
> - consider doing something at the application level along the lines
>   of an "openserctl ul show" to get this data.  This has the advantage
>   of not going "behind the back" of the proxy and would even work for
>   t_replicate() situations in which the proxies are not flushing usrloc
>   to persistent storage.
> 
> Our architecture load shares two proxies.  While UAs think they have a
> single proxy they've registered to, inbound INVITEs are randomly
> distributed among the two proxies (e.g. on our PSTN media gateways, or
> other UAs that happen to have chosen the other proxy as their outbound).
> 
> Any comments from people who have already dealt with this issue or are
> thinking about it would be appreciated.
> /a
> 
> Cesc wrote:
>> Though it is not my field of speciality, you most probably wanna synch
>> directly the Mysql database ... maybe mysql provides such "sync"
>> function, otherwise you may have to write some script or such ... This
>> way on boot the db is already sinch'd
>>
>> Cesc
>>
>> On 4/22/07, Alan Crosswell <alan at columbia.edu> wrote:
>>> Bogdan,
>>>
>>> I already have persistence across restarts wth mysql support.  The issue
>>> is that with replicated servers, using t_replicate(), if one is down for
>>> several hours or days (e.g. due to a hardware failure -- which is why we
>>> are replicating in the first place), then it no longer has current state
>>> and needs to acquire it somehow.
>>>
>>> /a
>>>
>>> Bogdan-Andrei Iancu wrote:
>>>> Hi Alan,
>>>>
>>>> if you need persistence over restarts, you need to use mysql support.
>>>>
>>>> regards,
>>>> bogdan
>>>>
>>>> Alan Crosswell wrote:
>>>>> We are using t_replicate() to replicate REGISTERs among redundant
>>>>> proxies (and a separate presence server that needs REGISTER for
>>>>> pua_bla).  Before reinventing the wheel here, I thought I'd ask if
>>>>> others already have a method in place to re-sync a restarted proxy's
>>>>> state?  I guess one way is to pull the usrloc data from mysql....
>>>>> Another would be to somehow ask the proxy to walk the usrloc table and
>>>>> do a bunch of t_registers()...
>>>>>
>>>>> Any thoughts appreciated.
>>>>> /a
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at openser.org
>>>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at openser.org
>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>
> 
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users





More information about the Users mailing list