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
| Layer | Role | Notes |
|---|---|---|
| Functionality Layer | Web management interface | Runs the management web interface that can be accessed in the browser or through APIs such as SystemAPI and UnifiedAPI. |
| Functionality Layer | SIP | Telephony signaling in the infrastructure. |
| Functionality Layer | PBX | Applications on the telephony, media. Any functionality of the system that uses telephony in a way or another uses this role. |
| Infrastructure Management | Infrastructure Controller | Responsible with running, managing and controlling the distributed infrastructure. |
| Infrastructure Management | Worker | Helps with the execution of tasks in distributed environments. It allows for multiple background tasks to be executed simultaneously and significantly faster. |
| Infrastructure Management | Queue | Responsible with passing messages between the system components. |
| Storage Layer | SQL | Stores the information in a structured way under the ACID (atomicity, consistency, isolation, durability) constraints. |
| Storage Layer | Distributed Database | Distributed, highly scalable layer that stores semi-structured information persistently or non-persistently. It is used for storing information that should be frequently queried. |
| Storage Layer | Elasticsearch | Stores information in a proper format to handle search and analystics features. |
| Storage Layer | Unstructured Storage | Handles 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 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.
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.
Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 4.0 International.