Google Cloud에서 SAP 배포 복원력

이 문서에서는 Google Cloud에서 복원력이 우수하고 안정적인 SAP 시스템을 실행하는 데 도움이 되는 설계 고려사항을 설명합니다.

인프라 및 소프트웨어가 실패할 수 있습니다. 이러한 실패의 원인과 범위로 인해 Google Cloud 인프라를 최대한 활용하려면 SAP 시스템 배포에서 특정 원칙을 따라야 합니다. 인프라 옵션을 복원력이 우수한 SAP 소프트웨어 배포 아키텍처와 결합하면 데이터 무결성을 보장하고 데이터 손실 또는 시스템 사용 불능으로부터 보호할 수 있습니다.

복원력 및 안정성 옵션

인프라와 애플리케이션 레이어의 기능을 모두 활용하여 장애를 흡수하거나 장애를 복구할 수 있게 함으로써 복원력이 우수하고 강력한 시스템을 배포할 수 있습니다. Google Cloud에서 SAP 시스템 배포에 대한 복원력과 안정성을 보장하기 위해 다음 옵션을 고려하는 것이 좋습니다.

• 플랫폼 복원력: Google Cloud 서비스 및 제품은 복원력을 염두에 두고 설계되었으며 게시된 서비스수준계약을 달성하기 위해 기본 제공되는 중복성 기능을 제공합니다. Google Cloud 가이드라인 및 권장사항에 따라 SAP 시스템을 배포하면 기본 플랫폼 메커니즘이 SAP 시스템의 복원력을 향상시킵니다. 이렇게 하면 장애나 재해 발생 시 비즈니스 운영을 계속할 수 있습니다.
• 고가용성(HA): HA를 지원하는 인프라 및 소프트웨어 구성을 사용하면 최소한의 중단으로 자동화된 시스템 복구를 사용 설정할 수 있습니다. 또한 이렇게 하면 기본 인프라 또는 애플리케이션 소프트웨어의 일부에서 오류가 발생할 경우 최소한의 개입이 필요할 수 있습니다. HA는 시스템 구성요소에 중복성을 제공하여 단일 구성요소 장애 또는 성능 저하로부터 시스템을 보호하기 위한 것입니다.
• 재해 복구(DR): DR은 재해로 인해 장애가 발생한 경우 비즈니스 운영 복구를 지원합니다. DR에는 서비스 및 애플리케이션을 운영이 계속될 수 있는 물리적으로 격리된 보조 위치로 이전하는 작업이 포함됩니다. DR 시스템은 단일 구성요소 또는 서비스 장애 이상으로 확장되어 빈도는 낮지만 영향력이 더 큰 이벤트를 완화합니다. 여기에는 자연재해, 전력망 손실과 같은 리전별 이벤트와 화재 또는 인적 오류와 같은 현지화된 이벤트가 포함될 수 있습니다. DR 조항에는 다음이 포함됩니다.
  • 데이터 복제: 소프트웨어 또는 스토리지 수준 복제를 사용하여 잠재적인 데이터 손실을 최소화하면서 데이터를 보조 위치로 전송할 수 있습니다.
  • 백업: 기본 데이터 스토리지와 별도로 저장된 백업을 사용하여 시스템 또는 데이터베이스를 복구할 수 있습니다. 여기에는 스냅샷 또는 백업이 시스템이 배포된 곳이 아닌 리전에 저장된 경우 Cloud Storage에 업로드된 스냅샷이나 백업 사용이 포함될 수 있습니다.

이러한 옵션은 상호 보완적이므로 각 옵션의 측면을 결합하여 SAP 배포 내의 복원력을 높일 수 있습니다. 선택한 옵션은 배포의 복구 시간 목표(RTO) 및 목표 복구 시간(RPO)에 영향을 줍니다. 따라서 이러한 옵션의 비용을 시스템 복원력 및 비즈니스 연속성에 미치는 영향과 비교하여 평가해야 합니다. 사용 가능한 모든 옵션을 신중하게 고려하고 재해 복구 목표에 맞게 구현하는 것이 좋습니다.

다음 섹션에서는 SAP 배포 예시와 다양한 HA 및 DR 구성이 복원력과 안정성에 미치는 영향을 설명합니다.

시나리오 예시

Google Cloud에 수직 확장 SAP S/4HANA를 배포하는 것이 좋습니다. 다음 표에서는 이 배포에 적용할 수 있는 예시 HA 및 DR 구성과 가용성, RTO, RPO와 같은 시스템 복원력 및 신뢰성 측정기준에 대해 예상되는 영향을 보여줍니다.

HA 또는 DR 구성	복원력 또는 안정성 측정기준	예상
HA 구성. 한 가지 예를 살펴보겠습니다: us-central1은 기본 리전입니다. X4 인스턴스는 us-central1-a 및 us-central1-b와 같은 서로 다른 두 영역에 배포됩니다.	가용성	전체 시스템에서 99.99% 이상 각 개별 인스턴스에서 99.9% 이상
완전 메모리 상주 DR 시스템에 비동기 SAP HANA 시스템 복제를 사용하는 DR 구성. 한 가지 예를 살펴보겠습니다: us-central1은 기본 위치입니다. us-east4는 DR 위치이며 기본 위치와 동일한 크기의 X4 인스턴스를 실행합니다. 데이터는 DR 위치에서 SAP HANA를 실행하는 X4 인스턴스에 사전 로드됩니다. DR 위치에서 애플리케이션 서버가 프로비저닝되거나 이에 대한 예약을 구매했습니다. ^참고 1	복구 시간	몇 시간(클라이언트 시스템에 DNS 전파에 필요한 시간이 포함될 수 있음)
	복구 지점	분(마지막 비동기 복제와 관련)
사전 프로비저닝된 인프라가 있는 백업을 사용하는 DR 구성 ^참고 1 Backint 기반 백업 및 복구를 사용하는 시스템을 고려합니다.	복구 시간	백업에서 데이터베이스를 복구하는 시간 ^참고 2.
	복구 지점	SAP HANA 로그 백업 또는 스냅샷의 마지막 시점까지입니다.
사전 프로비저닝된 인프라 없이 백업을 사용하는 DR 구성 ^참고 3. Backint 기반 백업 및 복구를 사용하는 시스템을 고려합니다.	복구 시간	인프라를 프로비저닝하고^참고 4 백업에서 데이터를 복구하는 데^참고 3 며칠 정도 걸립니다.
	복구 지점	SAP HANA 로그 백업 또는 스냅샷의 마지막 시점까지입니다.

표 참고사항:

1. 필요한 리소스를 미리 예약하여 필요한 인프라를 사전 프로비저닝하지 않고도 DR 솔루션을 배포할 수 있습니다. 이렇게 하면 기본 위치의 재해로 인해 DR 솔루션을 활성화해야 할 때 필요한 리소스의 가용성을 보장할 수 있습니다. 자세한 내용은 Compute Engine 영역별 리소스 예약을 참조하세요.
2. 복구 작업의 실행 시간은 사용되는 백업 솔루션과 백업 파일의 크기에 따라 크게 달라집니다. 데이터베이스 크기와 변경 비율에 대한 정확한 예측 시간을 확인하려면 사용 중인 백업 솔루션(예: Backint 또는 디스크 스냅샷)의 복구 속도를 평가해야 합니다.
3. 필요한 리소스를 사전 프로비저닝하거나 예약하지 않고 DR 솔루션을 배포하면 필요한 리소스를 사용할 수 없는 상황이 발생할 수 있습니다. 이렇게 하면 배포 복구 시간이 늘어나 비즈니스 운영에 영향을 줄 수 있습니다.
4. 주문형으로 제공되지 않고 주문이 필요한 X4 등의 머신 유형의 경우 사전 용량 예약 없이 몇 주의 리드 타임이 필요할 수 있습니다.

위 표에 제시된 정보는 업계 기준에서 파생된 기존 설계 및 재해 복구 계획을 보완하는 것으로 고려하세요. 자세한 내용은 다음 리소스를 참조하세요.

• 재해 복구 계획 가이드
• 복원력이 우수한 시스템 설계

복원력이 우수한 배포 권장사항

다음 섹션에서는 Google Cloud에서 복원력이 우수하고 안정적인 SAP 워크로드를 배포하는 데 권장되는 HA 및 DR 구성을 간략하게 설명합니다.

업무상 중요한 프로덕션 작업을 호스팅하는 SAP 워크로드에 대해 이러한 권장사항을 구현하는 것이 좋지만 장시간의 중단이 비즈니스 운영에 부정적인 영향을 줄 수 있는 비프로덕션 SAP 시스템에도 이 권장사항을 구현할 수 있습니다.

권장사항에 대한 자세한 내용은 다음 섹션을 참조하세요.

• 고가용성 권장사항
• 재해 복구 권장사항
• 기타 권장사항

고가용성 권장사항

• 인스턴스 배포를 위해 동일한 리전 내에 2개 이상의 서로 다른 영역을 사용합니다.
• 단일 장애점을 삭제합니다. 이를 위해서는 장애가 발생할 경우 장애가 있는 서비스 또는 애플리케이션 구성요소에 복원력과 중복성을 제공하는 리소스를 추가하면 됩니다.
• 중복 기능이 기본 제공되는 리전 서비스를 사용합니다. 예를 들어 공유 파일을 호스팅하는 데 Filestore Enterprise를 사용하고 Cloud Load Balancing에서 제공되는 부하 분산기를 사용합니다.
• 장애 조치에 자동화를 사용합니다. 자동화를 통해 장애 발생 시 수동으로 개입할 필요성을 제한하고 비즈니스 운영에 미치는 영향을 줄일 수 있습니다. 예를 들어 Pacemaker와 같은 Linux 클러스터 관리자를 사용할 수 있습니다.

• 중복된 네트워크 경로를 사용합니다. 기본 리전에 중복 연결이 있는지 확인합니다. 연결 요구사항에 따라 다양한 옵션을 사용할 수 있습니다. 자세한 내용은 Google Cloud 연결을 참조하세요.

  Google Cloud 리전 연결에 대해 99.99% 의 가용성을 달성하려면 여러 연결을 구성하는 것이 좋습니다. 자세한 내용은 Dedicated Interconnect를 위한 99.99%의 가용성 설정을 참조하세요.

• Compute Engine 리소스에 라이브 마이그레이션 및 자동 다시 시작 정책 사용 설정:

  • Google에서 시작한 유지보수 이벤트 중에 컴퓨팅 인스턴스를 온라인 상태로 유지하려면 onHostMaintenance 속성을 MIGRATE(기본값) 옵션으로 설정하여 라이브 마이그레이션을 사용할 수 있습니다. 라이브 마이그레이션을 지원하지 않는 컴퓨팅 인스턴스의 경우 automaticRestart 속성을 true(기본값)로 설정합니다. 이렇게 하면 Google에서는 응답하지 않는 모든 인스턴스를 다시 시작합니다. 자세한 내용은 호스트 이벤트 정보를 참조하세요.
  • 라이브 마이그레이션 또는 계획된 유지보수를 지원하지 않는 컴퓨팅 인스턴스의 경우 고급 유지보수 제어를 사용할 수 있습니다. 자세한 내용은 단독 테넌트 노드에 고급 유지보수 제어 사용 설정을 참조하세요.

• 실행하기 전에 환경에서 장애 조치 테스트

  • HA 구성이 올바르게 설정되어 있고 예상대로 작동하는지 확인하려면 한 개 이상의 구성요소 종료를 트리거하는 장애 시나리오를 테스트해야 합니다. 자세한 내용은 Google Cloud에서 HA 클러스터 테스트를 참조하세요.
  • HA 구성을 평가하려면 워크로드 관리자를 사용하면 됩니다. 자세한 내용은 워크로드 관리자 평가 정보를 참조하세요. 워크로드 관리자가 SAP 워크로드에 대해 지원하는 평가에 대한 자세한 내용은 SAP용 워크로드 관리자 권장사항을 참조하세요.

재해 복구 권장사항

• 기본 위치가 아닌 다른 위치에서 DR 솔루션을 호스팅합니다. DR 솔루션이 기본 시스템과 동일한 이벤트에 의해 영향을 받지 않도록 하려면 두 시스템이 서로 다른 위치에서 호스팅되는지 확인합니다.

  이상적으로 DR 위치는 다른 리전에 있어야 합니다. 하지만 데이터 상주 또는 주권 문제로 인해 두 번째 리전 사용이 적합하지 않은 경우 Google Cloud 영업팀에 문의하여 사용 가능한 다른 옵션을 논의하세요.

  다음 다이어그램은 다음 HA 및 DR 프로비저닝이 포함된 Google Cloud에서 SAP HANA 배포의 개략적인 아키텍처를 보여줍니다.

  • HA를 확보하기 위해 기본 시스템에는 같은 리전 내의 서로 다른 영역에 배포되는 2개의 노드가 있습니다.
  • 복원력을 지원하기 위해 기본 및 DR 시스템은 비동기 복제를 통해 서로 다른 리전에서 호스팅됩니다.

  

• DR 위치에 적절한 용량이 있는지 확인합니다.

  • DR 시스템을 기본 시스템과 동일한 용량으로 실행해야 하는지 아니면 용량 감소로 실행해야 하는지 결정합니다. SAP HANA와 같은 데이터베이스의 경우 DR 위치에 SAP 워크로드를 생산적으로 운영하기에 충분한 리소스가 있어야 합니다.
  • 또한 DR 위치에서 필요한 리소스를 사용할 수 있는지 미리 확인합니다. 리소스 가용성을 보장하기 위해 DR 위치에서 이를 프로비저닝하거나 미리 예약을 구매할 수 있습니다. 예약을 구매하면 장애 발생 후 다른 Google Cloud 고객에게 할당되어 리소스를 사용할 수 없는 시나리오를 방지하는 데 도움이 됩니다. 이는 M2 또는 X4와 같은 더 큰 컴퓨팅 인스턴스 유형에 특히 중요합니다. 예약에 대한 자세한 내용은 Compute Engine 영역별 리소스 예약을 참조하세요.

  비용 효율성을 높이기 위해 DR 위치의 인프라를 비프로덕션 워크로드에 사용할 수 있으며 DR 이벤트 중에 프로덕션 워크로드를 제공하도록 전환할 수 있습니다. 하지만 이렇게 하면 복구 시간이 길어집니다.

• DR 위치에 대한 연결을 검사합니다. 기본 위치에 대한 중복 네트워크 경로와 마찬가지로 Cloud VPN과 같은 대체 옵션을 추가하는 것이 좋습니다.

• 재해를 식별하는 데 사용할 수 있는 신호를 식별합니다. 이러한 신호는 DR 솔루션을 트리거할 시기를 결정하는 데 도움이 됩니다. 다음은 이러한 신호의 예시입니다.

  • Google Cloud Service Health의 Google Cloud 서비스 상태에 대한 정보
  • Google Cloud 프로젝트에 구성된 대로 Cloud Monitoring에서 보고한 인스턴스 가용성이 완전히 손실됨
  • 서비스 중단 및 잠재적인 해결 시간을 조언하는 Google Cloud Customer Care 또는 Google Cloud 계정 담당자가 보내는 커뮤니케이션
  • HA 메커니즘으로 해결할 수 없는 SAP 시스템의 사용자 또는 관리자가 결정한 데이터베이스의 논리적 손상

• DR 솔루션을 정기적으로 테스트합니다. 재해 발생 시 솔루션이 작동하는지 확인합니다. 이로 인해 일상적인 운영에 영향을 미칠 수 있습니다. 운영상 허용되는 경우 기본 위치와 보조 위치에서 대칭적으로 운영하고 3~6개월마다 작업을 순환하는 것이 좋습니다.

• 복제를 사용하여 최적의 복구 지점을 달성하세요. 복제는 DR 사이트에서 기본 사이트의 거의 실시간 버전을 제공합니다. SAP 워크로드의 설계 방식에 따라 다음과 같은 복제 옵션을 사용할 수 있습니다.

  • 기본 사이트와 DR 사이트 간에 논리적 수준에서 복제되는 SAP HANA 시스템 복제와 같은 메커니즘을 활용하여 데이터베이스 수준 복제
  • 블록 스토리지 수준에서 복제하는 PD 비동기 복제와 같은 메커니즘을 활용하여 스토리지 수준 복제. SAP 워크로드에서 사용하는 스토리지 옵션에 따라 사용 가능한 스토리지 수준 복제 옵션이 다릅니다.

  SAP HANA Cockpit과 같은 적절한 도구를 사용하여 복제를 모니터링해야 합니다. 이렇게 하면 DR 이벤트가 발생할 경우 DR 솔루션이 트리거되기 전에 SAP 워크로드가 완전히 복제되었는지 확인할 수 있습니다.

• 데이터 백업을 사용하여 특정 시점 복구 기능을 제공합니다.

  • 중복성을 만들려면 여러 스토리지 위치를 사용하여 백업을 저장합니다. 예를 들면 다음과 같습니다.
    • SAP용 Google Cloud 에이전트를 사용하여 Backint 기반 백업을 만들 때는 이중 리전 또는 멀티 리전 버킷 위치를 사용합니다. 자세한 내용은 Cloud Storage 버킷 만들기를 참조하세요.
    • 디스크 스냅샷 기반 백업을 만들 때는 멀티 리전 또는 이중 리전 Cloud Storage를 사용합니다. Cloud Storage 버킷 위치에 대한 자세한 내용은 버킷 위치를 참조하세요.
  • Google Cloud에 스냅샷 저장을 포함하는 증분 또는 차등 백업을 사용할 수 있습니다.
  • 백업을 모니터링하여 백업 전략에 따라 올바르게 생성되었는지 확인합니다. 완전한 데이터 보호 솔루션을 위해서는 Google Cloud의 백업 및 DR 서비스를 사용하는 것이 좋습니다.
  • 재해 발생 시 백업을 복구할 수 있는지 정기적으로 테스트하고 시스템 또는 데이터베이스를 복구하는 데 걸리는 시간을 검토합니다. 일반적으로 28일 동안 지속되는 백업 주기마다 한 번씩 복구를 테스트하는 것이 좋습니다.
  • 예를 들어 스토리지 보관 설정 및 암호화 키를 사용하여 기본 시스템과 마찬가지로 백업을 보호합니다.

기타 권장사항

• HA 및 DR 구성의 비용을 비즈니스의 다음 측면에 미치는 영향을 기준으로 평가합니다.
  • 운영 및 비즈니스 트랜잭션의 잠재적인 다운타임
  • 판매 손실, 고객 또는 공급업체 신뢰 상실, 또는 규정 준수 실패로 이어질 수 있는 데이터 손실
• 모든 비즈니스는 고유한 고려사항이 있습니다. 특정 상황에 보다 맞춤화된 솔루션이 필요한 경우 언제든지 Google Cloud 영업팀에 문의하세요.

다음 단계

• SAP HANA 고가용성 계획 가이드
• SAP HANA 재해 복구 계획 가이드
• Google Cloud에서 SAP NetWeaver용 고가용성 계획 가이드
• Google Cloud 기반 SAP NetWeaver용 재해 복구 계획 가이드