비즈니스 연속성 및 재해 복구 최적화
Oracle 리소스를 Azure로 마이그레이션할 때 데이터베이스의 안정성과 VM(가상 머신), 가상 네트워크 서브넷 및 스토리지 구성 요소에 대한 계층의 안정성도 고려합니다.
Azure IaaS(Infrastructure as a Service)의 Oracle은 가장 까다로운 Oracle 워크로드의 필요한 복원력 목표를 달성할 수 있습니다. 이 문서의 지침을 효과적으로 사용하려면 먼저 비즈니스 요구 사항에 따라 KPI(복원력 키 성과 지표)를 정의합니다. RTO(복구 시간 목표) 및 RPO(복구 지점 목표) 요구 사항을 기준 KPI로 사용하여 Azure에서 Oracle 워크로드에 가장 적합한 아키텍처를 결정합니다.
RTO는 재해, 실패 또는 유사한 이벤트 후 애플리케이션을 사용할 수 없는 상태로 유지되는 최대 시간입니다.
RPO는 재해, 실패 또는 비교 가능한 이벤트 후 데이터 손실의 최대 크기입니다.
데이터 보호를 위한 백업 방법
Azure IaaS의 Oracle 워크로드에 대한 세 가지 Oracle 데이터베이스 백업 방법은 다음과 같습니다.
스트리밍 백업. 이 메서드에는 RMAN(Oracle Recovery Manager)을 사용합니다. RMAN은 순차 테이프 미디어에 백업을 스트리밍합니다.
Azure의 백업 대상은 다음과 같습니다.
- Azure Marketplace에서 찾을 수 있는 타사 가상 테이프 라이브러리입니다.
- 네트워크 파일 시스템 프로토콜, Azure Files 및 Azure NetApp Files를 사용하는 Azure Blob Storage와 같은 로컬 및 원격 파일 공유입니다.
스토리지 수준 스냅샷. 이 메서드에 Azure Backup을 사용합니다. 이 메서드는 데이터베이스 파일에 사용하는 스토리지 형식을 사용합니다. 예를 들어 Azure Premium SSD 와 같은 Azure 관리 디스크를 사용하는 경우 Azure Backup은 Oracle 데이터베이스와 통합됩니다. Azure NetApp Files를 사용하는 경우 Azure NetApp Files 백업 및 지역 간 복제와 같은 Azure NetApp Files 데이터 보호 기능을 사용할 수 있습니다.
VM 수준 백업. 이 메서드에 Azure Backup을 사용합니다.
주의
백업 환경의 VM에서 지원 가능성이 있는 OS를 실행하고 있는지 확인합니다. 지원되는 OS에 대해 알아봅니다.
대규모 데이터베이스의 백업을 스트리밍하는 경우 데이터를 복사한 다음 복원하는 데 걸리는 시간이 RTO 요구 사항을 초과할 수 있습니다. 스토리지 수준 스냅샷은 해당 시나리오에 가장 적합한 옵션입니다.
권장 사항
스트리밍, 스토리지 수준 스냅샷 또는 두 전략을 기반으로 하는 백업 전략을 구현할지 신중하게 고려합니다.
백업 전략이 RTO 및 RPO 요구 사항에 미치는 영향을 평가합니다.
각 옵션에 대해 문서화된 처리량 제한에 따라 RMAN 백업에 사용 가능한 스토리지 대상을 분석합니다. 요구 사항을 충족하는 옵션을 선택합니다.
스토리지 수준 스냅샷에 Azure Backup을 사용하는 것이 좋습니다. 추가 보호를 위해 쌍을 이루는 지역 또는 가용성 영역에 스냅샷을 배치하는 것이 좋습니다.
데이터베이스를 복구하는 데 필요한 보관 로그 백업을 저장하려면 다양한 스토리지 옵션을 고려합니다. 각 옵션의 성능, 복제 및 비용 고려 사항을 고려합니다.
프로덕션 환경에서 원치 않는 놀라움을 방지하기 위해 백업 및 복원 계획을 개발하고 정기적으로 테스트합니다.
서비스 보호 및 비즈니스 연속성
이 섹션에서는 서비스 보호 및 BC(비즈니스 연속성) 고려 사항을 구현하여 Azure IaaS에서 Oracle 워크로드의 전반적인 HA(고가용성) 및 DR(재해 복구)을 개선하는 방법을 설명합니다.
아키텍처 중복성을 개선하고 궁극적으로 서비스를 사용할 수 있는 시간을 최대화하기 위해 다음 권장 사항을 통합합니다. 패치, 업데이트 및 업그레이드, 계획되지 않은 중단(예: 오류)과 같은 계획된 중단으로 인한 서비스 가동 중지 시간을 최소화하는 것을 목표로 합니다. Azure 및 Oracle 기능을 사용하여 지리 전체 오류로부터 복구를 개선합니다.
Azure는 IaaS 아키텍처의 Oracle에서 개별 구성 요소의 고가용성을 위한 많은 옵션을 제공합니다. 이렇게 시작할 수 있는 작업의 예는 다음과 같습니다.
- 장애 도메인에 VM을 자동으로 분산하는 유연한 가상 머신 확장 집합을 사용하여 VM을 배포합니다.
- 데이터 센터 오류로부터 보호하기 위한 가용성 영역을 만듭니다.
- 전체 지역 오류로부터 보호하기 위해 다른 지역에 배포를 배치합니다.
다양한 Azure 스토리지 기능은 로컬 중복 스토리지, 영역 중복 스토리지 및 지역 중복 스토리지와 같은 다양한 스토리지 중복 수준을 제공합니다. Azure IaaS에서 Oracle 워크로드 배포를 계획할 때 각 옵션을 고려합니다.
Oracle 데이터베이스 서비스 보호 설정 도구인 Oracle Data Guard를 사용할 수도 있습니다. Data Guard는 하나 이상의 대기 데이터베이스에 트랜잭션 로그를 전달하고 적용합니다. 이 프로세스는 계획된 유지 관리 또는 오류 시나리오가 있는 경우 장애 조치(failover)할 수 있는 주 데이터베이스의 정확한 복사본을 유지 관리합니다.
Data Guard에는 최대 보호, 최대 가용성 및 최대 성능의 세 가지 데이터 복제 모드가 있습니다. 각 복제 모드는 로그 전송 모드의 다른 조합과 보조 데이터베이스의 애플리케이션에 대한 서로 다른 트랜잭션 보장을 제공합니다.
대기 시간 0 또는 데이터 손실 0 전략과 같은 전략에 따라 동기 또는 비동기 구성을 선택할 수 있습니다. 최대 가동 중지 시간 요구 사항에 따라 빠른 시작 장애 조치(failover)를 구현할 수도 있습니다. 1분 미만 또는 5분 미만, 최대 4시간 이내에 복구를 제공하는 참조 아키텍처를 사용할 수 있습니다. Enterprise Edition of Oracle Database에는 Data Guard가 포함되어 있습니다.
Oracle GoldenGate 는 두 데이터베이스 간에 데이터를 복제하고 다중 기본 시나리오를 사용하도록 설정하는 데 사용할 수 있는 또 다른 도구입니다. GoldenGate를 별도로 구매해야 합니다.
권장 사항
Azure IaaS 구현의 Oracle에서 다양한 인프라 구성 요소의 고가용성을 위해 Azure에서 제공하는 기능을 고려합니다.
HA 및 DR용 Data Guard를 사용할 때 요구 사항을 충족하는 데이터베이스 보호 모드를 신중하게 선택합니다. 예를 들어 최대 성능 모드는 원본에 미치는 영향을 최소화하지만 데이터 손실 가능성이 가장 높습니다. 자세한 내용은 Azure Virtual Machines 랜딩 존 가속기 및 Oracle Data Guard 보호 모드에서 Oracle용 BCDR을 참조하세요.
장애 조치(failover) 프로세스를 자동화하는 것이 좋습니다. 예를 들어 빠른 시작 장애 조치(failover)를 사용할 수 있습니다.
장애 조치(failover) 프로세스에 대한 테스트 절차를 수립하고 문제를 방지하기 위해 정기적인 테스트를 수행합니다.
가용성 영역과 같은 Azure 네이티브 기능과 Ha 및 DR 요구 사항을 충족하기 위해 Data Guard와 같은 Oracle 네이티브 도구를 사용하여 솔루션을 전체적으로 설계합니다. 다음 두 예제에서는 Azure 네이티브 구성 요소와 Oracle 네이티브 구성 요소를 사용합니다.
수동 대기를 사용하여 장애 조치(failover) 만들기
이 섹션에서는 수동 대기 상태의 2 가용성 영역 배포에서 중요 비즈니스용 Oracle 애플리케이션에 대한 장애 조치(failover) 시나리오의 예를 설명합니다.
Oracle E-Business Suite와 같은 중요 비즈니스용 Oracle 애플리케이션에는 오류 방지 및 전체적인 아키텍처가 필요합니다.
이 예제는 다음과 같이 작성되었습니다.
2 가용성 영역 배포가 있습니다. 애플리케이션 계층은 수동 보조 VM과 함께 Azure Site Recovery를 사용합니다.
Data Guard 빠른 시작 장애 조치(failover) 기능을 활용합니다. 가장 높은 가용성을 얻으려면 두 개의 관찰자를 설치하는 것이 좋습니다. 주 관찰자는 가용성 영역 1에 있고 보조 관찰자는 가용성 영역 2에 있습니다. 관찰자는 트래픽을 모니터링하고 직접 전송합니다. 주 데이터베이스를 사용할 수 없는 경우 관찰자는 자동으로 보조 데이터베이스로 장애 조치(fail over)합니다. Data Guard는 다시 실행 동기화를 수행합니다. 다시 실행 동기화의 시간 프레임은 다시 실행 구성에 따라 달라집니다.
Data Guard가 최대 가용성, 최대 성능 또는 최대 보호와 같은 데이터 보호 모드로 구성되었습니다. 워크로드 요구 사항에 대한 모드를 선택하는 방법에 대한 자세한 내용은 Oracle Data Guard 보호 모드를 참조 하세요.
다음 아키텍처는 5분 미만의 가동 중지 시간 임계값을 목표로 합니다.
활성 대기를 사용하여 장애 조치(failover) 만들기
이 섹션에서는 활성 대기 상태의 2 가용성 영역 배포에서 중요 비즈니스용 Oracle 애플리케이션에 대한 장애 조치(failover) 시나리오의 예를 설명합니다.
이 예에서는 다음이 적용됩니다.
웹 서버 계층, 애플리케이션 계층 및 데이터베이스 계층은 자체 가상 네트워크 서브넷에 상주합니다.
주 데이터베이스는 가용성 영역 1에 있습니다.
Active Data Guard를 사용하여 주 데이터베이스를 활성 대기 상태로 복제하는 데이터베이스는 가용성 영역 3에 상주합니다.
참고 항목
이 설정에는 Active Data Guard 라이선스가 필요합니다.
다음 아키텍처는 1분 미만의 가동 중지 시간 임계값을 목표로 합니다. 이 장애 조치(failover) 시나리오에는 활성 대기 구성이 있지만 읽기 전용 기능이 있습니다.
