[Asterisk-Users] load balancing 20 asterisk servers
Rich Adamson
radamson at routers.com
Wed Feb 2 07:12:03 MST 2005
Inline...
> I've read several other emails and pages on the wiki but none give any
> deffinate answers. if you have 20 asterisk servers each with 4 pri's, all
> running RealTime Extensions and RealTime SIPBuddies from the same MySQL
> server, what prevents you from putting all 20 servers behind a single load
> balancer? That way all of your UA's can use the same IP to register to; vs
> maintaining which customer is assigned to which machine.
Load balancers vary rather dramatically in exactly how they fucntion.
Some work at layer-2, others at layer-3, and some at layers above.
Some include a small app that executes on each server to monitor
processor utilitization, etc, communicating key parameters to the
balancer. I've not tried any of these with *, but I'd have to guess
that selecting a specific model that properly handles udp sessions
(including variable length registrations) might require some resarch
that is a little more extensive then what the causual observer might
guess.
> perhaps its just that i am not that familiar with load balancers. i was
> under the impression that a load balancer could/would send each recieved
> packet to a different server.
That assumption is basically correct, however most balancers will
maintain some sort of session-oriented function that will try to keep
the flow directed to the server for which it first assigned the traffic,
keeping in mind that it balances 'inbound' data flows not outbound
traffic.
> this doesn't matter in the case of register requests since all asterisk
> boxes share same SIP registry database.
I'd have to guess that registrations would be the tricky part of an
implementation simply because there are so many variations of that.
(Eg, some devices/systems register every minute while others every
hour, and about everything in between. From a load balancer perspective,
does the first registration look any different from the second and
follow-on registrations, and would the balancer consider those as
the same or different end points? Might that cause a flurry of other
system activities that have not been considered?)
> but what about invite requests and the rtp stream? you would have a majorly
> broken conversation if each packet in the rtp stream went to a different
> asterisk box.
No, there are parameters available to cause all packets associated with
a session to stay with the initial system and not try to load balance
on a per-packet basis. Some balancers refer to the parameter as a
sticky bit. However, careful thought has to be given to how the balancer
functions when an rtp session is _first_ initiated from an internal
* system verses a remote * system as an example.
> or are load balancers SIP aware? or is there some sort of session control
> that the balancer is aware of and will send all packets in a "sip session"
> to the same asterisk box?
I have not heard of any balancer being sip-aware, and would suspect that
some of the nat-like issues probably apply to load balancers. It certainly
would _not_ be cool for the balancer to treat the rtp session setup as
a new session when its tied directly to the sip negotitation process.
> and then what about meet me conferences? if 10 UA's all dial a conference
> DID number and all 10 get balanced to 10 different servers then they are all
> sitting in seperate rooms right?
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? How much inter-system traffic
would generated because various resources are scattered across
multiple systems such as meetme sessions, etc?)
There are obviously a lot of folks on the list that shot from the
hip with little or no practical experience. Load balancing will require
a little more well thought out engineering then that. I'm not sure
the actual realtime * implementation is at a point where these issues
can be addressed today.
More information about the asterisk-users
mailing list