InfraAWSetcAWS Application Migration Service (MGN)

AWS Application Migration Service (MGN)

Introduction

우리는 IDC 데이터센터에 서버가 5대가 있는데,
오랫동안 사용하지 않은 홈페이지와 application이 들어있다.
이 서버들을 다른 용도로 사용하기 위해 OS를 다시 설치하기 전에 우선 기존에 있던 것을 백업하기로 결정했다.

수동으로 압축을 하거나 이미지를 떠서 AWS S3에 저장해놓고, EC2 instance에 다시 원복을 해보려고 했지만 워낙 on-premise와 AWS는 네트워크 환경 자체가 달라서 고려해야할 사항들이 생각보다 너무 많다.
그래서 AWS Application Migration Service을 이용해보기로 했다. AWS에서 줄여서 MGN이라고 부른다.

공식문서: https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html

AWS console에서는 default로 MGN은 비활성화되어있다.
→ Get Started를 누르는 순간 활성화가 되고, 이 순간 IAM role이 자동으로 7개가 생성됨
IAM 메뉴에 가면 service linked role 1개와 service roles 6개가 생긴다.

MGN의 첫 화면에 다음과 같은 문구가 나온다.

Add your source servers to this console by installing the AWS Replication Agent. Alternatively, you can add source servers without installing an agent on each guest server by installing the AWS vCenter client on your vCenter.

→ 즉, VM에 agent를 설치해도 되고, vCenter를 이용하면 설치 필요없음
우리는 VM에 agent를 설치하는 방식으로 할 것이다.

IAM user 생성

보안상 least privilege를 실현하기 위해 AWS console에서 IAM메뉴에 들어가 user를 생성하고 permission policy를 최소한으로만 준다. → AWSApplicationMigrationAgentPolicy → v1, v2 만 준다. → 그리고 access key를 생성하고 → access key와 secret access key를 복사해둔다.

Network architecture

On-premise의 각 VM에 agent를 설치하기 전에 subnet을 만들면 좋다. 이미 있는 기존의 subnet를 활용해도 되지만 공식문서 (https://docs.aws.amazon.com/mgn/latest/ug/preparing-environments.html)를 보면 새로 생성하는 것을 추천한다. 이 문서에는 있는 네트워크 구성도를 보자면


MGN안의 Replication template이란 것을 설정하고, VM에 agent를 설치하는 순간, 이관을 위한 EC2 instance가 생성되고, 443 포트로 전송이 되고 데이터를 1500 포트로 전송이 된다. 대부분 환경은 inbound는 제약을 걸지만 outbound는 제약이 없으니 새로 생성할 subnet에 443과 1500 port를 열어주면 된다. 그리고 S3에 업로드 권한도 준다.

좌측 메뉴 > Settings > Replication template > Edit → subnet, instance, SG 수정

Agent Installation

다시 MGN(Application Migration Service) 메뉴에 가서 Add Server를 누르고,
위에서 IAM에서 생성한 user의 accesskey와 secret access key를 입력하면
아래처럼 설치하라는 명령어가 2개 나온다.

이 5번 6번을 Source server에 설치하면 AWS console에 메뉴가 뜬다. → 6번 명령어는 10분 정도 걸린다.

나중에 필요하지만 Settings > Launch template도 설정해준다. → Replication template처럼 만들어질 Subnet 적용할 Security Group 등을 지정해주면 된다. → 미리 해놔야 아래 life-cyle 6단계에서 수정할 필요가 없다.

다시 좌측메뉴 > Source servers로 와서 서버 이름 클릭하면 migration dashboard에 migration lifecycle이 보인다.
총 6가지 상태가 있다.

위의 두 번째 명령어가 다 실행이 되면 MGN dashbaord에 Source server 목록들이 자동으로 뜬다.



위와 같이 5대 서버에서 모두 동시에 위의 2개 명령어를 실행해서 병렬로 걸어놔도 된다.
AWS console에서 EC2 메뉴로 들어오면

위와 같이 instance가 Replication template에서 정의한 것대로 새로 생긴 것을 볼 수 있다.

아무튼 위에 보이는 Initial sync가 가장 시간이 많이 걸린다. 각각 storage가 1Tb정도인데 평균 30시간씩 걸린다.

혹시나 취소하고 싶다면
server 선택하고 Disconnect 선택하고 → Actions > Archive 하고 → AWS CLI에서

❯ aws mgn delete-source-server \
  --region ap-northeast-2 \
  --source-server-id s-7e146b165b53ea6c4

Migration Life Cycle

Source server 를 클릭하면 Life Cycle이 6단계로 나오는데 이 순서대로 진행하면 된다.

총 6단계가 있다.
참고: https://docs.aws.amazon.com/mgn/latest/ug/adding-servers-gs.html

  1. Not ready – Initial sync가 진행되고 있는 상태이다. 마냥 기다려야한다.
  2. Ready for testing → Initial sync가 끝난 상태
  3. Test in progress → 우측 상단 메뉴에서 Launch test instances 클릭 (몇 분 소요)
  4. Ready for cutover – 우측 상단 메뉴에서 Mark as “Ready for cutover” 클릭 (몇 분 소요)
    상단에 뜨는 View job details를 클릭해서 진행 상황을 본다.
    400
    진행이 완료된 것을 확인하고 다음 단계로 넘어간다.
  5. Cutover in progress – 우측 상단 Launch cutover instances 클릭
  6. Cutover complete – 우측 상단에 Finalize cutover 클릭

Initial sync가 완료되면 차례대로 진행하면 된다. 가장 중요한 것은 위에서 말한 것처럼 Replication template과 Launch template인데, 이 두 가지만 제대로 설정해주면 쉽게 넘어갈 수 있다.


맨 마지막 단계까지 마무리하면 Disconnect 시키고, AMI로 백업을 뜨고 snapshot을 포함한 잔재들을 다 정리 삭제 시켜주면 된다.

우선 좌측 Settings에서 Launch template에서 subnet과 SG등을 맞게 수정한다.
Instance type right-sizing 설정은 instance 생성 즉시 삭제할 것이라면 상관없지만 자동으로 세팅하면 쓸데없이 큰 instance를 할당한다. 내 경우는 c5.9xlarge → t3.xlarge만 해도 충분하기 때문에 수동으로 바꿔줘도 된다.

Test and cutover에서 Launch test instances 클릭 → 팝업창에서 Launch