VoIP Clusters

• FusionPBX

This is one of the most complex cluster scheme OKay can bring you. Its architecture protects your server against downtimes.

All the operation stays on PBX 1 (active) while PBX 2 (passive) is synced all time.

When PBX 1 fails, the floating IP will be moved to the PBX 2 server, now acting as active. Depending on your customers' configuration, they may need to redial or they may have 2 to 3 seconds dead-air.

Because this solution is server end based, you do not need to do anything on the endpoints.

Variant 1: High Availability with Outsourced Database

The high availability cluster has a requirement: the active and passive server must be in the same network segment. Therefore, this approach doesn't protect against data centre failures.

This variant adds a simple failover to the cluster. If the data centre 1 goes down, by changing some DNS records will be enough to recover the service.

When do I need the High Available FusionPBX Cluster?

Since the recovery time of this clustering scheme is long comparing to others, this is ideal if you:

• have a business that can't afford more than one minute offline.

How do I get this High Available FusionPBX Cluster?

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. 

• FusionPBX

This is the simplest cluster scheme OKay can bring you. Its simplicity makes it really affordable for everyone who wants to start slowly and doesn't want to feel unprotected by running a standalone server only.

All the operation stays on PBX 1 (active) while the PBX 2 (backup) is synced on specific times.

When PBX 1 fails, communications will be down until the DNS records are updated to point to backup PBX.

There are some native DNS approaches that could make the server switch automatically (if the endpoint supports it) such as using the SRV and NAPTR records. There are other solutions such as OKay's PowerDNS add-on that not only update SRV records automatically but the A records as well.  Because the switch happens on the user end, it requires that the endpoints and routers honour the DNS TTL. Some odd brands require a reboot to take the DNS update.

The new active server will have the information when the last transfer was done. For example, if PBX 2 syncs at three of the morning and the failure switch happens at ten, there will be only seven hours out of sync; mostly the CDR, faxes or voicemails.

Variant 1: Simple Failover with Outsourced Database

This variant of the simple failover cluster presents the database outsourced from the PBX 1 (active) server. Regarding the disponibility aspects, there is no advantage from the original scheme. However, because the database is outsourced, the PBX 1 server can hold more workload such as more simultaneous calls. When the failover takes place, PBX 2 will be acting as a standalone server. Its performance won't be like PBX 1 (mainly because the database is hosted within the server) but it will give a breath while the PBX 1 is recovered.

Variant 2: Simple Failover within the Database

In this scheme, the PBX 1 (active) server doesn't host the database (similar to the first variant). The database server also hosts the PBX acting as a backup. The advantage of this approach is that because the database resides in the backup server, the synchronization span doesn't affect the database.

This variant suits perfectly if you want to have real-time synchronization. This may allow you not to lose information between the last checkpoint and the failover. However, real-time replication requires more CPU that may be useful in other areas such as the SIP or RTP processing.

When do I need the Failover FusionPBX Cluster?

Since the recovery time of this clustering scheme is long comparing to others, this is ideal if you:

• use the PBX for personal purposes (including hosting your own PBX for your home),
• use the PBX for your small business that doesn't depend on the telephone to operate
• use the PBX for a business that can hold out of line for several minutes (maybe 1 hour)

How do I get this Failover FusionPBX Cluster?

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. 

• FusionPBX

Fault Tolerance

	Failure Sensitiveness	Time to Recover Back	Easiness To Recover Back
Simple Failover
Simple Failover (variant 1)
Simple Failover (variant 2)
Load Balanced
Highly Available
Highly Available (variant 1)
Enterprise

• Failure Sensitiveness: how sensible is the configuration that a given event may switch the tolerance mechanism. The more stars, the more sensible. The fewer stars, the better (more resistant).
• Time to Recover Back: when an event happens, how long does it take to recover and return to a normal operation state. The more stars, the longer. The fewer stars, the better.
• Easiness to recover Back: after an event happens, how big is the effort to return to a normal operation state. The more stars, the harder. The fewer stars, the better.

Deployment

	Easiness to Deploy	Time to Deploy	Expensiveness to Deploy	Can have SBC?	Minimum required Servers
Simple Failover				Yes	2
Simple Failover (variant 1)				Yes	3
Simple Failover (variant 2)				Yes	2
Load Balanced				Yes	5
Highly Available				Yes	5
Highly Available (variant 1)				Yes	6
Enterprise				Included	7

• Easiness to Deploy: How easy for a seasoned system administrator is to set up the given architecture. The more stars, the easiest. The fewer stars, the harder.
• Time to Deploy: How long does it take. The more stars, the longest. The fewer stars, the shorter.
• Expensiveness to Deploy: Relative cost compared against others architectures. The more stars, the more expensive. The fewer stars, the cheaper.
• Can have SBC?: If this architecture supports the SBC add-on.
• Minimum number of Servers to Deploy: Some of these architectures may have more servers. These number represents the minimum quantity needed to do the proper deployment.