[Serusers] ser mysql/cache sync

[Greger V. Teigre]

See inline.

Andrei Pelinescu-Onciul wrote:
> On Jul 10, 2005 at 10:49, Greger V. Teigre <greger at teigre.com> wrote:
>> Jack Wei wrote:
>>> i am running a cluster with 2 sers.  i start the 1st ser and several
>>> users registers.  the users show up in both the cache and the mysql
>>> db.  then i start the 2nd ser, and it loads the db into the cache.
>>> when the cache entries in the 2nd server times out, the entries are
>>> deleted from the db.  however, when the users registers in the 1st
>>> ser, they aren't entered into the db.  how do i fix this problem?
>>>
>>> the db_mode is set to "2" w/ timer_interval at "10".  i've even
>>> tried setting the db_mode to "1", but that didn't help.
>>
>> Write-through DB mode will write all usrloc changes to the DB.
>> However, all locations are cached in ser memory. This means that
>> there is no way a secondary ser can reload a location from DB. If a
>> location is not found in memory, it is assumed not there.  A new
>> caching approach has been discussed previously on this list (or was
>> it serdev?).
>>
>> You can do the following:
>> - Use write-through DB mode to the shared SQL DB
>> - Use t_replicate to the secondary ser
>> - On the secondary ser, call save_memory() instead of save() (as the
>> location has already been saved in DB)
>>
>> This only works for deployment scenarios where EUCs are not NATed.
>> The reason is that the secondary ser will have another public IP
>> address than the primary and restricted NATs will not accept
>> incoming packets from other IPs than the one the EUC has registered
>> to.
>>
>> The way to solve this is to either route all INVITEs coming to the
>> secondary through the primary (ex. using Path) or to set up LVS (or
>> similar) where both SERs have the same IP address.  However,
>> currently LVS does not do Call-id based load balancing and people
>> who report this scenario have patched LVS or use a commercial load
>> balancing solution.
>
> It depends a lot on what you are trying to solve: failover or load
> balancing. For failover you need the same ip configured on all the
> machines, t_replicate and a way (outside of ser) of cutting down the
> traffic from the slave machines (and allowing only the primary).
> I think openbsd/freebsd carp would work perfectly for such a setup (I
> haven't tried it though).

Yes, failover is the "easy" part of a setup.  I don't know carp, but I know 
that many people have used Linux HA successfully. The "problem" is that you 
have an active-passive configuration, so you have one server just idling 
standby waiting for something bad to happen :-(

> For load balancing it depends a lot on your setup. For example load
> balancing over call-id makes sense only if you share the entire
> database. OTOH database access and database writes in particular are
> the things which will slow ser the most, so it's better to keep at
> least separate usrloc dbs. In this case, you would need balancing
> after r-uri for
> requests and to-uri for registers.
> You could use  a ser + dispatcher as a load balancer in front. You
> don't even need Path support if you use only one load balancer (you
> just
> forward everything back through it).


Thanks for emphasizing this!  In one of posts on load balancing a while back 
I detailed the non-Path configuration using separate usrloc dbs. I would 
think that a sensible separation of SER, authentication DB, and RTP proxy 
server(s) coupled with a non-Path load balancing two-server system would fit 
most needs.  Also, dependent on the EUCs support for DNS SRV, you could use 
DNS SRV instead of ser + dispatcher as load balancer (which would give 
another failover requirement for the load balancer).

g-)


>
>
> Andrei