In another project based on a real-world scenario, I acted as the Cloud Specialist responsible for migrating a workload running in a Corporate Data Center to AWS.
The application and database were migrated to AWS using the Lift & Shift (rehost) model, moving both application and database data.
Migration steps:
Planning: sizing, prerequisites, resource naming
Implementation: resource provisioning, best practices
Go-live: validation test — Dry-run, final migration — Cutover
Post Go-live: ensuring the operation of the application and user access
The client provided information and files for the application and the database to migrate from the on-premise environment to the AWS cloud.
Python Web — Wiki Server Application: Prerequisite python packages and libraries for the application to be run successfully on the AWS EC2 application server are determined.
MySQL 5.7 Python Web — Wiki DB Server: Size, host/server name, IP address, CPU, and necessary description are provided to migrate it to the Amazon RDB server.
Create an EC2 instance with a new Security Group and Key Pair (.pem): EC2 instance(AMI: Ubuntu 18.04) within the previously launched VPC network was created.
Key pair was created while creating the EC2 instance and downloaded to the desktop. It is necessary to connect remotely to the EC2 instance from the desktop via ssh.
Security Group was created and configured to open a port so that we can access the services running on the virtual machine. A new security rule was added for the application to be accessed over the internet only port 8080.
Pre-requisites steps: It should be connected to the EC2 instance using ssh and pair-key which was downloaded before in “.pem” format. It is important to prepare the EC2 instance to make the application work properly on it. Required python packages and libraries were installed as determined in the planning step.
Set the permissions of your private key so that only you can read it. chmod 400 key-pair-name.pem
This is broken into two steps, the validation (dry run) and the cutover.
Validation(dry-run):
The on-premises resources should be up and running at this stage. Once the validation is completed successfully, a downtime window can be scheduled when the business is not running and run the final migration switching from the on-premise environment to the cloud (cutover).
1) Database and 2) application deployment resources from the on-premises environment were exported and 3) put in an AWS S3 bucket. Then we can transfer files from the S3 bucket to related subnets in VCP. It is connected to the EC2 instance and opened remote connectivity from the local computer.
4) The application deployment files were imported to the EC2 instance.
$ ssh ubuntu@ -i
:8080
Cutover: It is the next step of the On-Live process. So, in a production environment, we can schedule the downtime to bring the actual data from the on-premises environment, import the data, and make sure that the on-premises database and application are down. Once it is done we can switch from the on-premises environment to the AWS completely.
Last step of migration. We should make sure there is no problem after go-live. Stability, ongoing support; access, performance, integration. Ongoing support can continue for 2 weeks, more or less depending on the complexity of the application.
The above is the detailed content of Migration of a Workload running in a Corporate Data Center to AWS using the Amazon ECnd RDS service. For more information, please follow other related articles on the PHP Chinese website!