[ ]에서 가상 서버의 마이그레이션 일정을 계획하기 IBM Cloud VPC

가상 머신( VM ) 간의 종속성을 파악하고, 진행 속도를 예측하며, 애플리케이션 스택에 대한 전환 기간을 계획함으로써 IBM Cloud VPC 로의 마이그레이션 단계를 수립하십시오.

종속성 계획

마이그레이션 작업을 시작하기 전에 다음 애플리케이션 종속성을 매핑해야 합니다:

티어 기반:

  • 웹 티어 → 앱 티어
  • 앱 티어 → 데이터베이스 티어
  • 데이터베이스 계층 → 공유 스토리지 및 서비스

교차 애플리케이션:

  • 인증
  • 모니터링
  • 백업
  • 로그 집계
  • DNS 및 NTP

검색을 위한 도구:

  • VMware vRealize Network Insight ( ) vRNI
  • 애플리케이션 종속성 매핑 도구
  • 네트워크 흐름 분석
  • 애플리케이션 소유자의 수동 문서

각 가상 서버에 대해 마이그레이션 계획에 다음 정보를 기록합니다:

  • 인바운드 종속성
  • 아웃바운드 종속성
  • 공유 자원

테스트 마이그레이션 웨이브 설계

첫 번째 마이그레이션 웨이브는 테스트(파일럿) 웨이브입니다. 성공적인 테스트 웨이브를 구현하려면 다음 정보를 준수해야 합니다:

가상 서버를 올바르게 표현합니다:

  • Linux 단일 디스크 가상 서버
  • 다중 디스크 기반 Linux 가상 서버
  • 단일 디스크 Windows 가상 서버
  • 멀티 디스크 Windows 가상 서버
  • 종속성이 있는 애플리케이션(3티어 앱)

'최소 위험' 옵션을 사용합니다:

  • 비프로덕션 환경에서 마이그레이션을 구현합니다. 또는 유지 관리 기간이 긴 프로덕션 환경을 사용하세요.
  • 애플리케이션의 롤백 절차를 파악하세요.

전체 마이그레이션을 수행합니다:

  • 선택한 방법에 대한 전체 엔드투엔드 테스트
  • 참고 마이그레이션 타이밍과 예상 타이밍 비교
  • 테스트에서 발견되지 않은 문제 발견

성공적인 마이그레이션 기준:

  • 모든 가상 서버가 성공적으로 시작됨
  • 애플리케이션이 올바르게 작동합니다
  • 네트워크 연결 확인
  • 성능 기준 충족 또는 초과
  • 데이터 손실 또는 손상 없음
  • 마이그레이션 문서가 완전하고 정확합니다

웨이브 구조 가이드라인

서브넷 기반 그룹화:

VMware 와 VPC 사이에는 서브넷을 확장할 수 없다는 점을 기억하세요. 즉, 다음 작업을 수행해야 합니다:

  • 서브넷별로 가상 서버 그룹화
  • 전체 서브넷을 한 번에 마이그레이션하거나 일부 가상 서버의 IP를 다시 지정해야 하는 경우
  • 서브넷과 VPC 서브넷 매핑을 조기에 계획하세요

다계층 애플리케이션을 위한 애플리케이션 스택 그룹화:

  • 가능하면 전체 스택을 한 번에 마이그레이션하세요.
  • 마이그레이션 규모가 너무 크면 데이터베이스에서 먼저 마이그레이션한 다음 앱 순으로 마이그레이션하세요.
  • IBM Cloud Transit Gateway 를 통해 마이그레이션된 계층과 마이그레이션되지 않은 계층 간의 연결성을 유지하십시오.

종속성 인식 시퀀싱을 위한 애플리케이션 스택 그룹화:

  • 인프라 서비스(DNS, 모니터링, 백업)를 먼저 마이그레이션하세요.
  • 필요한 애플리케이션보다 먼저 공유 서비스를 마이그레이션하세요.
  • 각 웨이브의 효과를 고려하고 실패할 경우 미치는 영향을 고려하세요.

병렬 마이그레이션 기능:

방법 3 라이브 네트워크 전송(규모에 권장됨)은 여기에서 탁월합니다:

  • 여러 작업자 가상 서버 인스턴스 프로비저닝
  • 여러 가상 서버를 동시에 마이그레이션하기
  • 네트워크 대역폭 및 워커 가상 서버 인스턴스 리소스에 의해 제한됨
  • 일반: 작업자 가상 서버 인스턴스당 4~8개의 동시 마이그레이션 가능

테스트 웨이브 예제 구조

다음 예는 50개의 가상 서버 마이그레이션을 보여줍니다.

웨이브 0(테스트): 가상 서버 5개

  • 1x 단일 디스크 Linux (방법 1 테스트)
  • 1x 멀티 디스크 Linux (방법 2 테스트)
  • 1x 단일 디스크 Windows(방법 1, sysprep 사용)
  • 1x 멀티 디스크 Windows(방법 2, virt-v2v )
  • 1x 3단계 테스트 앱(방법 2 및 3, 전체 스택)

웨이브 1(인프라): 가상 서버 8개

  • DNS 서버
  • 서버 모니터링
  • 점프 호스트 또는 바스티온 서버
  • VPC 파일 스토리지로 마이그레이션한 공유 파일 서버

웨이브 2(애플리케이션 A): 12개의 가상 서버

  • 데이터베이스 계층(가상 서버 3개)
  • 앱 티어(가상 서버 6개)
  • 웹 티어(가상 서버 3개)
  • 서브넷 10.50.10.0/24 → VPC 서브넷 10.240.10.0/24

웨이브 3(애플리케이션 B): 가상 서버 10개

  • 데이터베이스 및 앱 티어 결합(가상 서버 4개)
  • 웹 티어(가상 서버 6개)
  • 서브넷 10.50.20.0/24 → VPC 서브넷 10.240.20.0/24

웨이브 4(애플리케이션 C): 가상 서버 15개

  • 대규모 멀티티어 애플리케이션
  • 서브넷 10.50.30.0/24 → VPC 서브넷 10.240.30.0/24

전환 기간 설계

각 웨이브에는 잘 정의된 컷오버 기간이 필요합니다.

사전 전환 타임라인(마이그레이션 일까지 7일):

  • 웨이브 계획 및 런북 마무리
  • Transit Gateway 연결 확인
  • 워커 가상 서버 인스턴스 및 대상 볼륨 프로비저닝
  • 이해 관계자에게 컷오버 기간 전달
  • 마이그레이션 중인 서비스에 대한 DNS TTL 줄이기
  • 사용자에게 유지 관리 기간 알림

전환 실행 ( T-0 )

다음 정보에서는 전환 단계에 대해 설명합니다.

1단계: 일시 중단 및 마이그레이션(0~4시간)

  1. 연결 배수 - 로드 밸런서에서 제거하고 세션이 종료될 때까지 기다립니다.
  2. 애플리케이션을 정상적으로 중지
  3. 방법 3의 경우 가상 서버를 종료하거나 라이브 ISO에서 시작합니다
  4. 디스크 전송 시작
  5. 전송 진행 상황 모니터링

2단계: 변환 및 프로비저닝(4~6시간)

  1. 필요한 경우 virt-v2v 을 실행하여 드라이버를 주입합니다
  2. 디스크 전송 확인(fdisk, 체크섬)
  3. 버퍼를 플러시하고 워커에서 볼륨 분리하기
  4. 마이그레이션된 볼륨에서 가상 서버 인스턴스 만들기
  5. 가상 서버 인스턴스를 시작합니다

3단계: 유효성 검사 및 컷오버(6~8시간)

  1. 가상 서버 인스턴스를 시작하고 필요한 경우 VNC 콘솔을 통해 액세스합니다
  2. 네트워크 구성을 확인하고 필요한 경우 조정
  3. 애플리케이션 시작
  4. 기능 테스트(애플리케이션 작동, 데이터 액세스 가능)
  5. 로드밸런서에 추가 및 DNS 업데이트
  6. 애플리케이션 성능 모니터링

4단계: 안정화(8~12시간)

  1. 문제 모니터링
  2. 외부 연결 확인
  3. 애플리케이션 로그에서 오류가 있는지 확인하십시오
  4. 기준선 대비 성능 비교

마이그레이션 롤백 결정 시점:

  • 1단계 이후: 간편한 롤백( VMware 가상 서버 재시작)
  • 2단계 이후: 중간 난이도(가상 서버 인스턴스 삭제, VMware 가상 서버 재시작, DNS 복원)
  • 3단계 이후: 어려움(VPC에 새 데이터가 있을 수 있으며, VMware 로 데이터를 다시 동기화해야 함)

디자인 권장 사항: 명시적인 이동, 이동 금지 체크포인트를 정의하세요. 예:

  • 2단계 이후 가상 서버 인스턴스의 20% 이상이 시작되지 않으면 롤백을 구현합니다.
  • 3단계 이후 애플리케이션 기능 테스트에 실패하면 롤백을 구현합니다.
  • 4단계 이후에도 성과가 기준선보다 30% 이상 낮으면 롤백을 실행하지 말고 조사하세요.

마이그레이션 속도 추정

가상 서버당 마이그레이션 시간을 예측하여 현실적인 웨이브 크기와 기간을 계획하세요. 다음 타임라인은 달성할 수 있지만 실제 마이그레이션 전에 PoC 에서 확인해야 합니다.

시간 구성 요소:

방법 1-2를 사용하여 예상 시간을 내보냅니다:

  • 100GB 가상 서버: 20~30분
  • 500GB 가상 서버: 2~3시간
  • VMware 스토리지 성능에 따라 다름

전송 시간 예상:

  • 네트워크: 100GB = 20-25분
  • 네트워크: 500GB = 90-120분
  • 압축을 사용하는 방법 3: 압축으로 인해 2~3배 빠른 경우가 많습니다

다음을 사용하여 변환 시간 추정 virt-v2v:

  • Linux: 5-10분
  • Windows: 10~20분
  • 워커 가상 서버 인스턴스 성능에 따라 다름

프로비저닝 시간 예상:

  • 가상 서버 인스턴스 생성: 5분
  • 부팅 및 네트워크 구성: 5~10분

예상 시간 예시:

소규모 Linux 가상 서버(디스크 1개, 100GB, 방법 3):

  • 내보내기가 없습니다: 0분
  • 압축을 통한 전송: 25분
  • 변환: 5분
  • 프로비저닝: 10분
  • 총 시간: 40분

방법 2를 사용하여 디스크 4개, 총 1TB의 대용량 Windows 가상 서버 시간을 추정합니다:

  • 내보내기: 내보내기: 3시간
  • 환승: 2시간
  • 변환 ( virt-v2v ): 20분
  • 프로비저닝: 10분
  • 총: 5.5 시간

방법 3, 4의 시간 추정치를 모두 사용하여 병렬 마이그레이션의 효율성을 높입니다:

  • 4x 병렬로 마이그레이션되는 100GB 가상 서버
  • 각각 30분
  • 총 웨이브 시간: 35분(시작 및 종료 시간 포함)

순차적으로 마이그레이션하는 4x 100GB 가상 서버 마이그레이션과 비교:

총 웨이브 시간은 120분입니다

병렬 처리를 사용하면 이 시나리오에서 3~4배의 성능을 향상시킬 수 있습니다.