[Asterisk-Users] load balancing 20 asterisk servers

[Rich Adamson]

> > I'd have to guess that registrations would be the tricky part of an
> > implementation simply because there are so many variations of that.
> 
>     Actually, this is the easiest part. It doesn't matter how often a UA
> registers nor does it matter to which of the 20 servers handles the
> registration since all servers share the same database tables.

The actual registration interaction (those few packets) I wouldn't expect
to be an issue either. My comment was more oriented towards the
more real time interactions of call handling shortly after the registration
process, and what _might_ be impacted in terms of those calls. By that
I mean, a call (in either direction) starts out using sip to negotiate
an rtp session. If a sticky bit is applied, then all traffic from a
specific IP address is essentially assigned to a single server. If the
sticky bit is not used, then the load balancer _may_ send the initial
rtp data flow to a different server, thus breaking the sip negotiation
process (the call won't get set up).

> > Meetme (as well as other * functions) would certainly need to be
> > well thought out before considering a balancer. (Eg, where does the
> > customer's voicemail actually reside?
> 
>     Voicemail is not a problem. Again, all voicemails are stored in database
> including the audio portions.
> 
> 
> The problem with MeetMe conferences still bugs me.
> 
> I was un-aware that UDP had "sessions".

I was using the term more generically. The application assumes udp
sessions exist; layer-three doesn't contain session data. In other
words, from a load balancer perspective, there is noting in an
individual packet for it to recognize a session. Therefore, the load
balancer has to keep track of these so called sessions at layer-3
only (eg, ip address). The balancer (again) in watching/balancing
incoming connections and doesn't really know about outbound data.

So, if server1 was _completing_ 90% of all outgoing calls, how would
the balancer know that it should not allocate another _incoming_ rtp
session to that server? (Maybe a poor example, but think that process
through and I'm not sure a load balancer can truly deal with the
problem.)

If the sticky bit kind of thing is applied, then a business customer
with an * box will send all calls to the same itsp server.

Analyzing the call setups from both an incoming and outgoing perspective
becomes very important. Separating the two is certainly doable, but
more thought has to be given to the different sip setup states to
ensure the process flows correctly and still load balances.