Azure로 Oracle 워크로드 마이그레이션
클라우드 채택 과정의 일환으로 기존 워크로드를 클라우드로 마이그레이션해야 합니다. Oracle 워크로드는 다른 워크로드와 유사하며 성공적인 마이그레이션을 위해 체계적인 접근 방식이 필요합니다. 마이그레이션 방법론에 대한 자세한 내용은 Azure클라우드 채택 프레임워크의
Oracle 마이그레이션 시나리오
Oracle 워크로드를 마이그레이션할 때 데이터베이스 및 애플리케이션을 전환해야 합니다. 이 문서에서는 애플리케이션 및 데이터베이스 마이그레이션에 대한 리프트 앤 시프트 접근 방식을 설명합니다. 리프트 앤 시프트 접근 방식에는 Azure Virtual Machines에 Oracle 애플리케이션을 배포하는 것이 포함됩니다. 데이터베이스 마이그레이션의 경우 몇 가지 옵션을 사용할 수 있습니다. 이 문서는 Oracle Database@Azure에 적용되는 지침을 제공합니다.
Virtual Machines에서 애플리케이션 : Azure 인프라에서 Siebel, PeopleSoft, JD Edwards, E-Business Suite 또는 사용자 지정된 WebLogic Server 애플리케이션과 같은 Oracle 엔터프라이즈 애플리케이션을 실행합니다.
Virtual Machines의 Oracle Standard Edition 또는 Enterprise Edition 데이터베이스: 이 시나리오에서는 Virtual Machine에 Oracle 데이터베이스를 배포합니다. 자체 관리형 데이터베이스에서 관리되는 데이터베이스에 이르기까지 몇 가지 옵션을 사용할 수 있습니다. 관리되는 데이터베이스 솔루션을 선호하는 경우 Tessell검토합니다.
Oracle Database@Azure: Oracle Database@Azure OCI(Oracle 클라우드 인프라)에서 실행되는 Oracle 데이터베이스 서비스이며 Microsoft 데이터 센터에 배치됩니다.
메모
특정 데이터베이스 버전에 대해 지원되는 운영 체제를 확인하려면 지원되는 데이터베이스 및 운영 체제
Oracle 마이그레이션 프로세스
인프라 요구 사항을 지속적으로 재평가하여 성능을 개선하고 워크로드에 적합한 유형의 서비스를 사용하여 비용을 절감해야 합니다. 예를 들어 앞에서 언급한 모든 시나리오의 경우 마이그레이션에 충분한 대역폭을 사용할 수 있는지 확인합니다. PoC(개념 증명)를 수행할 때 필요한 대역폭을 검토하는 것이 좋습니다.
Virtual Machines의 Oracle로 워크로드를 이동하는 경우 VM(가상 머신) 크기가 요구 사항을 충족하는지 확인합니다. 자세한 내용은 Oracle 워크로드를 Azure 랜딩 존으로 마이그레이션하기 위한 용량 계획을 참조하세요.
마이그레이션 리소스를 검토하여 Oracle에서 Azure로의 마이그레이션 프로세스를 정의합니다. 다음도 가능합니다.
- Azure 구독 할당량 한도 확인: Azure 구독의 할당량 한도가 Virtual Machines에서 Oracle로 마이그레이션할 때 선택한 대상 VM 크기를 수용할 수 있는지 확인합니다.
메모
Oracle Database@Azure 워크로드를 호스트하고 할당량을 늘려야 하는 경우 Oracle 담당자에게 문의하세요.
배포 모델 식별: 인프라를 코드, 지속적인 통합 및 지속적인 업데이트 파이프라인 및 기타 DevOps 사례로 사용하여 솔루션 구성 요소의 배포를 최대한 자동화합니다.
애플리케이션 종속성 확인: 마이그레이션 작업이 가능한 한 중단되지 않는지 확인합니다.
데이터 용량 식별: 온-프레미스 환경에서 Azure로 현재 사용 가능한 네트워크 연결 용량을 마이그레이션하고 평가할 데이터의 양을 식별합니다. 이 정보를 사용하여 온-프레미스 환경에서 Azure로 직접 데이터를 복사할 수 있는지 확인합니다. 초기 데이터 로드를 위해 Azure Data Box와 같은 물리적 데이터 전송 어플라이언스도 필요할 수 있습니다.
가용성 요구 사항 확인: 사용할 수 있는 마이그레이션 도구에 영향을 줄 수 있으므로 워크로드 가용성 요구 사항을 결정합니다. 허용되는 최대 가동 중지 시간을 정의합니다. 이 메트릭은 마이그레이션 도구 및 접근 방식을 정의하는 데 도움이 됩니다.
이 고려 사항은 애플리케이션에 동일하게 적용됩니다. 일상적인 작업의 중단을 허용할 수 없는 경우 온라인 마이그레이션을 수행해야 합니다.
- Azure 가상 머신에서 Oracle로 워크로드를 마이그레이션하기 위한 도구를 결정합니다. 두 가지 기본 마이그레이션 경로는 오프라인 및 온라인입니다.
| 오프라인 마이그레이션 | 온라인 마이그레이션 |
|---|---|
| 데이터베이스의 일회성 직접 복사본입니다. | 마이그레이션 중에 데이터베이스의 초기 복사본과 변경 데이터 캡처가 뒤따릅니다. |
| 마이그레이션 중에 영향을 받는 애플리케이션이 오프라인 상태여야 합니다. | 애플리케이션은 마이그레이션 중에 온라인 상태를 유지할 수 있습니다. |
| 도구 사용: Data Box, DataPump, Oracle Recovery Manager(RMAN) | 도구 사용: DataGuard, Oracle 복구 관리자(RMAN), GoldenGate |
메모
온라인 마이그레이션을 수행하기로 결정한 경우 데이터 전송을 허용하도록 방화벽 규칙을 구성해야 합니다.
Oracle 마이그레이션 워크로드 관련 활동
다음 섹션에서는 마이그레이션 프로세스에 대해 자세히 설명합니다. 단계가 반드시 순차적인 것은 아닙니다. 몇 가지 단계를 병렬로 수행할 수 있습니다.
원본 및 대상 시스템 버전 평가: 온-프레미스 OS(운영 체제) 버전, 애플리케이션 버전 및 데이터베이스 버전이 온-프레미스 및 Azure에서 동일한지 여부를 평가합니다.
하나 이상의 리소스를 업데이트해야 하는 경우 마이그레이션 전에 업데이트하여 마이그레이션 프로세스를 간소화합니다.
온-프레미스 데이터베이스가 Oracle Solaris, IBM Advanced Interactive eXecutive 또는 Hewlett Packard Unix와 같은 빅 엔디안 OS에서 실행되는 경우 데이터베이스 마이그레이션 프로세스에는 엔디안 변환이 포함됩니다. Azure는 little-endian 운영 체제만 지원합니다. 이 제한으로 마이그레이션에 사용할 수 있는 도구 수가 줄어듭니다. 특히 Oracle Data Guard 또는 다른 파일 복사 방법은 사용할 수 없습니다. Endian 변환과 호환되는 마이그레이션 방법에는 Oracle Data Pump Export 또는 Oracle Data Pump Import, Oracle XTTS(플랫폼 간 전송 가능 테이블스페이스) 또는 Oracle GoldenGate, Quest SharePlex 및 Striim과 같은 데이터 복제 유틸리티가 포함됩니다.
요구 사항 및 호환성에 따라 온-프레미스 애플리케이션 서버를 현대화하거나 마이그레이션할 수 있습니다. 자세한 내용은 클라우드 채택 시나리오를 참조하세요.
마이그레이션 프로세스 중에 워크로드 가용성 요구 사항을 평가합니다. 워크로드 가동 중지 시간을 최소화해야 하는 경우 데이터 펌프 내보내기 또는 데이터 펌프 가져오기와 같은 마이그레이션 방법이 워크로드에 적합하지 않을 수 있습니다. 이 경우 다음 4단계 프로세스를 수행합니다.
RMAN을 사용하여 Azure에서 전체 데이터베이스를 백업한 다음 복원합니다. 필요한 경우 XTTS를 통해 엔디안 변환을 수행합니다. 그 결과 온-프레미스 원본 데이터베이스의 지정 시간 복사본인 데이터베이스가 생성됩니다. 자세한 내용은 플랫폼 간에 데이터 전송을 참조하세요.
두 원본이 모두 little-endian 형식인 경우 Oracle Data Guard를 사용하여 Azure에서 새로 복원된 데이터베이스를 원본 데이터베이스와 동기화합니다. 마이그레이션에 big-endian에서 little-endian으로의 변환이 포함된 경우 Data Guard를 사용할 수 없습니다. 대신 Oracle GoldenGate, Quest SharePlex 또는 Striim과 같은 SQL 기반 데이터 복제 유틸리티를 사용하여 Azure에서 새로 복원된 데이터베이스를 원본 데이터베이스와 동기화합니다.
Azure의 대상 데이터베이스를 원본 온-프레미스 데이터베이스와 동기화한 후 컷오버를 예약할 수 있습니다. 컷오버는 원본 온-프레미스 데이터베이스를 종료하고 마지막 몇 개의 트랜잭션을 Azure의 대상 데이터베이스로 플러시합니다. 그런 다음 Azure에서 대상 데이터베이스를 새 원본 데이터베이스로 열 수 있습니다. 커버전 작업은 사용하는 동기화 방법에 따라 몇 분 정도 걸릴 수 있습니다.
애플리케이션 서비스에 대해 선택한 마이그레이션 방법에 따라 애플리케이션을 Azure로 완전히 마이그레이션하기 전에 여러 애플리케이션 서비스 작업을 완료해야 할 수 있습니다.
필요한 라이선스 평가: 마이그레이션 도구에 따라 데이터베이스에 다양한 라이선스가 필요할 수 있습니다. 예를 들면 다음과 같습니다.
Oracle Data Guard에는 Oracle Database Enterprise Edition이 필요합니다.
Oracle GoldenGate에는 Oracle GoldenGate 라이선스가 필요합니다.
Azure의 Oracle 라이선스에 대한 자세한 내용은 클라우드 컴퓨팅 환경에서 Oracle 소프트웨어 라이선스를 참조하세요.
Oracle Database@Azure 마이그레이션 지침
솔루션을 배포하려는 지역에서 Oracle Database@Azure 솔루션을 사용할 수 있는지 확인합니다. 자세한 내용은 이용 가능 지역을 참조하세요.
마이그레이션 프로세스에 Oracle 제로 가동 중지 시간 마이그레이션을 사용하는 것이 좋습니다. 마이그레이션 전략을 평가하여 특정 마이그레이션 요구 사항에 가장 적합한 방법을 결정합니다. 자세한 내용을 보려면 ZDM(제로 가동 중지 시간 마이그레이션)을 참조하세요. ZDM은 논리적 또는 물리적 마이그레이션 시나리오를 선택할 수 있는 기능을 제공합니다. 더 많은 정보를 보려면 ZDM 마이그레이션을 참조하세요.
메모
ADB-S(자치 데이터베이스 서비스)를 선택하는 경우 논리적 마이그레이션 시나리오만 지원됩니다.
기타 지침
다음 섹션에서는 요구 사항 및 데이터 크기에 적합한 마이그레이션 옵션을 선택하는 데 도움이 될 수 있습니다.
ExpressRoute 기반 마이그레이션 기간 참조
다음 표는 기준선으로만 사용됩니다. 동일한 Azure ExpressRoute 연결을 통해 실행되는 다른 프로덕션 워크로드는 고려하지 않습니다.
VMware는 표시된 것보다 더 많은 대역폭이 필요할 수 있습니다. PoC 단계에서 대역폭 요구 사항을 평가합니다. 지원이 필요한 경우 로컬 연락처에 문의하세요.
| 데이터 크기 | 1 Gpb의 대역폭 | 10Gbps의 대역폭 |
|---|---|---|
| 1TB | 3시간 | 15분 |
| 10TB | 1일 | 3시간 |
| 35TB | 4일 | 9시간 |
| 80TB | 8일 | 20시간 |
| 100TB | 11일 | 1일 |
| 200TB | 21일 | 2일 |
| 500TB | 53일 | 5일 |
마이그레이션에 ExpressRoute를 사용할 계획이라면, 복원력이요구 사항을 충족하는지 확인하십시오.