Difference between revisions of "M4 System Architecture"
| (5 intermediate revisions by 2 users not shown) | |||
| Line 8: | Line 8: | ||
<br><br> | <br><br> | ||
= | = Single-server solution (up to 500 cc) = | ||
[[File:A.png]] | [[File:A.png]] | ||
| Line 21: | Line 21: | ||
<br><br> | <br><br> | ||
= | = 2-server solution (up to 2000 cc) = | ||
Signaling/Media separated from Processing(Core)/Management(GUI)/Database | Signaling/Media separated from Processing(Core)/Management(GUI)/Database | ||
| Line 35: | Line 35: | ||
<br><br> | <br><br> | ||
= | = 4-server redundant solution (up to 2000 cc) = | ||
[[File:B-R.png]] | [[File:B-R.png]] | ||
CPS/Concurrent Calls same as in the system without redundancy. If GUI uses slave DB, then CPS/CC can be higher compared to the system without redundancy. | CPS/Concurrent Calls same as in the system without redundancy. | ||
If GUI uses slave DB, then CPS/CC can be higher compared to the system without redundancy. | |||
<br><br> | <br><br> | ||
= | = 3-server solution (up to 2500 cc) = | ||
Signaling/Media + Processing(Core)/Database + Management(GUI) | Signaling/Media + Processing(Core)/Database + Management(GUI) | ||
| Line 56: | Line 58: | ||
<br><br> | <br><br> | ||
= | = 3-server solution with MySQL Replication (up to 2500 cc) = | ||
It is almost identical to the previous one but with Slave DB for the GUI. | |||
[[File:B3.png]] | [[File:B3.png]] | ||
| Line 71: | Line 73: | ||
<br><br> | <br><br> | ||
= | = 4-server solution with partial redundancy and MySQL Replication (up to 2500 cc) = | ||
[[File:B3-R.png]] | [[File:B3-R.png]] | ||
| Line 84: | Line 86: | ||
<br><br> | <br><br> | ||
= ( | = Scalable multi-server solution (up to 10 000 cc) = | ||
N is Media (RTPEngine) servers, each one can handle media streams for ~4000 concurrent calls. | |||
[[File:C.png]] | [[File:C.png]] | ||
| Line 93: | Line 95: | ||
* Concurrent Calls with Media Proxy: N x 4000 (max N=3. CC 10000) | * Concurrent Calls with Media Proxy: N x 4000 (max N=3. CC 10000) | ||
* Concurrent Calls without Media Proxy: 10000 | * Concurrent Calls without Media Proxy: 10000 | ||
* Concurrent Calls (CC) with transcoding can be from 1200 to 8400, depending on Codecs/CPU/NIC. [[M4 Codec Transcoding | More details]] | |||
NOTE: Heavy GUI usage (report generation/analysis, etc) will reduce CC/CPS. | NOTE: Heavy GUI usage (report generation/analysis, etc) will reduce CC/CPS. | ||
| Line 98: | Line 101: | ||
<br><br> | <br><br> | ||
= | = Scalable multi-server solution with redundancy (up to 10 000 cc) = | ||
[[File:C-R.png]] | [[File:C-R.png]] | ||
<br> | <br> | ||
CPS/Concurrent Calls same as in the system without redundancy | CPS/Concurrent Calls same as in the system without redundancy. | ||
If GUI uses slave DB, then CPS/CC can be higher compared to the system without redundancy under the same GUI usage. | |||
If there are 2 Core servers, Proxy will connect to the second Core server if the main one is offline. | |||
Max Core servers: 2 | |||
Proxy servers can be > 2 | |||
<br><br> | <br><br> | ||
= 4-server geo-redundant solution between two data centers with two active IPs = | |||
[[File:4-server geo-redundant solution between two data centers with two active IPs.jpg|780px]] | |||
<br> | |||
* Two active media servers can accept traffic at the same time | |||
* Data synchronization between two DCs through MySQL replication | |||
* Traffic distribution is controlled by client through DNS SRV | |||
* In case of DC1 main DB/GUI/CORE server failure, the backup server on DC2 will be activated and whole system will be operational | |||
* In case of DC1 SIP server failure, DC2 SIP server will be operational and traffic from the CD1 SIP server can go to it and vice versa. | |||
<br><br> | |||
= See also = | = See also = | ||
* [[Recommended hardware]] | * [[Recommended hardware]] | ||
* [[M4 Codec Transcoding]] | * [[M4 Codec Transcoding]] | ||
Latest revision as of 05:44, 10 September 2024
Each box/rectangle represents 1 real hardware server, not a virtual machine (VM).
If you want to design the system with VMs, take note of how many real servers are used.
You can have many VMs but if they are all on the same hardware server - there will not be enough processing power to handle the load.
All elements can be on the VMs, but the results will vary case by case.
Single-server solution (up to 500 cc)
- CPS: 100
- Concurrent Calls (CC) with Media Proxy (media goes over the system): 500
- Concurrent Calls (CC) without Media Proxy (media goes directly between originator and terminator): 1000
- Concurrent Calls (CC) with transcoding can be from 400 to 500, depending on Codecs/CPU/NIC. More details
NOTE: Any GUI usage will reduce CC/CPS a lot. Not recommended for production, only for light testing.
2-server solution (up to 2000 cc)
Signaling/Media separated from Processing(Core)/Management(GUI)/Database
- CPS: 300
- Concurrent Calls with Media Proxy: 2000
- Concurrent Calls without Media Proxy: 4000
- Concurrent Calls (CC) with transcoding can be from 400 to 2000, depending on Codecs/CPU/NIC. More details
NOTE: Heavy GUI usage (report generation/analysis, etc) will reduce CC/CPS.
4-server redundant solution (up to 2000 cc)
CPS/Concurrent Calls same as in the system without redundancy.
If GUI uses slave DB, then CPS/CC can be higher compared to the system without redundancy.
3-server solution (up to 2500 cc)
Signaling/Media + Processing(Core)/Database + Management(GUI)
- CPS: 500
- Concurrent Calls with Media Proxy: 2500
- Concurrent Calls without Media Proxy: 5000
- Concurrent Calls (CC) with transcoding can be from 400 to 2500, depending on Codecs/CPU/NIC. More details
NOTE: Heavy GUI usage (report generation/analysis, etc) will reduce CC/CPS.
3-server solution with MySQL Replication (up to 2500 cc)
It is almost identical to the previous one but with Slave DB for the GUI.
- CPS: 500
- Concurrent Calls with Media Proxy: 2500
- Concurrent Calls without Media Proxy: 5000
- Concurrent Calls (CC) with transcoding can be from 400 to 2500, depending on Codecs/CPU/NIC. More details
NOTE: GUI usage will not impact CC/CPS at all.
4-server solution with partial redundancy and MySQL Replication (up to 2500 cc)
- CPS: 500
- Concurrent Calls with Media Proxy: 2500
- Concurrent Calls without Media Proxy: 5000
- Concurrent Calls (CC) with transcoding can be from 400 to 2500, depending on Codecs/CPU/NIC. More details
NOTE: GUI usage will not impact CC/CPS at all.
Scalable multi-server solution (up to 10 000 cc)
N is Media (RTPEngine) servers, each one can handle media streams for ~4000 concurrent calls.
- CPS: 1000
- Concurrent Calls with Media Proxy: N x 4000 (max N=3. CC 10000)
- Concurrent Calls without Media Proxy: 10000
- Concurrent Calls (CC) with transcoding can be from 1200 to 8400, depending on Codecs/CPU/NIC. More details
NOTE: Heavy GUI usage (report generation/analysis, etc) will reduce CC/CPS.
Scalable multi-server solution with redundancy (up to 10 000 cc)
CPS/Concurrent Calls same as in the system without redundancy.
If GUI uses slave DB, then CPS/CC can be higher compared to the system without redundancy under the same GUI usage.
If there are 2 Core servers, Proxy will connect to the second Core server if the main one is offline.
Max Core servers: 2
Proxy servers can be > 2
4-server geo-redundant solution between two data centers with two active IPs
- Two active media servers can accept traffic at the same time
- Data synchronization between two DCs through MySQL replication
- Traffic distribution is controlled by client through DNS SRV
- In case of DC1 main DB/GUI/CORE server failure, the backup server on DC2 will be activated and whole system will be operational
- In case of DC1 SIP server failure, DC2 SIP server will be operational and traffic from the CD1 SIP server can go to it and vice versa.
