Failover FusionPBX Cluster

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.