[Serusers] Global Failover Server

Greger V. Teigre greger at teigre.com
Sat Jul 8 09:35:06 CEST 2006 

I'm not sure if I understand your scenario. A stateless proxy would need 
a peer for hardware failures and "a bunch of servers" sounds expensive 
and I'm not sure what you gain. Could you provide some details? (The 
dispatcher module can be used for stateless proxy; using a SER for load 
balancing.  You can also use 302 REFER to divide load across registrars. 
However, regardless how you do it, you need some routing between SER 
servers to make sure that messages to a UA go through the SER server the 
UA contacted as first hop).
g-)

Edson wrote:
>
> Correct me if I'm wrong, but since SER is capable to handle tens or 
> hundreds of thousands of SIP messages per second, why not cut this 
> number down to thousands and compose a HA and Redundancy solution 
> combining some stateless proxy in front of a bunch of servers using 
> cache based (like in 2 -- MySQL cluster, p.ex.)? The stateless proxy 
> could have some local replication (two peers: one active and one 
> inactive) sharing a common IP (registered on SRV) for HA, and the 
> geographic issue could be achieved with a complete replication of this 
> set.
>
>  
>
> The down-point in this approach is that in a geographic switch there 
> is no guarantee that the clusters would be totally consistent between 
> the two sets. The fall can (and Murphy says it will) occur just 
> before, or in the middle, a big replication DB operation. But if You 
> can accomplish that than I see this as a good solution.
>
>  
>
> Comments?
>
>  
>
> Edson.
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* serusers-bounces at lists.iptel.org 
> [mailto:serusers-bounces at lists.iptel.org] *On Behalf Of *Greger V. Teigre
> *Sent:* sexta-feira, 7 de julho de 2006 06:49
> *To:* G.Jacobsen
> *Cc:* seruser List
> *Subject:* Re: [Serusers] Global Failover Server
>
>  
>
> Yes, but this depends on your deployment setup and policies. 
> Obviously, you cannot support all features with all UAs. Three-way 
> conferencing for example. There's no guarantee that REFER and NOTIFYs 
> work for three random UAs from different vendors. There are still too 
> many bugs around. So, you need to say: If you have this and that UA, 
> you will probably not get three-way conferencing.  Not much difference 
> from saying: If you have this and that UA, you may experience service 
> outages.
>
> There are several ways of creating server-side redundancy and 
> scalability. Unfortunately, none are trivial. There are three I have 
> heard have been successfully used in large-scale setups:
> 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
> 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
> 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())
>
> Each of these three can be combined with either:
> a. call-id sticky front-end load balancer (commercial or modified LVS)
> b. DNS SRV
> c. Linux HA creating two and two peers
>
> Only b) combined with either 1) or 3) or 2+c) can give geographic, 
> client and server-side redundancy and scalability.
>
> Scalability and redundancy is sort of a pet project of mine... I would 
> like to see a simple, clear-documented and code-supported setup that 
> satisfies most common requirements. Currently I'm leaning against #2 
> (which actually can be implemented in vanilla SER 0.9.x, but would be 
> easier and better with built-in support). I'm thinking about a setup 
> where two and two servers are peers to eachother using Linux HA. Both 
> servers would have one active SER instance and one inactive ready for 
> taking over for the peer.
>
> I have posted this overview to:
> http://www.iptel.org/drupal/failover_redundancy_and_scalability_overview
>
> See also:
> http://www.iptel.org/drupal/ser/wishlist
>
> g-)
> G.Jacobsen wrote:
>
> Samuel,
>
>  
>
> Do you happen to know what percentage of UAs out there are really 
> "Compliant" UAs ?
>
>  
>
> My impression so far regarding SRV DNS records is that they are 
> theoretically a nice feature but unfortunately almost useless since 
> one needs to cater for those non-compliant UAs anyway. I would love to 
> be convinced of the contrary.
>
>  
>
> Can anyone supply real usage figures regarding compliant/non-compliant 
> UAS ?
>
>  
>
> TIA
>
>  
>
> Gerry
>
>  
>
>  
>
>  
>
>     -----Original Message-----
>     *From:* serusers-bounces at lists.iptel.org
>     <mailto:serusers-bounces at lists.iptel.org>
>     [mailto:serusers-bounces at lists.iptel.org]*On Behalf Of *samuel
>     *Sent:* Donnerstag, 6. Juli 2006 14:52
>     *To:* Ritesh Jalan
>     *Cc:* seruser List
>     *Subject:* [Bulk] Re: [Serusers] Global Failover Server
>
>
>     Look at RFC 3623.
>     Cofigure two SRV entries in
>     your DNS, one pointing to the UAS SERver and another to the UK server.
>     "Compliant" UAs will try to contact the other proxy upon failure
>     of their current one.
>
>     Samuel.
>
>     2006/7/5, Ritesh Jalan <ritesh.j at net4.in <mailto:ritesh.j at net4.in>>:
>
>     Hi All
>
>      
>
>     Pls. guide me how can we implement failover on SIP Server located
>     globally, Like one server in USA another in UK.
>
>      
>
>      
>
>      
>
>     Ritesh Jalan
>     Mobile: 91-9818616329
>     MSN: ritesh_jalan at hotmail.com <mailto:ritesh_jalan at hotmail.com>
>
>
>     _______________________________________________
>     Serusers mailing list
>     Serusers at lists.iptel.org <mailto:Serusers at lists.iptel.org>
>     http://lists.iptel.org/mailman/listinfo/serusers
>
>      
>
>  
>
>
> ------------------------------------------------------------------------
>
>
>  
> _______________________________________________
> Serusers mailing list
> Serusers at lists.iptel.org <mailto:Serusers at lists.iptel.org>
> http://lists.iptel.org/mailman/listinfo/serusers
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060708/97efb61c/attachment.htm>

More information about the sr-users mailing list