See inline.
Andrei Pelinescu-Onciul wrote:
On Jul 10, 2005 at 10:49, Greger V. Teigre
<greger(a)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