...
| 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. |
| 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.
...
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 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 notes?
The system is flexible- the more users you get, the more nodes you can add.
...
Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 4.0 International.