[Serusers] Carrier-grade framework for SER

[Erik Versaevel]

You might allso want to check the LVS mailinglist, there is some 
discussion going on for a SIP module for the LVS with call-id 
persistence, that would solve distributing request among the real servers.



Greger V. Teigre wrote:

> Dear Andreas,
>
> As I indicated in an earlier email, I would be interested in taking 
> part in a joint effort to further develop ser's high-availability and 
> scalability (HAS).  I would probably have to do some development 
> anyway, and I would prefer to see such support in the public domain.  
> In Nov/Dec I called for responses on a SOAP-based provisioning 
> interface, but heard nothing, so here is an overlap of interests.
>    Please see inline comments.
>
> Andreas Granig wrote:
>
>> Hi guys,
>>
>> I'd like to propose another possibility for a highly-available and
>> scalable system design based on SER:
>>
>> The problems I've encountered for scalable systems are:
>> - Distribution of the user location and alias location among the nodes
>>   (user location is based on registrations, alias location comes from
>>   web interfaces and is used for call forwarding).
>> - Reloading up to date location tables after breakdown and recovery
>>   of a node
>
>
> If we are to define the elements required as part of a HAS-effort, I 
> think I would also include load balancing across servers in a single 
> data center, not only distribution of usrloc/alias replication across 
> centers.  You mentioned yourself the problem of clients not supporting 
> DNS SRV.  I think some kind of reference design using Linux HA or 
> virtual server would be useful for the community. I have seen several 
> people asking questions, but I haven't seen documentation of a 
> successful implementation. The reference design must of course handle 
> NAT traversal and the possibility of RTP proxying.
>    Anybody with experiences or thoughts?
>
>> So I'm just thinking loud about the following provisioning system:
>>
>> - Write a client which fulfills the this demands:
>>
>>   - Receive one or more locations from SER via a SER module or from a
>>     web application and distribute them to other
>>     known clients. Take care of retransmissions if a client isn't
>>     reachable or reports a temporary failure.
>>
>>   - Receive one or more locations from other clients and write
>>     them into the SER FIFO. If writing into the FIFO fails, try to
>>     write directly into the database (location-table, alias-table
>>     etc.). Report a temporary failure if this also fails.
>
>
> yes, I see you here define a more general network wrapper to the 
> FIFO.  Why not extend the scope right now to support any FIFO 
> implemented command, also future?
>    If FIFO writing is not possible, I believe an alert should be made 
> and the request left in a transaction queue.  There is probably a 
> reason for the FIFO error and also writing directly to the database 
> will mess up the synch between DB and server.
>
>> Maybe a centralized server should be used which receives the locations
>> from the clients and distributes them to other clients, so that the
>> nodes just know about the server and nothing about other nodes. This
>> would make integration of new nodes easy.
>> On the other hand, it's another single point of failure, so a
>> decentralized solution should be considered. But that would mean that
>> you've to inform every node about the existence of a new node.
>
>
> I agree that that each node should be independent. I once implemented 
> a token ring-like system where each node would report its existance. 
> Something similar would be appropriate. We could even use SIP REGISTER 
> from each client using a specifically crafted username and use NOTIFYs 
> to update everybody about changes :-) Each client could use its local 
> ser server to lookup contacts.  Well, this could create a dependency 
> loop, but it was sort of a cool idea ...
>    Bringing up new clients will of course need some special thoughts 
> in terms of their status and at what point in replication they should 
> enter. Probably each transaction should use a unique transaction id...
>
>> The protocol used between the nodes should be simple and fast. So I
>> think SOAP drops out here. Maybe XMLRPC or ICE
>> (http://www.zeroc.com/ice.html) could be used.
>
>
> Why do you think SOAP should be dropped?
>    If this is to be a general module for both provisioning and 
> replication across servers, we must handle many different usage 
> scenarios, ex. provisioning over the Internet, and we should use a 
> framework where we can get as much as possible for "free", ex. 
> SSL/TLS, authentication etc.
>    In my experience, SOAP can be both simple and fast and there are 
> far more auto-generation tools/frameworks etc for SOAP.  A simple 
> RPC-type SOAP message is not really far from XML-RPC, basically an 
> envelope extra.  The ability to auto-generate a client based on a WSDL 
> file is pretty nice, as well.  With regards to ICE, we should probably 
> avoid using toolkits where commercial licenses must be bought for 
> commercial usage.
>    I have used gSOAP (http://www.cs.fsu.edu/~engelen/soap.html), which 
> is a powerful, but very simple to use C/C++.
>
>> I'd be willing to release these parts as GPL for creating an open
>> framework for carrier-grade SER integration, so any feedback,
>> improvements or flames are highly welcome.
>
>
> Ditto.
>
> I have here contributed to increasing the scope... But I think the 
> correct approach would be to make something simple in the beginning, 
> maybe only the provisioning and the queue and a text-based config file 
> for clients to replicate to.  We could then add the ser module for 
> forwarding usrloc to the local client.
>
> Andreas: What's your time scope?
>
> Core developers of ser:  I think we need your opinion(s) before we 
> start anything?!
>
> Regards,
> Greger
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>