[Serdev] usrloc loading

[Jiri Kuthan]

At 10:17 23/01/2007, Greger V. Teigre wrote:
>My turnaround time is probably too fast for Jiri, here... Only about a week :-) So, Jiri, feel free to jump in whenever you have the time!

Well, thank you all for your patience and interest in my opinion -- I try at least
a bit from underway :-) 


>Martin Hoffmann wrote: 
>>>
>>>* 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.

I guess I jumped in quite late, but Martin, could you send me a list of such constraints?

Undisputably though the flexibility in SER is a terrible thing and the only thing
which would be even worse is not to have it :-) We have observed couple of ways to
deal with complexity.

Having a bunch of mainstream config files (like onsip.cfg or new ser.cfg and hopefuly 
more in the future) is certainly most useful. 

In many cases what turned out useful to us was to turn scripting into lcr-like database
processing -- that helped to lower number of degrees of freedom , was thus less error
prone and scaled better in many cases.

Yet other thing which turned out to be most useful is proper system packaging along
with installation and ocnfiguration processes. We have done that for our commercial
products, it was quite laborous but eventually very useful too. (we used debian)



>>>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.
>>>    
>>
>>
>>The way I see it, SER is a SIP proxy for professionals. This may sound
>>arrogant, but you _really_ have to know what you are doing. You have to
>>know SIP otherwise you will break things. Your Getting Started is a very
>>valuable document on covering these things and help people climbing the
>>steep parts of the learning curves. But even with those documents, the
>>fact remains that SER is not the right tool for people who just want to
>>have a SIP proxy for their private or SMB use. For now, there is
>>Asterisk; repro is a good proper proxy that "just works".
>>  
>Yes, you're right. It sounds sort of arrogant. ;-)
>
>I think the discussion we should have (and it's long overdue) is "who should SER be for?"

Mostly service providers in my experience. I like to use it too very much indeed.
I agree that posting some "am I a potential SER user" on the website may be helpful
to folks for whom SER is not the ideal tool.


>>If you reach the point where you need load balancing, chances are
>>that your responsible sysadmin has very strong opinions on how to do these
>>things. Sysadmins tend to be like this, they rather implement their own
>>solution based on experience.

Frequently I observed too, they come to us too when later things fly apart :-)

>Well, using your own argument with regards to usrloc-cl: they should still have the tools and flexibility available in SER, so they don't have to rewrite SER to accomplish what they want.
>And unless we describe the various scenarios we want SER to support, we don't know whether they are really needed or really work. So again, we are on the same page here.

I think the most effective step to carry out it to have folks documented their
scenarios. There are indeed very many of such, some better for some purposes than
the others; certainly some would benefit of taking the scenarios off-the-shelve.

Really folks -- stand up and ensure your place in ser's hall of fame :-)
Just publish scenarios you have tried, the community will amplify the
result back for you.

We can debate the whole solution space which is almost infinitely large, but
if folks were willing to publish their best-current-practices, it could save the
mailing list participants a lot of time. (Badly many of those I'm familiar with
done for our customers fall under NDAs and I'm afraid the same can be said of
others...)

Perhaps a couple of notes may be useful for those who like to try to build a new
clustering scheme (and these are suggestions of my personal opinion and taste
which may or more likely may not be anyone else's).
- never trust database. If you can, get finished on the application/SER side and
  dont let the traffic go to database. If there is some annoyance, better stop
  at the gate than in backyard. Specifically, I like to keep usrloc isolated.
- "horizontal partitioning" is good. Then you have all the data you need at the
  place where you are -- it is fast and fail-safe.
- multi-tier  clustering with three levels (IP-LB-ing, SIP lb-ing, and the 
  eventual 'work horses') seems a good (simple and reliable) division-of-work to me.

-jiri

--
Jiri Kuthan            http://iptel.org/~jiri/