Page tree

This document describes the VoipNow roles and the basic things you should know about them.

Overview

VoipNow functionality is performed by multiple roles. Technically, more roles can be added in the future as the system complexity increases and new functions are added. Each role has particular provisioning requirements, therefore it is important to understand each role before going further.

Layout

Notes

LayerRoleNotes
Functionality LayerWeb management interfaceRuns the management web interface that can be accessed in the browser or through APIs such as SystemAPI and UnifiedAPI.
Functionality LayerSIPTelephony signaling in the infrastructure.
Functionality LayerPBXApplications on the telephony, media. Any functionality of the system that uses telephony in a way or another uses this role.
Infrastructure ManagementInfrastructure ControllerResponsible with running, managing and controlling the distributed infrastructure.
Infrastructure ManagementWorkerHelps with the execution of tasks in distributed environments. It allows for multiple background tasks to be executed simultaneously and significantly faster.
Infrastructure ManagementQueueResponsible with passing messages between the system components.
Storage LayerSQLStores the information in a structured way under the ACID (atomicity, consistency, isolation, durability) constraints.
Storage LayerDistributed DatabaseDistributed, highly scalable layer that stores semi-structured information persistently or non-persistently. It is used for storing information that should be frequently queried.
Storage LayerElasticsearchStores information in a proper format to handle search and analystics features.
Storage LayerUnstructured StorageHandles content (files like voicemails, recordings, faxes, etc). Supports POSIX file systems (including network ones like NFS), or Object Storage (like Amazon S3).

What is most important?

Managing a distributed environment that deals with real time services is never a trivial task. But some things are more complicated than others, so we will cover the critical stuff first, which is storage. Storage is the limiting factor for most distributed storage systems.

Unstructured storage

The infrastructure might need a lot of storage space for storing files, tens of terrabytes is not uncommon. While VoipNow can use a POSIX file system it is much better to use cloud Object Storage as it's much more scalable, more cost efficient and dramatically simplifies infrastructure management.

We support Amazon S3, but this does not mean that you have to use Amazon S3 - any system that provides Amazon S3 interface will do the job.

Structures storage (Databases)

We use three different specialized roles. From the scalability point of view, they are quite diferent.

SQL

The SQL role requires special scalling strategies and it's difficult to manage. MySQL is heavily I/O bound, which means that the speed of disk system (IOPS), memory size, and memory bandwidth are extremely important.

VoipNow can work with a master/slave MySQL cluster (one master and multiple slaves). Due to the complexity of the MySQL setup, the provisioning of the MySQL replication must be performed manually when nodes are set up. Fortunately, as the system grows it is not necessary to perform changes on the SQL layer often. A typical operation is to add more slave nodes. Usually more than four slave nodes might not increase the overall SQL role performance. Therefore, the best way to scale the system is to use more powerful hardware on the master MySQL node level.

The master MySQL node is critical. If it goes down, the entire system is down. Therefore, it is required to be provisioned under virtualization system HA. We highly recommend virtualization because, in case of hardware upgrades, these can be performed transparently, without any interruption (see technologies like VMware vMotion).

The slave MySQL nodes are not as critical because VoipNow will continue to work even when one or more slaves fail - the only downside is that performance might degrade.

Distributed database

The Distributed Database role provides built-in redundancy and failover. The Distributed Database role can scale relatively easy, by adding new nodes. This operation involves database rebalancing, which is an expensive operation. To avoid such events, it is recommended to start the deployment with several nodes, provisioned on computing containers with modest hardware resources.

The distributed database is memory bound. During the infrastructure setup, you may provision 18 nodes in the Distributed Database role, each of them having low memory resources such as 512MB. Once the hardware resources become insufficient, these can be increased.

The distributed database nodes must join an Availability Group (AG). It is recommended to provision the infrastructure in multiple Availability Groups, each group having an equal number of nodes allocated. To take advantage of redundancy and failover, it is necessary to provision at least two nodes in an Availability Group. Due to replication overhead, the performance may degrade if you have more than four nodes in one AG.

Elasticsearch

While Elasticsearch implements a very scalable clustering model, modifying the cluster layout (adding new nodes) might involve data reindexing/rebalancing.

Due to this reason it is a good idea to apply the same principles like with the Distributed database role - provision a larger number of nodes, add them to a cluster and increase the hardware capabilities once it's necessary.

Get Help

If you plan to deploy a large setup, we highly recommend you to seek the help of our Expert Infrastructure Team in the infrastructure planning steps.

This might save a lot of time and effort after the system is provisioned. Get help in Support Zone.


  • No labels

Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 4.0 International.