Google Cloud를 사용하여 Google Cloud, 온프레미스 또는 다른 클라우드 제공업체에서 실행 중인 SAP 시스템용 재해 복구 솔루션을 호스팅할 수 있습니다.
재해 복구 정의
재해 복구(DR) 및 고가용성(HA)은 더 큰 개념인 비즈니스 연속성 안에 속하는 별개의 요소입니다. 이 가이드에서는 재해 복구를 중점적으로 설명합니다.
DR 솔루션은 자연 재해나 인재 또는 인프라 장애로 인해 대규모 중단이 발생한 후 애플리케이션 처리를 복원하도록 설계되었습니다. 이러한 중단이 발생하면 기본 애플리케이션 처리 시스템뿐만 아니라 소규모 시스템 또는 로컬 인프라 장애로부터 보호하는 대기 시스템도 중지됩니다.
고가용성 솔루션과 구별되는 DR 솔루션의 기타 특징은 다음과 같습니다.
- DR 솔루션의 복구 시스템은 일반적으로 상시 대기 시스템이 아닙니다.
- 재해 복구 절차에서 데이터, 시스템, 인프라의 백업 또는 복제로부터 애플리케이션 처리를 복구하거나 복원하려면 대개 수동 개입이 필요합니다.
- 기본 시스템과 다른 지리적 위치에 있는 복구 사이트가 솔루션에 포함됩니다.
- 재해 복구 솔루션의 복구 시간 목표(RTO)는 대개 일 단위가 아닌 시간 단위로 측정됩니다.
다음 예시 아키텍처에서는 HA 솔루션과 DR 솔루션을 모두 포함하는 SAP 시스템을 보여줍니다. 재해 발생 후 시스템이 복원될 DR 사이트는 리전 2의 오른쪽에 있습니다. 기본 시스템은 리전 1의 왼쪽에 있으며 두 영역에 걸쳐 있는 장애 조치 클러스터로 고가용성을 제공하도록 구성되어 있습니다. DR 솔루션의 백업 기능은 두 리전에 걸쳐 있는 파선으로 표시됩니다. 시스템은 다이어그램 하단에 표시된 멀티 리전 Cloud Storage 버킷을 스토리지로 사용합니다.
예시에서는 데이터베이스도 보여줍니다. 애플리케이션 복구는 데이터 복구에 종속되지만 데이터베이스 시스템의 DR 절차는 이 가이드에서 다루지 않습니다. 데이터베이스 문서와 관련 SAP 노트를 참조하세요. 이 가이드에서는 특히 SAP NetWeaver 시스템(SAP ASCS/ERS)과 애플리케이션 서버(SAP AAS)에 중점을 둡니다.
Google Cloud에서 고가용성 SAP 시스템을 구현하는 방법에 대한 자세한 내용은 Google Cloud 기반 SAP NetWeaver용 고가용성 계획 가이드를 참조하세요.
Google Cloud 기반 SAP HANA의 고가용성 및 재해 복구에 대한 자세한 내용은 SAP HANA 고가용성 계획 가이드 및 SAP HANA 재해 복구 계획 가이드를 참조하세요.
Google Cloud의 DR에 대한 일반적인 정보는 재해 복구 계획 가이드를 참조하세요.
Google Cloud에서 실행되지 않는 SAP 시스템을 위한 DR 설계 접근 방식
기본 SAP 시스템이 Google Cloud에서 실행되지 않는 경우 Google Cloud의 DR 시스템 아키텍처 및 소프트웨어가 기본 시스템과 동일한 DR 솔루션에 대해 리프트 앤 시프트 접근 방식을 사용할 수 있습니다. 또는 DR 솔루션 설계의 일부로 Google Cloud 또는 Google Cloud 파트너 제품에서 지원하는 클라우드 또는 서비스의 복구된 시스템을 최적화하는 클라우드 기반 접근 방식을 사용할 수 있습니다.
리프트 앤 시프트 접근 방식을 사용하는 경우 기본 시스템의 아키텍처가 Google Cloud에서 완벽하게 지원되는지 확인해야 합니다. 두 접근 방식 모두 사용하는 모든 소프트웨어가 Google Cloud에서 사용을 위한 적절한 라이선스를 받았는지 확인해야 합니다.
라이선스에 대한 자세한 내용은 Google Cloud Platform 서비스 약관을 참조하세요.
Google Cloud 기반 SAP NetWeaver용 DR 솔루션의 설계 요소
Google Cloud 기반 SAP NetWeaver용 DR 솔루션의 설계 요소에는 다음이 포함될 수 있습니다.
- DR 사이트 위치
- 네트워킹
- 보안
- 가상 머신(VM) 고려 사항
- 백업 옵션
- 스토리지
이러한 각 설계 요소를 구현하기 위해 복구 및 비용 목표를 충족하는 여러 옵션이 있습니다.
DR 사이트 위치
DR 사이트의 Google Cloud 리전을 선택할 때 다음 사항을 고려해야 합니다.
- 기본 사이트에서 발생할 수 있는 재해의 잠재적 영향 범위
- SAP NetWeaver 시스템 사용자의 위치
- 선택하는 리전 및 영역에서 SAP 시스템에 사용되는 Google Cloud 리소스 및 기능을 사용할 수 있는지 여부
기본 사이트에서 발생할 수 있는 재해의 영향을 받지 않도록 기본 사이트에서 충분히 멀리 떨어져 있는 DR 사이트의 Google Cloud 리전을 선택합니다. 일반적으로 100km 이상 떨어져 있으면 충분하지만 규정이나 조직 가이드라인에 따라 최소 거리가 다를 수 있습니다.
기본 SAP 시스템이 Google Cloud에서 실행되는 경우 기본 사이트가 실행 중인 리전이 아닌 사용자와 가까운 Google Cloud 리전에 DR 사이트를 배치합니다. 두 Google Cloud 리전이 동일한 재해의 영향을 받지 않도록 서로 충분히 멀리 떨어져 있습니다.
기본 SAP 시스템이 Google Cloud 외부에서 실행되는 경우 기본 사이트에서 발생할 수 있는 재해의 영향을 받지 않고 사용자에게 최대한 가까운 리전에 DR 사이트를 배치합니다.
DR 리전에서 SAP 및 데이터베이스 시스템에 필요한 VM 인스턴스 유형과 다른 인프라를 지원하는 영역에 DR 시스템을 배치합니다.
DR 사이트의 리전을 선택한 후 이벤트 발생 전에 DR 시스템에 충분한 리소스를 제공하기 위해 리전의 리소스 할당량을 늘려야 할 수 있습니다.
모든 Google Cloud 리전의 위치는 리전 및 영역을 참조하세요.
각 리전에서 사용할 수 있는 기능을 보려면 사용 가능한 리전 및 영역을 참조하세요.
전역적, 리전별, 영역별 Google Cloud 리소스를 검토하려면 전역적, 리전별, 영역별 리소스를 참조하세요.
네트워킹
Google Cloud에서 Virtual Private Cloud(VPC)는 전 세계로 확장 가능한 네트워킹 기능을 제공합니다.
DR 사이트의 VPC 네트워크가 아직 없는 경우 하나 만들어야 합니다. DR 사이트의 서브네트워크와 IP 범위도 만들어야 합니다.
기본 시스템이 Google Cloud에 있는 경우 기본 사이트와 DR 사이트가 동일한 VPC 네트워크에 있으면 네트워크 구성이 더 쉽습니다. 그러나 필요한 경우 기본 VPC 사이트와 DR 사이트를 다른 VPC 네트워크나 프로젝트에 배치할 수 있습니다.
DR 솔루션을 설계할 때 다음 통신 경로를 고려해야 합니다.
- Google Cloud의 기본 사이트와 복구 사이트 간의 연결
- SAP 시스템을 구성하는 애플리케이션, 데이터베이스, 서버 간의 내부 통신
- 사용자와 SAP 시스템 간의 연결
Google Cloud 외부 사이트의 연결을 위해 Google Cloud는 이러한 각 연결 지점을 지원하는 다양한 네트워킹 제품을 제공합니다.
DR 사이트에 기본 사이트 연결
재해 발생 시 또는 재해 절차 테스트를 위해 복구 리소스를 바로 사용할 수 있도록 백업을 저장하거나 두 시스템 사이의 복제 경로를 제공하려면 기본 사이트와 DR 사이트 간의 연결이 필요합니다.
기본 시스템이 Google Cloud에서 실행되는 경우 거의 자동으로 DR 사이트에서 백업을 사용할 수 있습니다. Compute Engine 스냅샷을 멀티 리전으로 지정할 수 있습니다. 다른 백업은 DR 사이트에서 바로 사용할 수 있도록 기본 사이트에서 멀티 리전 Cloud Storage 버킷으로 직접 저장할 수 있습니다.
기본 시스템이 Google Cloud에서 실행되지 않는 경우 Cloud Interconnect 또는 Cloud VPN을 사용하여 기본 사이트를 Google Cloud의 DR 사이트에 연결할 수 있습니다.
몇 가지 변경 사항을 포함하여 DR 시나리오에 적용할 수 있는 고가용성 Cloud Interconnect 토폴로지의 예시는 Dedicated Interconnect를 위한 99.99%의 가용성 설정을 참조하세요.
DR 시나리오에도 적용할 수 있는 고가용성 멀티 리전 VPN 게이트웨이 토폴로지의 예시는 Cloud VPN 토폴로지를 참조하세요.
플랫폼 외부 사이트에서 Google Cloud 연결을 설정할 때 중요한 고려 사항은 대역폭입니다. 연결이 Google Cloud로의 데이터 및 백업 정기 전송을 적절히 지원해야 합니다.
플랫폼 외부 사이트에서 Google Cloud에 연결하는 옵션에 대한 자세한 내용은 하이브리드 연결 제품을 참조하세요.
SAP 애플리케이션, 데이터베이스, 서버 간의 연결
기본 시스템이 Google Cloud에서 실행되는 경우 DR 사이트의 SAP 애플리케이션, 데이터베이스, 서버 간의 연결을 유지하려면 기본 사이트의 호스트 이름, 서브넷, 방화벽 등을 모델링하면 됩니다.
기본 시스템이 Google Cloud에서 실행되지 않는 경우 기본 사이트의 네트워킹 아키텍처를 Google Cloud의 DR 사이트로 변환하기 위해 설계 단계에서 더 많은 노력이 필요할 수 있습니다.
DR 절차 테스트는 비즈니스가 복구된 시스템에 종속되기 전에 연결 문제를 식별하고 해결하는 데 중요합니다.
DR 사이트에 사용자 연결
복구 시 SAP 시스템이 DR 사이트로 복원된 후 사용자의 트래픽을 복구된 시스템으로 다시 라우팅해야 합니다. 일반적으로 이를 위해 DNS 항목의 네트워크 별칭을 새 IP 주소(리전별)로 업데이트합니다.
네트워킹 아키텍처에서 VPC 경로를 사용하는 경우 복구 중 경로를 업데이트해야 합니다.
Google Cloud에서는 Cloud DNS를 사용하거나 다른 DNS 솔루션을 사용할 수 있습니다.
리전별 네트워킹 리소스
기본 시스템이 Google Cloud에서 실행되고 Cloud NAT 또는 리전별 Cloud Load Balancing과 같은 리전별 네트워킹 리소스를 사용하는 경우 각 리전에 리소스의 인스턴스가 필요합니다.
추가 정보:
네트워크 액세스 제어
기본 사이트에서 열려 있는 것과 동일한 포트가 DR 사이트에서 열려 있는지 확인합니다.
VPC 네트워크에서 방화벽 규칙을 정의하여 VM과의 트래픽을 제어할 수 있습니다.
Windows Server에 Active Directory 서비스가 있는 경우 복구 전에 이를 설정하고 기본 사이트의 Active Directory 인스턴스와 동기화해야 합니다.
보안
기본 사이트와 동일한 보안 제어 및 권한을 DR 사이트에 구현해야 합니다. 동일한 규정 준수 규칙이 복구된 환경에도 적용됩니다.
기본 사이트에서 액세스 권한이 필요한 모든 사용자 또는 역할은 DR 사이트에서도 액세스 권한이 필요합니다.
Google Cloud의 DR 솔루션 보안 설계에 대한 일반적인 정보는 보안 및 규정 준수 제어 구현을 참조하세요.
VM 고려 사항
Cloud Deployment Manager, 인스턴스 템플릿, 커스텀 이미지 등의 Google Cloud에서 제공되는 Terraform 구성, 제품 및 기능을 사용하여 Compute Engine 가상 머신(VM) 인스턴스의 배포 속도를 높이고 DR 사이트의 구성 오류를 방지할 수 있습니다.
가상 머신 구성 및 배포
Google Cloud는 DR 사이트에서 SAP 시스템을 사전 정의하고 배포하는 데 사용할 수 있는 Google Cloud 기반 SAP용 Terraform 구성 파일 및 Deployment Manager 템플릿을 제공합니다. Terraform 또는 Deployment Manager 파일을 사용하면 배포 속도가 빨라지고 구성 오류가 줄며 SAP 시스템이 SAP 지원 요구 사항이 충족됩니다.
미리 VM을 구성하는 또 다른 옵션은 Compute Engine 인스턴스 템플릿입니다. 인스턴스 템플릿을 사용하면 배포 속도를 높이고 복구 중 VM의 수동 구성을 줄일 수 있습니다. 그러나 DR 사이트에 대한 몇 가지 재구성이 필요하므로 다음 섹션에 설명된 대로 복구 부팅 디스크에서 VM을 복구하는 것이 더 쉬울 수 있습니다.
인스턴스 템플릿에 대한 자세한 내용은 인스턴스 템플릿을 참조하세요.
Terraform과 같은 배포 조정 도구를 사용하여 Google Cloud에서 인프라 배포를 관리할 수도 있습니다.
RTO에 따라 Compute Engine 인스턴스를 사전 배포할 수 있습니다. 또는 VM 배포에 몇 분 밖에 걸리지 않으므로 복구 시 배포할 수 있습니다.
VM을 사전 배포하는 경우 비용 절감을 위해 VM을 중지하거나 복구에 필요할 때까지 필수적이지 않은 다른 목적으로 VM을 사용할 수 있습니다.
복구 사이트의 더 적은 VM에 분산 시스템을 통합하여 비용을 최소화할 수도 있습니다. 예를 들어 기본 사이트의 애플리케이션 서버가 DR 사이트에 있는 기본 사이트의 전용 호스트에 있는 경우 애플리케이션 서버를 SAP Central Services와 동일한 호스트에 배치할 수 있습니다. 그러나 사이트마다 다른 구성에 따른 복잡성 증가와 비용 절감을 비교 검토해야 합니다.
복구 부팅 디스크
기본 시스템의 호스트 부팅 디스크에서 커스텀 이미지를 만든 다음 이를 사용하여 DR 사이트에서 복구 인스턴스를 만들 수 있습니다.
시스템이 Google Cloud에서 실행되는 경우 기본 시스템의 Compute Engine 영구 부팅 디스크를 만들고 수정했으면 커스텀 이미지를 만듭니다. 수정되지 않은 Google Cloud 공개 이미지를 사용하는 경우 복구 사이트에 Google Cloud 공개 이미지도 사용할 수 있습니다. 자세한 내용은 커스텀 이미지 만들기, 삭제, 지원 중단을 참조하세요.
시스템이 Google Cloud에서 실행되지 않는 경우 온프레미스 환경에서 Google Cloud로 부팅 디스크 이미지를 가져오거나 로컬 워크스테이션 또는 다른 클라우드 플랫폼에서 실행 중인 VM에서 가상 디스크를 가져올 수 있습니다.
백업 옵션
Google Cloud는 DR 솔루션을 설계할 때 선택할 수 있는 다양한 백업 옵션을 제공합니다.
- Compute Engine 커스텀 이미지
- Compute Engine 영구 디스크 스냅샷
- 복제
Compute Engine 커스텀 이미지
복구에 사용할 기본 시스템의 부팅 디스크를 백업하려면 Google Cloud에 Compute Engine 커스텀 이미지로 저장합니다. 자세한 내용은 복구 부팅 디스크를 참조하세요.
Compute Engine 영구 디스크 스냅샷
Compute Engine 영구 디스크에 있는 SAP 또는 기타 파일 시스템을 백업하려면 영구 디스크 스냅샷을 사용합니다.
스냅샷 일정을 정의하여 정기적으로 스냅샷을 자동으로 만들 수도 있습니다. 영구 디스크의 예약된 스냅샷 만들기를 참조하세요.
스냅샷은 블록 수준의 일관성만 제공합니다. 파일 수준의 일관성을 보장하려면 이러한 스냅샷 중에 대상 파일 시스템에서 쓰기 활동을 정지하는 메커니즘을 구현해야 할 수 있습니다.
복제
공유 스토리지 솔루션과 복구 지점 목표에 따라 파일 시스템을 복제할 수 있습니다. 복제는 데이터베이스, 블록 수준 스토리지 또는 파일에 사용할 수 있습니다.
데이터 손실 허용 범위가 매우 낮은 비즈니스에 중요한 애플리케이션의 경우 복제를 사용하는 DR 솔루션을 설계하는 것이 가장 좋습니다.
기본 시스템이 Google Cloud에서 실행되는 경우 선택한 리전 간에 멀티 리전 버킷과 멀티 리전 스냅샷이 복제됩니다.
블록 수준 스토리지 복제의 경우 PD 비동기 복제를 사용할 수 있습니다. PD 비동기 복제는 리전 간 활성-수동 재해 복구를 위해 복구 지점 목표(RPO) 및 복구 시간 목표(RTO) 비동기 복제를 제공합니다.
타사 스토리지 솔루션에서 제공하는 복제를 사용할 수도 있습니다.
스토리지
Google Cloud에서 DR 솔루션을 설계할 때 기본 시스템의 실행 위치와 저장 대상에 따라 여러 유형의 스토리지를 사용할 수 있습니다.
백업 파일용 Cloud Storage 버킷
디스크 스냅샷 이외의 백업(예 : Google Cloud에서 실행되지 않는 SAP 시스템에서 업로드하는 파일)을 위해 기본 사이트와 DR 사이트 모두에서 액세스할 수 있는 Cloud Storage에 버킷을 만듭니다. 버킷을 만들 때 기본 스토리지 클래스와 위치를 선택합니다.
필요한 서비스수준계약(SLA), 예상 스토리지 사용량, 비용 제약 조건에 따라 기본 스토리지 클래스를 선택합니다. DR을 위해서는 Coldline 스토리지 클래스가 좋은 옵션인 경우가 많습니다.
버킷 위치로 DR 사이트의 리전을 포함하는 위치를 선택합니다. 기본 시스템이 Google Cloud에서 실행되는 경우 기본 사이트의 리전을 포함하는 위치를 선택합니다.
기본 시스템이 Google Cloud에 있는 경우 기본 사이트와 DR 사이트의 버킷에 액세스할 수 있도록 두 사이트의 리전이 모두 포함된 멀티 리전 위치를 선택합니다.
기본 시스템이 Google Cloud에 없는 경우 비용 절약을 위해 DR 사이트가 포함된 리전에서 단일 리전 위치를 선택할 수 있습니다.
기본 시스템이 Google Cloud에 있고 공유 스토리지에 타사 솔루션을 사용하는 경우 스토리지 옵션은 솔루션에 따라 결정될 수 있습니다. 솔루션 문서를 참조하거나 클라우드 고객 관리 담당자에게 문의하세요.
가격 책정에 대한 자세한 내용은 Cloud Storage 가격 책정을 참조하세요.
Compute Engine 영구 디스크 스냅샷의 스토리지
스냅샷을 만들 때 스토리지 위치를 지정할 수 있습니다. 스냅샷의 위치는 가용성에 영향을 미치며 스냅샷을 만들거나 새 디스크에 복원할 때 네트워킹 비용을 초래할 수 있습니다.
Cloud Storage 멀티 리전 위치(예: asia) 또는 Cloud Storage 리전 위치(예: asia-south1) 중 하나에 스냅샷을 저장할 수 있습니다.
Multi-Regional Storage 위치에 저장하면 가용성을 높이고 스냅샷을 만들거나 복원할 때 네트워크 비용을 줄일 수 있습니다. Regional Storage 위치에 저장하면 데이터의 물리적 위치를 더 세밀하게 제어할 수 있습니다.
선택하는 위치 옵션에 관계없이 스냅샷은 DR 사이트에서 액세스할 수 있는 위치에 저장되어야 합니다.
스냅샷 위치에 대한 자세한 내용은 스냅샷의 스토리지 위치 선택을 참조하세요.
스냅샷 스토리지의 가격 책정 정보는 영구 디스크 가격 책정을 참조하세요.
커스텀 이미지의 스토리지
커스텀 이미지 목록에 커스텀 이미지 파일을 추가한 후에는 Compute Engine이 이미지의 스토리지를 관리합니다. 커스텀 이미지 목록의 이미지는 전역 리소스이므로 모든 리전에서 사용할 수 있습니다.
이미지 스토리지 가격 책정에 대한 자세한 내용은 이미지 스토리지를 참조하세요.
DR 계획 테스트
DR 계획이 완료되면 정기적으로 테스트하여 문제가 발생했는지 확인하고 그에 따라 계획을 조정합니다.
다음과 같은 DR 계획의 모든 측면을 테스트해야 합니다.
- 백업 및 백업 일정
- 플랫폼 외부 사이트에서 데이터 전송
- 저장된 백업에서 복구
- 보안 제어 및 시스템 액세스
- 네트워크 라우팅
DR 시스템을 테스트할 때도 기본 시스템은 계속 실행됩니다. 충돌을 방지하거나 브레인 시나리오를 분할하려면 테스트 시스템을 기본 시스템 및 사용자와 분리해야 합니다.
Google Cloud의 DR 테스트에 대한 일반적인 정보는 재해 복구 계획 가이드를 참조하세요.
RPO 및 RTO를 충족하도록 DR 솔루션 설계
특정 Google 클라우드 제품, 기능, 서비스는 RPO 및 RTO를 충족하는 DR 솔루션 설계의 핵심입니다.
RPO를 위한 설계
Google Cloud에서 특정 RPO를 충족하도록 DR 솔루션을 설계할 때 복구할 수 있는 시점을 제어하는 변수는 다음과 같이 두 가지입니다.
- 백업 빈도
- 백업 보관
백업 빈도
백업 빈도는 마지막 백업과 재해 사이에 경과할 수 있는 최대 시간을 결정합니다. 24시간마다 DR 백업을 만들면 마지막 백업이 수행되고 23시간 59분 후에 재해가 발생하면 거의 24시간 분량의 데이터 업데이트가 손실될 수 있습니다.
복제는 마지막 백업 이후 최대 경과 시간을 0에 가깝게 줄일 수 있습니다. 그러나 비용이 많이 들기 때문에 데이터베이스와 비즈니스에 중요한 애플리케이션 파일에만 복제를 사용할 수 있습니다.
DR 솔루션에서 특정 시점 사본 또는 스냅샷은 일반적으로 복구에 필요한 SAP 애플리케이션 파일 시스템을 백업하는 데 사용됩니다.
Google Cloud에서는 시간별, 일별 또는 주별 스냅샷 일정을 만들어서 Compute Engine 영구 디스크 스냅샷을 자동화할 수 있습니다. 그러나 Compute Engine 스냅샷은 블록 수준에서만 일관성을 제어하므로 파일 수준의 일관성을 보장하기 위해 스냅샷 중에 대상 파일 시스템에서 쓰기 작업을 정지하는 것이 좋습니다.
백업 빈도를 선택할 때 고려해야 할 기본 비용은 데이터 전송 비용입니다. 스토리지 비용도 고려 사항이지만 백업 보관 정책이 백업 빈도보다 스토리지 비용에 더 큰 영향을 미칠 수 있습니다.
스냅샷 일정에 대한 자세한 내용은 영구 디스크의 예약 스냅샷 만들기를 참조하세요.
백업 보관
백업 보관은 복구 시점을 얼마나 뒤로 옮길 수 있는지 결정합니다. 백업 사본을 보관하면 논리적 오류가 발생하기 전의 시점으로 복구할 수 있습니다.
지정된 시간이 지난 후 백업 파일을 자동으로 삭제하는 Compute Engine 스냅샷과 Cloud Storage 버킷의 보관 정책을 설정할 수 있습니다.
보관 정책을 선택할 때 고려해야 할 기본 비용은 스토리지 비용입니다. Compute Engine 스냅샷은 첫 번째 전체 스냅샷이 저장된 후 증분 블록 수준의 변경 사항만 저장하여 여러 스냅샷에 필요한 스토리지 용량을 줄입니다.
스냅샷의 보관 정책 정의에 대한 자세한 내용은 스냅샷 보관 정책을 참조하세요.
Cloud Storage 버킷의 보관 정책 설정에 대한 자세한 내용은 버킷 잠금을 사용하는 보관 정책을 참조하세요.
RTO를 위한 설계
특정 RTO를 충족하도록 Google Cloud DR 솔루션을 설계할 때 기본 제어 변수는 DR 사이트의 인프라, 소프트웨어, 파일 시스템, 데이터 준비 상태입니다.
예를 들어 RTO를 매우 낮게 유지하기 위해 사전 배포된 인프라, 활성 SAP 시스템, 복제된 데이터를 사용하여 DR 사이트에서 상시 대기 시스템을 유지보수할 수 있습니다. 그러나 RTO가 낮으면 비용이 높아집니다.
저비용 또는 무료 인프라를 미리 설정하고 일부 설정 단계를 복구 시점까지 연기하여 비용과 복구 시간의 균형을 맞출 수 있습니다.
예를 들어 VM을 미리 구성하고 배포한 다음 VM을 중지할 수 있습니다. 외부 정적 IP 또는 영구 디스크와 같은 VM에 연결된 리소스에는 여전히 요금이 부과되지만 중지된 VM 자체에는 요금이 부과되지 않습니다.
Google Cloud에서 상대적으로 빠르게 Compute Engine VM을 구성하고 배포할 수 있으므로 복구 시간에 이를 수행하면서 RTO를 유지할 수 있습니다. 특히 Terraform 또는 Deployment Manager를 사용하여 DR 시스템을 배포하거나 미리 만드는 템플릿과 커스텀 이미지에서 VM을 만드는 경우 그렇습니다.
RTO가 높은 DR 솔루션의 할당량 및 리소스 고려 사항
인프라와 시스템을 사전 배포하지 않는 경우 DR 사이트의 리전에서 리소스 할당량을 정기적으로 확인하여 할당량이 DR 시스템을 배포하기에 충분한지 확인합니다.
DR 시스템이 할당량에 맞고 시스템에 필요한 Google Cloud 리소스를 필요할 때 사용할 수 있도록 예산에서 허용하는 만큼 DR 인프라와 시스템을 사전 배포하는 것이 좋습니다.
여러 목적을 위한 아키텍처 예시
다음 아키텍처 다이어그램은 다양한 RTO를 위한 DR 설계 예시를 보여줍니다.
각 다이어그램의 왼쪽에는 멀티 리전 백업 옵션이 표시되어 있고 오른쪽에는 DR 사이트의 해당하는 단순화된 SAP 구성이 표시되어 있습니다.
각 예시는 DR 설계 요소의 가능한 한 가지 조합을 보여줍니다. DR 설계를 목표와 상황에 맞게 조정하기 위해 일부 또는 모든 예시의 요소를 조합할 수 있습니다.
RTO가 낮은 DR 아키텍처 예시
다음 아키텍처 다이어그램은 RTO가 낮은 DR 설계 예시를 보여줍니다.
이 설계에서는 DR 사이트에서 SAP 시스템의 기능을 거의 그대로 유지합니다. VM은 배포되었으며 활성 상태입니다. SAP 애플리케이션 서버와 데이터베이스 서버는 활성 상태이지만 애플리케이션 서비스는 중지되었습니다.
이 시나리오에서 사용할 수 있는 백업 옵션에는 Compute Engine에 저장된 OS 이미지와 영구 디스크 스냅샷 및 기본 사이트와 DR 사이트 간의 데이터 복제가 포함됩니다. 데이터 복제의 경우 PD 비동기 복제를 사용할 수 있습니다.
데이터 복제가 사용되므로 데이터 손실 위험이 마지막 데이터베이스 동기화로 제한됩니다.
RPO를 뒤로 확장하기 위해 다이어그램에 표시되지 않은 Cloud Storage에 데이터 백업을 추가할 수 있습니다. 영구 디스크 스냅샷의 경우 예약된 스냅샷을 사용하고 RPO에 맞게 보관 정책을 조정할 수 있습니다.
이와 같이 RTO가 낮은 시스템을 복구하기 위해 수행해야 하는 작업은 다음과 같습니다.
- 필요한 경우 파일의 최종 동기화를 수행하거나 영구 디스크 스냅샷에서 파일을 복구합니다.
- 기본 데이터베이스를 DR 사이트로 전환합니다.
- DR 사이트에서 애플리케이션을 시작합니다.
표시된 세 가지 아키텍처 중 RTO가 낮은 예시가 비용이 가장 많이 듭니다.
RTO가 중간인 DR 아키텍처 예시
다음 DR 아키텍처 예시는 앞의 예시보다 RTO가 높지만 비용은 더 낮습니다.
이 설계에서 데이터베이스 서버는 기본 사이트에서 복제를 지원하기 위해 활성 상태입니다. 애플리케이션 서버의 VM은 활성 상태가 아닙니다.
이 시나리오에서 사용할 수 있는 백업 옵션에는 Compute Engine에 저장된 OS 이미지와 영구 디스크 스냅샷 및 기본 사이트와 DR 사이트 간의 데이터 복제가 포함됩니다. 데이터 복제의 경우 PD 비동기 복제를 사용할 수 있습니다.
데이터 복제가 사용되므로 데이터 손실 위험이 마지막 데이터베이스 동기화로 제한됩니다.
RPO를 다시 확장하기 위해 다이어그램에 표시되지 않은 Cloud Storage 버킷에 데이터 백업을 저장할 수 있습니다. 영구 디스크 스냅샷의 경우 예약된 스냅샷을 사용하고 RPO에 맞게 보관 정책을 조정할 수 있습니다.
데이터베이스 시스템의 요구 사항에 따라 기본 사이트에서 필요한 것보다 DR 사이트에서 더 작은 VM에 데이터베이스를 배포할 수 있으므로 DR 시스템이 활성화될 때까지 비용을 줄일 수 있습니다. 이 경우 복구 중에 VM을 필요한 크기로 조정해야 합니다.
다음과 같은 시스템 복구를 위해 수행해야 하는 작업은 다음과 같습니다.
- 필요한 경우 영구 디스크 스냅샷 또는 이미지에서 애플리케이션 서버와 SAP NetWeaver의 VM 인스턴스를 배포합니다.
- 영구 디스크 스냅샷 또는 기타 스토리지에서 파일 시스템을 동기화합니다.
- 필요한 경우 데이터베이스 VM 인스턴스의 크기를 조정합니다.
- 기본 데이터베이스를 DR 사이트로 전환합니다.
- DR 사이트에서 애플리케이션 서비스를 시작합니다.
RTO가 높은 DR 아키텍처 예시
다음 아키텍처 다이어그램은 표시된 예시 중 RTO가 가장 높으며 비용이 가장 낮은 옵션입니다.
이 설계에서는 서버를 사전 배포한 다음 중지하여 VM 요금이 청구되지 않도록 하거나 영구 디스크 및 기타 VM 관련 리소스와 관련된 비용을 방지하기 위해 복구 프로세스의 일부로 VM을 배포할 수 있습니다.
이 시나리오에서 사용할 수 있는 백업 옵션에는 Compute Engine에 저장된 OS 이미지와 영구 디스크 스냅샷 및 Cloud Storage에 저장된 데이터 백업이 포함됩니다.
RPO를 충족하기 위해 Cloud Storage 버킷에 있는 백업과 스냅샷 일정의 백업 빈도와 보관 정책을 모두 조정할 수 있습니다.
다음과 같은 시스템 복구를 위해 수행해야 하는 작업은 다음과 같습니다.
- 필요한 경우 Compute Engine에 저장된 멀티 리전 영구 디스크 스냅샷 또는 이미지에서 데이터베이스 서버, 애플리케이션 서버, SAP NetWeaver용 VM 인스턴스를 배포합니다.
- 영구 디스크 스냅샷 또는 기타 스토리지에서 파일 시스템을 동기화합니다.
- 멀티 리전 Cloud Storage 버킷 또는 다른 위치의 백업 파일에서 데이터베이스를 복구합니다.
- 기본 데이터베이스를 DR 사이트로 전환합니다.
- DR 사이트에서 애플리케이션 서비스를 시작합니다.
Google Cloud 기반 SAP용 DR 솔루션 파트너 및 제품
Google Cloud 파트너 디렉터리에서 DR 솔루션을 위한 파트너를 찾을 수 있습니다.
Google Cloud Marketplace에서 DR 솔루션을 지원하는 다양한 제품과 파트너를 찾을 수도 있습니다.