In 2020, the year of COVID, we all realized that business continuity challenges are more than real.
In a world full of unpredictable events, such as COVID pandemic, any business should be literally ready for anything. It does not matter if we speak about a busy holiday season in e-commerce when the systems are overloaded or about shifting to remote work or about environmental disasters that can destroy physical servers of the company.
Businesses must be ready to maintain the same level of continuity in any situation and be able to recover from any distarers quickly and resiliently. With cloud solutions, such as Amazon Web Services (AWS) or Azure, maintaining business continuity has become easy and accessible. Using cloud solutions, it is possible to ensure the failover of even the most complex and high load system.
Business Continuity Challenges for one of the Biggest EHS vendors
This is the story of our company’s business continuity maintenance quest for one of our most loyal clients, Cority (Enviance), a Canadian EHS vendor. We have been developing the Environmental compliance management system for our client for more than 15 years already, and in this context migration to the cloud was just the question of time.
What is an Environmental compliance management system ? In the essence, it is a multifunctional system which any business can use “to track and record emissions, make reports, automate workflow, manage numerous tasks and documents within a single system.”
The questions of security, compliance, and quality standards have always hada paramount level of importance for Cority (Enviance) which works with the companies from the Fortune 500 list. Business continuity and disaster recovery policies are the key element of the cooperation between our companies that is why we research and test top-notch approaches and solutions in this sphere.
Today cloud solutions are regarded as the most progressive and secure by Gartner and other industry analysts including IDC,TechRepublic,TechTarget. That is why it was decided to switch to the most cost-effective and reliable cloud service for.
“By 2024, more than 45% of IT spending on system infrastructure, infrastructure software, application software and business process outsourcing will shift from traditional solutions to cloud.”(Gartner)
Before the Cloud
Working with Cority (Enviance), we have the primary site (the data center where the servers are set up and deployed environments for development and testing) which we use for the service provision to the client and the disaster recovery site (DR site). In case of any emergency situation on the primary site, Softengi is supposed to switch to the DR site.
Before choosing cloud solutions for Cority (Enviance), Softengi had a DR site (standby server) located in a secure place in other country. In case of any emergency situation, environmental crisis or physical damage of the on-premise servers, the DR site would be activated within the next 6 hours.
Nevertheless, this solution was less cost-effective, secure, and reliable for the obvious reasons, that is why we researched the most effective cloud alternatives.
AWS vs Azure. How we chose cloud vendor
There are several options of cloud providers but the main battle is often fought between AWS vs Azure. Both vendors offer a wide range of internal services and which are different in terms of the location of the servers and the prices.
Our task was to replicate virtual servers from Hyper-V hypervisor to the cloud with maximum efficiency and minimal costs. To perform an effective and successful cloud migration the team set a number of goals:
- Creation of the roadmap for the replication of virtual servers from Hyper-V into the cloud. We were using Hyper-V for the virtualization of resources and we didn’t want to change it.
- Assessment of the existing options on the replication of virtual machines from Hyper-V into the cloud
- Preparation. Cost assessment
- Network configuration.
- Utilization of FortiGate+ AWS for highest security level
- Launch of the extended replica server on DR site.
- Creation of the access to AWS through the VPN tunnel
- Failover testing
Having analyzed the task and the services offered by AWS and Azure, we decided to go with AWS for 9 reasons:
- One of the main reasons for choosing AWS Server Migration is the fact that it is possible to pay only for the repositories which are used during the migration process. AWS permits the most efficient resource consumption.
- Another reason for choosing AWS is the possibility to launch all the capacities of the DR site within the next 4 hours after the incident.
- The possibility to use ECV for the Hyper-V replication.
- Remote access to the DR site via VPN is another tangible benefit
- Secure data transfer to the DR site in the cloud with the help of FortiGate, which is considered one of the most reliable firewalls.
- Continuous data replication to the AWS cloud.
- Transparency: the team uses VPN to switch their activities to the DR site.
The Peculiarities of Process of Migration to the Cloud: a Cost-Effective Approach
As it was mentioned, the main reason for the choice of AWS was cost-efficiency. We could use only those resources that we actually needed. For instance, for the replication we chose a small capacity machine, while for testing and development we use the machines with large memory, storage, and networking capacity. We can only use it for a short period of time, such as testing or failover, and thus, pay only for this time.
Most often the migration to cloud starts with a single virtual machine or testing environments if we speak about the software development. We chose the same way. Firstly, we transferred 30% of our infrastructure (it’s a domain controller, testing environment and the infrastructure monitor system). For the virtual machines we chose SSD (GP2) class of storage and S3 Glacier to store backup copies of virtual machines.
The DR site was located in Frankfurt and based on AWS t2.medium EC2 instance, Windows Server 2019 with Hyper-V installed. It acts as a Hyper-V extended replica server that receives altered data from the primary site and keeps replicated virtual machines up to date.
Inside AWS we were working with the on-demand instances.
The peculiarity of our cloud migration process is that we chose the type of instance that consumes minimum resources, but cannot use the hardware-based capabilities of the Hyper-V.
In this case we cannot launch virtual machines inside of the EC2 instance, and we use this instance only for the replication. When there is a need to run replicated machines we follow the scenario of shifting to the dedicated server – bare metal instance (m5.metal), which has virtualization capabilities to launch the replicated virtual machines in the Hyper-V.
- Creation of AMI image from the Hyper-V extended replica server.
- Deployment of the “bare metal” instance from the recently created image.
- Detach of the EBS volume from the replica server which contains the files of the replicated machines.
- Attach of the EBS volume to the “bare metal” instance.
- Launch of the failover for each replicated virtual machine.
- Configuration of the virtual machines (CPU, RAM and Network)
- Start of the virtual machines
- Connection of the team to the DR site over VPN
Monitoring FortiGate activity looks in the following way:
This approach allows us to spend resources efficiently: we save money by avoiding working with the constantly launched “bare metal” instance which is much more expensive.
The choice of AWS cloud service as a DR site was the most optimal, and, what is even more important for the client, the most cost – effective approach. Using AWS we don’t have redundant resources, we pay only for the resources we actually use, and this is a rock solid argument for cloud migration of any business.