You could use a load-balancer like LVS to balance the requests to sendsms. You could even script it so it sends more traffic to the box with the smaller queue and/or less load.
The advantages are: * Failsafe/High availability. You can stand the loss of N-1 boxes. * Redundant. Traffic is evenly split across the N boxes. * Scalabilty (at a price, see the drawbacks). The drawbacks are: * You need to establish N connections to each carriers (N being the number of bearerboxes). * If a box goes down, the messages queued on that box will remain unsent until the box comes up again. Regards, Alex On Thu, Apr 29, 2010 at 10:11 AM, Konstantin Vayner <[email protected]>wrote: > Yeah, but this doesnt really solve the problem for MT messages - as in this > case an external application needs to load balance the throughput instead of > Kannel. > And if i'm limited in speed (and i am) , neither bearerbox will know how > many messages has another one sent so far... > > > On Thu, Apr 29, 2010 at 10:30 AM, Illimar Reinbusch > <[email protected]>wrote: > >> Hi >> >> Does Kannel architecture allow scaling bearerbox in any way? >>> >>> Right now i have kannel running on one machine and a second machine >>> standing by to take over (by heartbeat) in case of the first machine >>> failure. >>> But thats only redundancy. >>> >>> I see that i can create a lot of smsboxes to connect to one bearerbox, >>> but this still leaves me with a single potential bottleneck since all the >>> connections to the operators are made from one process. >>> >>> I have resolved this problem by opening 2/4/6 connections to operator, >> so i have 1 SMSC/1 Bearerbox/ 1 smsbox on one server and 1 SMSC/1 >> Bearerbox/ 1 smsbox on second server. If one server fails, then all messages >> will come thru second connection, during normal operation both connections >> work and i have load-balancing scenario. >> >> Illimar >> > >
