Since release 3.6 of FusionPBX, it is possible to deploy a voice over IP solution on the cloud that satisfies next characteristics:
- Balancing: servers split the load among them depending on different network conditions;
- Cluster: servers know their peers and they send sync information each other;
- High Availability: servers detect when a pear is down and they split the load among them.
This solution works without Kamailio.
OKay's services can help you to do this kind of deployments. We explain in detail.
In a scene like next:
- One FusionPBX server in Buffalo, EUA
- One FusionPBX server in London, UK
- One FusionPBX in Singapore, Singapore
- One DNS server in Los Ángeles, EUA
- One DNS server in Jacksonville, EUA
Servers share the same database and they sync their file system on regular basis.
Balancing the Load among the Nodes
By monitoring algorithms, clients are forwarded to the server whose latency is the lowest. Monitoring is passive and not invasive to the customer network.
According to the example, users from Vancouver (Canada), Mexico City (Mexico) and Buenos Aires (Argentina) will be forwarded to the server in Búfalo; users from Roma (Italy) are connected to the server in London (UK); users in Sidney (Australia) and Tokio (Japan) are forwarded to the server in Singapour (Singapour).
The best way to get this done is by using the Low Latency PowerDNS Add-on. This piece of software will use statistics from the monitoring in order to select the best server.
Clustering and Interconnecting Peers
When a user calls another user connected to the same server, the call happens as a single deployment server. When a user calls a remote user (logged into another server), FusionPBX detects a non-local user and makes a connection to the target server.
In this example, a user in Vancouver calls a user in Tokio. The PBX in Buffalo makes connexion to the server in Singapore.
Faul Tolerance and Redirecting Endpoints
Fault Tolerance in this kind of deployment happens when a FusionPBX server fails; users are forwarded in minutes to the second best server.
In this case, when the server in London fails, the user in Roma is forwarded to the server in Buffalo.
This effect is archived thanks to a monitoring and smart DNS integration.
Availability of voice servers is monitoring always. When there is a failure, DNS servers are updated.