비즈니스 애플리케이션을 위한 두 가지 주요 지표가 있습니다.

이러한 요구사항은 사용된 애플리케이션의 종류와 비즈니스 데이터의 특성에 따라 정의됩니다. 단일 Azure 지역에서 발생하는 장애로부터 보호하려는 경우 RPO 및 RTO가 다를 수 있습니다. 또한 전체 Azure 지역의 손실과 같은 재해 준비를 하는 경우에도 다를 수 있습니다. RPO 및 RTO를 정의하는 비즈니스 요구 사항을 평가하는 것이 중요합니다. 이러한 요구 사항은 사용 가능한 기술 옵션에 상당한 영향을 미치기 때문입니다.

가상 머신, 네트워크, 스토리지와 같은 SAP HANA용 인프라에는 단일 장애 지점이 없도록 하는 이중 구성요소가 있어야 합니다. MS Azure는 다양한 인프라 구성 요소에 대한 이중화를 제공합니다.

컴퓨팅 및 애플리케이션 측에서 고가용성을 제공하기 위해 SAP HANA 다중 호스트 시스템을 통해 기본 제공 고가용성을 지원하도록 대기 SAP HANA 호스트를 구성할 수 있습니다. 서버 또는 SAP HANA 서비스에 장애가 발생하면 SAP HANA 서비스가 대기 호스트로 페일오버되어 애플리케이션 다운타임이 발생합니다.

서버 또는 애플리케이션 장애 발생 시에도 애플리케이션 다운타임이 허용되지 않는 경우에는 SAP HANA 시스템 복제를 매우 짧은 기간 동안 페일오버를 지원하는 고가용성 솔루션으로 사용할 수도 있습니다. SAP 고객은 HANA 시스템 복제를 사용하여 계획되지 않은 장애에 대한 고가용성을 제공할 뿐만 아니라 HANA 소프트웨어 업그레이드와 같은 계획된 운영의 다운타임을 최소화합니다.

논리적 손상은 소프트웨어 오류, 인적 오류 또는 태업 때문에 발생할 수 있습니다. 하지만 논리적 손상은 표준 고가용성 및 재해 복구 솔루션을 통해 해결할 수 없는 경우가 많습니다. 따라서 논리적 손상이 발생한 계층, 애플리케이션, 파일 시스템 또는 스토리지에 따라 RTO 및 RPO 요구 사항이 충족되지 않는 경우가 있습니다.

최악의 경우는 SAP 애플리케이션의 논리적 손상입니다. SAP 애플리케이션은 서로 다른 애플리케이션이 서로 통신하고 데이터를 교환하는 환경에서 작동하는 경우가 많습니다. 따라서 논리적 손상이 발생한 SAP 시스템을 복원 및 복구하는 것은 권장되는 방법이 아닙니다. 손상이 발생하기 전의 시점으로 시스템을 복원하면 데이터 손실이 발생하므로 RPO가 0보다 커집니다. 또한 SAP 환경은 더 이상 동기화되지 않으며 추가 후처리 작업이 필요합니다.

SAP 시스템을 복원하는 대신 별도의 복구 시스템에서 문제를 분석하여 시스템 내의 논리적 오류를 해결하는 것이 더 좋습니다. 근본 원인 분석에는 비즈니스 프로세스 및 애플리케이션 소유자의 참여가 필요합니다. 이 시나리오에서는 논리적 손상이 발생하기 전에 저장된 데이터를 기반으로 복구 시스템(운영 시스템의 클론)을 생성합니다. 복구 시스템 내에서 필요한 데이터를 내보낸 후 운영 시스템으로 가져올 수 있습니다. 이 방법을 사용하면 생산적인 시스템을 중단할 필요가 없으며, 최상의 시나리오에서는 데이터가 없거나 극히 일부의 데이터만 손실됩니다.

백업을 생성하여 여러 시점 데이터 세트에서 복원 및 복구를 수행할 수 있습니다. 일반적으로 이러한 백업은 며칠~몇 주 동안 보관됩니다.

손상 유형에 따라 데이터 손실 유무에 관계없이 복원 및 복구를 수행할 수 있습니다. RPO가 0이어야 하는 경우 운영 스토리지와 백업 스토리지가 손실되더라도 백업은 동기식 데이터 복제와 결합되어야 합니다.

복구 및 복구를 위한 RTO는 필요한 복원 시간, 복구 시간(데이터베이스 시작 포함) 및 데이터를 메모리로 로드하는 작업에 의해 정의됩니다. 대규모 데이터베이스와 기존 백업 접근법의 경우 RTO는 몇 시간이 될 수 있으며 이는 허용되지 않을 수 있습니다. 매우 낮은 RTO 값을 달성하려면 데이터를 메모리로 미리 로드하는 작업이 포함된 핫 스탠바이 솔루션과 백업을 결합해야 합니다.

반면, 데이터 복제 솔루션은 모든 종류의 논리적 손상을 포괄할 수 없으므로 백업 솔루션은 논리적 손상을 해결해야 합니다.

RPO는 주로 사용해야 하는 데이터 복제 방법을 결정합니다. 기본 및 백업 스토리지가 손실되더라도 RPO가 0이어야 하는 경우 데이터를 동기식으로 복제해야 합니다. 그러나 두 Azure 영역 간의 거리와 같은 동기식 복제에는 기술적 제한이 있습니다. 대부분의 경우 대기 시간으로 인해 100km 이상의 거리에는 동기식 복제가 적합하지 않으므로 Azure 영역 간의 데이터 복제 옵션은 아닙니다.

RPO가 더 크면 비동기식으로 복제를 원거리에서 사용할 수 있습니다. 이 경우 RPO는 복제 빈도로 정의됩니다.

SAP HANA 데이터베이스의 시작 시간은 기존 데이터베이스의 시작 시간보다 훨씬 더 깁니다. 데이터베이스가 예상 성능을 제공할 수 있으려면 먼저 대량의 데이터를 메모리에 로드해야 하기 때문입니다. 따라서 RTO의 중요한 부분은 데이터베이스를 시작하는 데 필요한 시간입니다. 모든 스토리지 기반 복제와 HANA 시스템 복제를 데이터 사전 로드 없이 수행할 경우 재해 복구 사이트로 페일오버할 경우 SAP HANA 데이터베이스를 시작해야 합니다.

SAP HANA 시스템 복제는 보조 호스트에서 데이터가 사전 로드되어 지속적으로 업데이트되는 운영 모드를 제공합니다. 이 모드에서는 매우 낮은 RTO 값을 사용할 수 있지만 소스 시스템으로부터 복제 데이터를 수신하는 데만 사용되는 전용 서버가 필요합니다.