[Serusers] Global Failover Server

[Greger V. Teigre]

TO ALL!!!
The link below describes three alternatives. A forth, quite recently 
discussed on this list and serdev, should also be there: using 
dispatcher on a stateless SER. If there are somebody who uses such a 
setup, feel free to add it to the page!
Also, Nick and others: If the descriptions are a bit short, misleading, 
or if something misses, feel free to add/change.

The rest is inline.

Nick Hoffman wrote:
> Hi Greger. I have a few questions about the three solutions you've proposed 
> in "Failover/redundancy and Scalability Overview" 
> (http://www.iptel.org/drupal/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?
>   
No, I mean the usrloc-cl module found in experimental (for 0.9.x). 
Nothing is stored in memory, all queries are thrown at the db.
> 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 
> db_mode(1)?
>   
Yep.
> With this setup, can any UA register with any SER?
>   
Yep, the path header will be stored in the DB and the info there would 
be used for routing.
>> 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?
>   
No, each peer is responsible for replicating to the other peers.
> I'm afraid I don't understand the last sentence you wrote above. Would you 
> mind explaining it in a bit more detail please?
>   
The UA #1 registers with SER A and call comes from UA #2 on SER B.  SER 
B can try to contact UA #1 directly, but if the UA is behind a symmetric 
NAT, the NAT will not allow incoming messages from other ip addresses 
than SER A. Thus, SER B should send the message to SER A, so that SER A 
can contact UA #1 by traversing the NAT.
>> 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?
>   
Yep.
>> Each of these three can be combined with either:
>> a. call-id sticky front-end load balancer (commercial or modified LVS)
>>     
>
> What is that?
>   
What is what? LVS, you mean?  http://www.linuxvirtualserver.org/
>   
>> c. Linux HA creating two and two peers
>>     
>
> What is "two and two peers"?
>   

Linux HA is Linux High Availability; two servers monitor each other and 
if one goes down, the other will take the IP address configured on the 
HA cluster. VRRP can also be used in combination or standalone.
http://www.linux-ha.org/
http://www.ietf.org/html.charters/vrrp-charter.html
http://www.keepalived.org/

The idea is that each physical server can either run virtualization 
(xen/vmware) or use multiple interfaces (one for an active SER and one 
for a standby SER), thus enabling each physical server to both be active 
and a backup for another SER. Of course, you need to make sure that one 
server can take the load of both in case one fails...
g-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060714/c61a88a4/attachment.htm>