Azure Virtual Machines 랜딩 존 가속기에서 Oracle에 대한 비즈니스 연속성 및 재해 복구

이 문서는 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 및 PCS(Corosync) 클러스터를 구현할 수 있습니다. 관리 디스크 또는 Azure NetApp Files를 PCS 클러스터 인스턴스에 대한 공유 스토리지로 사용할 수 있습니다. PCS 클러스터는 데이터를 복제하지 않습니다. 장애 조치(failover)에서 변경되지 않는 고정 IP 주소 또는 IP 네트워크 이름을 사용하여 가상 IP 서비스를 제공합니다.

근접 배치 그룹 사용

가능한 가장 낮은 대기 시간을 제공하려면 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)합니다. 대기 시간 문제를 방지하려면 일반적으로 애플리케이션 서비스에 대한 장애 조치(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를 사용하여 테이블을 선택적으로 복제하고 복제 중에 테이블 행을 필터링합니다.

Azure에서 Golden Gate를 구현하는 방법에 대한 단계별 가이드는 Linux 기반 Azure VM에서 Golden Gate 구현을 참조 하세요.

재해 복구에 백업 사용

백업 및 복원은 재해 복구 아키텍처의 일반적인 방법입니다. Azure의 Oracle 데이터베이스에 대한 재해 복구 방법으로 백업을 위한 두 가지 주요 구성 요소가 있습니다.

• 데이터베이스에서 데이터 백업을 추출하고 이동하여 재해 복구 사이트에 최신 데이터가 있는지 확인합니다.

• 재해 복구 사이트에서 최신 배포를 확인합니다. 사이트를 업데이트하려면 모든 네트워크 구성 요소, 애플리케이션 서버 및 구성의 동일한 배포를 재해 복구 사이트에 복제합니다.

데이터를 복제하는 데 사용할 수 있는 몇 가지 백업 옵션이 있습니다. 자세한 내용은 Azure의 Oracle Database에 대한 Backup 전략을 참조 하세요.

재해 복구 사이트를 유지 관리하려면 다음 방법 중 하나를 사용하는 것이 좋습니다.

접근 방식 1: 추가 유지 관리 작업 및 비용을 방지하려면 재해 복구 사이트에서 물리적 배포를 유지 관리하지 마세요. 인프라를 코드 및 사이트 안정성 엔지니어링 사례로 사용하여 리포지토리를 개발하고 유지 관리할 수 있습니다. 이 리포지토리는 장애 조치 시 배포를 재해 복구 사이트에 구성으로 복제할 수 있습니다. 이 메서드는 장애 조치(failover)가 발생할 때까지 물리적 리소스를 사용하지 않으므로 비용을 최적화합니다.

방법 2: 확장된 프로덕션 환경 버전을 배포하고 유지 관리합니다. 작은 워크로드에 대해 제대로 작동할 수 있고 프로덕션 부하에 맞게 장애 조치(failover) 중에 필요에 따라 확장할 수 있는 버전이 있습니다. 이 메서드는 일반적으로 사용되며, 특히 전체 환경을 만드는 위험을 감수하지 않으려는 복잡한 배포 또는 낮은 RTO를 제공하기 위해 신속하게 장애 조치(failover)하려는 경우에 사용됩니다.

접근 방식 3: 가장 빠른 RTO 및 장애 조치(failover) 시간을 위해 재해 복구 사이트에서 전체 솔루션을 배포하고 유지 관리합니다. 이 메서드는 완전 중복 인프라를 실행하여 비용을 증가합니다.

재해 복구를 구현하는 다른 방법을 고려합니다.

다음 섹션에서는 재해 복구에 대한 특별한 고려 사항을 설명합니다.

원거리 동기화 사용

Far Sync는 고가용성 기능을 향상하지는 않지만 Oracle 데이터베이스에 대한 데이터 손실 방지 기능을 사용하지 않는 데 사용할 수 있습니다. 주 데이터베이스가 실패하는 경우 워크로드에 데이터 손실이 0이 필요할 수 있습니다. 자세한 내용은 Azure의 Oracle 참조 아키텍처를 참조하세요.

올바른 데이터 복제 기술 선택

이 문서의 기술 외에도 두 Oracle 데이터베이스에서 데이터 복제를 용이하게 하는 모든 기술을 사용하여 Azure의 Oracle 데이터베이스에 대한 고가용성 복제본 및 재해 복구 복제본을 유지할 수 있습니다. 선택하는 기술은 이러한 범주에서 솔루션 요구 사항을 충족해야 합니다.

대기 시간: 고가용성 및 재해 복구를 위해 주 데이터베이스에서 보조 데이터베이스로 업데이트를 복제하는 데 걸리는 시간은 솔루션의 요구 사항을 준수해야 합니다.

대역폭: 고가용성 및 재해 복구를 위해 보조 데이터베이스에 데이터를 복제하는 데 필요한 대역폭의 양과 비용입니다. Azure는 가용성 영역 간에 고속 네트워크 인프라를 제공합니다. 재해 복구를 위해 다른 Azure 지역으로 복제하는 것을 고려할 때 Azure 데이터 센터를 떠나는 데이터의 대역폭 양과 송신 비용을 고려합니다.

영향: 복제가 주 데이터베이스의 트랜잭션 처리에 미치는 영향 수준은 솔루션의 요구 사항을 준수해야 합니다.

데이터 손실: 주 데이터베이스가 갑자기 실패하는 동안 예상되는 데이터 손실의 양은 솔루션의 요구 사항을 준수해야 합니다.

총 소유 비용: 비 Microsoft 복제 솔루션의 취득 비용과 복제 솔루션을 구성하고 유지 관리하는 데 필요한 노력을 고려합니다. 이러한 요소가 솔루션의 요구 사항을 준수하는지 확인합니다.

장애 조치(failover) 인스턴스 최적화

고가용성 모드 또는 높은 보호 모드에서 Data Guard를 사용하는 경우 주 서버가 실패할 때 보조 서버가 자동으로 발생되도록 자동 장애 조치(failover)를 구성할 수 있습니다. 애플리케이션 서버를 올바르게 구성하면 장애 조치(failover) 중에 애플리케이션 가동 중지 시간이 거의 없는지 확인할 수 있습니다.

이 구현에서는 장애 조치(failover) 후 데이터베이스가 동일하게 실행되어야 합니다. 따라서 주 서버와 동일한 CPU, 메모리 및 입력/출력(I/O) 용량을 가진 보조 서버를 구성해야 합니다. 보조 서버를 사용하여 대용량을 유지 관리해야 하므로 Azure 비용과 Oracle Database 라이선스 비용이 증가합니다. 보조 서버는 일반적으로 사용자 요청을 처리하지 않습니다.

Azure는 가용성 영역의 VM에 대해 99.9%의 가용성을 제공합니다. 자세한 내용은 VM 작동 시간 SLA를 참조하세요. 데이터 복제 기술을 사용하여 동일한 가용성 영역, 다른 가용성 영역 또는 다른 지역에서 데이터베이스의 보조 복제본을 유지 관리하는 경우 보조 용량을 최적화할 수 있습니다.

이 방법을 사용하면 보조 데이터베이스가 최신 상태로 유지되어야 하는 용량으로 구성됩니다. 오류가 발생하면 보조 데이터베이스의 크기가 주 데이터베이스와 동일한 용량으로 조정됩니다. 이 작업은 오류가 발생한 경우에만 발생합니다. 따라서 정상 작동 중에는 주 서버 비용의 일부만 지불합니다. 주 데이터베이스는 실패하는 동안 작동하지 않으므로 다른 Oracle 데이터베이스 라이선스가 필요하지 않습니다.

보조 데이터베이스를 복제 대상으로 작동하는 데 필요한 용량은 사용하는 복제 기술에 따라 달라집니다. 기본적으로 OLTP(트랜잭션 온라인 트랜잭션 처리) 시스템에 있는 워크로드에는 주로 읽기 요청이 있습니다. 예를 들어 90% 읽기 및 10% 쓰기 작업 또는 95% 읽기 및 5% 쓰기 작업은 OLTP 애플리케이션에서 일반적입니다. 데이터 복제는 기본적으로 원본 데이터베이스에서 요청을 작성한 결과를 복제합니다. 이 설정을 사용하면 보조 데이터베이스가 주 데이터베이스 용량의 1/10(읽기 90%와 쓰기 비율이 10%인 경우)으로 작동할 것으로 예상할 수 있습니다.

장애 조치(failover) 프로세스 중에 엔터프라이즈 표준을 충족하도록 장애 조치 절차를 자동화합니다. 엔드 투 엔드 프로세스를 간소화하는 서버 크기 조정 작업을 포함하도록 장애 조치 절차를 구성할 수 있습니다.

서비스 보호 및 데이터 보호를 위한 네트워크 토폴로지 구성

고가용성 및 재해 복구를 달성하려면 복구 시간, RTO, 잠재적 데이터 손실 또는 RPO와 다른 Oracle 라이선싱, VM 서비스 및 데이터 전송 비용의 균형을 맞추는 재무 및 비즈니스 결정을 내려야 합니다. 단일 Azure VM에서 워크로드를 호스트하는 경우 저렴한 비용으로 일반적인 하드웨어 오류에 대한 기본 보호를 받습니다. 그러나 단일 VM에서 오류가 발생하면 가동 중지 시간 및 데이터 손실이 발생할 수 있습니다. 따라서 프로덕션 환경에서 Data Guard를 사용하여 별도의 VM에 호스트되는 하나 이상의 보조 Oracle 데이터베이스를 포함합니다. 요구 사항에 따라 데이터 복제에 다음 Data Guard 구성 중 하나 이상을 사용합니다.

• 최적의 RTO 및 RPO. 대기 시간을 최소화하려면 보조 Oracle 데이터베이스를 동일한 Virtual Machine Scale Sets 유연한 오케스트레이션 내의 별도 VM 및 주 데이터베이스와 동일한 가용성 영역에 통합합니다. 이 구성은 단일 인스턴스 오류에 대한 고가용성 및 보호를 제공합니다.

• 데이터 센터 오류로부터 데이터 보호. 보조 Oracle 데이터베이스를 두 번째 가용성 영역에 배치하여 고가용성 설정을 제공하고 전체 가용성 영역이 실패할 경우 보호를 제공합니다. 이 구성은 주 데이터베이스와 보조 데이터베이스 간에 최대 2밀리초의 대기 시간을 가질 수 있으며 성능, RTO 및 RPO에 영향을 줄 수 있습니다.

• 지역별 오류로부터 데이터 보호. Azure 지역 오류로 인한 잠재적인 데이터 손실로부터 보호하기 위해 보조 데이터베이스를 다른 지역에 배치할 수 있습니다. 이 구성은 지역 간에 30밀리초에서 300밀리초의 대기 시간을 가질 수 있으므로 RTO 및 RPO 목표를 충족하지 못할 수 있습니다. 이 솔루션은 고가용성보다는 지역 재해 복구에 가장 적합합니다.

비즈니스 연속성을 위해서는 워크로드의 모든 구성 요소를 포함하는 통합된 접근 방식이 필요합니다. 네트워크 인프라는 Azure의 모든 워크로드에 대한 기본 구성 요소입니다. 네트워크 인프라는 고가용성 또는 재해 복구 아키텍처에 맞춰야 합니다. 다음 네트워크 인프라 요소를 고려합니다.

• Data Guard는 고가용성을 제공하며 대부분의 시나리오에서 일반적인 오류에 대한 충분한 지원을 제공합니다. VM을 Virtual Machine Scale Sets 유연한 오케스트레이션에 배치할 수 있습니다. 네트워크 대기 시간을 줄이려면 단일 솔루션의 모든 서비스가 동일한 가용성 영역 내에 있어야 하며 서비스는 동일한 가상 네트워크를 공유해야 합니다.

  추가 보호를 위해 VM을 단일 가용성 영역이 아닌 별도의 가용성 영역에 전략적으로 배치할 수 있습니다. 이 방법은 데이터 센터 오류 중에 가동 중지 시간을 방지할 수 있습니다.

• 최대 보호를 위해 주 데이터베이스 지역과 다른 Azure 지역에 보조 데이터베이스를 배치할 수 있습니다. 지속적인 업데이트를 적용하려면 Data Guard를 사용하여 글로벌 가상 네트워크 피어링을 구현할 수 있습니다. Microsoft 백본을 통해 보조 지역에 데이터 업데이트를 비공개로 적용하려면 이 방법을 사용합니다. 리소스는 게이트웨이, 추가 홉 또는 공용 인터넷을 통해 전송하지 않고 직접 통신합니다.

  이 네트워킹 옵션은 서로 다른 지역의 피어링된 가상 네트워크에서 높은 대역폭, 짧은 대기 시간 연결을 제공합니다. 글로벌 가상 네트워크 피어링을 사용하여 고속 네트워크를 통해 기본 사이트를 다른 지역의 재해 복구 사이트에 연결할 수 있습니다.

다양한 오류 유형에 대한 복원력 요약

다음 단계

엔터프라이즈 규모 시나리오에서 Virtual Machines 랜딩 존 가속기 보안의 Oracle에 대한 디자인 고려 사항에 대해 알아봅니다.

Virtual Machines 랜딩 존 가속기에서 Oracle에 대한 보안 지침