...
| 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 | 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. |
* The The private network is also required for administrative tasks by all roles.
Addressing requirements
We have the following recommendationsfollowing recommendations:
- Use an addressing scheme even in the private network. By By using DNS, when an IP renumbering occurs in the infrastructure, you do not have to reconfigure roles.
- Carefully plan the private network to allow expansion. If you do it properly on the network level, the private space is pretty much unlimited.
- Always use an addressing scheme in the public network. Ask your customers to connect to a hostname (yourservice.com), not directly to the IP address.
...
| Panel | ||
|---|---|---|
| ||
For the sake of the argument, let us assume that the software system is a car. If the AC breaks down, the car will still be able to run, maybe causing some inconvenience to its passengers its passengers (depending on the weather). The same car might be able to run at a very low speed even with a punctured tire, although it is obvious that such a damage is more important. There are also critical damages. For example, when the engine breaks down, the car will not be able to run anymore. The same happens in our environment. It might be able to work with some damages, but clearly functionality is impacted. |
In this chapter we determine the high-availability requirements based on the role type.
The table below shows what happens if nodes with nodes with a certain role go down due to any hardware fault.
| 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..| Status | | ||||||
| colour | Green | APP LEVEL | Deploy an Ejabberd cluster.|||||||||
| 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. |
|
...
Based on the above conclusions, it becomes obvious that distribution does not come with High Availability guarantees.
Application level HA
| Status | ||||
|---|---|---|---|---|
|
Some VoipNow roles are designed to work in fault tolerant clusters. This is an ideal situation because no other high availability technology is required. This provides application level high availability.
Virtualization layer HA
| Status | ||||
|---|---|---|---|---|
|
Unfortunately not all software is designed with high availability in mind. For instance, MySQL is not resilient to failures. As you can see in the table above, when the master MySQL nodes dies, the system goes goes totally down. There are promising projects that deliver multi master MySQL replication and VoipNow plays friendly with them, but for the moment we recommend to protect MySQL master node from failures using high availability technologies on the virtualization layer.
...
We are not making any specific hardware recommendations because hardware recommendations because hardware selection and sizing must be based on monitoring and usage information. Instead, we are explaining what to expect from each role.
...
| 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 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 High | Moderate | Low | High-CPU Extra Large Instance |
...
* The Amazon EC2 example provided above is purely for comparison purposes for comparison purposes and it is appropriate for a high performance is appropriate for a high performance infrastructure.
How many
...
nodes?
The system is flexible - the more users you get, the more nodes you can add.
| 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.