[Serdev] Re: [Serusers] Re: usrloc loading

[Greger V. Teigre]

Hi guys,
Thanks for a good discussion!  It's a bit like following a conversation 
between Earth and a space mission. For every post I had to re-read the 
previous to refresh my memory :-)

You both bring a tremendous amount of experience and knowledge of large 
installation, and appreciate the insights you bring.

I just want to jump and emphasize a few points I find important:
 * Jiri pointed out that blind reliance on generic database systems like 
cluster etc can sometimes lead to complex problems in operations and 
that application layer handling of specific situations is sometimes 
required. I find this true for most applications, also non-SIP ones. 
Often this is caused by the human brain's inability to cross over 
abstraction layers and foresee application-layer impacts on underlying 
layers (or vice versa).  Experience is the only way to catch these 
problems and having experience fed back to the design of SER is 
important. HOWEVER, without these experiences or design choices 
explicitly pointed out, other people will experience the design as a 
contraint and may even make their own design decisions that can make 
things worse (or find a new smart way...)

So, the pressure will be on SER design-changes, additions etc to support 
"other ways of doing it". Without discussions like the ones you guys 
have here now, we are not able to identity why people want changes and 
why the developers of SER resist those changes.  (which, incidentally, 
was the case with the usrloc-cl/path implementation that Andreas Granig 
did).

I thus encourage more discussions like these, and, to bring up one of my 
favorite topics, we need to describe scenarios, call them best practices 
or just templates etc, where we describe the architectural designs that 
SER is designed to support.  Only that way we have something to step on, 
challenge, and improve.

* Martin points out the importance of the flexibility of ser.cfg in 
supporting various network designs and "ways of doing it". This is true, 
and I fully agree. However, the "valid" or "appropriate" designs to use 
DO have constraints, both in SER design, available modules, as well as 
in ser.cfg language itself.  Thus, the flexibility of ser.cfg that 
enables professionals to tune SER, is a curse to others, less experienced. 
Which of course leads me to the original intention of SER - Getting 
Started configurations: create best practices for the basic tasks.

For some time now, I have tried to rally support around establishing 2-3 
best practice scenario for MORE THAN ONE SER SERVER!  With 200 users, 
you still want some redundancy, so people  spend lots of time figuring 
out how to do things. IMHO, failover and redundancy best practices 
scenarios is one of the important things that SER needs that will 
benefit the community the most: If people don't have to spend time on 
solving that issue, they can work on more interesting stuff that might 
be fed back to the community.

* Martin also says that "forcing users to use the usrloc cache is 
wrong." Obviously, I agree with that.  Lots of things in SER makes sense 
only when seen in combination with the commercial iptelorg.com add-ons. 
Not everybody buys from iptelorg.com and it's no surprise that people 
end up with different designs and solutions. I believe it's time we have 
a discussion and agree to which designs SER SHOULD support, describe 
them, and identify gaps in terms of code.  However, we cannot expect the 
existing developers to spend time on scenarios they don't use, so that 
means that people like you, Martin, step up and contribute in those 
areas where you have a stake, you need something working, and where you 
are in a position to feed back experiences.

That being said, Jiri, Jan, Andrei and the others than have to be open 
to the validity and merits of other ways of doing it, and, like in this 
thread, participate in discussions leading to a shared understanding of 
multiple best practices.

* Finally, to one of the conclusions you shared, Jiri and Martin: "what 
usrloc needs is a data store that allows data to be shared between 
different machines." 
This can be done in 0.9 in several ways, ex. using multiple usrloc 
tables and writing each ser.cfg with a peer-awareness.  usrloc-cl uses 
mysql cluster and implementation of the Path header to accomplish the 
same thing. 

I have been playing around with ideas for how this can be accomplished 
in a very simple way and in order to step up to my own challenge, I will 
here describe a new, simple scenario for "entry-level" failover and 
redundancy.

I have come up with the following basic scenario (without optimizations 
and only described as a "minimum-effort" implementation):

Basic idea: Turn up side down on the idea of all servers needing access 
to all usrlocs and rather implement a discovery system for which server 
has the registration.

 * A new SER module takes as module parameters a list of IP addresses of 
peer registrars with priority for each server. Another parameter 
controls whether non-local messages should be forwarded to a peer or if 
a 30x redirect should be returned
 * Each SER registrar listens on TCP using the XMLRPC interface
 * If a local ruri is not found in usrloc, call the t_relay_to_peer() 
function
 * The function will contact each peer according to priority using the 
standard usrloc lookup command in usrloc module (over XMLRPC). If the 
contact was found with a peer, either a 30x redirect is sent or the dst 
ip is changed to the peer and the message is t_relayed

Obviously, lots of improvements can be made (replacing XMLRPC with UDP 
binary protocol and storing a found location in a cache are the most 
obvious), but the basic idea is simple.  Having accomplished 
"location-sharing", one can use DNS SRV, load balancing, vsrp, etc etc 
in combinations.

Go ahead, guys, please shoot it full of holes! :-D
g-)


Martin Hoffmann wrote:
> Jiri Kuthan wrote:
>   
>> I think the feature you are suggesting (cancel-if-it-takes-too-long for whatever
>> reason) could be reasonable self-recovery tool. I think that in addition to that
>> going through the code case-by-case is unavoidable so that we dont have to
>> 503 unnecessarily.
>>     
>
> True. However, the strength of SER (and IMHO the main reason for its success)
> is that you can easily adapt it to all sorts of weird stuff through the
> routing script (We could start a section on the web page where people
> can post the most evil things they did with subst()).
>
> That's why I would like to give the option to do these things to the
> script writer and not set too much in stone. (Which sort of leads to
> another possible point for improvement: the module interface. If you
> like, I can elaborate a bit in another mail.)
>
>   
>>>> well -- aliases via usrloc was kind of temporary solution which stayed
>>>> longer than planned :-)
>>>>         
>>> I actually like it. 
>>>       
>> That's embarassing to me :-) I consider it a great feature not to have it any
>> more. One of the reasons is that aliases are actually provisoned data whereas
>> usrloc is kind of temporary data (or session data, web folks could say). In
>> highly optimized systems you may use completely different data processing
>> techniques. Then it is unfortunate if the provisoned alias data is treated 
>> using data tools for temporary data.
>>     
>
> >From a back-office point of view, alias is just another table (except,
> of course, for the caching). I do not know enough about database design
> to decide which approach is better, stuffing everything into one attribute-
> value table or having dedicated tables specifically designed for the
> purpose. I suspect your friendly DBA would rather have the latter.
>
>   
>>> More so, I recommend using usrloc for call
>>> forwarding as well. The advantage over AVPs is that you can have more
>>> than one address to forward to (aka parallel hunting).
>>>       
>> I think you can have it with AVPs as well.
>>     
>
> Damn. It is really time to start working with SER 0.10. If only the day
> had 36 hours.
>
> [...]
>
> On the next sections I think we agree to partly disagree. It comes down to:
>
>   
>> Again -- I think this is interesting what-if academic conversation but if you think there
>> is some design error which precludes some working scenario, highlite it for me.
>>     
>
> I think I did. IMHO forcing users to use the usrloc cache is wrong.
>
> Where this actually leads to is this: Will SER eventually have a
> none-caching database mode for usrloc? If yes, I am perfectly happy. If
> not, I have to consider takeing over maintainership of usrloc-cl since
> Andreas apparently jumped ship.
>
> Best regards,
> Martin
> _______________________________________________
> Serdev mailing list
> Serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.iptel.org/pipermail/serdev/attachments/20070114/d2c406a8/attachment.htm