...
| 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. |
| Functionality Layer | Jabber | Instant messaging functions. |
| 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 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). |
...
The infrastructure might need a lot of storage space for storing files, tens of terrabytes is not uncommon. While 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.
...
The SQL role requires special scalling strategies and it's difficult to manage. MySQL 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 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 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.
| Note |
|---|
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 Distributed Database role provides built-in redundancy and failover. The 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.
| Tip |
|---|
| 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 insufficientbecome 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 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.
...
Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 4.0 International.