If you are growing fast or you are planning an exponential boom, you need to plan the proper architecture. This means your architecture must support workload, be able to recover in case of a fault and it needs to be able to grow horizontally and vertically. The following architecture tries to address these concerns and others.
In this kind of scenarios, it is a bad idea to share responsibilities. A server who holds the VoIP processing and acts as file sharing server it is a bad idea. If something happens, more than one function may stop working. We will describe each important element.
The database cluster will hold all the information. Its architecture active-active allows querying any node. It is highly recommended they have enough RAM and hard disk space. The number of recommended nodes is 2n + 1 (odd number).
This SBC cluster will act as a layer-7 firewall. It will filter all the incoming calls from the carriers and it will pass only the one that is expected.
Not necessary a cluster, this function could be optional. If you opt to have this service outsourced in a server, all the servers will write here. This server needs to have enough space to host all the VoIP operation such as voicemails, faxes and call recordings.
If you decide not to outsource this function, all the servers will have a synchronization service that will transmit the files among them.
Yet another optional outsourced feature, it is a good idea to have a server or a mail service that sends the emails on behalf of the PBX. Because of the nature of the voicemail emails (having URL or attachment), it is very likely that they may be banned or sent to the SPAM box if they are sent by a node of the SIP Cluster.
Again, this can be optionally outsourced. Each time when telephone boots or a call ends there is HTTP traffic involved. HTTP traffic is heavy and it distracts the CPU from more important functions such as RTP processing. This server offloads the SIP cluster and as a consequence, the SIP cluster can hold more load.
Optionally but highly recommended. If you are planning to give your users access to the FusionPBX GUI, sooner than later this server will be under attack. Having this server, not only offloads the SIP cluster but it acts as a honeypot. If for a reason this server goes offline, the VoIP service will continue, your users will just lose the capability of self manage themselves for a while.
Since the recovery time of this clustering scheme is long comparing to others, this is ideal if you:
If you need any of these configurations in your own servers, please contact us. We will be more than happy to assist you.
However, OKay presents another affordable option. Just pay the rent of the servers and OKay will do the chosen configuration for free. All the servers must be under OKay's infrastructure to take advantage of this deal.