이 문서에서는 Compute Engine으로 동종 Db2 마이그레이션을 수행할 때의 권장사항을 설명합니다. 이 문서는 Db2 환경을 Google Cloud로 마이그레이션하려는 데이터베이스 관리자, 시스템 관리자 그리고 소프트웨어, 데이터베이스, 작업 엔지니어를 대상으로 합니다. Db2에서 다른 유형의 데이터베이스로의 마이그레이션은 이 문서에서 다루지 않습니다.
용어
- IBM Db2
- 복제 및 장애 조치 기능이 있는 엔터프라이즈급 관계형 데이터베이스 관리 시스템(RDBMS)입니다.
- 고가용성 재해 복구(HADR)
- 데이터베이스 로깅 활동을 사용하여 기본 데이터베이스의 데이터를 대기 데이터베이스에 복제하는 Db2 기능입니다. 이 기능을 사용 설정하면 수동으로 기본 데이터베이스에서 대기 데이터베이스로 장애 조치할 수 있습니다.
- 기본
- 쓰기 요청과 읽기 요청을 수락하는 Db2를 호스팅하는 머신입니다. 이 머신은 대기 머신에 대한 복제 소스입니다.
- 주 대기
- 읽기 요청만 수락하는 대기 머신입니다. 이 머신은 Db2에서 허용되는 모든 동기화 모드를 지원하며 HADR 목적으로 장애 복구 인스턴스로 지정됩니다. IBM Db2는 클러스터별로 이러한 머신을 한 개만 허용합니다.
- 보조 대기
- 읽기 요청만 수락하는 대기 머신입니다. 이 머신은 SUPERASYNC 동기화 모드만 지원하며 기본 데이터 센터에 장애가 발생하여 수동 장애 조치를 수행할 때를 대비하여 기본 머신과 다른 데이터 센터에 상주합니다.
- TSA/MP(Tivoli System Automation for Multiplatforms)
- 기본 데이터베이스에서 기본 대기 서버로의 자동 리소스 장애 조치를 용이하게 하는 클러스터 관리 소프트웨어입니다. 이 소프트웨어에는 클러스터의 일부로 정의된 네트워크, 스토리지, Compute 리소스가 포함되어 있습니다. Db2 엔터프라이즈 에디션은 HADR에 대한 TSAMP 권한이 포함된 상태로 제공됩니다.
- ACR(Automatic client reroute)
- 앱이 최소한의 중단으로 계속 작업할 수 있도록 장애가 발생한 서버의 클라이언트 앱을 대체 서버로 리디렉션하는 Db2 기능입니다.
- CDC(Change Data Capture)
- 다른 데이터베이스와의 데이터 동기화 또는 감사 추적 생성과 같은 데이터베이스 변경사항을 감지하는 일련의 기법 또는 도구입니다.
아키텍처
일반적으로 Db2 클러스터는 최소한 기본 노드와 주 대기 노드로 구성되며, 이들 둘 사이에는 HADR이 있습니다. 최신 버전의 Db2에서는 DR 용도로 사용되는 보조 대기 노드를 추가할 수도 있습니다.
다음 다이어그램은 원본 환경을 보여줍니다.
이 환경에서 기본과 주 대기는 한 데이터 센터에 있고 보조 대기는 다른 데이터 센터에 있습니다.
마이그레이션 목표는 다음 다이어그램과 같이 Google Cloud에서 이 환경을 다시 만드는 것입니다.
다음 표에서는 각 마이그레이션 유형을 비교합니다.
| Migrate to Virtual Machines | Q 복제 | SQL 복제 | HADR | |
|---|---|---|---|---|
| 소스 | VMware, Amazon Web Services(AWS) VM | 라이선스를 기반으로 하는 모든 Db2 환경 | 모든 Db2 환경 | 모든 Db2 환경 |
| 복제 대상 | 디스크의 블록 수준 복제 | 데이터베이스의 테이블 | 데이터베이스의 테이블 | 전체 데이터베이스 |
| 컷오버 | Google Cloud에서 VM을 시작하는 데 몇 분 정도 필요 | 앱과 DNS가 Compute Engine 인스턴스를 가리키도록 함 | 앱과 DNS가 클라우드 인스턴스를 가리키도록 함 | 앱과 DNS가 클라우드 인스턴스를 가리키도록 함 |
| DDL 변경 복제 | 예(복제 중인 디스크 쓰기) | 예 | 예 | 예 |
| 동기식 데이터 복제 | 해당 없음 | 아니요 | 예 | 예 |
| 비동기식 데이터 복제 | 해당 없음 | 예 | 예 | 예 |
| 특정 시점 데이터 복제 | 아니요 | 예 | 예 | 아니요 |
위 표는 대상 시스템 설정, 복제 설정, 시간 경과에 따른 복제 유지관리 및 테스트를 위해 시스템 가용성 요구사항과 리소스 노력 수준을 일치시킬 수 있도록 안내합니다. 다음 표에서는 Migrate to VMs가 구현하기 가장 쉬운 방식이지만 시스템 가용성 측면에서 유연성이 가장 낮음을 보여줍니다. 또한 HADR, Q 복제, SQL 복제에서는 시스템 가용성에 미치는 영향이 적지만 병렬 모델에서는 복제를 설정 및 유지하는 데 더 많은 노력이 들어갑니다.
마이그레이션 유형
Db2를 Compute Engine으로 마이그레이션하는 방법에는 다음과 같은 두 가지 방법이 있습니다.
- 기존 클러스터 구성 또는 토폴로지를 수정하는 마이그레이션
- 데이터를 완전히 새로운 클러스터에 복제하는 마이그레이션
기존 클러스터를 수정하면 클라우드에서 완전히 새로운 클러스터를 시작하지 않아도 되므로 더 빠르게 마이그레이션을 수행할 수 있습니다. 두 번째 방법으로 마이그레이션하려면 Google Cloud에 새 클러스터를 배포해야 하지만 복제가 대역 외이므로 기존 클러스터에 미치는 영향이 적습니다. 이 방법은 또한 데이터베이스의 일부만 복제하거나 데이터가 대상에 도착하기 전에 데이터를 변환하려는 경우에 유용합니다.
다음 섹션에서는 Db2 인스턴스를 Google Cloud로 이전하기 전에 고려해야 할 사항을 설명합니다. 일반적으로 사용되는 일부 기능은 Google Cloud에서 예상대로 작동하지 않거나 일부 구성을 변경해야 할 수도 있습니다.
유동(가상) IP 주소
고가용성 Db2 클러스터에서 TSA/MP는 기본 노드에 가상 IP 주소를 할당할 수 있습니다. 이 주소는 유동 IP 주소라고도 하며 트래픽이 항상 대기 노드가 아닌 기본 노드로 라우팅됩니다.
Compute Engine은 Virtual Private Cloud(VPC) 네트워크에서 가상화된 네트워크 스택을 사용하므로 일반적인 구현 메커니즘이 작동하지 않을 수 있습니다. 예를 들어 VPC 네트워크는 구성된 라우팅 토폴로지에 따라 주소 확인 프로토콜(ARP) 요청을 처리하고 Gratuitous ARP 프레임을 무시합니다. 또한 최단 경로 우선 프로토콜(OSPF) 또는 경계 게이트웨이 프로토콜(BGP)과 같은 표준 라우팅 프로토콜로 VPC 네트워크 라우팅 테이블을 직접 수정할 수 없습니다. 따라서 유동 IP 주소의 대안을 구현하거나 ACR을 사용해야 합니다.
Db2 클러스터에서 전체 또는 일부 노드를 이전하는 경우 클러스터의 유동 IP 주소를 사용 중지한 후에 노드를 이동해야 합니다.
ACR
Db2 환경에서 ACR을 사용할 때 DNS 이름이 변경되거나 클라이언트가 IP 주소를 사용하여 연결할 경우 클라이언트의 카탈로그를 변경해야 할 수 있습니다.
결정자
TSA/MP에서는 대부분의 클러스터 노드가 온라인 상태여야 자동화 작업을 시작할 수 있습니다. 클러스터가 노드 짝수 개로 구성되어 있으면 클러스터 노드 중 정확히 절반이 온라인 상태이고 브레인 분할(Split-brain) 시나리오일 수 있습니다. 이 경우 TSA/MP는 결정자를 사용하여 쿼럼(다수 그룹) 상태를 결정하며, 이 상태에 따라 자동화 작업을 시작할 수 있는지 여부가 결정됩니다.
Db2 환경에서 사용할 수 있는 결정자는 다음과 같습니다.
- 스토리지 또는 디스크 결정자. IBM Db2는 디스크 예약을 사용하여 결정을 내립니다. Google Cloud에서는 예약을 사용할 수 없으므로 다른 유형의 결정자를 선택해야 합니다.
- 네트워크 결정자. (클러스터에 대한) 외부 IP 주소를 사용하여 결정을 내립니다. 하이브리드 배포에서는 클러스터 노드에서 네트워크 결정자를 연결할 수 있는 한 처음에 Google Cloud로 이전할 필요가 없습니다. 그러나 클러스터를 Google Cloud에서 실행한 후에는 다른 영역에 결정자를 만들거나 Google Cloud 메타데이터 서버를 결정자로 사용하는 것이 좋습니다.
- NFS 결정자. NFS 결정자는 NFS v4 서버에 저장된 예비 파일을 기준으로 결정을 내립니다. 네트워크 결정자와 마찬가지로 하이브리드 배포에서 NFS 결정자와 NFS v4 서버는 원래 위치를 유지할 수도 있습니다. 이후에 더 나은 방법은 자체 NFS 서버를 배포하거나 Elastifile과 같은 파트너를 Google Cloud에서 NFS 결정자 대상으로 사용하는 것입니다.
Migrate to VMs를 사용하여 마이그레이션
개발자 환경에서 다음 두 가지 사항이 모두 충족되면 Migrate to VMs를 사용하는 것이 좋습니다.
Amazon Elastic Compute Cloud(Amazon EC2)에 VMware vCenter 환경 또는 가상 머신이 있는 경우
Google Cloud에서 Cloud VPN이나 Cloud Interconnect와 같은 환경으로 비공개 연결이 설정된 경우
Migrate to VMs는 온프레미스 및 클라우드 환경의 가상 머신을 Google Cloud로 마이그레이션합니다. 몇 분만에 데이터를 백그라운드로 복사하면서 가상 머신을 Google Cloud로 마이그레이션할 수 있지만 가상 머신이 완벽하게 작동하지는 않습니다. Cloud VPN, Cloud Interconnect, Partner Interconnect와 같은 Google Cloud 프로젝트와 원본 환경 사이에 비공개 연결을 설정해야 합니다.
Migrate to VMs를 사용하면 클라우드 VM에서 데이터베이스 구성을 다시 평가해야 합니다. 레지스트리 변수, 버퍼 풀, 데이터베이스 관리자 구성 또는 데이터베이스 구성과 같은 일부 구성이 Google Cloud에 최적화되지 않을 수 있습니다.
AUTOCONFIGURE 유틸리티를 사용하여 이러한 재평가를 시작할 수 있습니다.
Migrate to VMs 작동 방법은 VM 마이그레이션 수명 주기에 자세히 설명되어 있습니다.
다음 섹션에서는 이러한 방법을 Db2 환경에 적용하는 방법을 간략하게 설명합니다.
테스트 클론
vCenter 환경에서만 테스트 클론을 사용할 수 있습니다.
Migrate to VMs는 VM 스냅샷을 만들고 이 스냅샷을 기반으로 Google Cloud에 즉시 사용 가능한 Compute 인스턴스를 만듭니다. Google Cloud에서 Db2 환경을 다시 만들고 원본 환경에 아무런 영향을 미치지 않으면서 배포의 변경, 테스트, 벤치마킹을 수행할 수 있습니다.
다음 다이어그램에서는 Migrate to VMs 테스트 클론 후 Google Cloud의 DB2 환경과 병렬 환경을 보여줍니다.
Google Cloud에서 테스트 클론을 벤치마킹하고 테스트한 후에는 테스트 클론을 삭제할 수 있습니다.
클라우드 실행(Run-in-cloud)
클라우드 실행을 활성화하면 Migrate to VMs에서 소스 클러스터를 종료하고 Google Cloud에서 VM을 시작합니다. 이 과정에서는 필요한 만큼 데이터를 가져오고 전체 스토리지를 Google Cloud로 스트리밍하지 않습니다. 클라우드 실행은 다시 쓰기를 지원하며 기본적으로 사용 설정되어 있습니다. Migrate to VMs를 사용하면 실제로 스토리지를 스트리밍하기 전에 환경을 테스트할 수 있습니다. 재이동 기능을 사용하여 VM을 원본 환경으로 다시 이전할 수도 있습니다. 클라우드 간 마이그레이션에서는 다시 쓰기를 소스에 복제할 수 없습니다.
다음 다이어그램에서는 모든 노드가 클라우드에서 실행되도록 설정한 경우의 클라우드 실행 단계를 보여줍니다. 한 번에 전체 클러스터를 이동하는 대신 점차적으로 클러스터 노드를 이전하도록 지정할 수 있습니다.
마이그레이션
마이그레이션 단계는 클라우드 실행 단계와 비슷하지만 Migrate to VMs에서 실제로 스토리지를 Google Cloud로 스트리밍합니다. 클라우드 실행 단계에서는 VM을 완전히 이전할 준비가 되었다고 알리지 않으므로 Migrate for VMs는 필요할 때만 데이터를 가져와 대역폭을 절약합니다.
분리
이 단계에서는 Migrate for VMs는 캐시와 객체 저장소의 데이터를 Google Cloud의 원시 데이터 디스크와 동기화한 후 디스크를 VM에 연결합니다. 이 단계에서는 Google Cloud에서 VM을 종료해야 합니다. Db2의 경우 한 번에 클러스터 노드 한 개씩 분리하는 것이 좋습니다.
복제 사용
Db2의 경우 복제는 캡처 프로그램을 사용하여 트랜잭션 로그의 변경사항을 캡처한 후 적용 프로그램을 사용하여 다른 클러스터에 적용하는 프로세스입니다. 캡처 프로그램에서 변경사항을 캡처하는 방식과 변경사항을 적용 프로그램에 전송하는 데 사용되는 통신 채널 유형은 복제 유형에 따라 다릅니다.
다음 다이어그램은 Db2 복제에서 정보의 논리적 흐름을 보여줍니다.
캡처 앱은 데이터베이스의 변경사항을 캡처하여 적용 앱에 보냅니다. 적용 앱은 이러한 변경사항을 대상 데이터베이스에 씁니다. 앱이 데이터 자체에서 수행할 수 있는 몇 가지 변형이 있습니다. 캡처 애플리케이션과 적용 애플리케이션이 반드시 데이터베이스 서버 자체에서 실행되어야 하는 것은 아닙니다.
SQL 복제
SQL 복제는 소스 테이블과 뷰의 변경사항을 캡처하고 스테이징 테이블을 사용하여 커밋된 트랜잭션 데이터를 저장합니다. 그러면 이러한 변경사항은 스테이징 테이블에서 읽히고 해당 대상 테이블에 복제됩니다. 이 문서를 작성한 시점에서는 Db2를 설치하면 SQL 복제가 제공됩니다.
SQL 복제를 활용한 마이그레이션 프로세스는 다음과 같습니다.
- Google Cloud에 Db2를 배포합니다.
- SQL 복제를 구성합니다.
- SQL 복제를 시작합니다.
- 배포가 동기화됐는지 확인합니다.
- 앱이 Google Cloud 인스턴스를 가리키도록 합니다. 복제를 중지합니다.
다음 다이어그램은 SQL 복제의 예시입니다.
Google Cloud에서 만든 새 클러스터에 SQL 명령어를 복제하는 동안 프로덕션 환경은 평소대로 작동합니다. 앞의 다이어그램에서 복제 프로세스는 기본 인스턴스에서 실행되지만 다른 방법으로 배포될 수 있습니다. 이 문서에서는 이러한 방법을 설명하지 않습니다.
Q 복제
Q 복제는 한 Db2 인스턴스에서 다른 Db2 인스턴스로 데이터를 복제할 수 있는 SQL 복제보다 더 새롭고 효율적인 방법입니다. 이 방법에서는 IBM MQ를 사용하여 데이터 변경사항 항목을 전달하므로 원본 환경과 대상 환경에 IBM MQ 인스턴스를 배포해야 합니다. 이 복제 방법은 메모리에서 수행되므로 SQL 복제보다 빠릅니다. SQL 복제는 느리지만 Q 복제는 IBM MQ를 설정해야 하므로 일반적으로 설정이 더 어렵습니다. Db2 라이선스에 따라 Q 복제용 라이선스를 구매해야 할 수도 있습니다.
Db2 Q 복제를 시작할 때 다음 두 가지 방법 중 하나를 선택할 수 있습니다.
자동 로드. Q 복제 프로세스가 초기 로드를 수행합니다. 즉, 소스 백업에서 대상 데이터베이스가 복원됩니다.
수동 로드. 사용자가 초기 로드를 수행한 후 지정된 로그 지점에서 복제를 시작합니다.
마이그레이션 프로세스는 다음과 같습니다.
- Google Cloud와 원본 환경에 IBM MQ를 배포합니다.
- Google Cloud에 Db2를 배포합니다.
- Q 복제를 구성합니다.
- 수동 로드 또는 자동 로드 중 하나로 Q 복제를 시작합니다.
- 두 배포가 동기화됐는지 확인합니다.
- 애플리케이션이 Google Cloud 인스턴스를 가리키도록 합니다. 복제를 중지합니다.
다음 다이어그램은 사용할 수 있는 Q 복제 솔루션을 보여줍니다.
원본 환경이 IBM Q 복제를 사용하여 데이터베이스 변경사항을 IBM MQ와 대상 환경으로 보내 Db2 클러스터를 Compute Engine으로 확장합니다.
이 방식에서는 기존 Db2 클러스터를 Compute Engine으로 점진적으로 이전하고 노드 간 데이터 전송에 HADR을 사용합니다.
다음 조건을 충족하는 경우에 이 방식을 사용합니다.
- Compute Engine에 완전히 새로운 클러스터를 배포하지 않으려는 경우
- Migrate to VMs를 활용할 수 없습니다.
- 복제 옵션 중 하나를 사용할 수 없는 경우
- 파트너 제품을 사용하지 않거나 사용할 수 없는 경우(라이선스, 비용 또는 규정 준수 등의 이유로 인해)
Db2 버전이 보조 대기를 지원하지 않는 경우
다음을 수행하면 됩니다.
- Compute Engine에 Db2 인스턴스를 배포합니다.
- 기본 인스턴스에서 백업을 만듭니다.
- 백업에서 Db2 인스턴스를 Compute Engine에 복원합니다.
- HADR 설정에서 대기 인스턴스를 삭제합니다.
- Compute Engine Db2 인스턴스를 대기로 연결합니다. 동기화 모드를 선택할 수 있지만 지연 시간이 길어질 수 있으므로
ASYNC또는NEARASYNC를 선택하는 것이 좋습니다. - Compute Engine Db2 인스턴스로 장애 조치하고 HADR 기본으로 설정합니다.
- 다른 Compute Engine Db2 인스턴스를 만들고, 백업에서 복원하고, HADR 대기로 설정합니다.
다음 다이어그램의 첫 번째 단계는 소스 Db2 기본의 주 대기로 설정된 Google Cloud에 새로 생성된 Db2 인스턴스를 보여줍니다.
앞의 다이어그램에서 Google Cloud 인스턴스는 HADR 기본이 됩니다. 그런 다음 소스 주 대기를 삭제하고 Compute Engine에서 다른 Db2 인스턴스를 주 대기 인스턴스로 연결합니다.
Db2 버전이 보조 대기를 지원하는 경우
한 가지 옵션은 Db2 버전이 보조 대기를 지원하지 않을 때와 동일한 단계를 수행하고 마지막에 보조 대기 인스턴스도 이전하는 것입니다.
또 다른 옵션은 보조 복제본을 활용하는 것입니다. 이 옵션을 사용하면 Google Cloud로 이전할 때 내결함성이 향상됩니다. 원본 환경에 기본 또는 주 대기가 없고 Google Cloud에 다른 인스턴스가 없기 때문입니다. 두 번째 옵션의 단계는 다음과 같습니다.
- Compute Engine의 정해진 위치에 Db2 인스턴스를 배포합니다(필요 시 기본, 주, 보조).
- 소스 클러스터에서 보조 대기 노드를 삭제합니다.
- 소스 클러스터에서 보조 대기의 기본 및 주가 될 노드를 구성합니다.
- Compute Engine 인스턴스 중 한 개를 인계합니다. 이 인스턴스가 기본 인스턴스가 됩니다. 다른 Compute Engine 인스턴스 중 한 개를 기본 인스턴스의 주 대기로 구성합니다.
다음 다이어그램의 첫 번째 단계는 Compute Engine에서 새로 생성된 Db2 인스턴스 두 개를 보여줍니다.
인스턴스는 원본 환경에서 보조 인스턴스가 아닌 소스 Db2 기본 인스턴스의 보조 대기로 설정됩니다. 그런 다음 Compute Engine 인스턴스 중 한 개에 인계를 수행하면 이 인스턴스가 HADR 기본 인스턴스가 되고 다른 인스턴스는 주 대기 인스턴스로 구성됩니다. 마지막 단계로, 서로 다른 인스턴스 두 개가 보조 대기로 구성됩니다.
파트너 제품
Google에는 이러한 마이그레이션을 지원하는 제품을 제공하는 여러 파트너가 있습니다. 이들 제품 대부분은 CDC를 활용하여 소스 Db2와 대상 간에 데이터를 복제합니다. 이들 제품은 Google Cloud 제품이 아니므로 각 제품 또는 서비스의 라이선스와 가격 책정을 직접 확인해야 합니다. 일반적으로 이 서비스는 기존 클러스터의 데이터를 Google Cloud에서 생성된 다른 클러스터에 복제합니다. 전체적인 방식은 이 문서에 설명된 복제 시나리오와 비슷합니다.
파트너 제품의 예는 다음과 같습니다.
다음 단계
- SAP용 IBM Db2 계획 가이드
- Google Cloud 데이터베이스 마이그레이션 센터
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기