Difference between revisions of "4 server redundant solution"

From Kolmisoft Wiki
Jump to navigationJump to search
 
(One intermediate revision by the same user not shown)
Line 2: Line 2:


'''Network setup'''
'''Network setup'''
* Best scenario when all 4 servers are on same LAN (subnet).
* Best scenario when all 4 servers are on the same LAN (subnet).
* Other possible solutions: Server 1 and 2 are on one LAN, Server 3 and 4 are on a different LAN (subnet). A VPN for better security from
* Other possible solutions: Server 1 and 2 are on one LAN, Server 3 and 4 are on a different LAN (subnet). A VPN for better security from
server 1 and 2 to server 3 and 4 can be made.
servers 1 and 2 to servers 3 and 4 can be made.
* If all 4 servers are on different LANs (subnets) in that case between servers VPNs have to be configured. Drawback - such setup
* If all 4 servers are on different LANs (subnets), then between servers, VPNs have to be configured. Drawback - such a setup
management becomes too complicated.
becomes too complicated for management.
* If servers are in the different countries (continents), it might cause latency problems which has negative influence on the speed of retrieving/instering data to the DB (loading statistics, trying to retrieve some data, searching for a sound file, etc. will longer than usually). <br>
* If servers are in different countries (continents), it might cause latency problems, which has a negative influence on the speed of retrieving/inserting data to the DB (loading statistics, trying to retrieve some data, searching for a sound file, etc., will take longer than usual). <br>
'''Workflow'''
'''Workflow'''
* Servers 1 and 2 (S1 and S2) are identical. They serve as gateways with Asterisk + MOR installed.
* Servers 1 and 2 (S1 and S2) are identical. They serve as gateways with Asterisk + MOR installed.
* Both of them have two network interfaces - one for [http://en.wikipedia.org/wiki/Virtual_IP_address  Virtual IP] which is visible from outside, and one for local IP for interconnection [[Linux Heartbeat | heartbeat monitoring]]
* Both of them have two network interfaces - one for [http://en.wikipedia.org/wiki/Virtual_IP_address  Virtual IP] which is visible from outside, and one for local IP for interconnection [[Linux Heartbeat | heartbeat monitoring]]
* LinuxHA heartbeat monitors servers, e.g.
* LinuxHA heartbeat monitors servers, e.g.
** When S1 fails - S2 sees that and after 10s (default) will take Virtual IP, e.g. will start to serve calls, it is done automatically
** When S1 fails - S2 sees that and after 10s (default) will take Virtual IP, e.g., will start to serve calls, it is done automatically
** When S1 is back up - S2 returns Virtual IP to S1 and system starts to function in normal work flow (done automatically).
** When S1 is back up, S2 returns the virtual IP to S1, and the system starts to function in normal workflow (done automatically).


* Servers 3 and 4 (S3 and S4) are identical. They serve as MySQL DB.
* Servers 3 and 4 (S3 and S4) are identical. They serve as a MySQL DB.
* Both of them have two network interfaces - one for Virtual DB IP (Virtual IP No. 2) which is visible for Asterisk servers S1 and S2, and one for local IP for interconnection [[Linux Heartbeat | heartbeat monitoring]]
* Both of them have two network interfaces - one for Virtual DB IP (Virtual IP No. 2), which is visible for Asterisk servers S1 and S2, and one for local IP for interconnection [[Linux Heartbeat | heartbeat monitoring]]
* LinuxHA heartbeat monitors servers, e.g.
* LinuxHA heartbeat monitors servers, e.g.
** When S3 fails - S4 sees that and after 10s (default) will take Virtual IP, it is done automatically
** When S3 fails, S4 sees that, and after 10s (default), it will take the Virtual IP; it is done automatically
** When S3 is back up - S4 returns Virtual IP to S3 and system starts to function in normal work flow (done automatically).
** When S3 is back up, S4 returns the Virtual IP to S3, and the system starts to function in normal workflow (done automatically).
** S1 connects to S3 over Virtual DB IP
** S1 connects to S3 over Virtual DB IP
* DBs on S3 and S4 are synchronized over MySQL Replication
* DBs on S3 and S4 are synchronized over MySQL Replication
Line 25: Line 25:


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

Latest revision as of 15:01, 20 February 2026

4 redundant with linuxha.jpg

Network setup

  • Best scenario when all 4 servers are on the same LAN (subnet).
  • Other possible solutions: Server 1 and 2 are on one LAN, Server 3 and 4 are on a different LAN (subnet). A VPN for better security from

servers 1 and 2 to servers 3 and 4 can be made.

  • If all 4 servers are on different LANs (subnets), then between servers, VPNs have to be configured. Drawback - such a setup

becomes too complicated for management.

  • If servers are in different countries (continents), it might cause latency problems, which has a negative influence on the speed of retrieving/inserting data to the DB (loading statistics, trying to retrieve some data, searching for a sound file, etc., will take longer than usual).

Workflow

  • Servers 1 and 2 (S1 and S2) are identical. They serve as gateways with Asterisk + MOR installed.
  • Both of them have two network interfaces - one for Virtual IP which is visible from outside, and one for local IP for interconnection heartbeat monitoring
  • LinuxHA heartbeat monitors servers, e.g.
    • When S1 fails - S2 sees that and after 10s (default) will take Virtual IP, e.g., will start to serve calls, it is done automatically
    • When S1 is back up, S2 returns the virtual IP to S1, and the system starts to function in normal workflow (done automatically).
  • Servers 3 and 4 (S3 and S4) are identical. They serve as a MySQL DB.
  • Both of them have two network interfaces - one for Virtual DB IP (Virtual IP No. 2), which is visible for Asterisk servers S1 and S2, and one for local IP for interconnection heartbeat monitoring
  • LinuxHA heartbeat monitors servers, e.g.
    • When S3 fails, S4 sees that, and after 10s (default), it will take the Virtual IP; it is done automatically
    • When S3 is back up, S4 returns the Virtual IP to S3, and the system starts to function in normal workflow (done automatically).
    • S1 connects to S3 over Virtual DB IP
  • DBs on S3 and S4 are synchronized over MySQL Replication


More info: