DR and Migration

By October 4, 2019 Case Study, Migration

Customer: Matrimony.com

Problem Statement

Until recently, an online matrimony service provider Matrimony.com implemented
traditional disaster recovery through a secondary data center in Mumbai. The
business needed a technology infrastructure that could both keep up with demand
and help drive further growth. Purchasing duplicate storage, compute and
connectivity resources for the secondary location as its business scaled, translated
to additional cost burden — all of which might never actually be used. Given the
“always-on” nature of the business it was of paramount importance that the
application availability remains high. Keeping all the above factors into
consideration, the business decided to leverage the benefits of the public cloud by
migrating their core matrimony applications to AWS.

Proposed Solution

After thorough evaluation, Matrimony.com engaged Powerup and decided to use
AWS to build its business continuity and DR solution.

The approach – A pilot with DR

After thorough evaluation, it was decided to use AWS to build its business continuity
and DR solution with a ‘Pilot-light’ DR strategy was chosen and a minimal
environment of the entire DC setup to be run on AWS. All applications, database
and High Availability (HA) proxy instances were replicated to instances of minimal
size to optimize cost — a classic backup-and-restore scenario. AWS allows
maintenance of a pilot-light model by configuring and running only the most critical
core elements of a system. When required in case of a recovery, one can rapidly
provision a full-scale production environment around the critical core by upgrading
the instances.

Powerup built a replica of all required servers and launched it using AWS
CloudFormation (CF) templates. For Matrimony.com, the legacy applications
required Powerup to use the same IP addresses in the new environment as well.
Powerup used Asymmetric routing mechanism to accommodate multiple IP
addresses and resolve connectivity issues on the secondary IP addresses. Load
balancers were required to have custom static private IPs to accommodate legacy
applications. However, Elastic Load balancer did not support this. To resolve this
issue, Powerup set up highly available HAProxy as an alternative to the internal load
balancer traffic with Keep-Alive. Keep-alive, when enabled, allows the load balancer
to reuse connections to the instance, which reduces the CPU utilization. In this case,
failover support was enabled between two HA Proxy servers by load balancing
between DC and DR for periodic application check. Code commit was used to update
the code to both DC and DR environments simultaneously.

Powerup complied with customer data centre security guidelines and the migration
was successful. Multiple VPCs were created for production, recovery and
management applications. All application servers were migrated using AWS Server
Migration Service(SMS) by replicating server VMs as cloud-hosted Amazon Machine
Images (AMIs) ready for deployment. Lambda was used to trigger the creation of
new AMIs. Database servers were deployed on EC2, replicated using native
replication techniques. The Configuration of the environment is automated by AWS
CF templates.

Cloud platform

AWS.

Technologies used

EC2, CloudFormation, Lambda, S3, AWS SMS-Migration tool, DMS, ELB/ALB, VPC.

Leave a Reply