June 22, 2016
Migrating from VMware to AWS
Migrating from VMware to AWS – Case Study
About a year ago, our management has set a goal to move all organization’s mission-critical servers to the Amazon Web Services cloud to enable our geographically distributed teams to work seamlessly, securely, and safely. At that time, all our servers were based on VMware vSphere.
The migration from VMware to AWS project has started.
VMware to AWS Migration
At the first stage of VMware to AWS migration, it was necessary to assess the resources needed at AWS for each server: disk capacity, CPU, and RAM. The particularity of instances (an instance is a VM in Amazon terms) is that you cannot buy an exact amount of CPU GHz and GB of RAM. AWS provides a few dozen types of instances with a fixed amount of resources. The objective was to choose the right type of instances, based on the usage statistics of each server.
Structure of Payments for Amazon Web Services (AWS)
Here I want to describe the structure of your payments for Amazon Web Services.
Firstly, the payment depends on the type of your instances. AWS only offers fixed sets of physical resources of CPU and RAM, meaning that you cannot buy an exact amount of CPU or RAM. You can choose from a dozen sets of instances (an instance is a VM in Amazon terms) and select the type of instance that is suitable for you. For example, it might be the t2.micro instance with 1 vCPU and 1 GB of RAM or the m4.2xlarge instance with 8 vCPU and 32 GB of RAM.
Secondly, you need to pay for an operating system. There are various operating systems offered by AWS, including Linux, SLES, RHEL, and Windows (with or without SQL installed). In addition, Amazon has its own Marketplace, which offers different types of operating systems with preinstalled applications that are available for free or for a charge.
Moreover, you need to pay for the amount of used storage. The price is based per GB. There are several types of storage, such as general purpose SSD-based volumes, SSD-based volumes with guaranteed IOPs, and specific types of SSD disk layout, which are more suitable for databases and other specific applications.
As a result, the final payment for your instance will be based on the type of instance (CPU and RAM resources), size and type of storage, and the OS you will run.
Secure Access to Services Running in AWS
A separate issue was secure access to services running in AWS. Placing a server on the Internet and providing access to it directly through a real IP is quite risky from a security standpoint. Therefore, I decided to set up two networks in AWS – an internal network without Internet access, where all the servers would be placed, and an external network with Internet access. A software router, which is also a VPN server, runs between these two networks. Thus, in order to obtain access to the servers, it is necessary to connect to the VPN. Basically, AWS has its own solution for the VPN access, but it has an extra cost.
There are two ways to approach VMware to AWS migration:
– Create new instances with a required operating system, install required software, and transfer databases, configuration settings, etc. from source servers
– Migrate an existing VM(s) via AWS services
Amazon provides a set of well-documented tools for migrating VMs from a VMware vSphere environment to AWS. It is possible to understand the whole process in a couple of hours, nothing is really complicated.
As a result, all the servers were successfully migrated to the AWS, and local VMs were powered off. Users have started working with IT services through a permanent VPN connection to AWS.
This way, we implemented the task of hosting servers in Amazon EC2 and arranged a secure encrypted access to the resources.
Backup and Recovery of EC2 Instances
Logically, the next step was backup and recovery of instances.
In terms of backup, AWS provides a mechanism for creating snapshots. Snapshots are created not for a whole instance, as it is done in VMware vSphere, but just for disks connected to the instance. Snapshots must be created for each individual disk. This means that if you have 5 instances and 20 disks are connected to each instance, you have to make 100 snapshots. Snapshots can be created manually or by using scripts launched by tools offered by AWS.
While analyzing the existing solutions for automated backups, we saw that all of the proposed solutions simply create scheduled snapshots. No solution offered a backup outside of the AWS infrastructure.
Being a backup company, we could not be satisfied only with the creation of snapshots. NAKIVO started developing a solution that would allow storing backups of AWS instances locally, on the client’s site. The solution would allow restoring an instance from a locally stored backup in any AWS region.
EC2 Instance Protection in NAKIVO Backup & Replication
Recently, NAKIVO Backup & Replication has developed a solution for EC2 instance protection. In version 6, NAKIVO Backup & Replication allows performing AWS instance backups and storing them anywhere: in the same Amazon region, a different Amazon region, or even in your office.
Adding EC2 instances to the Inventory is as easy as adding a VMware vCenter server. You just need to enter an access key ID and a secret access key from your AWS account, instead of IP and credentials for VMware vCenter.
Then, you should deploy a Transporter in the EC2 region that you need to backup. You just need to choose an instance type for a new Transporter and its region.
The Transporter will be deployed automatically. Basically, the t2.small instance type is enough for it to handle small to mid-size environments. After a Transporter is deployed, you are ready to create a backup job. The process is the same as for VMware.
Overall, you will just need 5-10 minutes to add an AWS account to the Inventory, deploy a Transporter in EC2, and create and run a backup job of AWS instance. You do not need to do anything in the AWS admin console. All actions required upon VMware to AWS migration are performed in the NAKIVO Backup & Replication web interface.