I'm hoping to clarify a couple questions on clustering SER in high-volume environments as well. Assuming authentication is RADIUS, wouldn't clustering something like what Darren is talking about be as simple as installing multiple SER boxes and just doing some DNS round-robin? Would that introduce any registration issues?
-Corey
Darren Nay wrote:
Senad, Thanks for your response.
There are several reasons.
The 2 biggest are..
1 - We offer our customers the option to forward calls when an IAD is not registered .. In order to do that the registration interval needs to be relatively low.
Fine... But still I am curious why u need to do in order to forward the calls.
2 - We've had some issues with setting registration intervals higher than 10 minutes. It seems to work about 99.5% of the time, but occaisionally an endpoint won't reregister before the reg interval on SER times out. I believe this is a bug in our endpoint and have been working with them on that. Setting the reg interval below 10 minutes has eliminated that problem for the time being .. However, even if this problem was fixed by the IAD manufacturer we still have the first reason (above) that would keep us from being able to increase the interval.
Well. apart from fixing the issue with your IAD, you could use DNS SRV record. Each time, IAD wants to re-register it will use DNS SRV record, hence "hitting" different server.
This way, u will need more than one SER server each getting its data from central network database. If you need cluster file system, then you could use GFS or similar.
Regards,
Senad
PSS!!! Which IAD are you using ?
********************************************* This message has been scanned for viruses and dangerous content, and is believed to be clean.
that sounds fine, but what about all the other messages lets say a INVITE went to machine1, and the ACK went to machine2, then how would ser know what its doing. There is a discussion in the archives, subject LVS or something like that. Some are using a dispatcher module, from what I have read, but I dont think it is a complete solution...in fact I am unsure as to whether this is one....
Iqbal
Corey S. McFadden wrote:
I'm hoping to clarify a couple questions on clustering SER in high-volume environments as well. Assuming authentication is RADIUS, wouldn't clustering something like what Darren is talking about be as simple as installing multiple SER boxes and just doing some DNS round-robin? Would that introduce any registration issues?
-Corey
Darren Nay wrote:
Senad, Thanks for your response.
There are several reasons.
The 2 biggest are..
1 - We offer our customers the option to forward calls when an IAD is not registered .. In order to do that the registration interval needs to be relatively low.
Fine... But still I am curious why u need to do in order to forward the calls.
2 - We've had some issues with setting registration intervals higher than 10 minutes. It seems to work about 99.5% of the time, but occaisionally an endpoint won't reregister before the reg interval on SER times out. I believe this is a bug in our endpoint and have been working with them on that. Setting the reg interval below 10 minutes has eliminated that problem for the time being .. However, even if this problem was fixed by the IAD manufacturer we still have the first reason (above) that would keep us from being able to increase the interval.
Well. apart from fixing the issue with your IAD, you could use DNS SRV record. Each time, IAD wants to re-register it will use DNS SRV record, hence "hitting" different server.
This way, u will need more than one SER server each getting its data from central network database. If you need cluster file system, then you could use GFS or similar.
Regards,
Senad
PSS!!! Which IAD are you using ?
This message has been scanned for viruses and dangerous content, and is believed to be clean.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
.
serusers-bounces@lists.iptel.org wrote:
that sounds fine, but what about all the other messages lets say a INVITE went to machine1, and the ACK went to machine2, then how would ser know what its doing. There is a discussion in the archives, subject LVS or something like that. Some are using a dispatcher module, from what I have read, but I dont think it is a complete solution...in fact I am unsure as to whether this is one....
Why would INVITE, ACK etc. go to the other SER machines if UAD are registered to its machine?
Corey S. McFadden wrote:
I'm hoping to clarify a couple questions on clustering SER in high-volume environments as well. Assuming authentication is RADIUS, wouldn't clustering something like what Darren is talking about be as simple as installing multiple SER boxes and just doing some DNS round-robin?
kind of...yes.. but controlled at the application level. In another words.. UAd need to support DNS SRV records.. plus heartbeat will provide IP takeover services.
Would that introduce any registration issues?
Sorry.. I do not have experince with RADIUS...
My understanding of our conclusions: If you don't have to support NATed devices, there are several ways to do both load balancing and redundancy using SER. If you needto support NATed devices, you can do load balancing (ex. using DNS SRV or dispatcher and in some way make sure that INVITEs to a particular user goes through the server the user is registred with, see the thread Iqbal is referring to), but you cannot do redundancy (as you get into all kinds of scenarios if the server the user is registered with goes down). OR you can do both load balancing and redundancy, by making each registration server redundant using Linux HA. However, such a solution is expensive and hard to maintain. And you have idle servers. If you do the math, you end up leasing or buying a commercial load balancer like F5's BIG-IP or Cisco...
g-)
Iqbal wrote:
that sounds fine, but what about all the other messages lets say a INVITE went to machine1, and the ACK went to machine2, then how would ser know what its doing. There is a discussion in the archives, subject LVS or something like that. Some are using a dispatcher module, from what I have read, but I dont think it is a complete solution...in fact I am unsure as to whether this is one....
Iqbal
Corey S. McFadden wrote:
I'm hoping to clarify a couple questions on clustering SER in high-volume environments as well. Assuming authentication is RADIUS, wouldn't clustering something like what Darren is talking about be as simple as installing multiple SER boxes and just doing some DNS round-robin? Would that introduce any registration issues?
-Corey
Darren Nay wrote:
Senad, Thanks for your response.
There are several reasons.
The 2 biggest are..
1 - We offer our customers the option to forward calls when an IAD is not registered .. In order to do that the registration interval needs to be relatively low.
Fine... But still I am curious why u need to do in order to forward the calls.
2 - We've had some issues with setting registration intervals higher than 10 minutes. It seems to work about 99.5% of the time, but occaisionally an endpoint won't reregister before the reg interval on SER times out. I believe this is a bug in our endpoint and have been working with them on that. Setting the reg interval below 10 minutes has eliminated that problem for the time being .. However, even if this problem was fixed by the IAD manufacturer we still have the first reason (above) that would keep us from being able to increase the interval.
Well. apart from fixing the issue with your IAD, you could use DNS SRV record. Each time, IAD wants to re-register it will use DNS SRV record, hence "hitting" different server.
This way, u will need more than one SER server each getting its data from central network database. If you need cluster file system, then you could use GFS or similar.
Regards,
Senad
PSS!!! Which IAD are you using ?
This message has been scanned for viruses and dangerous content, and is believed to be clean.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Corey S. McFadden -
Greger V. Teigre -
Iqbal -
Senad J