[Serusers] Global Failover Server

Nick Hoffman nick.hoffman at altcall.com
Thu Jul 13 05:53:23 CEST 2006

Hi Greger. I have a few questions about the three solutions you've proposed 
in "Failover/redundancy and Scalability Overview" 

> 1. Cacheless usrloc with a mysql cluster as back-end DB combined with
> implementation of the Path header (to find the registrar of a given UA).
> No replication across servers

By "cacheless usrloc", do you mean db_mode(1) for the "usrloc" module?

What do you mean by "implementation of the Path header (to find the 
registrar of a given UA)"?

Would [registration?] replication across servers not be needed because of 

With this setup, can any UA register with any SER?

> 2.  Multiple SER registrars, each with a standalone, local DB and where
> SIP is used to replicate registrations.  By storing replications from a
> peer in a location_peer1 table and then lookup using this table, you can
> route INVITEs to the registrar being able to pinhole the NAT in front of
> a given UA

If each SER has its own local DB, UAs have to register with a specific SER 
rather than any of the available SERs, right?

I'm afraid I don't understand the last sentence you wrote above. Would you 
mind explaining it in a bit more detail please?

> 3. Each SER is connected to a single mysql DB cluster as in #1, but
> since usrloc also is in memory (cacheless usrloc is not used),
> replication is done between the SER servers and save_memory() is used to
> store the location only in memory (the registrar updates the cluster
> with save())

With this setup, can any UA register with any SER?

> Each of these three can be combined with either:
> a. call-id sticky front-end load balancer (commercial or modified LVS)

What is that?

> c. Linux HA creating two and two peers

What is "two and two peers"?

-- Nick
e: nick.hoffman at altcall.com
p: +61 7 5591 3588
f: +61 7 5591 6588

If you receive this email by mistake, please notify us and do not make any 
use of the email.  We do not waive any privilege, confidentiality or 
copyright associated with it.

More information about the sr-users mailing list