This is somthing that I have been giving somth thought to as well.. not that I have any need to handle 10 000+ calls but the idea of a "clustered" PBX is awesome..Scenario one: One asterisk server, 200+ calls/channels through it. Judging by related posts this scenario will work fine.
Scenario two: 10000+ calls/channels with one registration URL. I heard that Voyage has 50,000+ clients now. I am talking about that sort of scenario. Mass deployment. What then?
1. Do a lot of "switch" command to move the calls between servers? 2. Implement a load balancing/high availability solution 3. Your suggestions please
Here is my understanding of load balancing: 1. One or more director server are needed which will accept all incoming requests and direct those requests to least busy application server. 2. Two or more application servers running * with shared network file system for all needed directories /var/log/asterisk , /etc/asterisk etc. 3. RAID File Server (RAID 5 preferably)
The "weakest link" would be the director server but if run in a pair that should provide very good reassurance that at least one of them will be running while the faulty one is being replaced. The file server, of course should have its own redundancy put in place.
Anyone out there: Is there anything in * operation or structure preventing this sort of
setup?
Any other suggestions?
Ta
Senad
Here are some of the issues..
If you are load balancing with a "director" that spreads the load across multiple servers, the first problem would be sharing the SIP registration information between the two or more servers..
This is so that if UA1 is registered on Server1 and UA2 is registered on Server2.. Then when a call is made from UA1 to UA2, Server1 would know the registration details of UA2 in order to connect the call.. Sure it could be made to try the other servers from within the dialplan but this will be very messy as the number of servers goes up..
Then there is the NAT issue.. If UA1 or UA2 are behind NAT then the NAT table will have an entry for the Server where the UA registered and not the other servers.. So when the call was initiated from one of the other servers the NAT would simply drop the packets..
What is probably needed is one of two things..
a. An SSI(Single System Image) cluster that load balances the processing to multiple nodes but all data in and out are seen to be from a single IP address..
b. A front end "router/proxy" that handles the IP traffic and SIP information to and from a number of Asterisk nodes behind it that are doing the processing..
Or alternatively a method where by Asterisk is able to be clustered within itself sharing the relevant data and load between the nodes of the cluster and managing the data flow in and out of the server and removing and adding nodes dynamically to the cluster when a node fails or is taken offline and brought back online.. Basically an SSI Asterisk application.. Of course if it did manage this who would need telco's anymore.. :)
I guess you could always pop down to the store and order up a 64 way SMP server... that should get at least a couple of thousand concurrent calls going.. :)
Later..
_______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
