이 문서는 BCDR(비즈니스 연속성 및 재해 복구)에 대한 Azure 랜딩 존 디자인 영역에 정의된 고려 사항 및 권장 사항을 기반으로 합니다. 이 문서에서는 해당 지침을 따르고 Azure 인프라 VM(가상 머신)에서 Oracle 워크로드 배포를 위한 BCDR 옵션에 대한 디자인 고려 사항 및 모범 사례를 설명합니다.
Azure는 고가용성 및 복원력 있는 아키텍처를 설계하는 데 사용할 수 있는 서비스를 제공합니다. 이 가이드에서는 Azure Virtual Machines 랜딩 존 가속기에서 Oracle 데이터베이스에 대한 고가용성 및 재해 복구를 설계하는 데 도움이 되는 다양한 옵션과 모범 사례를 간략하게 설명합니다. 또한 솔루션에 대한 높은 종단 간 가용성을 달성하는 데 도움이 되도록 함께 제공되는 Azure 서비스를 구성하는 방법에 대해서도 설명합니다.
시작하기
워크로드 환경에 대한 복원력 있는 아키텍처를 구축하려면 다양한 오류 수준에 대한 RTO(복구 시간 목표) 및 RPO(복구 지점 목표)를 기반으로 솔루션의 가용성 요구 사항을 결정합니다. RTO는 인시던트가 발생한 후 애플리케이션을 사용할 수 없는 최대 시간입니다. RPO는 재해 발생 시 최대 데이터 손실량입니다. 솔루션에 대한 요구 사항을 결정한 후에는 설정된 수준의 복원력과 가용성을 제공하도록 아키텍처를 디자인합니다.
Azure 워크로드의 Oracle은 주로 복제 기술을 사용하는 기본 제공 Oracle Database Enterprise Edition 기능인 Oracle Data Guard를 사용합니다. Data Guard를 사용하여 고가용성 및 재해 복구 요구 사항을 충족할 수 있습니다. Data Guard는 최대 성능, 최대 가용성 및 최대 보호의 세 가지 보호 모드를 제공합니다. 아키텍처 설계와 특정 RPO 및 RTO 요구 사항에 따라 보호 모드를 선택합니다.
고가용성을 위한 워크로드 구성
Oracle 워크로드를 실행하는 Azure Virtual Machines 인스턴스는 Azure Virtual Machine Scale Sets 아키텍처, 특히 유연한 오케스트레이션 모드의 이점을 누릴 수 있습니다. 고가용성 구성은 잠재적으로 빠른 장애 조치(failover) 기능을 통해 실시간에 가까운 데이터 복제를 제공합니다. 고가용성 구성은 Azure 데이터 센터 수준 또는 지역 수준 오류에 대한 보호를 제공하지 않습니다.
올바른 고가용성 옵션 선택
다음 순서도를 사용하여 Oracle 데이터베이스에 가장 적합한 고가용성 옵션을 선택합니다.
고가용성을 위해 최대 가용성 모드에서 Data Guard를 사용하십시오.
최대 가용성 모드의 Data Guard는 정상 작동에 대해 데이터 손실 제로(RPO=0)로 최고의 가용성을 제공합니다. Virtual Machine Scale Sets 유연한 오케스트레이션 내에서 생성된 두 Oracle 데이터베이스 서버의 고가용성 구성을 위해 Azure는 장애 도메인에 분산된 인스턴스에 대한 SLA(서비스 수준 계약)에 대해 99.95% 서비스 가용성을 제공합니다. Azure는 가용성 영역에 분산된 인스턴스에 대해 99.99% 서비스 가용성을 제공합니다. 자세한 내용은 Virtual Machine Scale Sets의 고가용성을 참조하세요.
Azure에서 Data Guard의 단계별 구성은 Linux 기반 Azure VM에서 Oracle Data Guard 구현을 참조하세요.
고가용성을 위해 최대 보호 모드에서 Data Guard를 사용하십시오.
트랜잭션이 일관된 데이터베이스 복사본이 필요한 경우 최대 보호 모드에서 Data Guard를 사용하는 것이 좋습니다. 그러나 최대 보호 모드에서는 대기 데이터베이스를 사용할 수 없을 때 트랜잭션을 계속할 수 없습니다. 따라서 Virtual Machines Scale Sets 유연한 오케스트레이션을 사용하더라도 최대 보호 모드를 사용할 때 SLA가 99.9% x 99.9% = 99.8%로 줄어듭니다. 이 구성은 일관된 데이터 복사본을 보장하지만 반드시 가용성을 높이지는 않습니다.
이 아키텍처의 다른 특성은 최대 가용성 모드와 동일합니다. 예를 들어 RPO는 0이고 RTO는 2분 이하입니다.
고가용성을 구현하는 다른 방법 고려
다음 섹션에서는 고가용성을 위한 특별한 고려 사항에 대해 설명합니다.
고가용성 향상을 위해 가용성 영역 사용
Azure 가용성 영역은 동일한 Azure 지역 내에 있는 Azure 데이터 센터입니다. 가용 영역의 왕복 지연 시간은 2밀리초 미만입니다. 일반적으로 재해 복구를 위해 가용성 영역을 사용하지만 고가용성을 개선하는 데 사용할 수 있습니다. 이 경우 솔루션이 가용성 영역이 제공하는 대기 시간 및 처리량으로 실행될 수 있는지 확인해야 합니다.
Virtual Machine Scale Sets 유연한 오케스트레이션을 사용하는 가용성 영역의 장점은 VM 가용성 SLA가 99.99%로 증가한다는 것입니다.
고가용성을 위해 공유 스토리지 클러스터링 사용
공유 스토리지 클러스터링 기술은 비즈니스 목표를 달성하는 데 도움이 되는 고유한 속성을 제공합니다. 예를 들어 공유 스토리지를 사용하여 Pacemaker 및 Corosync(PCS) 클러스터를 구현할 수 있습니다. 관리 디스크 또는 Azure NetApp Files를 PCS 클러스터 인스턴스의 공유 스토리지로 사용할 수 있습니다. PCS 클러스터는 데이터를 복제하지 않습니다. 장애 조치(failover) 간에 변경되지 않는 고정 IP 주소 또는 IP 네트워크 이름을 가진 가상 IP 서비스를 제공합니다.
비고
PCS 클러스터는 Oracle 인증 솔루션이 아닙니다. 고가용성 아키텍처를 선택할 때 이 요소를 염두에 두십시오.
근접 배치 그룹 사용
가능한 가장 낮은 대기 시간을 제공하려면 VM을 가능한 한 가깝게 배치합니다. 근접 배치 그룹 내에 배포할 수 있습니다. 근접 배치 그룹은 Azure 컴퓨팅 리소스가 물리적으로 서로 가까이 있도록 하는 논리적 그룹화입니다. 근접 배치 그룹은 짧은 대기 시간이 필요한 워크로드에 유용합니다.
재해 복구를 위한 워크로드 구성
재해 복구 아키텍처는 Azure 데이터 센터 또는 지역에 영향을 주는 오류 또는 전체 지역에서 애플리케이션 기능을 방해하는 오류에 대한 복원력을 제공합니다. 이러한 시나리오에서는 전체 워크로드를 다른 데이터 센터 또는 지역으로 이동해야 합니다.
솔루션 요구 사항에 따라 재해 복구 아키텍처를 선택하십시오. RTO 및 RPO에 따라 요구 사항을 결정합니다. 재해 복구 아키텍처는 예외적인 장애 사례를 위한 것이므로 장애 조치(failover) 프로세스는 수동입니다. 고가용성 설계에서 장애 조치(failover) 프로세스는 자동으로 수행됩니다. 재해 복구 아키텍처에서는 RTO 및 RPO에 대한 요구 사항을 보다 완화해야 하므로 비용이 절감됩니다.
이 문서에서는 주 서버와 보조 서버가 모두 Azure에 있는 시나리오를 중점적으로 설명합니다. 재해 복구를 위해 온-프레미스에 주 서버와 Azure에 보조 서버를 사용할 수도 있습니다. 자세한 내용은 Azure의 기본 사이트 온-프레미스 및 재해 복구 사이트를 참조하세요.
올바른 재해 복구 옵션 선택
다음 순서도를 사용하여 Oracle 데이터베이스에 가장 적합한 재해 복구 옵션을 선택합니다.
재해 복구를 위해 Data Guard 사용
Data Guard를 사용하여 데이터를 재해 복구 사이트에 복제할 수 있습니다. 해당 사이트를 데이터 보호 요구 사항에 따라 동일한 지역 또는 다른 지역의 다른 가용성 영역으로 사용합니다. 또한 구성은 프로덕션 사이트의 가용성 영역 구조에 따라 달라집니다. 재해 복구 시나리오의 Data Guard 구현은 앞에서 설명한 고가용성 시나리오와 유사하지만 몇 가지 중요한 차이점이 있습니다. 다음은 그 예입니다.
고가용성 시나리오에서 보조 복제본으로 장애 조치(failover)하는 경우 요청을 새 주 데이터베이스 인스턴스로 리디렉션하도록 Azure Load Balancer 구성합니다.
재해 복구 사이트로 장애 조치하면 전체 솔루션이 새 사이트로 장애 조치됩니다. 대기 시간 문제를 방지하려면 일반적으로 응용 프로그램 서비스에 대한 장애 조치(failover)를 구성해야 합니다.
재해 복구 사이트가 다른 지역에 있는 경우 요구 사항에 따라 장애 조치(failover)를 위한 사이트를 설계해야 합니다.
단일 데이터 센터 내의 대기 시간은 서로 멀리 떨어져 있는 데이터 센터 간의 대기 시간보다 짧으며 서로 다른 지역 간의 대기 시간보다 훨씬 짧습니다. 따라서 가장 복잡하고 가장 저렴한 옵션은 재해 복구를 위해 최대 성능 모드에서 Data Guard를 사용하는 것입니다. 최대 성능 모드에서 잠재적 데이터 손실이 너무 높으면 Oracle Data Guard Far Sync 메커니즘과 함께 최대 가용성 모드를 사용할 수 있습니다. 그러나 Far Sync 인스턴스는 기본 환경 및 대기 환경에서 Active Data Guard 라이선싱을 트리거합니다. 자세한 내용은 Oracle 라이선스 세부 정보를 참조하세요.
또한 Azure 지역 또는 데이터 센터 간에 데이터를 보낼 때 재해 복구 사이트로 전송되는 다시 실행 로그와 같은 데이터에 대한 송신 비용을 지불합니다. 데이터베이스의 모든 데이터를 복제할 필요가 없는 경우 Oracle Golden Gate 기반 복제를 사용하여 필요에 따라 부분적인 데이터만 복제할 수 있으므로 송신 비용이 절감됩니다.
Azure에서 Data Guard의 단계별 구성은 Linux 기반 Azure Linux VM에서 Data Guard 구현을 참조하세요.
재해 복구를 위해 Golden Gate 사용
Golden Gate는 소스 데이터베이스에서 대상 데이터베이스로 또는 여러 주 데이터베이스 간에 데이터를 실시간으로 복제, 필터링 및 변환하는 데 사용할 수 있는 논리적 복제 소프트웨어입니다. 이 기능을 사용하면 원본 데이터베이스의 변경 내용이 거의 실시간으로 복제되어 대상 데이터베이스가 최신 데이터로 최신 상태가 됩니다.
Golden Gate를 사용하여 재해 복구 구성에서 기본 데이터베이스에서 보조 데이터베이스로 데이터를 복제할 수 있습니다. Golden Gate는 일부 데이터만 보호해야 하는 경우 특히 실용적입니다. 불필요한 데이터의 복제를 방지하려면 Golden Gate를 사용하여 테이블을 선택적으로 복제하고 복제 중에 테이블 행을 필터링합니다.
Azure에서 Golden Gate를 구현하는 방법에 대한 단계별 가이드는 Linux 기반 Azure VM에서 Golden Gate 구현을 참조하세요.
재해 복구를 위해 백업 사용
백업 및 복원은 재해 복구 아키텍처를 위한 전통적인 방법입니다. Azure의 Oracle 데이터베이스에 대한 재해 복구 방법으로 백업을 위한 두 가지 주요 구성 요소가 있습니다.
데이터베이스에서 데이터 백업을 추출하고 이동하여 재해 복구 사이트에 up-to날짜 데이터가 있는지 확인합니다.
재해 복구 사이트에서 up-to날짜 배포를 확인합니다. 사이트를 업데이트하려면 모든 네트워크 구성 요소, 응용 프로그램 서버 및 구성의 동일한 배포를 재해 복구 사이트에 복제합니다.
데이터를 복제하는 데 사용할 수 있는 몇 가지 백업 옵션이 있습니다. 자세한 내용은 Azure의 Oracle Database에 대한 백업 전략을 참조하세요.
다음 방법 중 하나를 사용하여 재해 복구 사이트를 유지 관리하는 것이 좋습니다.
접근법 1: 추가 유지 관리 노력과 비용을 방지하려면 재해 복구 사이트에서 물리적 배포를 유지 관리하지 마세요. 코드형 인프라 및 사이트 안정성 엔지니어링 사례를 사용하여 리포지토리를 개발하고 유지 관리할 수 있습니다. 이 저장소는 장애 조치(failover) 시 재해 복구 사이트에 대한 구성으로 배포를 복제할 수 있습니다. 이 방법은 장애 조치(failover)가 발생할 때까지 물리적 리소스를 사용하지 않기 때문에 비용을 최적화합니다.
중요합니다
장애 조치(failover) 중에 전체 배포를 처음부터 만드는 경우 배포가 솔루션의 RTO 요구 사항을 충족할 수 있는지 확인해야 합니다. 배포 코드가 손상되지 않도록 하려면 재해 복구 시나리오를 정기적으로 시뮬레이션하고 테스트해야 합니다.
접근 방식 2: 확장된 버전의 프로덕션 환경을 배포하고 유지 관리합니다. 작은 워크로드에 대해 제대로 작동할 수 있고 프로덕션 로드를 처리하기 위해 장애 조치(failover) 중에 필요에 따라 잠재적으로 확장할 수 있는 버전이 있어야 합니다. 이 방법은 일반적으로 사용되며, 특히 전체 환경을 만드는 위험을 감수하지 않으려는 복잡한 배포나 낮은 RTO를 제공하기 위해 신속하게 장애 조치(failover)하려는 경우에 사용됩니다.
접근법 3: 재해 복구 사이트에서 전체 솔루션을 배포하고 유지 관리하여 RTO 및 장애 조치(failover) 시간을 단축합니다. 이 방법은 완전히 중복된 인프라를 실행하기 때문에 비용이 증가합니다.
재해 복구를 구현하는 다른 방법 고려
다음 섹션에서는 재해 복구에 대한 특별한 고려 사항에 대해 설명합니다.
원거리 동기화 사용
Far Sync는 고가용성 기능을 개선하지 않지만 Oracle 데이터베이스에 대한 데이터 손실 방지 기능을 달성하는 데 사용할 수 있습니다. 워크로드는 기본 데이터베이스에 장애가 발생할 경우 데이터 손실이 필요하지 않을 수 있습니다. 자세한 내용은 Azure의 Oracle 참조 아키텍처를 참조하세요.
올바른 데이터 복제 기술 선택
이 문서의 기술 외에도 두 Oracle 데이터베이스 간의 데이터 복제를 용이하게 하는 모든 기술을 사용하여 Azure에서 Oracle 데이터베이스에 대한 고가용성 복제본 및 재해 복구 복제본을 유지 관리할 수 있습니다. 선택한 기술은 이러한 범주의 솔루션 요구 사항을 충족해야 합니다.
숨어 있음: 고가용성 및 재해 복구를 위해 주 데이터베이스에서 보조 데이터베이스로 업데이트를 복제하는 데 걸리는 시간은 솔루션의 요구 사항을 준수해야 합니다.
대역폭: 고가용성 및 재해 복구를 위해 보조 데이터베이스에 데이터를 복제하는 데 필요한 대역폭의 양과 비용입니다. Azure는 가용성 영역 간에 고속 네트워크 인프라를 제공합니다. 재해 복구를 위해 다른 Azure 지역으로의 복제를 고려하는 경우 Azure 데이터 센터를 떠나는 데이터의 대역폭 양과 송신 비용을 고려합니다.
영향: 복제가 주 데이터베이스의 트랜잭션 처리에 미치는 영향 수준은 솔루션의 요구 사항을 준수해야 합니다.
데이터 손실: 주 데이터베이스의 갑작스러운 오류 발생 시 예상되는 데이터 손실의 양은 솔루션의 요구 사항을 준수해야 합니다.
총 소유 비용: 타사 복제 솔루션에 대한 구입 비용과 복제 솔루션을 구성하고 유지 관리하는 데 필요한 노력의 양을 고려합니다. 이러한 요소가 솔루션의 요구 사항을 준수하는지 확인합니다.
장애 조치(failover) 인스턴스 최적화
고가용성 모드 또는 고가용성 모드에서 Data Guard를 사용하는 경우 기본 서버에 오류가 발생하면 보조 서버가 자동으로 작동되도록 자동 장애 복구를 구성할 수 있습니다. 응용 프로그램 서버를 적절하게 구성하면 장애 복구 중에 응용 프로그램 가동 중지 시간이 거의 없도록 할 수 있습니다.
이 구현에서 데이터베이스는 장애 조치(failover) 후에도 동일하게 실행되어야 합니다. 따라서 주 서버와 동일한 CPU, 메모리 및 I/O(입력/출력) 용량으로 보조 서버를 구성해야 합니다. 보조 서버를 사용하여 고용량을 유지해야 하며, 이로 인해 Azure 비용과 Oracle Database 라이선스 비용이 증가합니다. 보조 서버는 일반적으로 사용자 요청을 처리하지 않습니다.
Azure는 가용성 영역의 VM에 대해 99.9% 가용성을 제공합니다. 자세한 내용은 VM 작동 시간 SLA를 참조하세요. 데이터 복제 기술을 사용하여 데이터베이스의 보조 복제본을 동일한 가용 영역, 다른 가용 영역 또는 다른 리전에 유지 관리하는 경우 보조 용량을 최적화할 수 있습니다.
이 방법을 사용하면 보조 데이터베이스가 최신 상태로 유지되는 데 필요한 용량으로 구성됩니다. 오류가 발생하면 보조 데이터베이스의 크기가 주 데이터베이스와 동일한 용량으로 조정됩니다. 이 작업은 오류가 있는 경우에만 발생합니다. 따라서 정상 작동 중에는 기본 서버 비용의 일부만 지불하면 됩니다. 장애 중에는 주 데이터베이스가 작동하지 않으므로 다른 Oracle 데이터베이스 라이선스가 필요하지 않습니다.
보조 데이터베이스를 복제 대상으로 운영하는 데 필요한 용량은 사용하는 복제 기술에 따라 다릅니다. 기본적으로 트랜잭션 OLTP(온라인 트랜잭션 처리) 시스템에 있는 워크로드에는 주로 읽기 요청이 있습니다. 예를 들어 OLTP 애플리케이션에서는 90개의% 읽기 작업과 10개의% 쓰기 작업 또는 95개의% 읽기 작업과 5개의% 쓰기 작업이 일반적입니다. 데이터 복제는 기본적으로 소스 데이터베이스에서 요청을 쓴 결과를 복제합니다. 이 설정을 사용하면 보조 데이터베이스가 기본 데이터베이스 용량의 1/10(읽기 비율이 90%이고 쓰기 비율이 10%인 경우)으로 작동할 것으로 예상할 수 있습니다.
장애 조치(failover) 절차를 자동화하여 장애 조치 프로세스 중에 엔터프라이즈 표준을 충족하도록 합니다. 종단 간 프로세스를 간소화하는 서버 크기 조정 작업을 포함하도록 장애 조치 절차를 구성할 수 있습니다.
서비스 보호 및 데이터 보호를 위한 네트워크 토폴로지 구성
고가용성 및 재해 복구를 달성하려면 복구 시간(RTO) 및 잠재적 데이터 손실(RPO)과 다른 Oracle 라이선싱, VM 서비스 및 데이터 전송 비용의 균형을 맞추는 재무 및 비즈니스 결정을 내려야 합니다. 단일 Azure VM에서 워크로드를 호스트하면 저렴한 비용으로 일반적인 하드웨어 오류에 대한 기본 보호를 받을 수 있습니다. 그러나 단일 VM에서 오류가 발생하면 가동 중지 시간과 데이터 손실이 발생할 수 있습니다. 따라서 프로덕션 환경에서는 Data Guard를 사용하여 별도의 VM에서 호스팅되는 보조 Oracle 데이터베이스를 하나 이상 포함합니다. 요구 사항에 따라 데이터 복제에 다음 Data Guard 구성 중 하나 이상을 사용합니다.
최적의 RTO 및 RPO. 대기 시간을 최소화하려면 동일한 Virtual Machine Scale Sets 유연한 오케스트레이션 내의 별도 VM 및 주 데이터베이스와 동일한 가용성 영역에 보조 Oracle 데이터베이스를 통합합니다. 이 구성은 고가용성을 제공하고 단일 인스턴스 오류에 대한 보호를 제공합니다.
데이터 센터 장애로부터 데이터 보호. 보조 Oracle 데이터베이스를 두 번째 가용 영역에 배치하여 고가용성 설정을 제공하고 전체 가용 영역에 장애가 발생할 경우 보호를 제공합니다. 이 구성은 기본 데이터베이스와 보조 데이터베이스 간에 최대 2밀리초의 대기 시간을 가질 수 있으며, 이는 성능, RTO 및 RPO에 영향을 줄 수 있습니다.
지역 장애로부터 데이터 보호. Azure 지역 오류로 인한 잠재적인 데이터 손실을 방지하기 위해 보조 데이터베이스를 다른 지역에 배치할 수 있습니다. 이 구성은 지역 간에 30밀리초에서 300밀리초 사이의 대기 시간을 가질 수 있으므로 RTO 및 RPO 목표를 충족하지 못할 수 있습니다. 이 솔루션은 고가용성보다는 지역 재해 복구에 가장 적합합니다.
비즈니스 연속성을 위해서는 워크로드의 모든 구성 요소를 포함하는 통합된 접근 방식이 필요합니다. 네트워크 인프라는 Azure의 모든 워크로드에 대한 기본 구성 요소입니다. 네트워크 인프라는 고가용성 또는 재해 복구 아키텍처에 맞게 조정되어야 합니다. 다음과 같은 네트워크 인프라 요소를 고려합니다.
Data Guard는 고가용성을 제공하며 대부분의 시나리오에서 일반적인 오류에 대한 충분한 지원을 제공합니다. Virtual Machine Scale Sets 유연한 오케스트레이션에 VM을 배치할 수 있습니다. 네트워크 대기 시간을 줄이려면 단일 솔루션의 모든 서비스가 동일한 가용성 영역 내에 있어야 하며 서비스는 동일한 가상 네트워크를 공유해야 합니다.
추가 보호를 위해 VM을 단일 가용성 영역이 아닌 별도의 가용성 영역에 전략적으로 배치할 수 있습니다. 이 방법은 데이터 센터 오류 발생 시 가동 중지 시간을 방지할 수 있습니다.
최대한의 보호를 위해 주 데이터베이스 지역과 다른 Azure 지역에 보조 데이터베이스를 배치할 수 있습니다. 지속적인 업데이트를 적용하려면 Data Guard를 사용하여 글로벌 가상 네트워크 피어링을 구현할 수 있습니다. 이 방법을 사용하여 Microsoft 백본을 통해 보조 지역에 비공개로 데이터 업데이트를 적용합니다. 리소스는 게이트웨이, 추가 홉 또는 공용 인터넷을 통한 전송 없이 직접 통신합니다.
이 네트워킹 옵션은 서로 다른 지역의 피어링된 가상 네트워크에서 높은 대역폭, 짧은 대기 시간 연결을 제공합니다. 글로벌 가상 네트워크 피어링을 사용하여 고속 네트워크를 통해 기본 사이트를 다른 지역의 재해 복구 사이트에 연결할 수 있습니다.
다양한 오류 유형에 대한 복원력 요약
| 실패 시나리오 | Azure의 Oracle 고가용성 또는 재해 복구 시나리오 | RPO/RTO를 참조하십시오. |
|---|---|---|
| 단일 구성 요소 장애(예: 호스트, 랙, 냉각, 네트워킹 또는 전원 장애) | 동일한 데이터 센터에서 동일한 Virtual Machine Scale Sets 유연한 오케스트레이션에 두 개의 노드가 있는 Data Guard: - 단일 인스턴스 장애로부터 보호합니다. - 전체 데이터 센터에 장애가 발생하면 다운타임이 발생합니다. |
빠른 시작 페일오버 및 MAX_AVAILABILITY 위해 Observer를 사용하거나 Data Guard에 대한 MAX_PROTECTION 모드를 사용하는 경우: - RPO는 0입니다. - RTO가 2분 이하입니다. |
| 데이터 센터 오류 | 별도의 가용성 영역에 두 개의 노드가 있는 Data Guard: - 데이터 센터 장애로부터 보호합니다. - 전체 지역에 장애가 발생하면 다운타임이 발생합니다. - 네트워크 대기 시간을 관리하기 위해 앱 서버에 대한 더 많은 장애 조치(failover) 구성이 필요합니다. |
- RPO가 5분 이하인 경우 - RTO가 5분 이하입니다. Data Guard에 MAX_PERFORMANCE 모드 및 MAX_AVAILABILITY 모드를 사용하는 경우: - RPO는 0입니다. - RTO가 5분 이하입니다. |
| 지역 오류 | 별도의 Azure 지역에 두 개의 노드가 있는 Data Guard: - 지역별 장애로부터 보호합니다. - 네트워크 대기 시간을 관리하기 위해 앱 서버에 대한 더 많은 장애 조치(failover) 구성이 필요합니다. |
Data Guard에 MAX_PERFORMANCE 모드를 사용하는 경우: - RPO가 10분 이상입니다. - RTO가 15분 이상입니다. |
| 모든 시나리오: 단일 구성 요소, 데이터 센터 및 지역 오류 | 다른 Azure 지역으로 배송되는 백업: - 지역별 오류로부터 보호합니다. - 장애 조치(failover) 중에 대상 지역에 전체 Azure 환경을 설정해야 합니다. |
- RPO가 24시간 이상입니다. - RTO가 4시간 이상입니다. |
다음 단계
엔터프라이즈 규모 시나리오에서 Virtual Machines 랜딩 존 가속기 보안의 Oracle에 대한 설계 고려 사항에 대해 알아봅니다.