Difference between revisions of "Implementations"

From Kolmisoft Wiki
Jump to navigationJump to search
 
(47 intermediate revisions by 2 users not shown)
Line 1: Line 1:
This page shows some ways how MOR billing system can be used. Examples are from real implementations.
Here you can review the possible MOR implementations.


On all implementations listed below, Asterisk servers could be located on different Locations/Datacenters, however, increased latency will have high impact on performance and therefore Asterisks should be located as close to Database as possible.
You can start with a single-server solution and scale the system as your business grows.


For M2 implementations please check [[M2 Network Architecture | here]]
On all listed implementations it's recommended to deploy Asterisk and DB servers in the same datacenter to ensure stable system functioning.


<br>
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>


==Redundancy between two data centers ==
<br><br>
 
There's always a risk that data center in which you keep your servers can be down for various reasons.


To reduce such risk you can consider implementing redundancy between two data centers that are located in different countries or continents.
= 1 Server Basic System =


However, such implementation can work only if both data centers can meet requirements which are described [[Recommended_hardware#Requirements_for_multi-server_deployment | here]] (see '''Redundant servers''').
Up to 500cc


The most common problem is that different data centers cannot ensure such requirements for Virtual IP.
This is a very basic solution All-in-one-Server. No redundancy, no High-Availability, no Scalability.  


<br><br>
We recommend to use it only in the testing environment.
== 1 Server Basic-Testing System (Not for Production) ==


This is very basic solution All-in-one-Server. No redundancy, no High-Availability, no Scalability. Use only in the testing environment. Not suitable for business.
Not safe to use in the real business environment.




Line 29: Line 24:
<br><br>
<br><br>


==2 servers solution with Asterisk and GUI separated==
= 2 Servers Solution with 2 IP Addresses =
[[Image:2serversaASTDBandGUIDB.png|400px]]


This solution has two replicated databases.
Up to 1000cc


Asterisk connects to one database and GUI connects to another, so it increases performance when Web interface is used intensively.
The solution allows placing two servers in different locations.  


<br><br>
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.


==2 servers solution==
It provides double capacity with increased risk of malfunctioning in case of hardware/software/network failure.
[[Image:2serversaASTDBandGUIDB_v2.png|800px]]


Solution allows to place two server on different locations. In case of broken connection or broken database replication between servers, each site will became as separated systems and runs its own billing, which is not desirable in most cases.  
2 IP Addresses allows route balancing at the side of the customers/vendors. They will use 2 IPs to balance traffic on their side.
<br><br>


==2 Asterisk servers solution==
[[Image:2serversaASTDBandGUIDB_v2.png|800px]]
[[Image:2asterisks.png|400px]]


This solution has two Asterisk servers.


Such system is used in order to increase the capacity of the system in terms of concurrent calls.
<br><br>


=2 Server Redundant High-Availability Solution=


<br><br>
Up to 500cc
 
==2 server redundant solution==
[[Image:2serverredundant_withlinuxha.png|400px]] [[Image:2serverredundant_withlinuxha_v2.png|800px]]


This is the most popular solution because it is fully redundant and most stable.
This is the most popular solution because it is fully redundant and most stable.


More info: [[2 server redundant solution]]
More info: [[2 Server Redundant Solution]]




<br><br>
[[Image:2serverredundant_withlinuxha_v2.png|800px]]


==4 server redundant solution==
[[Image:4serverredundant_withlinuxha.png|400px]]
Stable and redundant solution for high performance.


More info: [[4 server redundant solution]]


<br><br>


<br><br>
=3 Server Non-High Availability Solution =


==[[Image:ita.jpg]] 4 server solution in Italy with 16 E1==
Up to 1000cc


Not-recommended solution because of the risk to have main components on one server.


[[Image:impl_2ast1db1gui16e1.png]]
[[Image:mor_proxy_1000cc_non_ha.png|800px]]


* Such system is in Italy serving Call Shops
* E1 hardware is 2 x [http://www.sangoma.com/datasheets/a108-specs Sangoma A108DE] cards
* This implementation is used for high volume calls to/from PSTN network over 16 E1 links were 4+4 E1 is for incoming and 4+4 E1 is for outgoing (on Asterisk 1 server 4 incoming/4 outgoing and same on server Asterisk 2).
* Separate server is dedicated to database which minimizes load on Asterisk servers.
* GUI is on separate server with it's own DB connected to main DB server over MySQL Replication.


<br><br>
<br><br>
==Many Asterisk servers with DB Replication==


[[Image:impl_nast2db1gui.png]]


<br><br>
=4 Server High Availability Redundant Solution =
=SIP Balancer solutions=


==Minimal structure without redundancy==
Up to 1000cc
[[File:ccl_3servers_minimal_structure.png]]


NOTES:
The recommended solution for High-Availability, Redundant System.
* GUI is on Asterisk/DB servers
* When Proxy server (OpenSIPS) crashes, all system is down -> no redundancy, not recommended in production, good for testing
* DB (Asterisk/GUI) servers share 1 IP also managed by Heartbeat
** Setup without Heartbeat also is possible, but this introduces 1 more point of failure (DB server), but simplifies the setup, thus allowing faster setup for testing


<br><br>
[[Image:mor_proxy_1000cc_ha.png|800px]]


==Minimal structure for full-redundancy==
[[File:ccl_4servers_full_redundancy.png]]
NOTES:
* GUI is on Asterisk/DB servers
* Proxy servers share 1 IP managed by Heartbeat
* DB (Asterisk/GUI) servers share another 1 IP also managed by Heartbeat


<br><br>
<br><br>


==Multiple Asterisk servers, high performance system with SIP balancer and DB Replication==
=Complete Redundancy, high-performance system with SIP balancer=


[[Image:impl_1sipbalnast2db1gui.png]]
Up to 2000cc, 100 CPS


* [[SIP balancer| SIP balancer]]
* GUI is on DB servers
* If one of Asterisk servers fails, SIP balancer routes calls via remained Asterisk 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
* LinuxHA heartbeat monitors Database servers
** When Main Database fails - Backup Database sees that and after 10s (default) will take Virtual IP, it is done automatically.
* If one of the Core-Asterisk servers fails, SIP balancer routes calls via remained Core-Asterisk servers.
** 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).
* 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.
* GUI server is connected to Backup Database to avoid load on Main Database in normal work flow.


This solution can handle up to 1000 simultaneous calls. Certain amount of calls may vary depending on hardware, codecs used and transcoding. Additional Asterisk servers can be added if larger amount of simultaneous calls is needed.
For more details about SIP Balancer solution click [[SIP_balancer|here]]
<br><br>
==Complete Redundancy, high performance system with SIP balancer==


[[Image:MOR_proxy_full.png|1001px]]
[[Image:MOR_proxy_full.png|1001px]]


[[Image:SIP_balancer_for_docs.png]]
=See Also=
<br><br>
Detailed schematic of SIP Proxy solution:


[[Image:SIP_balancer_detailed.png]]
* [[M4_System_Architecture | M4 Implementations]]
<br><br>
NOTES:
* GUI is on DB servers
* Proxy servers share 1 IP managed by Heartbeat
* DB (Asterisk/GUI) servers share another 1 IP also managed by Heartbeat
* More Asterisk Nodes can be connected, example with 2 is bare minimum
<br><br>
For more details about SIP Balancer solution click [[SIP_balancer|here]]
<br><br>

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.


MOR 1server.png



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.

2serversaASTDBandGUIDB v2.png




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


2serverredundant withlinuxha v2.png




3 Server Non-High Availability Solution

Up to 1000cc

Not-recommended solution because of the risk to have main components on one server.

Mor proxy 1000cc non ha.png





4 Server High Availability Redundant Solution

Up to 1000cc

The recommended solution for High-Availability, Redundant System.

Mor proxy 1000cc ha.png




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

MOR proxy full.png

See Also

Retrieved from "https://wiki.kolmisoft.com/index.php?title=Implementations&oldid=29180"