장애 복구란 무엇인가요?

장애 복구(DR)는 조직 내 다양한 업무 라인에서 고안하고 유지 관리하는 중요한 비즈니스 연속성 계획의 한 측면입니다. 효과적인 장애 복구 계획을 통해 미션 크리티컬 시스템 및 비즈니스 크리티컬 시스템의 계획되지 않은 또는 계획된 운용중단이 기업의 운영 능력 및 지속적인 수익 창출에 미치는 영향을 완화할 수 있습니다.

이를 위해 장애 복구 계획은 조직에 통합된 협업 방식으로 작동하여 시스템을 복원, 재개발 및 활성화하고 보다 탄력적인 기반구조를 구축할 수 있는 유연한 구조를 제공합니다.

장애 복구가 중요한 이유는 무엇입니까?

급여가 계산되고 계정이 자금 조달되기 직전에 급여 시스템이 손실되는 경우 비즈니스는 얼마나 오래 계속 운영할 수 있습니까? 연방세, 주세 및 지방세의 납부가 지연되면 회사에 어떤 위약금이 부과됩니까? 직원들에게 제때 급여를 지급하지 않을 경우 회사는 어떤 결과에 직면하게 되며 직원들은 얼마나 오래 일하게 될까요?

장애 복구를 수행하거나 수행하지 않으려면? 더 이상 질문이 되지 않습니다. 진짜 질문은 몇 분, 며칠, 몇 주 동안 축적된 중요한 데이터와 신뢰를 순식간에 잃는 진정한 비용이 얼마냐는 것입니다.

장애 복구는 오늘날의 조직이 업무 중단에 신속하게 대응하고 운영 상태를 유지할 것으로 예상되기 때문에 예산이 충분할 때만 고려할 수 있습니다. 조직은 탄력성 플랜을 구현하는 데 드는 비용으로 인해 좌절하기보다는 플랜을 전혀 수립하지 못한 실제 비용을 더 깊이 있게 검토하고 평가해야 합니다. 예를 들어, 충족할 수 없었던 SLA(서비스 수준 계약)나 운용중단으로 인한 위약금 및 수익 손실을 검토합니다. DR 구현에 드는 비용과 위약금, 매출 손실, 고객 신뢰 손실 등이 유발하는 비용을 비교해 보면 어떤 선택을 해야 할지 쉽게 알 수 있습니다.

이미지는 "매출, 생산성 및 충성도 손실"이라는 제목으로 표시됩니다. 이 이미지에는 세 가지 주요 통계가 표시됩니다. 이러한 통계는 2019년 IBM을 대신하여 Forrester Consulting이 수행한 위탁연구에서 도출되었습니다. 설문 응답자에게 던진 질문은 "계획된 작동 중지 시간과 계획되지 않은 작동 중지 시간으로 인해 조직이 직면한 비용은 다음 중 무엇입니까?"였습니다.
왼쪽에 표시된 통계는 조사 대상자의 53%가 "수익 손실"이라고 응답했음을 보여줍니다. 평균적으로 47%가 '생산성 손실'이라고 응답했습니다. 오른쪽은 41%가 '브랜드 자산 또는 신뢰 상실'이라고 응답한 것으로 나타났습니다.

계획되지 않은 운용중단

운용중단이 자연 재해, IT 운영자/서비스 제공자 오류, 데이터 손상 또는 랜섬웨어 공격으로 인해 발생하는 비즈니스 운영 중단, 기회주의적 경쟁업체로 대체, 평판 및 선의 인가 손실로부터 조직을 보호할 수 있어야 합니다.

이러한 결과는 극적인 것처럼 보이지만, 적시에 복구하지 못하고 대량의 중요한 트랜잭션 데이터, 고객 정보 및 신뢰를 잃어버린 잘 알려진 여러 조직의 최근 경험을 반영합니다.

다양한 시나리오와 근본 원인이 비즈니스 운영을 방해할 수 있습니다.

이 이미지의 제목은 "계획되지 않은 작동 중지 시간의 주요 원인"입니다. 이미지에 계획되지 않은 운용중단의 원인을 보여주는 막대 차트가 표시됩니다. 막대 차트는 운영 실패, 자연 재해, 사람이 일으킨 이벤트의 세 가지 범주로 나뉩니다. 작동 실패는 막대 차트의 맨 왼쪽 부분에, 자연 재해는 가운데에, 사람이 일으킨 이벤트는 막대 차트의 맨 오른쪽 부분에 그룹화됩니다. 이 차트의 출처는 Forrester Research, Inc.입니다.

계획된 운용중단

클라우드에서 서비스형 장애 복구(DRaaS)는 기업에 운영 유연성을 위한 탁월한 옵션을 제공합니다. 조직은 장애 복구 솔루션보다 계획된 운용중단에 대해 장애 복구 솔루션을 더 자주 사용합니다.

일반적인 고충 사항

• 장애 복구에 대한 기존 접근 방식에는 자동화에 대한 투자가 필요합니다.
• 계층 1 데이터 센터의 비즈니스 시스템도 정전의 영향을 받을 수 있습니다. 정전은 너무 자주 발생합니다. 정전과 같은 일반적인 사고로 인해 하루 또는 이틀 동안 생산성이 손실된 적이 얼마나 자주 있습니까? IT 직원은 결국 임시 솔루션을 사용하여 시스템을 다시 시작하고 실행하는 컨퍼런스 통화에 몇 시간 또는 며칠을 소비하게 됩니다. • 일부 기업은 장애 복구 관리를 위한 구내 자동화 개발에 IT 예산의 상당 부분을 투자하지만, 장애 복구를 사용하는 것을 두려워하거나 장애 복구가 예상대로 계속 작동하는지 확인하기 위해 정기적으로 테스트하기도 합니다. •계획된 유지 보수 기간에서 복구하는 데 종종 하루(또는 며칠)가 걸립니다. • 제대로 문서화된 장애 복구 플랜이나 실행서조차도 며칠 동안 생산성이 저하되고, IT 운영 직원은 업무를 다시 운영하기 위해 초인적인 행동을 할 수 있습니다.

장애 복구의 주요 목표

장애 복구의 두 가지 주요 목표는 영향을 받는 시스템을 가능한 한 빨리 운영 상태로 되돌리는 것이며, 장애 발생 또는 계획된 운용중단 후 데이터 손실을 최대한 줄이는 것입니다. 이러한 두 가지 주요 목표에 대한 척도는 일반적으로 각각 RTO(복구 시간 목표)와 RPO(복구 시점 목표)로 알려져 있습니다.

각 비즈니스 시스템은 IT 운영 및 비즈니스 소유자 간의 서비스 레벨 계약에 따라 이 두 가지 척도에 대한 요구 사항이 다릅니다.

이미지의 제목은 "데이터 보호 용어"입니다. 데이터 손실에 대한 허용오차와 작동 중지 시간에 대한 허용오차가 이미지 중심에서 반대 방향으로 확장되는 직선에 표시됩니다. 왼쪽에는 "데이터 손실"이, 오른쪽에는 "작동 중지 시간"이 있습니다.

복구 시간 목표(RTO)

복구 시간 목표는 계획된 운용중단 또는 계획되지 않은 운용중단 후 비즈니스 시스템을 완전한 운영 상태로 복원하는 데 걸리는 시간입니다.

복구 목표 시점(RPO)

복구 시점 목표는 특정 비즈니스 시스템에 해로운 영향을 미치기 전에 손실될 수 있는 최대 데이터 양입니다. RPO는 일반적으로 마지막 데이터 백업, 복제 또는 스냅샷의 델타에서 시간 단위로 측정됩니다.

장애 복구와 고 가용성 비교

기존 고 가용성(HA)은 단일 장애 지점을 보호하는 반면 장애 복구는 여러 장애 지점을 보호합니다. 클라우드 컴퓨팅에서 전원, 냉각, 스토리지, 네트워크 및 물리적 서버를 비롯한 물리적 기반 구조 계층의 단일 장애 지점에 대한 보호 기능은 가용성 및 장애 도메인을 통해 전체 구조로 완전히 추상화됩니다.

이 경우 고 가용성은 확장 가능하고 데이터 손실 또는 처리 성능 상실에 대한 복원력이 매우 높습니다. 거의 모든 엔터프라이즈급 클라우드 제공자가 자사의 오퍼링에 고 가용성을 구축합니다.

복잡한 데이터 매핑 및 복제 기술을 사용하면 데이터베이스에 데이터 손실 및 작동 중지 시간 방지 기능을 제공하는 고 가용성 장애 복구 솔루션은 비용이 많이 듭니다. 이러한 솔루션은 적시 복구 목표 및 불변 스토리지를 갖춘 포괄적인 백업을 통해 달성되는 랜섬웨어 보호 기능을 제공하지 않습니다.

기존 고 가용성 솔루션은 저비용 클라우드 DR(CDR) 솔루션과 함께 잘 작동합니다. 애드온 CDR 기술은 데이터 손실이 전혀 없고 작동 중지 시간이 없는 고 가용성을 필요로 하며 장기 증분 롤백을 통한 랜섬웨어 보호가 필요한 데이터베이스를 위한 추가적인 보호 계층을 제공합니다.

온프레미스 DR은 소스 위치 및 고정 대상 데이터 센터 위치에 IT 기반 구조를 복제하는 데 많은 비용이 소요되므로 유연성이 떨어지고 비용이 많이 드는 솔루션입니다. WAN을 통해 작동하거나 서로 다른 환경 간에 서버를 마이그레이션할 수 없으므로 단일 상호 연결된 LAN 환경처럼 작동하려면 소스 및 대상 데이터 센터 간의 전용 회로가 필요합니다. 또한 기존의 장애 복구는 온프레미스 환경과 클라우드 플랫폼 또는 두 개의 서로 다른 클라우드 플랫폼 간에 서로 다른 이기종 환경 간에 서버를 마이그레이션할 수 없습니다.

DRaaS는 공급업체가 제공하는 백업 솔루션과 오픈 소스 이전 툴의 패치워크를 사용하여 엄격하게 제어되고 매우 구체적인 환경을 구축합니다. 최종 사용자는 VMware 사내 환경에서 DRaaS 제공자의 기존 호스팅 환경의 워크로드만 복구할 수 있습니다. 공급업체가 제공하는 이러한 솔루션은 비용이 많이 들고 보호할 수 있는 워크로드와 지원할 수 있는 컴퓨트 환경의 범위가 제한적일 수 있습니다.

장애 복구 워크플로, 실행서 및 플랜

Oracle에서는 보통 DR 워크플로를 DR 플랜이라고 칭합니다. 장애 복구 플랜 또는 실행서는 컴퓨트 인스턴스, 플랫폼, 데이터베이스 및 애플리케이션을 클라우드의 사전 결정된 복구 영역으로 전환하기 위해 완료해야 하는 사전 결정된 단계 또는 작업 목록입니다. 여기에는 스위치오버 또는 페일오버와 같은 장애 복구 작업 중에 사람 또는 일종의 자동화에 의해 실행되는 모든 작업이나 개별 단계가 포함됩니다. 장애 복구 플랜, 장애 복구 실행서 및 장애 복구 워크플로라는 용어는 서로 바꿔서 사용할 수 있습니다.

장애 복구 작업(스위치오버와 페일오버 비교)

장애 복구 작업은 인프라, 데이터베이스 및 애플리케이션을 전체 작동 상태로 복원하는 데 필요한 장애 복구 플랜에서 미리 결정된 각 단계 또는 작업을 실행하는 프로세스입니다. 애플리케이션 스택의 다른 위치로의 전환을 설명하는 데 페일오버 및 스위치오버이라는 두 가지 용어가 사용됩니다.

페일오버

페일오버란 애플리케이션, 데이터베이스 및 가상 머신이 충돌하고 스토리지, 데이터 및 게스트 운영체제를 포함한 모든 리소스가 일관성이 없는 상태인 계획되지 않은 운용중단을 의미합니다. 이 경우 주요 클라우드 영역은 완전히 액세스할 수 없고 사용할 수 없는 것으로 가정되며, 이는 실제 장애 복구 작업을 트리거해야 함을 나타냅니다.

따라서 장애 복구 플랜의 모든 장애 복구 작업은 대기 클라우드 영역에서만 수행할 수 있습니다. 클라우드 제공자의 DRaaS 솔루션은 장애가 발생했을 때 액세스 가능하고 기능할 수 있도록 대기 영역에서 고 가용성을 제공하도록 설계되는 것이 중요합니다.

스위치오버

스위치오버는 애플리케이션, 데이터베이스, 가상 시스템 또는 서버의 순차적 종료를 포함하는 계획된 작동 중지 시간을 의미합니다. 이 경우 주요 영역과 대기 영역이 모두 정상적으로 작동하며, IT 운영 직원은 유지 보수를 위해 한 지역에서 다른 지역으로 하나 이상의 시스템을 "이동"하거나 롤링 업그레이드를 완료하는 데 집중할 가능성이 높습니다.

클라우드 배포 전략

최신 기업은 비용, 성능 및 비즈니스 연속성 요구 사항을 비롯한 다양한 이유로 다음 클라우드 배포 모델 중 하나 이상을 활용할 수 있습니다. 기업들이 운영을 클라우드로 계속 전환함에 따라 강력한 클라우드 배포 전략이 점점 더 보편화되고 있습니다.

영역 간 장애 복구 솔루션

영역 간 장애 복구 솔루션은 단일 클라우드 제공자의 클라우드 기반 구조에 호스팅되는 비즈니스 시스템에 대한 액세스에 영향을 미칠 수 있는 완벽한 운용중단으로부터 조직을 보호합니다. 이름에서 알 수 있듯이 가상 머신, 데이터베이스 및 애플리케이션을 포함한 모든 비즈니스 시스템의 전체 애플리케이션 스택을 필요에 따라 다른 지오로케이션의 완전히 다른 클라우드 영역으로 전환할 수 있습니다.

DRaaS 솔루션은 인사관리 포털, 금융 서비스 포털 또는 엔터프라이즈 리소스 관리 애플리케이션과 같은 전체 엔터프라이즈 시스템을 완전히 다른 클라우드 영역으로 전환할 수 있어야 합니다. DRaaS는 각 개별 애플리케이션에 대한 서비스 레벨 계약에 필요한 복구 시간 및 복구 시점 목표를 충족할 수 있어야 합니다.

Oracle Cloud Infrastructure(OCI) 풀스택 장애 복구와 같은 영역 간 장애 복구 솔루션은 해당 영역의 모든 가용성 도메인 손실을 포함하여 전체 클라우드 영역에 대한 대대적인 액세스 손실로부터 전체 엔터프라이즈 애플리케이션을 보호합니다.

하이브리드 클라우드 장애 복구 솔루션

하이브리드 클라우드 장애 복구는 기업이 워크로드와 가상 머신을 자체 데이터 센터에서 클라우드 인프라로 전환할 수 있도록 지원하는 매우 인기 있는 솔루션입니다. 하이브리드 클라우드는 기업 주요 비즈니스 시스템의 데이터와 실행 가능성을 보호하기 위한 장애 복구 솔루션으로 자주 사용됩니다.

Oracle 고객에게 하이브리드 클라우드는 OCI와 물리적 서버, Oracle 클라우드 어플라이언스 또는 기업의 물리적 데이터 센터에서 실행 중인 다른 시스템 간의 원활한 연결을 의미합니다. Oracle Private Cloud Appliance X9-2 및 Oracle Exadata Cloud@Customer와 같은 Oracle 클라우드 어플라이언스는 OCI와 완벽하게 통합된 온프레미스 시스템의 우수한 예입니다.

Rackware와 같은 Oracle 파트너의 일부 제품은 온프레미스 인프라와 OCI 간 장애 복구를 달성하는 데 사용될 수 있습니다. Rackware는 Oracle Cloud Marketplace를 통해 제공됩니다.

멀티클라우드 장애 복구 솔루션

멀티클라우드 장애 복구 솔루션은 애플리케이션 스택의 다양한 구성요소를 두 개 이상의 클라우드 제공자의 클라우드 기반 구조에 분산시켜 애플리케이션과 데이터를 보호합니다. Oracle과 Microsoft Azure의 파트너십은 멀티클라우드 관계의 좋은 예입니다..

서비스형 장애 복구는 영역 간 장애 복구, 하이브리드 클라우드 장애 복구 및 멀티클라우드 장애 복구를 수용할 수 있어야 합니다. OCI는 현재 영역 간 장애 복구 및 하이브리드 클라우드 장애 복구를 위한 DRaaS를 제공할 수 있습니다.

데이터베이스를 위한 데이터 일관성

데이터베이스를 포함하는 실행 가능한 장애 복구 솔루션에는 항상 데이터 일관성을 보장하는 수단이 포함되어야 합니다. 데이터베이스를 실행 중인 트랜잭션을 포함하여 전체 데이터 일관성으로 복구할 수 있는 지점은 복구 지점 목표를 정의합니다.

서버리스 또는 플랫 파일 데이터베이스에서는 데이터 일관성이 훨씬 적지만 Oracle Database 또는 MySQL과 같은 정교한 관계형 데이터베이스를 적시에 데이터 일관성 있는 상태로 복구하는 것은 매우 복잡하지만 여전히 중요합니다.

MySQL 데이터베이스에 대한 장애 복구 고려 사항

OCI에서 MySQL 데이터베이스 서비스를 사용할 때 MySQL 데이터베이스 시스템은 하나 이상의 MySQL 인스턴스를 위한 논리적 컨테이너입니다. 프로비저닝, 자동 백업 및 적시 복구와 같은 작업을 관리할 수 있는 인터페이스를 제공합니다.

MySQL 이진법 로그 및 네이티브 복제 기술을 통해 시점 복구, 고 가용성 및 장애 복구가 가능합니다. MySQL 그룹 복제는 일반적으로 고 가용성을 위해 로컬 내결합성 클러스터를 생성하는 데 사용되는 반면, MySQL 비동기 복제는 일반적으로 지리적으로 분산된 장애 복구에 사용됩니다.

고 가용성을 사용하도록 설정된 데이터베이스 시스템에는 서로 다른 가용성 도메인 또는 결함 도메인에 배치된 세 개의 MySQL 인스턴스가 있습니다. 데이터베이스 시스템은 한 인스턴스가 실패할 경우 다른 인스턴스가 데이터 손실 없이 최소한의 작동 중지 시간으로 이어받도록 보장합니다. 서로 다른 지역의 장애 복구를 위해 두 데이터베이스 시스템 간에 인바운드 복제 채널을 만들 수도 있습니다.

다음 링크를 통해 클라우드에서 MySQL의 장애 복구에 대해 자세히 알아봅니다.

• MySQL을 위한 비즈니스 연속성 개요
• MySQL을 위한 비즈니스 고 가용성 개요
• MySQL을 위한 인바운드 복제 개요

Oracle 데이터베이스를 위한 장애 복구 고려 사항

Oracle Maximum Availability Architecture(MAA)는 Oracle 데이터베이스를 위한 아키텍처, 구성 및 라이프사이클 모범 사례를 제공하여 온프레미스, 클라우드 또는 하이브리드 구성 내 데이터베이스의 고가용성 서비스 수준을 지원합니다.

다음 링크를 통해 클라우드에서의 장애 복구를 위한 Oracle Maximum Availability Architecture에 대해 자세히 알아봅니다.

• Oracle Maximum Availability Architecture 랜딩 페이지
• Oracle Maximum Availability Architecture 참조 구조
• Oracle Maximum Availability Architecture Oracle Fusion Middleware에 대한 모범 사례
• Oracle Maximum Availability Architecture 애플리케이션 모범 사례

클라우드 기반 배포 아키텍처

배포 구조는 클라우드 영역 간에 컴퓨팅, 플랫폼/데이터베이스 및 애플리케이션과 같은 다양한 구성 요소를 구축하여 데이터 센터의 전체 장애로부터 복구하는 탄력적인 방법을 설명합니다. 배포 구조는 애플리케이션 스위트의 정상적인 운영 중에 모든 것이 위치한 위치와 대기 영역에서 복구해야 할 작업을 다시 실행할 수 있는 사항을 설명합니다.

Oracle은 DRaaS 솔루션은 고유한 비즈니스 시스템 각각에 대한 개별 서비스 수준 요구 사항을 충족하기 위해 DR 배포 아키텍처의 모든 조합을 수용할 수 있는 유연성을 제공해야 한다고 믿습니다. 클라우드 제공자는 조직이 일반적으로 지원하는 다양한 비즈니스 시스템의 SLA를 충족하기 위해 고객에게 "위 모든" 솔루션을 선택할 수 있는 자유를 제공해야 합니다.

장애 복구 전략 및 배포 구조를 설명하는 데 많은 용어가 사용됩니다. 그러나 장애 복구를 위해 인프라, 플랫폼 및 애플리케이션을 구축하는 방법을 설명하는 다양한 접근 방식과 패턴은 활성/활성 및 활성/대기 장애 복구의 두 가지 전략 범주로 분류됩니다.

다음 표에서는 두 가지 광범위한 장애 복구 전략에 속하는 다양한 배치 구조를 설명하는 데 사용되는 일반적인 용어를 분석합니다.

전략	배포 구조	RPO	RTO
활성/대기	콜드 스탠바이	시간	시간
활성/대기	파일럿 라이트	분	시간
활성/대기	웜 스탠바이	시간(초)	시간
활성/대기	핫 스탠바이	시간(초)	분
활성/활성	활성/활성	0에 가까움	0에 가까움

이 섹션에서는 장애 복구에 대한 액티브/액티브 및 액티브/스탠바이 접근 방식의 몇 가지 변형을 보여줍니다. 두 장애 복구 전략 모두 비즈니스 연속성을 달성하기 위해 사용할 수 있는 무기고에 자리를 잡고 있습니다.

활성/스탠바이 배포 구조

활성/스탠바이 배포 구조에는 다양한 변형이 있습니다. 액티브/패시브 배포라고도 하는 액티브/스탠바이 배포는 종종 파일럿 라이트, 콜드, 웜 및 핫 스탠바이 배포의 특징을 갖습니다.

파일럿 라이트, 콜드 스탠바이, 웜 스탠바이 및 핫 스탠바이 시나리오는 모두 애플리케이션 스택의 100%가 주요 영역에서 실행되는 반면 동일한 비즈니스 시스템의 100% 미만이 대기 영역에서 활발하게 실행되는 동일한 테마의 일부 형태를 나타냅니다.

다음 일련의 매우 높은 레벨의 개념 다이어그램은 공통 배치 구조 간의 몇 가지 근본적인 차이점을 설명하기 위한 것이며 참조 구조로 의도된 것이 아닙니다. 애플리케이션 스택에 대한 장애 복구 구현 방법을 설명하지 않습니다.

콜드 스탠바이

이 시나리오에서는 가상 머신(VM), 데이터베이스 및 애플리케이션이 현재 주요 영역에만 존재합니다. 각 VM의 부팅 디스크 및 기타 가상 디스크가 포함된 파일 및 블록 스토리지 볼륨 그룹이 대기 영역에 복제됩니다.

주요 영역이 왼쪽에 있고 대기 영역이 오른쪽에 있는 이미지를 표시합니다. 주요 영역에는 애플리케이션, 데이터베이스 및 기반 구조의 세 가지 블록이 있으며, 각 블록에는 각각의 아이콘이 포함되어 있습니다. 두 영역 모두 상단에 로드 밸런서를 나타내는 아이콘이 있습니다. 대기 영역의 로드 밸런서 아이콘이 주요 영역의 아이콘보다 밝습니다. 대기 영역에는 애플리케이션, 데이터베이스 및 기반 구조의 세 가지 블록이 있습니다. 대기 영역에서는 기반 구조 블록에만 객체 스토리지, 블록 스토리지 및 파일 스토리지를 위한 아이콘이 하나씩 채워집니다. 대기 영역의 데이터베이스 및 애플리케이션 블록이 비어 있습니다. 두 기반 구조 블록 사이에 객체 스토리지 복제 및 스토리지 복제를 나타내는 화살표 두 개가 표시됩니다. 이 화살표는 주요 영역에서 대기 영역으로 복제를 나타냅니다.

스위치오버 또는 페일오버와 같은 장애 복구 작업 중에 동일한 VM을 포함하는 복제된 스토리지가 대기 영역에서 활성화되고 동일한 VM이 중지되거나 충돌한 지점에서 다시 시작됩니다. VM은 이전에 활성 영역에서 실행되었던 것과 동일한 가상 머신입니다.

이 배포 구조는 낮은 배포 비용, 낮은 유지보수 간접비 및 낮은 운영 비용을 포함한 몇 가지 이점을 제공합니다. 그러나 데이터의 일관성을 보장하는 유일한 방법은 주기적으로 콜드 백업을 수행하는 것이기 때문에 백엔드의 관계형 데이터베이스에 의존하는 애플리케이션에는 이 솔루션이 가장 적합한 솔루션이 아닐 수 있습니다. 이 접근 방식은 짧고 완전한 운용중단을 견딜 수 있는 애플리케이션에 적합합니다.

대부분의 IT 운영은 데이터베이스를 주기적으로 종료하고 블록 스토리지의 스냅샷을 생성한 다음 정상 운영을 재개함으로써 이 문제를 해결합니다. 백업이 완료된 적시에만 복원할 수 있으므로 복구 지점 목표를 정의합니다.

이 구조는 복구 시간이 약간 길어지고 데이터 손실 위험이 훨씬 더 커지지만 올바른 워크로드를 위한 실행 가능한 솔루션입니다. 예를 들어, 이 솔루션은 플랫 파일 데이터베이스, 서버리스 데이터베이스 또는 데이터베이스가 전혀 없는 애플리케이션에 적합하거나 유연성을 높이기 위해 단순히 지역 간에 가상 머신 집합을 이동하려는 고객에게 적합합니다.

이 배포 구조의 장애 복구 워크플로 예시

다음 두 가지 시나리오에서는 콜드 스탠바이 배포를 위한 장애 복구 작업의 프로세스 흐름이 어떻게 진행될 수 있는지 설명합니다.

스위치오버의 경우 주요 영역과 대기 영역 모두에서 다음 작업이 수행됩니다.

• 주요 애플리케이션이 정지되었습니다.
• 주요 데이터베이스가 중지되고 대기 영역에 동기화됩니다.
• 주요 가상 머신이 정상적으로 중지됩니다.
• 주요 저장 영역이 대기 영역과 동기화됩니다.
• 복제된 스토리지는 온라인 상태로 전환되고, 복제는 반대로 이루어지며, 이제 대기 영역에서 주요 스토리지가 됩니다.
• 주요 가상 머신의 복제된 복사본이 시작되고 애플리케이션 스택에 필요한 모든 시스템 애플리케이션 또는 툴이 시작되며 이제 대기 영역에서 주요 영역이 됩니다.
• 주요 데이터베이스의 복제된 복사본은 대기 영역에서 최신 콜드 백업 또는 트랜잭션을 사용하여 복구되고 복제된 스토리지에서 리두 로그가 복구됩니다.
• 주요 데이터베이스의 복제된 복사본이 시작 및 마운트되고 이제 대기 영역에서 주요 복사본이 됩니다.
• 주요 애플리케이션의 복제된 복사본이 실행 및 검증되고 이제 대기 영역에서 주요 복사본이 됩니다.
• DNS 및 로드 밸런서의 변경 사항은 공용 네트워크를 통해 애플리케이션에 액세스할 수 있도록 합니다.

페일오버의 경우 다음 작업은 대기 영역에서만 수행됩니다.

• 복제된 스토리지는 온라인 상태로 전환되고, 복제는 반대로 이루어지며, 이제 대기 영역에서 주요 스토리지가 됩니다.
• 주요 가상 머신의 복제된 복사본이 시작되고 애플리케이션 스택에 필요한 모든 시스템 애플리케이션 또는 툴이 시작되며 이제 대기 영역에서 주요 영역이 됩니다.
• 주요 데이터베이스의 복제된 복사본은 대기 영역에서 최신 콜드 백업 또는 트랜잭션을 사용하여 복구되고 복제된 스토리지에서 리두 로그가 복구됩니다.
• 주요 데이터베이스의 복제된 복사본이 시작 및 마운트되고 이제 대기 영역에서 주요 복사본이 됩니다.
• 주요 애플리케이션의 복제된 복사본이 실행 및 검증되고 이제 대기 영역에서 주요 복사본이 됩니다.
• DNS 및 로드 밸런서의 변경 사항은 공용 네트워크를 통해 애플리케이션에 액세스할 수 있도록 합니다.

웜 스탠바이

이 시나리오에서는 가상 머신이 주요 및 대기 영역에 모두 존재하지만 서로 완전히 독립적이며 고유한 호스트 이름과 미리 할당된 IP 주소를 갖습니다. 대기 영역의 VM은 존재하며 고객 환경설정에 따라 중지하거나 실행할 수 있습니다.

주요 영역이 왼쪽에 있고 대기 영역이 오른쪽에 있는 이미지를 표시합니다. 주요 영역에는 애플리케이션, 데이터베이스 및 기반 구조의 세 가지 블록이 있으며, 각 블록에는 각각의 아이콘이 포함되어 있습니다. 두 영역 모두 상단에 로드 밸런서를 나타내는 아이콘이 있습니다. 대기 영역의 로드 밸런서 아이콘이 주요 영역의 아이콘보다 밝습니다. 대기 영역에는 애플리케이션, 데이터베이스 및 기반 구조의 세 가지 블록이 있습니다. 대기 영역에서는 기반 구조 블록에 개체 저장, 블록 저장 및 파일 저장을 위한 아이콘이 하나씩 채워집니다. 기반 구조 레벨에도 가상 머신에 대한 아이콘이 있지만 더 밝습니다. 대기 영역의 데이터베이스 아이콘과 애플리케이션 아이콘도 밝습니다. 두 기반 구조 블록 사이에 객체 스토리지 복제 및 스토리지 복제를 나타내는 화살표 두 개가 표시됩니다. 이 화살표는 주요 영역에서 대기 영역으로 복제를 나타냅니다.

데이터베이스는 주요 및 대기 영역에서 모두 실행 중이어야 합니다.

Oracle 데이터베이스에는 Oracle Data Guard를 사용하여 주요 및 대기 데이터베이스를 복제할 것을 권장합니다. 자세한 내용은 Gold MAA 참조 구조를 참조하세요.

비Oracle 데이터베이스의 경우, 주요 리전과 대기 리전 간 데이터베이스 동기화를 위한 적합한 네이티브 복제 기술이 사용됩니다.

애플리케이션도 대기 클라우드 영역에 존재하지만 실행 중이거나 액세스할 수 없습니다.

이 배포 구조의 장애 복구 워크플로 예시

다음 두 가지 시나리오에서는 웜 스탠바이 배포를 위한 장애 복구 작업의 프로세스 흐름이 어떻게 진행될 수 있는지 설명합니다.

스위치오버의 경우 주요 영역과 대기 영역 모두에서 다음 작업이 수행됩니다.

• 주요 애플리케이션이 정지되었습니다.
• 주요 데이터베이스가 중지되고 대기 영역에 동기화됩니다.
• 주요 가상 머신이 정상적으로 중지됩니다.
• 주요 저장 영역이 대기 영역과 동기화됩니다.
• 복제된 스토리지는 온라인 상태로 전환되고, 복제는 반대로 이루어지며, 이제 대기 영역에서 주요 스토리지가 됩니다.
• 아직 실행 중이 아닌 경우 대기 가상 머신이 시작되고 애플리케이션 스택에 필요한 시스템 애플리케이션 또는 툴이 시작되며 이제 대기 영역에서 주요 영역이 됩니다.
• 대기 데이터베이스는 전체 읽기/쓰기 액세스로 전환되고 이제 대기 영역에서 주요 데이터베이스로 설정됩니다.
• 대기 애플리케이션이 시작되고 검증되며 이제 대기 영역에서 주요 애플리케이션이 됩니다.
• DNS 및 로드 밸런서의 변경 사항은 공용 네트워크를 통해 애플리케이션에 액세스할 수 있도록 합니다.

페일오버의 경우 다음 작업은 대기 영역에서만 수행됩니다.

• 복제된 스토리지는 온라인 상태로 전환되고, 가능한 경우 복제가 반대로 이루어지며, 대기 영역에서 주요 스토리지가 됩니다.
• 아직 실행 중이 아닌 경우 대기 가상 머신이 시작되고 애플리케이션 스택에 필요한 시스템 애플리케이션 또는 툴이 시작되며 이제 대기 영역에서 주요 영역이 됩니다.
• 대기 데이터베이스는 복제된 스토리지에서 최신 트랜잭션 및 리두 로그를 사용하여 복구됩니다.
• 대기 데이터베이스는 전체 읽기/쓰기 액세스로 전환되고 이제 대기 영역에서 주요 데이터베이스로 설정됩니다.
• 대기 애플리케이션이 시작되고 검증되며 이제 대기 영역에서 주요 애플리케이션이 됩니다.
• DNS 및 로드 밸런서의 변경 사항은 공용 네트워크를 통해 애플리케이션에 액세스할 수 있도록 합니다.

핫 스탠바이

이 시나리오에서는 가상 머신이 존재하고 고유한 호스트 이름과 미리 할당된 IP 주소를 사용하여 주요 및 대기 영역에서 모두 실행되고 있습니다.

주요 영역이 왼쪽에 있고 대기 영역이 오른쪽에 있는 이미지를 표시합니다. 주요 영역에는 애플리케이션, 데이터베이스 및 기반 구조의 세 가지 블록이 있으며, 각 블록에는 각각의 아이콘이 포함되어 있습니다. 두 영역 모두 상단에 로드 밸런서를 나타내는 아이콘이 있습니다. 대기 영역의 로드 밸런서 아이콘이 주요 영역의 아이콘보다 밝습니다. 대기 영역에는 애플리케이션, 데이터베이스 및 기반 구조의 세 가지 블록이 있습니다. 주요 영역과 대기 영역 모두 애플리케이션, 데이터베이스 및 기반 구조 블록에 아이콘이 있습니다. 기반 구조 블록에는 주요 및 대기 영역의 가상 머신, 파일 저장 영역, 객체 저장 영역 및 블록 저장 영역에 대한 아이콘이 있습니다. 대기 영역의 데이터베이스 아이콘만 더 밝은색으로 표시됩니다. 두 기반 구조 블록 사이에 객체 스토리지 복제 및 스토리지 복제를 나타내는 화살표 두 개가 표시됩니다. 이 화살표는 주요 영역에서 대기 영역으로 복제를 나타냅니다.

데이터베이스는 주요 및 대기 영역에서 모두 실행 중이어야 합니다.

Oracle 데이터베이스에는 Oracle Data Guard를 사용하여 주요 및 대기 데이터베이스를 복제할 것을 권장합니다. 자세한 내용은 Gold MAA 참조 구조를 참조하세요.

비Oracle 데이터베이스의 경우, 주요 리전과 대기 리전 간 데이터베이스 동기화를 위한 적합한 네이티브 복제 기술이 사용됩니다.

애플리케이션은 대기 클라우드 영역에서 실행 중이지만 공용 네트워크를 통해 액세스할 수 없습니다.

이 배포 구조의 장애 복구 워크플로 예시

다음 두 가지 시나리오에서는 핫 스탠바이 배포를 위한 장애 복구 작업의 프로세스 흐름이 어떻게 진행될 수 있는지 간략히 설명합니다.

스위치오버의 경우 주요 영역과 대기 영역 모두에서 다음 작업이 수행됩니다.

• 주요 애플리케이션이 정지되었습니다.
• 주요 데이터베이스가 중지되고 대기 영역에 동기화됩니다.
• 주요 가상 머신이 정상적으로 중지됩니다.
• 주요 저장 영역이 대기 영역과 동기화됩니다.
• 복제된 스토리지는 온라인 상태로 전환되고, 복제는 반대로 이루어지며, 이제 대기 영역에서 주요 스토리지가 됩니다.
• 대기 가상 머신이 이미 실행 중이며, 애플리케이션 스택에 필요한 시스템 애플리케이션 또는 툴이 시작되었으며 이제 대기 영역에서 주요 영역이 됩니다.
• 대기 데이터베이스는 전체 읽기/쓰기 액세스로 전환되고 이제 대기 영역에서 주요 데이터베이스로 설정됩니다.
• 대기 애플리케이션이 시작되고 검증되며 이제 대기 영역에서 주요 애플리케이션이 됩니다.
• DNS 및 로드 밸런서의 변경 사항은 공용 네트워크를 통해 애플리케이션에 액세스할 수 있도록 합니다.

페일오버의 경우 다음 작업은 대기 영역에서만 수행됩니다.

• 복제된 스토리지는 온라인 상태로 전환되고, 가능한 경우 복제가 반대로 이루어지며, 대기 영역에서 주요 스토리지가 됩니다.
• 아직 실행 중이 아닌 경우 대기 가상 머신이 시작되고 애플리케이션 스택에 필요한 시스템 애플리케이션 또는 툴이 시작되며 이제 대기 영역에서 주요 영역이 됩니다.
• 대기 데이터베이스는 복제된 스토리지에서 최신 트랜잭션 및 리두 로그를 사용하여 복구됩니다.
• 대기 데이터베이스는 전체 읽기/쓰기 액세스로 전환되고 이제 대기 영역에서 주요 데이터베이스로 설정됩니다.
• 대기 애플리케이션이 시작되고 검증되며 이제 대기 영역에서 주요 애플리케이션이 됩니다.
• DNS 및 로드 밸런서의 변경 사항은 공용 네트워크를 통해 애플리케이션에 액세스할 수 있도록 합니다.

활성/활성 배포 구조

이 시나리오에서는 전체 애플리케이션 스택이 완벽하게 작동하며 주요 영역과 대기 영역 모두에서 워크로드를 처리합니다.

주요 영역이 왼쪽에 있고 대기 영역이 오른쪽에 있는 이미지를 표시합니다. 주요 영역과 대기 영역에는 각각 애플리케이션, 데이터베이스 및 기반 구조의 세 가지 블록이 있으며, 각 블록에는 각각의 아이콘이 포함되어 있습니다. 두 영역 모두 상단에 로드 밸런서를 나타내는 아이콘이 있습니다. 사용할 수 없는 옵션은 없습니다. 주요 영역과 대기 영역 모두에서 애플리케이션, 데이터베이스 및 기반 구조 블록의 아이콘이 색상으로 표시됩니다. 두 기반 구조 블록 사이에 선택적 스토리지 복제를 나타내는 화살표가 하나씩 표시됩니다. 이 화살표는 주요 영역에서 대기 영역으로 복제를 나타냅니다.

데이터베이스는 주요 및 대기 영역에서 모두 실행 중이어야 합니다.

Oracle 데이터베이스의 경우 Oracle GoldenGate를 사용해 활성/활성 애플리케이션 구성을 보유하는 것을 권장합니다. 이와는 별도로 Oracle Data Guard를 사용하여 RTO 및 RPO가 거의 0에 가깝도록 각 영역에 로컬 대기 데이터베이스를 구축하는 것이 좋습니다. 자세한 내용은 platinum MAA 참조 구조를 참고하세요.

비Oracle 데이터베이스의 경우 주요 리전과 대기 리전 간 데이터베이스 동기화를 위한 적합한 네이티브 복제 및 활성/활성 기술이 사용됩니다.

애플리케이션은 대기 클라우드 영역에서 공용 네트워크를 통해 실행 중이고 액세스 가능하며 실행 중인 워크로드가 있습니다.

DRaaS로 장애 복구 작업 자동화

Oracle 팀들은 대부분의 Oracle 엔터프라이즈급 데이터베이스 및 애플리케이션을 포함한 제품에 고가용성을 설계하고, 클라우드뿐만 아니라 기존의 온프레미스 환경에서도 장애 복구 기능을 제공하기 위한 모범 사례 및 배포 구조를 고안하는 데 많은 노력을 기울였습니다. 각 생산 라인은 느슨하게 결합된 단계를 통합하여 애플리케이션을 지원하는 데 필요한 모든 구성 요소를 복구하는 개별 애플리케이션에 대한 장애 복구 접근 방식을 결정합니다.

클라우드 기반 서비스형 장애 복구는 개발자, 클라우드 설계자 및 제품 솔루션 설계자가 고안한 느슨하게 결합된 모든 단계를 한 번의 클릭으로 시작할 수 있는 단일 워크플로로 연결할 수 있습니다. OCI는 유연하고 확장성이 뛰어나며 확장성이 뛰어난 풀스택 장애 복구라는 DRaaS 솔루션을 제공합니다.

OCI 풀스택 장애 복구는 클릭 한 번으로 전 세계 어디에서나 OCI 지역 간에 기반 구조, 데이터베이스 및 애플리케이션의 전환을 관리합니다. 고객은 기존 기반 구조, 데이터베이스 또는 애플리케이션을 재설계하거나 재배치하지 않고도 장애 복구 환경을 배포할 수 있으며, 전문화된 관리 또는 변환 서버가 필요하지 않습니다.

• OCI 풀스택 장애 복구에 대해 더 알아보기
• OCI 장애 복구에 대해 더 알아보기