Deploying MiaRec on Amazon AWS (up to 2,000 users)

1. Network architecture

This guide provides step-by-step instructions for deployment of MiaRec call recording software on Amazon AWS.

MiaRec on AWS can leverage many of the services that are designed with High Availability. Depending on anticipated capacity, we recommend two types of HA architecture:

  • Basic HA with two EC2 instances in all-in-one configuration (*). Recommended for up to 2,000 subscribers.
  • Advanced HA with dedicated EC2 instances for each of components. Recommended for more than 2,000 subscribers.

(*) All-in-one configuration means recorder, database, web application and other components are hosted on the same virtual server.

This guide describes the Basic HA setup for recording of up to 2,000 subscribers. The recommended network architecture for MiaRec on AWS is shown in the following diagram.

Components:

  • Two EC2 instances (Virtual Servers) hosting MiaRec software in all-in-one configuration.

  • S3 (Cloud Storage) for long term storage of recorded audio/video files.

  • Route 53 service (Managed Cloud DNS) for DNS failover

High Availability characteristics:

  • Server Redundancy. In the proposed architecture, we have two independent MiaRec servers (EC2 instances). These instances are configured in Hot Standby mode. When the primary server fails, the secondary server is switched into operation. The instances are deployed in different Availability Zones (covered in this guide) or Regions.

  • Data Redundancy. Configuration and call metadata is stored in database. The recorded files are stored in file system. Database data is replicated asynchronously between two MiaRec instances. The audio/video files are uploaded to Amazon S3 storage, which provides replication and redundancy.

  • Auto Failover mechanism. Amazon Route 53 service monitors the health and performance of MiaRec instances. Using DNS failover, it can route the web traffic from an unhealthy instance to a healthy one. For SIPREC traffic, we recommend to use DNS SRV-based failover if the phone platform supports it (DNS SRV-based failover will minimize downtime). If DNS SRV is not supported by phone platform, then it is possible to use Router 53 DNS failover mechanism for SIPREC traffic.

Frequently asked questions:

Why not use DNS round-robin for web traffic load balancing?

Round Robin DNS works by responding to DNS requests with a list of potential IP addresses corresponding to several web servers that host identical resources. The DNS server returns a list of IP addresses in random order.

DNS round robin works the best for load balancing. Failover scenarios are not recommended due to how browsers handle multiple addresses. Modern browsers will choose one of IP addresses and if it cannot connect, the browser will try the next server. the process is user-transparent, and occurs only if the first server tried times out, and only for the first page requested from our site in any browser session. If one of the servers is down for long time, then 50% of users will receive its IP address the first in a list, they will experience high load time (about 3 minutes) for the first page. Older browsers (like IE7) do not support switching to the second IP address, i.e. 50% of users on old browsers will not be able to access the web server (many web-sites today do not support old web browsers, so, this fact probably can be ignored).

Another drawback of DNS round robin technique comes from how MiaRec replicates data between instances. DNS round robin works the best with stateless servers. In this guide, we build stateful MiaRec server, which includes database in the same machine. Data between machines is replicated asynchronously. Asynchronous replication has a lot of advantages comparing to synchronous replication, but there is the expected delay in data synchronization. For example, MiaRec synchronizes only the completed calls. The in-progress calls will be visible on of servers only. If using DNS round robin, then 50% of users will not be able to see in-progress calls.

DNS SRV vs DNS failover for SIPREC traffic

If the phone platform supports DNS SRV for SIPREC, then it should be used as a preferred method. With DNS SRV, the phone platform receives a list of IP-addresses with priorities. The IP-addresses will be tried in particular order depending on record priority/weight. If one of servers does not respond, then the second one will be tried automatically.

The phone platform determines that server is not available based on its SIP response. DNS SRV-based failover time is shorter than DNS failover. The Amazon Route 53 DNS failover uses health checks, which are good for web servers, but they cannot check health of SIP devices.

Depending of implementation, the phone platform can preemptively monitor each of IP-addresses using SIP keep alive mechanism (usually, send SIP OPTIONS message) and make failover time even shorter.

Why upload audio/video files to S3 instead of storing them locally on EC2 instance?

Short answer: costs and reliability.

According to official documentation "Amazon EBS volumes are designed for an annual failure rate (AFR) of between 0.1% - 0.2%, where failure refers to a complete or partial loss of the volume, depending on the size and performance of the volume." Amazon S3 is designed to deliver 99.999999999% durability (documentation).

Amazon EBS volume data is replicated across multiple servers in an Availability Zone. With Amazon S3 data is automatically distributed across a minimum of three physical facilities that are geographically separated by at least 10 kilometers within an AWS Region, and Amazon S3 can also automatically replicate data to any other AWS Region.

EBS costs are $0.10 per GB/month (US East Region, General Purpose SSD). S3 storage costs are $0.023 per GB/month (US East Region, first 50TB).

How to scale this architecture?

The architecture described supports vertical scaling, i.e. the EC2 instance can resized to larger CPU/memory values. You must stop your Amazon EBS–backed instance before you can change its instance type.

How big is a delay in synchronization between servers?

Data is replicated asynchronously. The replication process can be configured to start either by schedule or continuously. In the latter case, call recording metadata and file will be replicated as soon as call completes. Other configuration data, like users/groups/roles will be replicated as soon as the next recording is replicated or up to 1 minute after a change, if call traffic is low.

What happens if the primary server is down?

This is probably the most important question in this guide.

When the primary server is down, then failover mechanism is initiated. Amazon Route 53 service monitors the health and performance of MiaRec instances. If it detects that one the primary server is unhealthy, then DNS records are updated to point to the secondary server. The web traffic will be automatically loaded to the secondary server.

Failover for SIPREC traffic is managed independently of web traffic failover. The phone platform reds a list of IP addresses of recording servers from DNS SVR record. It automatically route SIPREC traffic to the secondary server if the primary server doesn't respond to SIP requests.

If the server is down completely, then both SIPREC and web traffic will be automatically routed to the second instance. This scenario is straight forward. But there is a potential situation when only one of software components experiences issues. For example, web server is not responding on the primary server, but recorder service is fully functioning. In this case, the failover occurs only for web traffic. Such loosely coupled architecture (independence in web and siprec failover events) has some pros and cons. Good thing in MiaRec architecture is it allows the recorder service to continue recording of calls even if other components, like database and web server are completely down. This guarantees that the most critical part of call recording platform is as robust as possible. If, for example, both servers experience problems with the web component, the recording process is not affected at all. In order to detect such enormous situations with partial failure, it is necessary to utilize monitoring tools like CloudWatch, Zabbix or similar.

How much data may be lost in case of primary server is down?

Data between servers is replicated asynchronously by schedule or continuously. In the later case, call metadata will be uploaded to other server as soon as call completes.

If there were in-progress call recordings on the primary server before it died, then such calls will be recorded only partially. If disk storage of the primary server is recovered later, then it is possible to recover the first portion of media for such in-progress calls. The replication process will be restored automatically after the server is alive again.

If the disk storage of the primary server is unrecoverable, then data for in-progress recordings as well as data of not-uploaded yet recordings is lost.

2. Create VPC

A virtual private cloud (VPC) is a virtual network that closely resembles a traditional network that you'd operate in your own data center, with the benefits of using the scalable infrastructure of Amazon Web Services (AWS). You have complete control over your virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways.

In this guide, we will create a dedicated VPC for MiaRec cluster.

Create VPC

To create a VPC:

  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
  2. In the dashboard, choose Your VPC and click Create VPC button.
  3. Choose the name which will help you to identify it later in the console.
  4. We use 10.0.0.0/16 for the CIDR block and leave tenancy as default if we don't require dedicated hardware. For more information about IPv4 and IPv6 addressing, see IP Addressing in Your VPC
  5. Click Yes, Create.

MiaRec on AWS

Create subnets

Now let's create two subnets in different Availability Zones. We will deploy two MiaRec instances in different Availability Zones for redundancy. An Availability Zone is a logical data center in Amazon AWS. Each zone has redundant and separate power, networking and connectivity to reduce the likelihood of two zones failing simultaneously.

To create subnets:

  1. In the VPC Dashboard, choose Subnets and click Create Subnet button.
  2. Choose the name
  3. Associated this subnet with the previously created VPC.
  4. Select different different Availability Zones for each of subnets.
  5. We use 10.0.1.0/24 for one subnet and 10.0.2.0/24 for the second

MiaRec on AWS

MiaRec on AWS

In this example, we created two subnets:

Subnet name Availability Zone IPv4 CIDR block
miarec-public-10.0.1.0 us-east-1a 10.0.1.0/24
miarec-public-10.0.2.0 us-east-1b 10.0.2.0/24

Create Internet Gateway

Up to now all our subnets are private. We need to create Internet Gateway. An Internet gateway is a virtual router that connects a VPC to the Internet. An Internet gateway serves two purposes: to provide a target in your VPC route tables for Internet-routable traffic, and to perform network address translation (NAT) for instances that have been assigned public IPv4 addresses.

To create Internet Gateway:

  1. In the VPC Dashboard, choose Internet Gateways and click Create Internet Gateway button.
  2. Choose the name
  3. Click Yes, Create
  4. Select the newly created Internet Gateway from the list and click Attach to VPC to associate it with your MiaRec VPC.
  5. Click Yes, Attach

MiaRec on AWS

MiaRec on AWS

MiaRec on AWS

Associate subnets with Route Table

Now we need to associate the subnets with Route Table.

  1. Navigate to Route Tables in VPC Dashboard.
  2. Select the existing route table associated with your newly created VPC.
  3. Press the Subnet Associations tab on the bottom section. Click Edit.
  4. Select the subnets and click Save

MiaRec on AWS

MiaRec on AWS

Configure default gateway

We need to add a custom route table for destination 0.0.0.0/0 and Internet Gateway as a target. This will allow our machines to communicate to public Internet, for example, to download software updates.

  1. Navigate to Route Tables in VPC Dashboard.
  2. Select the existing route table associated with your newly created VPC.
  3. Press the Routes tab on the bottom section. Click Add another route
  4. Create Destination 0.0.0.0/0 with the newly created Internet Gateway as a Target.

MiaRec on AWS

Next step

3. Create EC2 instances

We are going to launch two EC2 instances and install MiaRec software on them. These two instances will be created in different Availability Zones for redundancy.

To create EC instance:

  1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2
  2. Select Instances in the left pane and click Launch Instance

Step 1. Choose an Amazon Machine Image (AMI)

Select Ubuntu Server 14.04 LTS, EBS General Purpose (SSD) Volume Type.

MiaRec supports the following operating systems:

  • Centos 6
  • Centos 7
  • Ubuntu Server 14.04 LTS
  • Ubuntu Server 16.04 LTS.

MiaRec on AWS

Step 2. Choose an Instance Type

Amazon EC2 provides a wide selection of instance types optimized to fit different use cases. Instances are virtual servers that can run applications. They have varying combinations of CPU, memory, storage, and networking capacity.

For MiaRec, we recommend Compute Optimized instances. Refer to the following table for instance type recommendations. These recommendations are based on average system usage (10 calls per day per user, 5 minutes average call duration). Actual hardware requirements may be differ in your case.

Max subscribers Instance Type vCPU Memory (GiB) Storage On-demand, Monthly * 1-Year Term, No Upfront, Monthly *
250 c4.large 2 3.75 GiB EBS only $72.00 $45.99
500 c4.xlarge 4 8 GiB EBS only $143.28 $91.98
1,000 c4.2xlarge 8 15 GiB EBS only $286.56 $183.96
2,000 c4.4xlarge 16 31 GiB EBS only $573.12 $367.92

(*) - The provided pricing as of data of article (Septempter, 2017) for US-East region, Linux host (Centos/Ubuntu/Amazon Linux).

More than 2,000 users? We recommend to use a decoupled architecture instead of all-in-one setup.

MiaRec on AWS

Step 3. Configure Instance Details

Choose separate subnets for each of two MiaRec instances. This will allow to deploy them in different Availability Zones for redundancy.

Shutdown behavior should be set to Stop.

We recommend to Enable termination protection as a protection from accidental deletion of server.

MiaRec on AWS

Step 4. Add Storage

Specify the desired disk storage size for EBS volume.

  • As a Volume Type select General Purpose SSD as a minimum. For high load, it is possible to select Provisioned IOPS SSD (it is more expensive, but provides guaranteed I/O performance).

Imporant!. Uncheck Delete on Termination. This will allow you to detach this EBS volume from EC2 instance and attach to new one, for example, with better hardware specs.

Disk storage will be used for:

  • OS and application files
  • Database data files, approximately 3GB per 1 million records in database
  • Application logs
  • Temporary location for audio files (before the files are uploaded to S3 for long term storage). 0.24 MB/minute in MP3 stereo format. We recommend to keep available disk space for at least 3 days of data. In case of issues in upload process to S3, it gives enough time to administrator to troubleshoot and fix issue. This will make the system less dependent on S3 availability.
Number of users Avg calls/day/user Avg duration Total minutes/day Storage/day Recommended EBS volume
50 10 5 min 75,000 min 18 GB 100 GB
100 10 5 min 150,000 min 36 GB 150 GB
250 10 5 min 375,000 min 90 GB 320 GB
500 10 5 min 750,000 min 180 GB 600 GB
1,000 10 5 min 1,500,000 min 360 GB 1,200 GB
2,000 10 5 min 3,000,000 min 720 GB 2,400 GB

MiaRec on AWS

Step 6. Configure Security Group

A security group is a set of firewall rules that control the traffic for your instance.

MiaRec application requires the following ports to be opened:

  • TCP 22 for SSH inbound connection
  • TCP 80 and 443 for web server
  • TCP 6554 and UDP 7000-7999 for live monitoring (optional)
  • TCP/UDP 5080 for SIPREC signaling and UDP 20000-23999 for RTP media (these port values can be changed in MiaRec web admin portal)

Important!. In the following example, SIPREC and RTP ports are opened to all sources (0.0.0.0/0). For security reasons, access to these ports should be limited to your phone only. Specify there the IP-addresses, from which your phone system sends SIPREC and RTP traffic.

MiaRec on AWS

Create SSH keys

When you launch an instance, you should specify the name of the key pair you plan to use to connect to the instance. You can use Amazon EC2 to create your key pair. Alternatively, you could use a third-party tool and then import the public key to Amazon EC2.

If you use Amazon to create your key pair, then you have to download the private key file (*.pem file) and store it in a secure and accessible location. You will use this key to access the instance via SSH.

MiaRec on AWS

Check status of running instances

Navigate to Instances section of EC2 Dashboard to see your new instance running.

MiaRec on AWS

Next step

4. Configure Elastic IP address

An Elastic IP address is a public IPv4 address, which is reachable from the Internet. An Elastic IP address is associated with your AWS account. With an Elastic IP address, you can mask the failure of an instance or software by rapidly remapping the address to another instance in your account.

We need to create an Elastip IP address for each MiaRec instance as both of them will be accessible from the Internet.

To allocate Elastic IP address:

  1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2
  2. Select Elastic IP address in the left pane and click Allocate new address
  3. Once the IP address is allocated, select it in a list and choose Associate address from Actions drop-down.
  4. Associate the IP address with EC2 instances.
  5. Repeat these steps for the second EC2 instance.

MiaRec on AWS

MiaRec on AWS

MiaRec on AWS

5. Install MiaRec software on EC2 instance

We will deploy MiaRec to Amazon EC2 instances using Ansible provisioning tool.

You need to follow the step-by-step instructions "Installation on Linux using Ansible" with a few additions described below.

You can run Ansible playbook from:

  • Any Linux host with Internet access (Ubuntu, Centos, Redhat). Mac OS X should work as well, but not tested by us.
  • Windows 10 with Linux subsystem
  • Another EC2 instance.

Copy SSH private key to Ansible Controller machine

You need to use previously created key to access the instance via SSH. Check Connecting to Your Linux Instance Using SSH for details.

Copy the private key to the Ansible Controller machine, for example, to ~/.ssh/aws-key.pem.

Use the chmod command to make sure that your private key file isn't publicly viewable:

chmod 400 ~/.ssh/aws-key.pem

Test SSH connection to EC2 instance:

ssh -i ~/.ssh/aws-miarec.pem ubuntu@34.235.2.126

If everything is ok, you should see the following message the first time you connect to it:

The authenticity of host '34.235.2.126 (34.235.2.126)' can't be established.
ECDSA key fingerprint is SHA256:uTU/hyG+7qy1Aq0CxliKekYDWXZI0EEAaPkmXuA9K9M.
Are you sure you want to continue connecting (yes/no)?

Enter yes. You should connect to the instance now and see Ubuntu welcome message like:

Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 3.13.0-125-generic x86_64)

* Documentation:  https://help.ubuntu.com/

System information as of Fri Sep 22 01:32:04 UTC 2017

System load:  0.0                Processes:           103
Usage of /:   0.6% of 125.86GB   Users logged in:     0
Memory usage: 2%                 IP address for eth0: 10.0.1.65
Swap usage:   0%

Create Inventory file (/opt/ansible-miarec/hosts)

In the step [3. Configure deployment] of instructions, you will need to create hosts file. If you selected Ubuntu as OS for EC2 instance, then create the following file:

miarec1 ansible_ssh_host=1.1.1.1 ansible_ssh_private_key_file=~/.ssh/aws-key.pem ansible_port=22 ansible_user=ubuntu
miarec2 ansible_ssh_host=2.2.2.2 ansible_ssh_private_key_file=~/.ssh/aws-key.pem ansible_port=22 ansible_user=ubuntu

[miarec]
miarec1
miarec2

Where:

  • Two hosts are defined inside group miarec. Ansible playbook will be executed against all hosts in group. By default, installation will be done simultaneously.
  • Replace 1.1.1.1 and 2.2.2.2 with public ip-addresses of your EC2 instances (these should point to Elastic IP addresses created previously).
  • The parameter ansible_ssh_private_key specifies the location of SSH private key for connecting to EC2 instance (in our example, it is ~/.ssh/aws-key.pem).
  • The parameter ansible_user is set to ubuntu for Ubuntu system. For Centos, you need to set it to root.

Now, test Ansible connection to AWS using the command:

 ansible miarec -m shell -a "uname -a" 

This command will connect to all hosts in group miarec in inventory file and print the output of command uname -a.

You should see something like:

miarec1 | SUCCESS | rc=0 >>
Linux ip-10-0-1-65 3.13.0-125-generic #174-Ubuntu SMP Mon Jul 10 18:51:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

miarec2 | SUCCESS | rc=0 >>
Linux ip-10-0-2-73 3.13.0-125-generic #174-Ubuntu SMP Mon Jul 10 18:51:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Deploy MiaRec to EC2 instances

Follow instructions to deploy MiaRec on EC2 instances using Ansible.

Verify MiaRec web portal and create admin account

Navigate in web browser to the Elastic IP address of each of MiaRec instances, like http://1.2.3.4.

When you access MiaRec web portal the first time, it will ask you to create admin account. You need to create unique accounts for these two servers, like "admin" and "admin2". This is necessary to prevent conflicts during synchronization between servers.

MiaRec on AWS

Next steps

6. Configure Route 53 DNS Failover for web traffic

Amazon Route 53 service monitors the health and performance of MiaRec instances. Using DNS failover, it can route the web traffic from an unhealthy instance to a healthy one.

Prerequisites:

  • Your domain name has to be managed by Amazon Route 53, otherwise it will not be possible to use DNS Failover. You can register new domain name for your MiaRec HA cluster or use existing one.

Create Hosted Zone

  1. Sign in to the AWS Management Console and open the Amazon Route 53 console at https://console.aws.amazon.com/route53/.
  2. In the navigation pane of the Route 53 console, choose Hosted zones, and then choose Create Hosted Zone.
  3. Enter the registered domain name into Domain Name. In this guide, we use domain miarecorder.com as an example.

MiaRec on AWS

Create A-records for MiaRec servers (miarec1 and miarec2)

We need to create DNS A-record for each of our MiaRec servers. In this example, we use "miarec1" and "miarec2", but you can name it whatever you want.

Name Type Alias TTL Value Routing Policy
miarec1 A No 300 x.x.x.x Simple
miarec2 A No 300 y.y.y.y Simple

Where:

  • x.x.x.x is the Elastic IP address (public) of the first MiaRec instance
  • y.y.y.y is the Elastic IP address (public) of the second MiaRec instance

To create A-records:

  1. In the navigation pane of the Route 53 console, choose Hosted zones, select the domain name, and then choose Create Record Set.
  2. Choose A - IPv4 address for Type.
  3. Enter Elastic IP address of the MiaRec EC2 instance into Value field.
  4. Choose Simple for Routing Policy
  5. A default TTL value is ok
  6. Repeat these steps for the second MiaRec EC2 instance.

MiaRec on AWS

Create Health checks for MiaRec web servers

For DNS Failover, we need to configure health checks for each of servers.

For each MiaRec instance:

  1. In the navigation pane of the Route 53 console, choose Hosted checks, select the domain name, and then choose Create health check.
  2. Choose a convenient name, like "miarec-www-primary" and "miarec-www-secondary".
  3. Choose Domain name from Specify endpoint by options.
  4. Choose HTTP for Protocol (this option should be HTTPS if HTTP is disabled)
  5. Enter the DNS name of the MiaRec EC2 instance, in our example, domain names are "miarec1.miarecorder.com" and "miarec2.miarecorder.com".
  6. Choose 80 for Port
  7. Enter "login" for Path (this health check will verify if login page is accessible).
  8. Keep other settings as default.
  9. Repeat these steps for the second MiaRec EC2 instance.

MiaRec on AWS

In a couple of minutes, you should be able to see health check report as shown in the following screenshot.

MiaRec on AWS

Create DNS A-record for web traffic (with failover)

Now, we are going to create DNS A-record, which will be used by end users for accessing MiaRec web portal, something like "recordings.mycompany.com". We will configure DNS Failover for this record. Amazon Route 53 services will route web traffic to the secondary server, when health check for the primary server returns error.

Create two records with the following settings:

Name Type Alias TTL Value Routing Policy Failover Record Type Set ID Health Check to Associate
recordings A No 60 x.x.x.x Failover Primary recordings-Primary miarec-www-primary
recordings A No 60 y.y.y.y Failover Secondary recordings-Secondary miarec-www-secondary

Where:

  • x.x.x.x is the Elastic IP address (public) of the first MiaRec instance
  • y.y.y.y is the Elastic IP address (public) of the second MiaRec instance

To create A-records with DNS Failover, repeat for each MiaRec instance:

  1. In the navigation pane of the Route 53 console, choose Hosted zones, select the domain name, and then choose Create Record Set.
  2. Choose A - IPv4 address for Type.
  3. Select 60 for TTL. Recommended value is between 30 to 60 seconds. Each client caches DNS records. In case of failover, the web browser may attempt to access the unhealthy instance until cache expires.
  4. Enter Elastic IP address of the MiaRec EC2 instance into Value field.
  5. Choose Failover for Routing Policy
  6. Choose Primary for the first instance and Secondary for the second instance for Failover Record Type
  7. Choose a convenient name for Set ID
  8. Associate this record to the corresponding health check, created previously.
  9. Repeat these steps for the second MiaRec EC2 instance.

Below screenshots, demonstrate configuration of Record Set for both MiaRec instances.

MiaRec on AWS

MiaRec on AWS

Test DNS failover

Navigate in web browser to http://recordings.yourdomain.com.

Login as administrator and navigate to Administration -> Maintenance -> Recording Servers. You should see the private IP address of this instance. This information allows you to determine on which instance you are now. The primary instance should be in a subnet 10.0.1.x and the secondary in 10.0.2.x.

MiaRec on AWS

Now, simulate failure using one of the following methods:

  • Stop Apache web server using SSH (on Ubuntu the command is sudo service apache2 stop, on Centos it is sudo service httpd stop).
  • Shutdown the server via SSH using command sudo shutdown -h now
  • Stop instance via Actions menu in Amazon EC2 Dashboard.

Try to access MiaRec web portal using web browser. It may take a few minutes for Amazon Route 53 to detect server failure (by default, it checks the server health every 30 seconds and requires at least 3 consecutive failures before the server is marked unhealthy). Once the server is marked unhealthy, the domain name http://recordings.yourdomain.com is automatically routed to the secondary MiaRec instance IP-address. If the TTL value is reasonably small (no more than 60 seconds), then failover should shortly after that.

Within 3-4 minutes, you should be able to access the MiaRec web portal again. Login as administrator and navigate Administration -> Maintenance -> Recording Servers to check on which instance you are now.

MiaRec on AWS

Now, restore the primary server and verify if web-traffic is routed back to it after 3-5 minutes.

7. Configure DNS SRV for SIPREC traffic

The SRV record is a Domain Name System (DNS) resource record that is used to identify servers that host specific services. Each of servers is assigned a priority and weight, which allows to use DNS SRV for failover, load balancing or both. In this guide, we use DNS SRV for failover purposes only. For load balancing, we recommend to use different architecture (decoupled).

To create DNS SRV records in Route 53:

  1. In the navigation pane of the Route 53 console, choose Hosted zones, select the domain name, and then choose Create Record Set.
  2. Choose SRV - Service locator for Type.
  3. Enter the following data into Value field:

    1 10 5080 miarec1.yourdomain.com
    2 10 5080 miarec2.yourdomain.com
    

    Here, we configure two servers with priority 1 and 2 correspondingly. In this configuration the phone platform will always use the miarec1.yourdomain.com server (priority 1) unless it is not healthy.

  4. A default TTL value is ok

  5. Choose Simple for Routing Policy

The following screenshot demonstrates the configuration of DNS SRV:

MiaRec on AWS

8. Configure SIPREC recording

Configure SIPREC recording interface in MiaRec

We need to configure public ip-address in each of MiaRec instances. MiaRec will advertise this ip-address to the phone platform in SDP media description info (ip-address and port on which it expects to receive RTP packets from the phone platform).

Navigate in MiaRec web portal to Administration -> System -> Recording Interfaces -> SIPREC -> Configure.

Configure the Elastic IP address in each of two MiaRec instances. See below screenshot for details:

MiaRec on AWS

Configure SIPREC recording interface in your phone platform

Refer to the corresponding documentation for your phone platform.

References:

Test recording

Make some test calls and locate the recordings in MiaRec web portal.

Test SIPREC failover

Simulate failure on the primary server (shutdown instance or stop "miarec" service) and verify if recording is switched over to the secondary instance.

9. Configure automatic file relocation to Amazon S3

1. Create an S3 bucket

  1. Sign in to the AWS Management Console and open the Amazon S3 console at https://console.aws.amazon.com/s3/.

  2. Choose Create bucket.

    MiaRec on AWS

  3. In the Bucket name field, type a unique DNS-compliant name for your new bucket. (The example screen shot uses the bucket name miarec-s3-storage. You cannot use this name because S3 bucket names must be unique.) Create your own bucket name using the follow naming guidelines:

    • The name must be unique across all existing bucket names in Amazon S3.
    • After you create the bucket you cannot change the name, so choose wisely.
    • Choose a bucket name that reflects the objects in the bucket because the bucket name is visible in the URL that points to the objects that you're going to put in your bucket.

    For information about naming buckets, see Rules for Bucket Naming in the Amazon Simple Storage Service Developer Guide.

  4. For Region, choose the region where you want the bucket to reside. You can use the same region as you were using for VPC in previous steps.

    MiaRec on AWS

  5. At the step 3. Set permissions, make sure that public access is not granted.

    MiaRec on AWS

  6. Click Create bucket in the last screen.

2. Create policy that grants access to the S3 bucket

  1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.

  2. In the navigation pane on the left, click Policies and then click Create Policy.

    MiaRec on AWS

  3. Next to Create Your Own Policy, click Select.

    MiaRec on AWS

  4. Copy the following access policy and paste it into the Policy Document field. And replace miarec-s3-storage with your bucket name).

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::miarec-s3-storage"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::miarec-s3-storage/*"
            ]
        }
    ]
    }
    

    MiaRec on AWS

3. Create IAM user

  1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.

  2. In the navigation pane on the left, click Users and then click Add user.

    MiaRec on AWS

  3. On Details screen, choose User name and enable Proigrammatic access.

    MiaRec on AWS

  4. On Permissions screen, select Attach existing policies directly and then select the previously created policy from the list. Use the search box to find the policy by name.

    MiaRec on AWS

  5. Review the settings and click Create user.

    MiaRec on AWS

  6. On Complete screen, copy Access Key ID and Secret access Key and store them in secure place. We will use it for configuring storage target in MiaRec.

    MiaRec on AWS

4. Add Cross-Origin Resource Sharing (CORS) configuration to an S3 bucket

Cross-Origin Resource Sharing (CORS) allows client web applications that are loaded in one domain to interact with resources in another domain. This configuration is required for our setup because MiaRec web application is accessible using one domain (for example, https://recorder.example.com), but audio files are located at Amazon S3 domain (https://s3.amazonaws.com)

To add a CORS configuration to an S3 bucket:

  1. Sign in to the AWS Management Console and open the Amazon S3 console at https://console.aws.amazon.com/s3/.

  2. In the Bucket name list, choose the name of the bucket that you want to create a bucket policy for.

    MiaRec on AWS

  3. Choose Permissions, and then choose CORS configuration.

    MiaRec on AWS

  4. Copy the following CORS configuration and paste it into the CORS configuration editor field:

    <?xml version="1.0" encoding="UTF-8"?>
    <CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <CORSRule>
        <AllowedOrigin>*</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <MaxAgeSeconds>3000</MaxAgeSeconds>
        <AllowedHeader>*</AllowedHeader>
    </CORSRule>
    </CORSConfiguration>
    

    MiaRec on AWS

  5. Choose Save.

5. Configure Storage Target in MiaRec

  1. Navigate in MiaRec web portal to Administration -> Storage -> Storage Targets and choose Add.

  2. Select Amazon S3 in Storage Target Type. Configure S3 Bucket, AWS Access Key ID and AWS Secret Access Key accordingly (as configured in the previous steps).

    MiaRec on AWS

6. Configure automatic file relocation to S3 storate target

  1. Navigate in MiaRec web portal to Administration -> Storage -> Relocate Recording files and choose Add job.

  2. Configure Storage Target. Change Mode to Incremental. Select scheduler setting Run this job to Continuously (optionally, you can configure a scheduled relocation, for example, at night).

    MiaRec on AWS

    Make a few test calls and check status of this job. It is expected that files are automatically relocated to S3.

    MiaRec on AWS

    Navigate to Amazon S3 console and verify that files are located there:

    MiaRec on AWS

10. Configure MiaRec replication

Documentation is in progress... Please, check later or contact our Support Team anytime.

11. Configure HTTPS for web server

Documentation is in progress... Please, check later or contact our Support Team anytime.

12. Configure CloudWatch monitoring

Documentation is in progress... Please, check later or contact our Support Team anytime.

13. Disaster recovery plan

Documentation is in progress... Please, check later or contact our Support Team anytime.