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.
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.
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.
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.
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.
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.
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.
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 | ![]() | ![]() | ![]() ![]() |
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 |
An IT Company whose mission is generating value with low cost of ownership.
We will offer you Linux based solutions that satisfy your needs. We focus on VoIP & Linux, but we are up for any other challenge you may want to bring.