...
| Table of Contents | ||
|---|---|---|
|
| 4psafasttrack | ||
|---|---|---|
| ||
In this section, we will detail each role in order to determine provisioning constraints such as: You are free to go solely through the tables if you are confident about your infrastructure. At the same time, we understand that some things might get complicated, that's why we provide infrastructure design consulting services. |
Networking requirements
Public and private
...
| Role | Private Network * | Public Network | Notes | |||
|---|---|---|---|---|---|---|
| SQL | Required | Not required | We strongly discourage exposing SQL nodes in a public network. | |||
| Distributed Database | Required | Not required | We strongly discourage exposing Distributed Database nodes in a public network. If there are more than 3 extensions on the server, the Distributed Database role cannot be assigned. | |||
| Elasticsearch | Required | Not required | We strongly discourage exposing Elasticsearch nodes in a public network. | |||
| Web Management Interface | Required | Required | Technically could run on a private IP as well, but a HTTP load balancer (that obviously runs on a public IP) is required. | |||
| SIP | Required | Required | Private IP required for management purposes. | |||
| PBX | Required | Required | Private IP required for management purposes. | |||
| Jabber | Required | Required | Private IP required for management purposes. | |||
| Infrastructure Controller | Required | Optional | The public IP is necessary only if it's impossible to access the infrastructure controller management interface through private network.Queue | |||
| Required | Not required | We strongly discourage exposing Queue nodes exposed in a public network. | Worker | Required | Not required | We strongly discourage exposing Worker nodes exposed in a public network. |
...
| Role | Outcome | Recommended HA strategy | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| SQL | System is not affected if one of the slave nodes is lost, but system functionality is totally lost when master MySQL node goes down. |
| |||||||||||||||
| Distributed Database | System is not affected as long as quorum exists.. |
| |||||||||||||||
| Elasticsearch | System is not affected as long as quorum exists.. |
| |||||||||||||||
| Web Management Interface | System is not affected as long as a health based balancer is configured to distribute requests to web management interface nodes. |
| |||||||||||||||
| SIP | A group of customers is affected, phone functionality is lost, current calls are not be dropped. |
| |||||||||||||||
| PBX | A group of customers is affected, phone calls are dropped, no loss of functionality after. |
| |||||||||||||||
| Jabber | System is not affected as long as quorum exists.. |
| |||||||||||||||
| Infrastructure Controller | Infrastructure provisioning affected. |
| Queue | System is not affected as long as quorum exists.. |
| ||||||||||||
| Worker | System is not affected as long as a sufficient number of worker nodes survive the event in order to be able to process requests. |
|
...
| Role | CPU | Memory | I/O | Example: Amazon EC2 Instance Type * |
|---|---|---|---|---|
| SQL | High | Very High | Very High | High I/O Quadruple Extra Large Instance |
| Distributed Database | Moderate | High | Moderate | Large Instance |
| Elasticsearch | Moderate | High | Moderate | Large Instance |
| Web Management Interface | High | Low | Low | High-CPU Extra Large Instance |
| SIP | High | Moderate | Low | High-CPU Extra Large Instance |
| PBX | High | Moderate | Moderate | High-CPU Extra Large Instance |
| Jabber | Moderate | Moderate | Low | Large Instance |
| Infrastructure Controller | Low | Low | Low | Small Instance |
| Queue | Moderate | Low | Low | Medium Instance |
| Worker | High | Moderate | Low | High-CPU Extra Large Instance |
...
| Role | Node Type | Min/Max Nodes | Comments | ||||
|---|---|---|---|---|---|---|---|
| SQL | Master | 1/1 | A single MySQL node can sustain a large infrastructure. We support sharding to address the cases when a single master MySQL node becomes a limitation. | ||||
| SQL | Slave | 0/4 | Slaves offload some queries from the master. It's not necessary to deploy slaves, but if you do, keep their number to a maximum of four. | ||||
| Distributed Database | - | 1/128 | The number of distributed database nodes must not be changed for the system lifetime, but this is not a problem because, for the start, you can use virtual machines or instances with very limited resources. | ||||
| Elasticsearch | - | 1/Cluster | It is recommended to deploy an Elasticsearch cluster. | ||||
| Web Management Interface | - | 1/No limit | You can add nodes dynamically, based on the web interface utilization. | ||||
| SIP | - | 1/No limit | The SIP role uses dynamic sharding. This means that customers are assigned automatically to one of the existing SIP roles. That's why you cannot remove SIP nodes after these are provisioned. You can start with one and add more as capacity increases demand it. | ||||
| PBX | - | 1/No limit | The PBX nodes are dynamically chosen by VoipNow. This means that you can remove PBX nodes that are not used. You can start with one and add more capacity when telephony utilization information shows this. | Jabber | - | 1/Cluster | It is recommended to deploy an Ejabberd cluster. |
Infrastructure Controller | - | 1/3 | A single node running the infrastructure controller is necessary, but it can be protected with Fault Tollerance technologies. | Queue | - | 1/Cluster | It is recommended to deploy a RabbitMQ cluster. |
| Worker | - | 1/No limit | You can add nodes dynamically, based on the worker layer utilization. |
...
Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 4.0 International.