<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..
You are right, but what if each * server had a single source for all of its configuration files from a file server over NFS or similar. This scenario (in theory) will allow each * instance on separate boxes to deal with the same conf files hence all users will use one single * URL for registrations and other requests. Director servers will than spread those requests over multiple boxes. >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.. I think cluster can be setup with using only public IPs. >What is probably needed is one of two things.. >. 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.. Absolutely >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.. Director servers should be able to handle this >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.. :) Could not agree more but those sort of operations already exist in many cluster solutions. So, why replicate? What is more important is that * can work with cluster as you described. Mark? Have you any comments on this? >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.. :) Hmm, that "baby" will rock but even that will reach its limit one day. _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
