Difference between revisions of "Implementations"
| (91 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
Here you can review the possible MOR implementations. | |||
You can start with a single-server solution and scale the system as your business grows. | |||
On all listed implementations it's recommended to deploy Asterisk and DB servers in the same datacenter to ensure stable system functioning. | |||
Even though it's possible to deploy these elements in different locations, such implementations may cause many issues, related to delays between different networks. | |||
<br><br> | |||
= 1 Server Basic System = | |||
Up to 500cc | |||
This is a very basic solution All-in-one-Server. No redundancy, no High-Availability, no Scalability. | |||
We recommend to use it only in the testing environment. | |||
Not safe to use in the real business environment. | |||
[[Image: | [[Image:MOR_1server.png|600px]] | ||
* | <br><br> | ||
* If | |||
* | = 2 Servers Solution with 2 IP Addresses = | ||
Up to 1000cc | |||
The solution allows placing two servers in different locations. | |||
In case of broken connection or broken database replication between servers, each site will become separated systems and runs its own billing, which is not desirable in most cases. | |||
It provides double capacity with increased risk of malfunctioning in case of hardware/software/network failure. | |||
2 IP Addresses allows route balancing at the side of the customers/vendors. They will use 2 IPs to balance traffic on their side. | |||
[[Image:2serversaASTDBandGUIDB_v2.png|800px]] | |||
<br><br> | |||
=2 Server Redundant High-Availability Solution= | |||
Up to 500cc | |||
This is the most popular solution because it is fully redundant and most stable. | |||
More info: [[2 Server Redundant Solution]] | |||
[[Image:2serverredundant_withlinuxha_v2.png|800px]] | |||
<br><br> | |||
=3 Server Non-High Availability Solution = | |||
Up to 1000cc | |||
Not-recommended solution because of the risk to have main components on one server. | |||
[[Image:mor_proxy_1000cc_non_ha.png|800px]] | |||
<br><br> | |||
=4 Server High Availability Redundant Solution = | |||
Up to 1000cc | |||
The recommended solution for High-Availability, Redundant System. | |||
[[Image:mor_proxy_1000cc_ha.png|800px]] | |||
<br><br> | |||
=Complete Redundancy, high-performance system with SIP balancer= | |||
Up to 2000cc, 100 CPS | |||
* GUI is on DB servers | |||
* Proxy servers share 1 IP managed by Heartbeat | |||
* DB (Core-Asterisk/GUI) servers share another 1 IP also managed by Heartbeat | |||
* LinuxHA heartbeat monitors Database servers | |||
* If one of the Core-Asterisk servers fails, SIP balancer routes calls via remained Core-Asterisk servers. | |||
* More Core-Asterisk Nodes can be connected, example with 2 is a bare minimum | |||
* When Main Database fails - Backup Database sees that and after 10s (default) will take Virtual IP, it is done automatically. | |||
* When Main Database is back up - Backup Database returns Virtual IP to Main Database and system starts to function in normal work flow (done automatically). | |||
* GUI server is connected to Backup Database to avoid load on Main Database in normal work flow. | |||
For more details about SIP Balancer solution click [[SIP_balancer|here]] | |||
[[Image:MOR_proxy_full.png|1001px]] | |||
=See Also= | |||
* [[M4_System_Architecture | M4 Implementations]] | |||
Latest revision as of 11:49, 9 November 2023
Here you can review the possible MOR implementations.
You can start with a single-server solution and scale the system as your business grows.
On all listed implementations it's recommended to deploy Asterisk and DB servers in the same datacenter to ensure stable system functioning.
Even though it's possible to deploy these elements in different locations, such implementations may cause many issues, related to delays between different networks.
1 Server Basic System
Up to 500cc
This is a very basic solution All-in-one-Server. No redundancy, no High-Availability, no Scalability.
We recommend to use it only in the testing environment.
Not safe to use in the real business environment.
2 Servers Solution with 2 IP Addresses
Up to 1000cc
The solution allows placing two servers in different locations.
In case of broken connection or broken database replication between servers, each site will become separated systems and runs its own billing, which is not desirable in most cases.
It provides double capacity with increased risk of malfunctioning in case of hardware/software/network failure.
2 IP Addresses allows route balancing at the side of the customers/vendors. They will use 2 IPs to balance traffic on their side.
2 Server Redundant High-Availability Solution
Up to 500cc
This is the most popular solution because it is fully redundant and most stable.
More info: 2 Server Redundant Solution
3 Server Non-High Availability Solution
Up to 1000cc
Not-recommended solution because of the risk to have main components on one server.
4 Server High Availability Redundant Solution
Up to 1000cc
The recommended solution for High-Availability, Redundant System.
Complete Redundancy, high-performance system with SIP balancer
Up to 2000cc, 100 CPS
- GUI is on DB servers
- Proxy servers share 1 IP managed by Heartbeat
- DB (Core-Asterisk/GUI) servers share another 1 IP also managed by Heartbeat
- LinuxHA heartbeat monitors Database servers
- If one of the Core-Asterisk servers fails, SIP balancer routes calls via remained Core-Asterisk servers.
- More Core-Asterisk Nodes can be connected, example with 2 is a bare minimum
- When Main Database fails - Backup Database sees that and after 10s (default) will take Virtual IP, it is done automatically.
- When Main Database is back up - Backup Database returns Virtual IP to Main Database and system starts to function in normal work flow (done automatically).
- GUI server is connected to Backup Database to avoid load on Main Database in normal work flow.
For more details about SIP Balancer solution click here
