The Importance of Geo-Redundancy for Voice Service Providers

Written By Bicom Systems Team

Our greatest insights are brought to you with heartfelt devotion. We hope you’ll enjoy your read!

High service availability is one of the most important features that any voice service provider must ensure. You want your company protected from the risk of losing subscribers. The solution is a data recovery product with automatic takeover that ensures minimal downtime and high availability of your services.

This article will walk you through the capabilities of SERVERware and geo-redundancy and explain why this combination is the recipe for  success in a high-quality telecommunications business.


We must first take a quick dive into virtualization. For those unfamiliar, virtualization is the process of creating and running virtual machines (instances of computers) using a physical host’s resources (computer, server). There are numerous virtualization solutions, each with its own set of benefits, disadvantages, and purposes. (Learn more in our blog post “How to Choose a Virtualization Platform“.)

Virtualization is a hot topic in the telco industry because it allows voice service providers to reduce hardware requirements while increasing system administration capabilities. Virtualization improves performance and uptime by consolidating multiple servers in one physical location.

Virtualization for Next-Gen Communications

Bicom Systems has been in the telecommunications industry for two decades. One contribution we made to this fast-growing market is a platform specifically designed for telecommunications services. 

One thing that sets SERVERware apart from the competition is the fact that our virtualization solution is the only platform designed specifically for hosting VoIP telephony and cloud communications. (Learn more about SERVERware in “SERVERware 4.3: What’s New In The Latest Product Release“.)

In a redundant, highly available, and fault-tolerant manner, it provides a variety of IP services and applications.

It offers thorough control, adaptability, self-healing, and hardware redundancy between the servers with the mirror edition.


SERVERware is a next-generation communication technology solution powered by ZFS, iSCSI, and LXC Containers as the three main underlying technologies.

We’ve integrated ZFS into the system to give SERVERware disk redundancy, fault tolerance, and self-healing capabilities. ZFS is a hybrid file system and logical volume management that offers logical raid configurations, large storage support, effective data compression, and data corruption protection.

Let’s say you have a SERVERware Mirror edition, both servers with 4TB drives. ZFS will combine those two drives creating a mirror and a single storage pool by using the drives from both servers. If one of those disks fails, the other disk contains the exact copy of the data of the other disk, which offers additional redundancy in protecting data and services.


Now that we have covered virtualization and some highly functional features, let’s explain geo-redundancy and how VoIP providers can use it to safeguard their business.

Geo-redundancy is the distribution of critical data and services over multiple data centers located in geographically separated sites. This method aims to provide redundancy in the event of power outages, fires, natural disasters, or scheduled maintenance by data centers. Find out “Why you need Geo-Redundancy” in our previous blog post.

It is important to note that geo-redundancy differs from a backup, as they have different purposes. You can learn more about it by reading one of our earlier articles about geo-redundancy (here).

How is Geo-Redundancy Implemented in SERVERware?

Geo-redundancy is implemented through replications.

Replication is the process of sending a snapshot of a VPS from one SERVERware to another SERVERware site that acts as a GR Server. Therefore, for this to work, your company must own two SERVERwares sites. Each SERVERware has a NETSTOR storage pool formed, and a piece of that NETSTOR storage pool is reserved for the GR pool, which will be storing the replications of the VPSes from the primary site.

For this example, we’ll call them SW1 and SW2. SW1 and SW2 are physically separated and located in two geographically separate sites (e.g., London and Chicago).

Each SERVERware has a NETSTOR storage pool formed, and a piece of that NETSTOR storage pool is reserved for the GR pool, which will be storing the replications of the VPSes from the primary site

During the replication, a snapshot is created of the current state of the VPS, and that data is sent to the GR pool dataset on the SW2. If SW1 fails for any reason, the user can perform a takeover. The takeover process means another snapshot will be created of the one already stored in the GR pool, and a VPS will be created in the NETSTOR, where it will keep running.

A takeover is done in just a few clicks because all the necessary data is already located on that physical SERVERware (SW2). However, that will primarily depend on how frequent data replication is between sites. Users can schedule replication every minute, every 5 minutes, and the maximum time is every 24 hours.

Only the first initial replication transfers the entire VPS (e.g., 50Gb), and each subsequent one makes incremental replications, e.g., 300Mb, so there is no extensive data transfer that could lead to a network overload.

Does Geo-Redundancy Allow For An Automatic Takeover?

By default, the takeover in SERVERware is manual, but administrators don’t have to worry because there is also an option for the automatic takeover.

Administrators can create templates using SERVERware’s site monitoring feature. Site monitoring enables the SERVERware administrator to set up monitoring of remote sites by creating a set of tests that will report whether the monitored site is available or not. 

For example, SW2 pings the SW1 site and initiates the automatic takeover if it doesn’t get a return ping. Simple, effective, and much faster than backup.


There are no reasons not to implement geo-redundancy. There are no dangers other than poor planning since GR’s goal is clear.

Users implementing the GR need to keep in mind the resource usage of the primary site in order to have enough hardware and processing resources on the GR site to run their instances in case of a takeover, and this is a factor that might come with some difficulties in the implementation itself. Given that the virtual instances are using a specific amount of storage resources and RAM memory, they are generating calls and similar. If a takeover is done, the GR site must have a sufficient amount of those resources to run these virtual instances.

Thankfully, our team is here to support all of our partners, as they have done for a very long time, and as a result, the risk issue is eliminated.

How To Enable GR in your SERVERware?

Every SERVERware edition supports GR, but a separate license must be purchased to activate GR (per SERVERware).

Users who opt to implement the GR site will be working with our team of engineers, who will inspect their primary site and, based on the current resource usage and other important factors, provide suggestions for the number of hardware resources, hardware components, and similar for their GR site. This is called a staging process, which is completed before the actual implementation of the geo-redundancy to ensure the user will have enough resources for replications, takeover, or in other words, implementation of geo-redundancy.

The advantage of having two SERVERware sites is that the second one does more than simply wait to serve as a GR server (GRS). You can utilize the second SERVERware for PBXware and new VPSs just as the first one.


To learn more about SERVERware, please check out our wiki page and our YouTube Channel. Also, do not hesitate to contact us for any additional information you may have. geo