Difference between revisions of "M2 Network Architecture"

From Kolmisoft Wiki
Jump to navigationJump to search
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
__NOTOC__
This page shows some ways how M2 system can be used. Examples are from real implementations.
This page shows some ways how M2 system can be used. Examples are from real implementations.


Line 10: Line 8:




= 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 21: Line 19:


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


Up to 1000cc
Up to 1000cc
Line 37: Line 35:




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


Up to 500cc
Up to 500cc
Line 50: Line 48:
<br><br>
<br><br>


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


Up to 3000cc
Up to 3000cc
Line 62: Line 60:




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


Up to 3000cc
Up to 3000cc
Line 73: Line 71:
<br><br>
<br><br>


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


Up to 4000++cc, 100++ CPS
Up to 10000++cc, 1000++ CPS


* GUI is on DB servers
* GUI is on DB servers (or better in the separate server)
* Proxy servers share 1 IP managed by Heartbeat
* Proxy servers share 1 IP managed by Heartbeat
* DB (Core/GUI) servers share another 1 IP also managed by Heartbeat
* DB (Core/GUI) servers share another 1 IP also managed by Heartbeat
Line 85: Line 83:


* When Main Database fails - Backup Database sees that and after 10s (default) will take Virtual IP, it is done automatically.
* 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).
* When Main Database is back up - Backup Database returns Virtual IP to Main Database and system starts to function in the normal workflow (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 the normal workflow.


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

Latest revision as of 13:43, 25 March 2020

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

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

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

For MOR 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 1000cc

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.


M2 1server.png




2 Server Redundant High-Availability Solution

Up to 500cc

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


M2 2server ha.png




3 Server Non-High Availability Solution

Up to 3000cc

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

M2 3server non ha.png





4 Server High-Availability Redundant Solution

Up to 3000cc

The recommended solution for High-Availability, Redundant System.

M2 4server ha.png




Complete Redundancy, high-performance system with SIP balancer

Up to 10000++cc, 1000++ CPS

  • GUI is on DB servers (or better in the separate server)
  • Proxy servers share 1 IP managed by Heartbeat
  • DB (Core/GUI) servers share another 1 IP also managed by Heartbeat
  • LinuxHA heartbeat monitors Database servers
  • If one of the Core servers fails, SIP balancer routes calls via remained Core servers.
  • More Core 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 the normal workflow (done automatically).
  • GUI server is connected to Backup Database to avoid load on Main Database in the normal workflow.

M2 proxy full system.png