Difference between revisions of "Implementations"

From Kolmisoft Wiki
Jump to navigationJump to search
Line 9: Line 9:
For M2 implementations please check [[M2 Network Architecture | here]]
For M2 implementations please check [[M2 Network Architecture | here]]


<br>
----
<br>


==Redundancy between two data centers ==
=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 data center in which you keep your servers can be down for various reasons.
Line 24: Line 21:


<br><br>
<br><br>
== 1 Server Basic System ==
= 1 Server Basic System =


Up to 500cc
Up to 500cc
Line 39: Line 36:
<br><br>
<br><br>


== 2 Servers Solution with 2 IP Addresses ==
= 2 Servers Solution with 2 IP Addresses =


Up to 1000cc
Up to 1000cc
Line 56: Line 53:
<br><br>
<br><br>


==2 Server Redundant High-Availability Solution==
=2 Server Redundant High-Availability Solution=


Up to 500cc
Up to 500cc
Line 71: Line 68:
<br><br>
<br><br>


==3 Server Non-High Availability Solution ==
=3 Server Non-High Availability Solution =


Up to 1000cc
Up to 1000cc
Line 83: Line 80:




==4 Server High Availability Redundant Solution ==
=4 Server High Availability Redundant Solution =


Up to 1000cc
Up to 1000cc
Line 94: Line 91:
<br><br>
<br><br>


==Complete Redundancy, high performance system with SIP balancer==
=Complete Redundancy, high-performance system with SIP balancer=


Up to 2000cc, 100 CPS
Up to 2000cc, 100 CPS

Revision as of 10:59, 21 May 2019


This page shows some ways how MOR system can be used. Examples are from real implementations.

On all implementations listed below, it's recommended to deploy Asterisk and DB servers in the same datacenter. This will ensure stable system functioning.

Even though it's possible to deploy these elements in different locations, but such implementations may cause many issues, related with delays between different networks.

For M2 implementations please check here


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.

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

However, such implementation can work only if both data centers can meet requirements which are described here (see Redundant servers).

The most common problem is that different data centers cannot ensure such requirements for Virtual IP.



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