SnomOne Dimensioning

[global_s]

Hello,

I was wondering if somebody have a table explaining how to correctly dimensionate the system.

 

Something like...1000 ext + 30 call per seconds --> 4GB ram, dual Xeon etc etc

[Vodia PBX]

Sorry, this is not like in the old DSP times when you had 30 channels, guaranteed. The question how much calls you can make is sometimes like "how many emails can I send from my Exchange server?"...

 

Registrations can scale up into the thousands (TCP/TLS connections require 64 bit OS at such numbers), and the key element for memory is how many CDR you want to keep in memory. The key factor is the calls. As a rule of thumb, you can run around 100 simulteneous calls on a modern, but not top-notch core. Dual core makes sense, so that the OS can run the PBX on one core and everything else on the other (quad-core is a waste on the PBX). If you go highest CPU, you can get up to 200 calls running. The intensitiy of the call CPU load depends if you must perform transcoding (translate between different codecs), record calls, SRTP encryption and decryption, and of course conferencing and call barge in, whisper mode and listening in. The CPU performs a real-time CPU monitoring and begings to block additional calls when the load is getting to high, so at the end of the day is what probability you want to take that calls are being rejected because of resource exhaustion.

 

My recommendation is to start with a ~1000 USD standard server and monitor the performance load (sent every day). If the load gets regulary into the 50 % area, then it is time for a hardware upgrade. Otherwise and most often, the 1000 USD server will be a good investment and can run the service for many years. Instead of spending 2000 USD for a single server, I would rather buy two standard servers and run them in a virtualized environment with failover (e.g. Hyper-V), so that a hardware failure will not result in a long service shutdown: In such a case, your service might continue in a blink of an eye.

 

 

 

[Carlos Montemayor]

Hi,

 

I would like to follow on your last recommendation. Currently, I am building my own little systems based on Debian, and they have been performing just fine. However, as larger customers (with mission critical uses) start to show up, the need for physical failover becomes a reality. For what I have seen in my area, building two simple (but good) systems would cost about one third of what could cost a server with redundant power supplies, redundant hard drives and a CPU that will surely have more processing power that we will ever have use for, and for what I gather, will render just the same kind of reliability. So, how could we set up such a couple of boxes?

 

Thanks in advance

 

Sorry, this is not like in the old DSP times when you had 30 channels, guaranteed. The question how much calls you can make is sometimes like "how many emails can I send from my Exchange server?"...

 

Registrations can scale up into the thousands (TCP/TLS connections require 64 bit OS at such numbers), and the key element for memory is how many CDR you want to keep in memory. The key factor is the calls. As a rule of thumb, you can run around 100 simulteneous calls on a modern, but not top-notch core. Dual core makes sense, so that the OS can run the PBX on one core and everything else on the other (quad-core is a waste on the PBX). If you go highest CPU, you can get up to 200 calls running. The intensitiy of the call CPU load depends if you must perform transcoding (translate between different codecs), record calls, SRTP encryption and decryption, and of course conferencing and call barge in, whisper mode and listening in. The CPU performs a real-time CPU monitoring and begings to block additional calls when the load is getting to high, so at the end of the day is what probability you want to take that calls are being rejected because of resource exhaustion.

 

My recommendation is to start with a ~1000 USD standard server and monitor the performance load (sent every day). If the load gets regulary into the 50 % area, then it is time for a hardware upgrade. Otherwise and most often, the 1000 USD server will be a good investment and can run the service for many years. Instead of spending 2000 USD for a single server, I would rather buy two standard servers and run them in a virtualized environment with failover (e.g. Hyper-V), so that a hardware failure will not result in a long service shutdown: In such a case, your service might continue in a blink of an eye.

 

 

 

[Vodia PBX]

Regarding redundancy there are several ways to go. The best performing way is to run the PBX host in a virtual machine and run it exclusively on a hypervisor. Then use a tool that have the VM automatically failover to another machine when the primary server fails. That can work within seconds and calls can stay up. However the disadvantage is that this requires an expensive license on the virtualization side.

 

If the failover does not require such a fast failover, you can strip this setup down and have a server on standby. For example, you can take a snapshot of the VM from time to time and restore the snapshot on the secondary server in case you have to. This will have the advantage that you keep the configuration exactly the same, including IP address and even MAC.

 

If you don't want virtual machines, you can do the same with physical machines. Then rsync is your friend. When the primary server goes down, you have to start the PBX process on the secondary server. However our experience is that changing the IP address of the secondary server creates a lot of problems and that it is easier to use DNS to point to the active server. Consequently, your DNS server must be very stable, too. And you must provision the phones with DNS, not the IP address of the PBX. Some DNS hosting companies offer the service to poll the primary server and then automatically change the DNS settings to point to the secondary server.

 

But even if you just make regular backups and have a secondary server available, this relatively cheap setup can be effective. If people who are watching the system know what steps need to be done to restore the service on the secondary servers, the failover can be done within lets say an hour. This is much better than waiting several days for a new server and in many environments already okay.

[Carlos Montemayor]

Well, I believe that being the pbx a solution for business and that for a business, regardless of its size, communication is always a mission critical service, the handling of fast recovery from a disaster is something that has to be addressed. As integrators or value added resellers, we will be encountering some end users that will have knowledgeable IT people who can do some of the errands and some that will not. Budgets will differ as well, so, I think I will have to learn about the several ways to handle this. If downtime can be only minutes and such a thing will happen every other year or so, I will try to privilege and promote the solution that is easier and more economic to implant and that seems to be the one outlined on your second paragraph. I do not dislike virtual machines, I am just not acquainted with them, but that can be fixed. Browsing the web, I just found a product called: "VMware vSphere Hypervisor", it claims to be an entry level and free solution. It may be a good place to start to learn about this things unless there is another tool you would suggest.

 

Cheers!

 

 

Regarding redundancy there are several ways to go. The best performing way is to run the PBX host in a virtual machine and run it exclusively on a hypervisor. Then use a tool that have the VM automatically failover to another machine when the primary server fails. That can work within seconds and calls can stay up. However the disadvantage is that this requires an expensive license on the virtualization side.

 

If the failover does not require such a fast failover, you can strip this setup down and have a server on standby. For example, you can take a snapshot of the VM from time to time and restore the snapshot on the secondary server in case you have to. This will have the advantage that you keep the configuration exactly the same, including IP address and even MAC.

 

If you don't want virtual machines, you can do the same with physical machines. Then rsync is your friend. When the primary server goes down, you have to start the PBX process on the secondary server. However our experience is that changing the IP address of the secondary server creates a lot of problems and that it is easier to use DNS to point to the active server. Consequently, your DNS server must be very stable, too. And you must provision the phones with DNS, not the IP address of the PBX. Some DNS hosting companies offer the service to poll the primary server and then automatically change the DNS settings to point to the secondary server.

 

But even if you just make regular backups and have a secondary server available, this relatively cheap setup can be effective. If people who are watching the system know what steps need to be done to restore the service on the secondary servers, the failover can be done within lets say an hour. This is much better than waiting several days for a new server and in many environments already okay.

[Vodia PBX]

Browsing the web, I just found a product called: "VMware vSphere Hypervisor", it claims to be an entry level and free solution. It may be a good place to start to learn about this things unless there is another tool you would suggest.

 

Absolutely. If you are a Windows person, you might also check out Hyper-V.

[Pablo]

... I just found a product called: "VMware vSphere Hypervisor", it claims to be an entry level and free solution. It may be a good place to start to learn about this things unless there is another tool you would suggest.

 

Cheers!

 

 

I don't know if this is necessarily the best, for purposes of getting your feet wet; but here's a decent guide on deploying Microsoft's hypervisor: Building a Private Cloud VM Compute Foundation with the FREE Hyper-V Server 2012

[Carlos Montemayor]

Following up on your third paragraph (physical machines instead of virtualization). If the "production" system goes down and it has a fixed IP address of the local network (not DHCP) wouldn't it be easier to start the "failover" system with the backup configuration file that one should have generated recently from the production system? In that way, I suppose, everything, including its fixed IP address would be the same, exception made of the MAC address which would only cause the need to reset the license key which in turn could be done promptly too?

 

Regards,

 

 

 

Regarding redundancy there are several ways to go. The best performing way is to run the PBX host in a virtual machine and run it exclusively on a hypervisor. Then use a tool that have the VM automatically failover to another machine when the primary server fails. That can work within seconds and calls can stay up. However the disadvantage is that this requires an expensive license on the virtualization side.

 

If the failover does not require such a fast failover, you can strip this setup down and have a server on standby. For example, you can take a snapshot of the VM from time to time and restore the snapshot on the secondary server in case you have to. This will have the advantage that you keep the configuration exactly the same, including IP address and even MAC.

 

If you don't want virtual machines, you can do the same with physical machines. Then rsync is your friend. When the primary server goes down, you have to start the PBX process on the secondary server. However our experience is that changing the IP address of the secondary server creates a lot of problems and that it is easier to use DNS to point to the active server. Consequently, your DNS server must be very stable, too. And you must provision the phones with DNS, not the IP address of the PBX. Some DNS hosting companies offer the service to poll the primary server and then automatically change the DNS settings to point to the secondary server.

 

But even if you just make regular backups and have a secondary server available, this relatively cheap setup can be effective. If people who are watching the system know what steps need to be done to restore the service on the secondary servers, the failover can be done within lets say an hour. This is much better than waiting several days for a new server and in many environments already okay.

[Carlos Montemayor]

Thank you Pablo. I will certainly have a look into it.

 

I don't know if this is necessarily the best, for purposes of getting your feet wet; but here's a decent guide on deploying Microsoft's hypervisor: Building a Private Cloud VM Compute Foundation with the FREE Hyper-V Server 2012