Difference between revisions of "Recommended hardware"
(→FAQ) |
(→FAQ) |
||
| Line 70: | Line 70: | ||
* '''Do you have the provision of STUN and TURN servers on your end?''' | * '''Do you have the provision of STUN and TURN servers on your end?''' | ||
No, we do not provide STUN servers. MOR should receive Public IPs on SIP headers. NAT traversal should be done on customer's side. | No, we do not provide STUN servers. MOR should receive Public IPs on SIP headers. NAT traversal should be done on the customer's side. | ||
* '''Can I have redundancy between two data centers?''' | * '''Can I have redundancy between two data centers?''' | ||
There's always a risk that data center in which you keep your servers can be down for various reasons. | There's always a risk that the data center in which you keep your servers can be down for various reasons. | ||
To reduce such risk you can consider | To reduce such risk, you can consider redundancy between two data centers located in different countries or continents. | ||
Such implementation can work only if both data centers | Such implementation can work only if both data centers meet the requirements described [[Recommended_hardware#Requirements_for_redundant_deployment | here]]. | ||
However, we do not recommend this because of the following reasons: | However, we do not recommend this because of the following reasons: | ||
1. Different data centers cannot ensure the same subnet for servers, so you must use VPN which is difficult to manage or DNS. | 1. Different data centers cannot ensure the same subnet for servers, so you must use VPN which is difficult to manage or DNS. | ||
2. MySQL replication requires a stable connection. If replication fails, you will have a "split-brain" scenario and it will not be possible to fix this without losing calls and billing information. | 2. MySQL replication requires a stable connection. If replication fails, you will have a "split-brain" scenario and it will not be possible to fix this without losing calls and billing information. | ||
Revision as of 11:46, 9 November 2023
Specifications
Main principle - as powerful as possible.
It is required to have a clean server without any additional packets installed.
Default Centos kernel is required for all functionality to work correctly.
For single server solution we recommend:
| Component | Minimum requirement (for testing) | Recommended (for production) | Comment | |
| CPU | 4c/8t (four core, eight thread) Xeon | any higher CPU, at least 8 cores | ||
| RAM | 8 GB | 32 GB | 32/64 GB | |
| HDD | 100 Gb SSD (Solid State Drives) all space must be assigned to / partition; 500+ GB for M4 | 500+ Gb, SSD (Solid State Drives)/NVM Express (NVMe), RAID Type 1 all space must be assigned to / partition; | ||
| OS | Centos 7 x86_64 | Centos 7 x86_64 | OS timezone must be set to UTC or at least to Timezone which does not have daylight saving | |
| NIC | Any | M4: Intel I210, I350, X550T (if you need over 700 concurrent calls) | Realtek RTL8111/8168/8411, Intel 82574L are weak NICs, not recommended | |
| Brand | Any | Intel, DELL, HP, Fujitsu |
Requirements for specific elements in a multi-server deployment
Asterisk/Core server: same requirements as above, except SSD would not increase performance so it is not needed and 4 GB of RAM is sufficient. CPU is most important component here. If Proxy solution is in use, Asterisks cannot be under NAT, it must have Public IP for SIP and RTP traffic. Must be located as close as possible to Database server to avoid problems caused by latency.
Database server: same requirements as above and SSD is highly recommended here. SSD is must if system has more than one Asterisk server. There should be 100GB or more space as database grows fast on high traffic. It is recommended to start with at least 400GB on M2 systems. Fast data storage device and CPU are most important here. If more than one Database server is in use, UPS (Uninterruptible Power Supply) devices must be used for these servers, otherwise power outage would cause broken replication. 8Gb RAM minimum. Must be located as close as possible to Asterisk server to avoid problems caused by latency.
GUI server: same requirements as above, except SSD would not increase performance a lot. HDD with more space is recommended here.
Proxy server: same requirements as above, except 4 GB of RAM and 40 GB on HDD will be enough here. SSD would not increase performance. Proxy server cannot be under NAT, it must have Public IP for SIP traffic.
Requirements for redundant deployment
Requirements for network to which servers are connected:
- Both servers should be within same subnet.
- Both servers should be able to broadcast packets to UDP 694 port.
- Both servers should be able to receive packets broadcasted by other server.
- There should be Virtual IP reserved in Subnet.
- Both servers should be able to work with that Virtual IP (only one server at same time).
If any of requirements above are not met, in some cases it is possible to adapt different network configurations or services (like "IP Failover").
In this case, you need to develop and manage special scripts or third-party software to achieve this (Kolmisoft does not provide this service).
Virtualization
MOR system was tested and working on the following Virtualization technologies:
- VMware
- VirtualBox
- XEN
- AWS
- Azure
In general, we do not recommend using Virtual machines for multi-server solutions when those Virtual machines are running on the same host.
Best multi-server system performance is achieved when running on Dedicated servers or on Virtual machines running on dedicated servers.
FAQ
- Do you have the provision of STUN and TURN servers on your end?
No, we do not provide STUN servers. MOR should receive Public IPs on SIP headers. NAT traversal should be done on the customer's side.
- Can I have redundancy between two data centers?
There's always a risk that the data center in which you keep your servers can be down for various reasons.
To reduce such risk, you can consider redundancy between two data centers located in different countries or continents.
Such implementation can work only if both data centers meet the requirements described here.
However, we do not recommend this because of the following reasons:
1. Different data centers cannot ensure the same subnet for servers, so you must use VPN which is difficult to manage or DNS.
2. MySQL replication requires a stable connection. If replication fails, you will have a "split-brain" scenario and it will not be possible to fix this without losing calls and billing information.
