Google Cloud의 SAP 배포를 위한 탄력성

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

인프라와 소프트웨어가 다운될 수 있습니다. 이러한 실패의 원인과 범위로 인해 SAP 시스템은 Google Cloud 인프라를 최대한 활용하기 위해 특정 원칙을 따라야 합니다. 인프라 옵션을 탄력적인 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 솔루션을 활성화해야 할 때 필요한 리소스를 사용할 수 있도록 하는 방법입니다. 자세한 내용은 예약 유형 선택을 참고하세요.
2. 복구 작업의 실행 시간은 사용되는 백업 솔루션과 백업 파일의 크기에 따라 크게 달라집니다. 데이터베이스 크기와 변경 비율에 대한 정확한 예측 시간을 확인하려면 사용 중인 백업 솔루션(예: Backint 또는 디스크 스냅샷)의 복구 속도를 평가해야 합니다.
3. 필요한 리소스를 사전 프로비저닝하거나 예약하지 않고 DR 솔루션을 배포하면 필요한 리소스를 사용할 수 없는 상황이 발생할 수 있습니다. 이로 인해 배포 복구 시간이 늘어나 비즈니스 운영에 영향을 미칠 수 있습니다.
4. 주문해야 하며 주문 시 즉시 제공되지 않는 X4와 같은 머신 유형의 경우 사전 용량 예약 없이 몇 주가 소요될 수 있습니다.

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

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

복원력 있는 배포를 위한 권장사항

다음 섹션에서는Google Cloud에 복원력 있고 안정적인 SAP 워크로드를 배포할 때 권장되는 HA 및 DR 구성에 대한 개요를 제공합니다.

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

추천에 관한 자세한 내용은 다음 섹션을 참고하세요.

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

고가용성 권장사항

• 인스턴스를 배포할 때 동일한 리전 내에서 2개 이상의 서로 다른 영역을 사용합니다.
• 단일 장애점을 제거합니다. 이를 위해서는 장애 발생 시 결함이 있는 서비스 또는 애플리케이션 구성요소에 복원력과 중복성을 제공하는 리소스를 추가하면 됩니다.
• 중복 기능이 내장된 지역별 서비스를 사용합니다. 예를 들어 공유 파일 호스팅에는 Filestore Regional (이전의 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를 달성하기 위해 기본 시스템에는 동일한 리전 내의 서로 다른 영역에 배포된 두 개의 노드가 있습니다.
  • 복원력을 높이기 위해 기본 시스템과 DR 시스템은 비동기 복제를 사용하여 서로 다른 리전에 호스팅됩니다.

  

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

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

  비용 효율성을 높이기 위해 DR 위치의 인프라를 비프로덕션 워크로드에 사용하고 DR 이벤트 중에 프로덕션 워크로드를 제공하도록 전환할 수 있습니다. 그러나 이 경우 복구 시간이 늘어납니다.

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

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

  • Google Cloud 서비스 상태의 Google Cloud 서비스 상태에 대한 정보
  • 프로젝트에 구성된 대로 Cloud Monitoring에서 보고한 인스턴스 가용성 완전 손실 Google Cloud
  • Google Cloud Customer Care 또는Google Cloud 계정 담당자가 전송한 서비스 중단 및 예상 해결 시간에 관한 커뮤니케이션입니다.
  • SAP 시스템의 사용자 또는 관리자가 확인한 데이터베이스의 논리적 손상으로, HA 메커니즘으로 해결할 수 없습니다.

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

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

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

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

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

  • 중복을 만들려면 여러 스토리지 위치를 사용하여 백업을 저장합니다. 예를 들면 다음과 같습니다.
    • Google Cloud의 SAP용 에이전트의 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용 재해 복구 계획 가이드