The Sreenidhi Institute of Science and Technology (or SNIST) is a technical institute located in Hyderabad, Telangana, India. It is one of the top colleges in Telangana. The institution is affiliated with the Jawaharlal Nehru Technological University, Hyderabad (JNTUH). In the year 2010-11, the institution attained the autonomous status and it is the first college under JNTUH to get that status. The institution is proposed to get Deemed university status from the year 2020-21.
SNIST was established in 1997 with the approval of All India Council for Technical Education, Government of Andhra Pradesh, and is affiliated to Jawaharlal Nehru Technological University, Hyderabad. SNIST is sponsored by the Sree Education Society of the Sree Group of Industries.
It runs undergraduate and postgraduate programs and is engaged in research activity leading to Ph.D. Sreenidhi is recognized by the Department of Scientific and Industrial Research as a scientific and industrial research organization.
The institution was accredited by the NBA of AICTE within 5 years of its existence. It has received world bank assistance under TEQIP
The Challenge:
We had some challenges while migrating the MYSQL database from On-prem to AWS using DMS (Database Migration Service (MySQL to MySQL)).
Shreenidhi has a huge amount of databases on their on-prem server we had some challenges while migrating their workload on AWS using DMS but DMA has some beautiful features so we did it in a short amount of time and in a very efficient way.
Problems on-prem DB server:
The customer has workload on-prem but The DB server was not functionally well it was getting suddenly down, timeout, they were not able to manage the on-prem DB workload, a huge amount of Application server workload hence Db server storage getting an increase, taking manual backup was a problem, ans storing it also was the problem to them, Customer was worried about if any disaster occurs then how they will get their data back?, also having problems with Patch-management, autoupgrade DB version, storing snapshots etc.
Business impact of customer:
The customer was getting a complaint from their customer due to application server was not working problem due to Db server, sometimes it happed that customer didn’t get the bill from the client due to that reason client got a huge amount to lose in their application.
Business impact was that customer was getting a huge number of costs. In Db server, administration cost, scaling cost, increasing storage capabilities manging it, and most Important was that customer getting huge impact on their severs.
Ther are some reasons that forces our customer to move AWS cloud .
Require extra IT support
Adherence to industry compliance
Increase maintenance costs
Increase the risk of data loss
Some other Challenges while migrating workload.
The database was homogenous so we didn’t get that many of problems while migrating.
- How large Database is?
- How many tables we have in each database?
- Do we have primary keys on all the existing tables?
- Do we have any identity columns?
- Do we use truncate tables? how frequently
- Do we have temporary tables?
- Do we have any column-level encryption?
- How often are DDL executed?
- How hot (busy) is your source database?
- What kind of users, role, and permission has with the source database?
- How database can be accessed (firewall, VPN)
Above are some challenges that we had to consider while migrating the database to AWS and that was so helpful for migrating the server to AWS
Provided Partner Solution:
Database migration serveice and how its works.
The below diagram will help us to understand how DMS work.
Above diagram will show how the DMS work here we have applied same rule to migrate on prem database to Aws that help us very much in a cost-effective way.
Sreenidhi has an on-prem database that we need to migrate using DMS service we had some POC before migrating the database workload to AWS RDS.
The client has many databases in this server so sometimes we got stuck with its on-prem environment we need to understand the structure of the database server and how it works in a normal way, how much load the server can handle this we need to take into consideration.
Migration Actions-
Migration Discovery/Assessment:
- During Migration Assessment, we review the architecture of the existing application, produce an assessment report that includes a network diagram with all the application layers, identifies the application and database components that are not automatically migrated, and estimates the effort for manual conversion work. Although migration analysis tools exist to expedite the evaluation, the bulk of the assessment is conducted by internal staff or with help from AWS Professional Services. This effort is usually 2% of the whole migration effort. One of the key tools in the assessment analysis is the Database Migration Assessment Report. This report provides important information about the conversion of the schema from your source database to your target RDS database instance. More specifically, the Assessment Report does the following:
- Identifies schema objects (e.g., tables, views, stored procedures, triggers, etc.) in the source database and the actions that are required to convert them (Action Items) to the target database (including fully automated conversion, small changes like the selection of data types or attributes of tables, and rewrites of significant portions of the stored procedure).
- Recommends the best target engine, based on the source database and the features used
- Recommends other AWS services that can substitute for missing features
- Recommends unique features available in Amazon RDS that can save the customer licensing and other costs Amazon Web Services Migrating Applications Running Relational Databases to AWS
Migration:
we made a plan to migrate the database to AWS
Prepared the source database server: (MYSQL)
- Create a user that will be used for replication with proper permissions.
- Modify mysql.cnf to allow replication.
- Allow the firewall/security groups to access this instance.
After preparing the source database server we prepare AWS infrastructure to migrate.
- Create VPC
- Created subnet
- Created route table
- Created IAM user with appropriate access
- Specified RDS storage and instance type
Created target Amazon RDS database:
Here we have species RDS instance with its size, networking, storage and network performance.
Created a replication instance:
Created replication instance which will replicate all the content of source database to target Database.
Create target and source endpoints:
Refresh the source endpoint schema
Created a migration task
Created source endpoint, a target endpoint, and a replication instance before creating a migration task.
- Endpoint type
- Engine type
- Server name
- Port number
- Encryption protocols
- Credentials
Determined how the task should handle large binary objects (LOBs) on the source
Specified migration task settings, Enabled, and run premigration task assessments before you run the task.
Monitor migration task
We can Monitor migration task using AWS DMS events and notifications, Task status,
Amazon CloudWatch alarms and logs, AWS CloudTrail logs, Database logs.
Using the above tool on AWS .
Monitoring replication tasks using Amazon CloudWatch:
We have used Amazon CloudWatch alarms, events to more closely track your migration.
The AWS DMS console shows basic CloudWatch statistics for each task, including the task status, percent complete, elapsed time, and table statistics, as shown following. We have Selected the replication task and then selected the Task monitoring tab.
The AWS DMS console shows performance statistics for each table, including the number of inserts, deletions, and updates, when you select the Table statistics tab.
After Migration benefits.
- Minimal Downtime:
AS compare to On-prem DB customers getting very little downtime on AWS RDS.
- Supports widely used databases:
Here in AWS customer can use many types of the database server if he wants to use and with very minimal cost and with effectiveness.
- Fast and easy setup:
A migration task can be set up within a few minutes in the AWS Management Console
Customers can now set up any database in a quick way if they want in the future now.
- Low cost:
The customer getting low cost as compare to the on-prem database. Now the customer is paying based on the amount of log storage and computational power needed to transfer.
- Reliable:
DMS is a self-healing service and will automatically restart in case of an interruption occurs. DMS provides an option of setting up a multi-AZ (availability zone) replication for disaster recovery.
Architecture Diagram
