Decoupled Architecture

Within MiaRec's decoupled architecture, each software component (recorder engine, database, web portal, storage) is deployed on a dedicated server. As an option, the components may be duplicated to achieve full redundancy and/or scalability. Decoupled architecture is recommended for recording 2000 or more users. The following diagram shows the extreme case when at least two copies of each component are deployed on their own dedicated server (master/slave or multi-master) to achieve full redundancy.

Besides such extreme cases, MiaRec supports other configurations with a partial share of hardware resources with some other components. For example, for a small-scale deployment in a hosted environment, we recommend you isolate a recording server as the minimum requirement. The rest of the components may share hardware resources on the second server. This two-server setup provides a good balance between security (isolation of a critical recording server) and cost (sharing of hardware resources by other components).

Nowadays virtualization is a preferred deployment method for new software. In a virtual environment, it is significantly cheap to spin up additional VMs and isolate components from each other to achieve reliability, security, and scalability.

Such architecture allows you to achieve the following goals:

• Redundancy: All components are duplicates to eliminate single-point-of-failure issues. Some of these components support master/master, others support master/slave configuration with a floating IP address mechanism.

• Performance: The software components do not contend for the same server resources (CPU, Memory, I/O, etc.)

• Scalability: Multiple recording and web servers can be deployed for load balancing purposes. The additional servers could be easily added to the solution to cover customer growth. MiaRec software architecture provides the almost linear scalability of individual components. For example, if the bottle-neck is a web portal, then you just need to spin up an additional VM with web application.

• Reliability: The components are isolated from each other. In a hosted environment, it is important to isolate recording servers from web servers in order to prevent potential disruption of service due to occasional spikes in web traffic. With such architecture, the issues with some of the components are not propagated to other components. In the worse case, you may have a slowdown of the web portal, but the recording process will not suffer from such issues, and you will not lose any recordings due to CPU/disk/network overload.

• Security: In a hosted environment, it is important to keep recording and database servers in a private network isolated from end-user-facing web servers. A potential breach of the webserver will not spread to other servers.

Hardware specification recommendations

Different components have different requirements for hardware. For example, the MiaRec recording server benefits the most from multiple CPU cores and does not benefit at all from additional memory (for example, recording 500 concurrent sessions consumes less than 1GB of memory, but requires a 16-core CPU). The database server benefits the most from SSD disks with high-speed random access. The web portal doesn't benefit from SSD disks, but it benefits from additional memory. Below you will find recommendations on the hardware specification of each individual component.

Recording server hardware requirements

We recommend one recording server (or virtual machine) for each 500 concurrently recorded sessions (equivalent to approximately 5,000 users in a Hosted PBX environment). MiaRec recording engine has exceptional performance, and can record 1,000 and more concurrent sessions on a single server; we recommend you keep an average load of 500 concurrent sessions per server in order to have enough room for potential spikes in load.

When using audio file encryption, the recommendations are one server per 250-300 concurrently recorded sessions.

Small server configuration (about 1,000 users per recorder server):

CPU	4 cores or more. Frequency of at least 2.26GHz.
Memory	16 GB or more
Storage	2 hard disks using RAID 1 for storing OS, binary files, and log files. The minimum free disk space is 300GB (for log files). 2 high-speed hard disks (10K or 15K RPM) using RAID 1 for the temporary storage of audio files for in-progress calls. The minimum free disk space is 300GB. (*)

 

Large server configuration (about 10,000 users per recorder server):

CPU	12 cores or more. Frequency of at least 2.26GHz.
Memory	32 GB or more
Storage	2 hard disks using RAID 1 for storing OS, binary files, and log files. The minimum free disk space is 300GB (for log files). 2 high-speed hard disks (10K or 15K RPM) using RAID 1 for the temporary storage of audio files for in-progress calls. The minimum free disk space is 300GB. (*)

 

(*) - For performance reasons, it is recommended that you store audio files for in-progress calls locally on the server. The audio file will be moved to the network-attached storage at the end of each call.

In addition to performance reasons, this solution provides another layer of protection to prevent network failures. In case there are network connection issues due to the NAS, the recorder process may continue to record calls, and store audio files locally till the connection to the NAS server is recovered.

Database server requirements

One or two database servers (PostgreSQL) in master/slave configuration using floating IP failover mechanism.

CPU	2 cores or more. Frequency of at least 2.26GHz.
Memory	32 GB or more
Storage	Solid state drives (SSDs) using RAID 1 or RAID 10 with free space 3GB for each 1M records stored in a database

 

Web application server requirements

One or more web application servers are required for load balancing and redundancy purposes. Each of the servers hosts web portals as well as worker processes for the task manager. The task manager is used to execute various maintenance tasks like export, backup, replication, retention, etc. The workers on multiple web application servers form the pool of workers, i.e. the tasks are automatically distributed over multiple application servers for redundancy and load balancing purposes. The recommended number of web servers depends on anticipated pages/s web requests load. For a hosted PBX environment a rough estimate is one web server per 5,000 users.

CPU	4 cores or more. Frequency of at least 2.26GHz.
Memory	16 GB or more
Storage	2 hard disks using RAID 1 for storing OS, binary files, and log files. The minimum, free disk space is 150GB (for log files).

 

Web load balancer requirements

The web load balancer (HAProxy) is required when two or more web servers are deployed. The load balancer server itself may be duplicated to eliminate a single point of failure situation. Switchover between load balancing servers is implemented using the floating IP mechanism.

CPU	2 cores. Frequency of at least 3.00GHz.
Memory	4 GB
Storage	Storage is not critical because HAProxy is a mostly CPU-consuming process (single thread). 64GB of disk storage for OS, application binary files, and logs should be enough.

 

Message Broker server requirements

One or two servers in master/slave configuration for message queue system. The message queue system is used for internal communication between various components of the MiaRec solution.

CPU	2 cores or more. Frequency of at least 2.26GHz.
Memory	16 GB or more
Storage	2 hard disks using RAID 1 for storing OS and binary files (64GB) 2 high-speed hard disks (10K or 15K RPM) using RAID 1 for persistent storage of messages with free space of at least 64GB.

 

Network-attached storage (NAS) for audio files

MiaRec stores audio files in compressed MP3 format. Default compression settings are 0.24MB/minute of recording.