아래 링크들은 MGN 실습 중 참고한 블로그다.
진행 자체는 그대로 따라가면 되는데... 세세한 부분에서 겪은 문제들을 정리할 예정이다.
MGN의 작동 흐름은 DMS와 유사하다.
source(서버)가 있고, 소스에서 데이터를 긁어서 받아두는 replication server가 있다.
그리고 replication server를 기반으로 target(서버. MGN에서는 cutover instance라고 한다)이 만들어진다.
흐름을 조금 더 자세히 설명하자면...
1. 소스 서버에 MGN 에이전트를 다운로드/설치한다(사실 설치보다는 실행이 맞는 표현이다).
2. 에이전트를 실행하면 MGN 콘솔의 source servers에 진행 상황이 표시된다.
3. replication server 실행까지 끝나면 Ready for testing 단계가 된다. 이후에는 상단의 Next action를 따라 각 단계를 착실히 진행하면 된다.
Source server에서 에이전트 실행
→ 에이전트 설치 및 replication server launch
→ Not ready
→ replication server 준비 끝나면(Data replication status 확인) Ready for testing 단계로 변함
→ Launch settings에서 시작 템플릿 설정
→ Launch test instances
→ Test in progress
→ test 끝나면 Mark as “Ready for cutover” 클릭
→ Launch cutover instance
→ Finalize cutover
대충 이런 흐름이다.
상세히 어떻게 흘러가는지는 상단의 블로그들에서 더 잘 설명해주고 있다.
내가 작성할 부분은 위 블로그들에서 언급하지 않은, 내가 겪은 오류들이다.
1. source server에 MGN Agent 설치하는 명령어는 어떻게 알지?
MGN 콘솔의 Source servers > Add servers로 이동하면 정보를 입력하는 항목들이 나온다.
소스의 OS/어떤 디스크를 마이그레이션할 것인지/소스에서 에이전트를 실행할 IAM 사용자의 Access key, Secret Access key를 입력.
그러면 하단에 에이전트 다운로드 명령어와 실행 명령어가 뜬다. 그냥 그걸 갖다붙여서 실행하면 된다.
※ MGN 에이전트 실행에 사용할 IAM 사용자에게 할당할 정책은 AWSApplicationMigrationAgentPolicy다.
2. replication template 설정하기
MGN 콘솔의 Settings > Replication template > Edit template를 클릭해 복제 서버의 설정을 진행한다.
1) 서브넷 : 맘대로 해라. 단, 소스 서버와 통신이 가능한지는 확인할 것.
2) 인스턴스 타입 : 넉넉하게 잡아라. 어차피 마이그레이션을 한달 내내 하는 것도 아니고 유형을 소심하게 잡아봤자 마이그레이션 오래 걸려서 답답하기만 하다.
3) 볼륨 : 상동. 대충 잡아라.
4) 보안 그룹 : 자동으로 적절한 보안 그룹을 생성해주는 옵션이 있는데, 이걸 선택하면 1500 포트만 열린다. 문서에서는 443 포트도 열어주라는데 왜 이러지? 그래서 그냥 443 포트도 열어줬다.
5) 데이터 라우팅 & 쓰로틀링 : 복제 서버에 퍼블릭 IP/프라이빗 IP를 어떻게 넣을 것인지 설정.
쓰로틀링은... 소스가 IDC 같은 곳에 있다면 마이그레이션 하겠다고 대역폭을 다 잡아먹어 다른 서버들이 맛이 가는 대참사가 벌어질 수 있으니 제한하는 것이 좋긴 하다.
서버 여러 개를 마이그레이션할 경우, 각 서버 작업마다 복제 서버의 설정을 다르게 하고 싶다면 Reinitialize service permissions를 실행하고 재설정을 해야 할 것 같다...?
※ 보안 그룹 설정 시 나는 귀찮아서 모든 대상(0.0.0.0/0)에 열어줬다. 하지만 열어줘야 할 대상을 특정해야 한다면 좀 까다로울 듯.
https://docs.aws.amazon.com/ko_kr/mgn/latest/ug/Network-Requirements.html
3. MGN Agent 삭제하기
- windows : C:\Program Files (x86)\AWS Replication Agent\dist에 있는 폴더를 다른 곳으로 옮긴 후 삭제(install_agent_windows.exe --remove)
- linux : /var/lib/aws-replication-agent/stopAgent.sh 실행 후 /var/lib/aws-replication-agent/install_agent --remove
4. Launch template 설정하기
복제 서버의 설정은 2번에서처럼 설정하지만, 테스트 인스턴스와 컷오버 인스턴스 설정은 별개다.
이 서버들은 시작 템플릿의 형식을 따르며, source servers 항목에서 진행 중인 작업의 Launch settings 탭으로 가서 설정해야 한다. 가보면 시작 템플릿이 알아서 생성되어 있으니, 수정해서 새 버전을 만든 후 버전 적용하면 끝.
시작 템플릿 설정 외에도 General launch settings에서 설정하는 부분도 있다. 여기에서 소스 서버의 프라이빗 ip를 그대로 컷오버/테스트 인스턴스 적용할 수 있는 방법도 있는데... 이 옵션을 쓸 것이라면 CIDR를 일치시켜야 하고, 그렇다면 VPN 연결은 할 수 없다는 의미다.
5. 소스 서버가 Ubuntu 22.04일 경우 에러 발생
실습 시 소스 서버를 AWS에서 AMI를 우분투 22.04로 골라 만들었는데...마이그레이션이 정상적으로 되지 않았다.
서비스(아파치)는 제대로 실행되지 않았고, 루트 사용자 전환은 드럽게 오래 걸리고...
이리저리 뒤져보니 디스크가 제대로 복제가 안된 것 같기도 하고 뭐 아무튼 문제가 많았다.
볼륨 용량 문제는 아니었다. 우분투 18.04로 해보니 바로 성공.
MGN docs에서는 12.04 이후 버전은 모두 지원한다고 하던데...docs라고 무조건 믿을 것도 아닌가 보다.
아무래도 실무에 적용할 경우 사전 테스트가 좀 필요할 것 같다.
나름 최신 OS라고 차이점이 좀 있는건지...
지원한다고 해놓고 이런 문제가 발생하니 믿을 수가 없네.
6. test instance/cutover instance에서도 서비스가 잘 작동하는지?
잘 작동해야 하는 것이 정상이다. 물론 도메인 연결은 좀 다른 문제겠지만 최소한 서버 내에서 작동하는 서비스들은 동일하게 작동해야 한다.
5번 문제로 고통받을 때 테스트/컷오보 인스턴스에 웹 접속이 안되길래 원래 이러나 싶었는데, 생각해보면 테스트/컷오버가 성공했다는 것을 확인하려면 서비스가 잘 작동되는 것이 정상이다.
7. 소스 서버가 WIndows 사용 시 라이센스 문제
라이센스 BYOL 문제로 윈도우 서버 마이그레이션 시 전용 호스트필요.
-> 비용 폭발
https://aws.amazon.com/ko/ec2/dedicated-hosts/
아니면 라이선스 모빌리티 필요
https://aws.amazon.com/ko/windows/resources/licensemobility/
소스 서버에서 상용 SW/솔루션 등을 사용하고 있다면 더더욱 복잡해진다.
사실상 Windows OS는 MGN 사용 불가능이라고 생각하는 것이 편하다.
당연한 것이지만...마이그레이션이라는 작업이 결정이 한 큐에 끝나고 작업도 한 큐에 끝나는 그런 종류의 일이 아니다.
기존 환경에 테스트 환경을 구성해놓지 않았다면 테스트마저도 본 서비스에 영향을 줄 수 있기에 신중해야 한다.
마이그레이션 한다고 해놓고 연락두절된 고객이 한둘이 아니다.
'AWS' 카테고리의 다른 글
EC2 관리하기 : 자동 백업, 자동 재부팅, 자동 재실행 (0) | 2024.01.18 |
---|---|
Mountpoint for Amazon S3 정식 출시 및 테스트 (1) | 2023.08.23 |
AWS CodeDeploy 실습 중 이모저모 (0) | 2022.10.25 |
Linux/Windows CloudWatch Agent 설치 (0) | 2022.08.09 |
MongoDB with AWS Marketplace (0) | 2022.07.11 |
댓글