참조 아키텍처: Google Cloud 기반 SAP S/4HANA

이 참조 아키텍처는 SAP S/4HANA 워크로드 배포용 플랫폼으로서 Google Cloud를 평가하는 사용자를 대상으로 합니다. 여기에는 계획 단계 중의 고려사항, 배포 모델 및 자동화, 백업 및 DR 작업과 같은 일반적인 운영 절차가 포함됩니다.

Google Cloud는 SAP HANA에서 SAP S/4HANA를 실행하는 경제적이고도 안정적이며 안전한 고성능 SAP 인증 인프라를 제공합니다. 지원되는 Google Cloud 기반 SAP 솔루션의 전체 목록은 Google Cloud의 SAP를 참조하세요.

아키텍처

다음 다이어그램은 SAP S/4HANA에 대한 세 가지 일반적인 배포 모델 중앙 집중식, 분산고가용성으로 분산에 대해 개략적으로 보여줍니다.

중앙 집중식 배포

중앙 집중식 배포에서는 S/4HANA와 SAP HANA 데이터베이스를 동일한 Compute Engine VM 인스턴스에 설치할 수 있습니다. 샌드박스 및 개발 환경과 같은 비프로덕션 환경에 이 방식을 사용하세요.

다음 다이어그램에서는 중앙 집중식 배포에서 SAP S/4HANA의 참조 아키텍처를 보여줍니다. SAP ASCS, PAS, WD, HANA는 모두 동일한 VM 인스턴스에 설치된다는 점에 유의하세요.

중앙 집중식 배포에서 Google Cloud 기반 SAP S/4HANA 아키텍처 다이어그램

분산형 배포

분산형 배포에서는 서로 다른 Compute Engine 인스턴스에 다양한 구성요소를 설치할 수 있습니다. 부하가 높은 트랜잭션을 처리하기 위해 높은 컴퓨팅 성능이 요구되는 환경이나 프로덕션 환경에는 이 방식을 사용하는 것이 좋습니다.

다음 다이어그램에서는 분산형 배포에서 SAP S/4HANA의 참조 아키텍처를 보여줍니다. SAP ASCS, PAS, WD, HANA는 모두 서로 다른 VM 인스턴스에 설치된다는 점에 유의하세요.

분산형 배포 내 Google Cloud 기반 SAP S/4HANA 아키텍처 다이어그램

고가용성을 갖춘 분산형 배포

고가용성을 갖춘 분산형 배포에서 Linux 클러스터는 특정 지역의 구성요소 장애를 방지하기 위해 여러 구역에 걸쳐 설정됩니다. 활성/수동 구성 또는 활성/활성 구성 중 하나를 사용하여 여러 영역에 Linux 클러스터를 배포할 수 있습니다. 두 경우 모두 중복성을 최대화하기 위해 각각 자체 SAP HANA 데이터베이스가 있는 개별 영역에 최대 두 개의 Compute Engine 인스턴스를 설정하는 것부터 시작합니다.

다음 다이어그램은 애플리케이션 및 SAP HANA 데이터베이스 측면에서 모두 고가용성을 달성하기 위해 Linux 클러스터를 사용하는 SAP S/4HANA 아키텍처를 보여줍니다.

분산형 고가용성 배포 내 Google Cloud 기반 SAP S/4HANA 아키텍처 다이어그램

다음 다이어그램은 정상 운영 및 인계 작업 모두에서 가용성이 높은 SAP HANA 데이터베이스를 보여줍니다.

  • 정상 운영:

    정상 운영 중인 Google Cloud 기반 SAP HANA 고가용성 아키텍처 다이어그램

  • 인계 작업:

    인계 작업 중인 Google Cloud 기반 SAP HANA 고가용성 아키텍처 다이어그램

데이터베이스에 대해 고가용성 및 재해 복구를 모두 결합하려면 SAP HANA 시스템 복제를 사용하면 됩니다. 다음 다이어그램은 가용성과 내결함성을 극대화하기 위해 이 둘을 조합한 것을 보여줍니다.

고가용성과 재해 복구를 갖춘 Google Cloud 기반 SAP S/4HANA의 대략적인 아키텍처 다이어그램

고가용성을 관리하는 클러스터에는 다음 기능 및 특징이 포함됩니다.

  • 호스트 VM 두 개(각각 SAP HANA 인스턴스 한 개 포함)
  • 동기식 SAP HANA 시스템 복제
  • Pacemaker 고가용성 클러스터 리소스 관리자
  • 장애 발생 노드를 차단하는 펜싱 메커니즘
  • 실패한 인스턴스를 새 보조 인스턴스로 자동 다시 시작

애플리케이션 측면의 아키텍처는 비슷합니다. 이 경우 클러스터는 ASCS 및 ERS 인스턴스 중 하나에 문제가 발생할 경우 SAP S/4HANA 시스템에 고가용성을 제공하는 데 사용되는 ABAP SAP Central Services(ASCS)와 Enqueue Replication Server 또는 Enqueue Replicator(ERS)를 관리합니다.

SAP S/4HANA 시스템에서 사용하는 SAP S/4HANA 버전에 따라 Enqueue Server와 Enqueue Replication Server/Enqueue Replicator는 다른 버전에서 실행됩니다.

  • S/4HANA 1709 이전: ENSA1 및 ERS
  • S/4HANA 1809 이상: ENSA2 및 ERS2

다음 다이어그램은 Message Server 및 Enqueue Server의 단일 장애점을 제한하기 위해 Pacemaker 클러스터를 사용하는 SAP S/4HANA 시스템을 보여줍니다.

Google Cloud의 고가용성 배포를 사용하는 SAP NetWeaver 및 SAP HANA의 아키텍처 다이어그램

고가용성 시스템 배포 및 영역 간 Linux 클러스터링에 대한 자세한 내용은 이 문서의 뒷부분에서 다룹니다.

부하 분산에 대한 참고사항

분산형 SAP S/4HANA 환경에서는 부하 분산이 필수입니다. SAP 애플리케이션 레이어 및 네트워크 부하 분산기 조합을 사용해서 애플리케이션 부하 분산을 구성할 수 있습니다. 자세한 내용은 Google Cloud의 SAP NetWeaver용 고가용성 계획 가이드에서 내부 패스 스루 네트워크 부하 분산기 VIP 구현 섹션을 참조하세요.

배포 구성요소

SAP S/4HANA는 다음과 같은 기술 구성요소로 구성됩니다.

  • SAP HANA 데이터베이스
  • ASCS: ABAP SAP Central Services
    • 모든 SAP ABAP 시스템에 필요한 메시지 서버 및 Enqueue Server를 포함합니다.
    • HA 배포의 자체 VM 인스턴스에 배포되거나 PAS를 호스팅하는 VM 인스턴스에 배포됩니다.
    • HA 배포에서 ASCS 리소스는 Pacemaker와 같은 Linux 클러스터 리소스 관리자에 의해 관리됩니다.
  • ERS: Enqueue Replication Server 또는 Enqueue Replicator
    • HA 배포에 배포하여 ASCS 인스턴스에 어떤 일이 발생할 경우 잠금 테이블의 복제본을 보관합니다.
    • Pacemaker와 같은 Linux 클러스터 리소스 관리자가 관리합니다.
  • PAS: Primary Application Server
    • SAP 시스템을 위한 첫 번째이자 유일한 애플리케이션 서버입니다.
  • AAS: Additional Application Server
    • 애플리케이션 수준의 부하 부산용으로 배포됩니다. 애플리케이션 레이어 관점에서 높은 가용성을 확보하기 위해 여러 AAS 인스턴스를 설치할 수도 있습니다. 애플리케이션 서버 중 하나가 다운되면 해당 애플리케이션 서버에 연결된 모든 사용자 세션이 종료되지만 사용자는 환경에 있는 다른 AAS에 다시 로그인할 수 있습니다.
  • SAP NetWeaver 게이트웨이
    • 독립형 시스템 또는 SAP S/4HANA 시스템으로 배포됩니다.
    • 시스템이 Open Data Protocol(OData)을 사용하여 기기, 환경, 플랫폼을 SAP 시스템에 연결할 수 있도록 합니다.
  • SAP Fiori 프런트엔드 서버
    • 독립형 시스템 또는 SAP S/4HANA 시스템으로 배포됩니다.
    • SAP Netweaver ABAP 시스템은 SAP Fiori 애플리케이션을 호스팅하기 위해 사용됩니다.
  • WD: Web Dispatcher(선택사항)
    • 애플리케이션 유형에 따라 HTTP 및 HTTPS 요청을 PAS 및 AAS로 분산하는 지능형 소프트웨어 부하 분산기입니다.

다음 Google Cloud 서비스가 SAP S/4HANA에서 사용됩니다.

서비스 설명
VPC 네트워킹

VM 인스턴스를 서로 간에 그리고 인터넷에 연결합니다.

각 VM 인스턴스는 단일 전역 IP 범위를 가진 기존 네트워크의 구성원이거나 대규모 네트워크에 속한 단일 서브네트워크에 VM 인스턴스가 속하는 권장 서브넷 네트워크입니다.

가상 프라이빗 클라우드(VPC) 네트워크는 Google Cloud 프로젝트를 포함할 수 없지만 Google Cloud 프로젝트에는 여러 VPC 네트워크가 있을 수 있습니다.

여러 프로젝트의 리소스를 공통 VPC 네트워크에 연결하려면 공유 VPC를 사용합니다. 이렇게 하면 해당 네트워크의 내부 IP 주소를 사용하여 리소스가 서로 안전하고 효율적으로 통신할 수 있습니다. 요구사항, 구성 단계, 사용을 비롯하여 공유 VPC를 프로비저닝하는 방법에 대한 자세한 내용은 공유 VPC 프로비저닝을 참조하세요.

Compute Engine 원하는 운영체제 및 소프트웨어 스택을 사용하여 VM을 만들고 관리합니다.
Persistent Disk 및 Hyperdisk

Persistent Disk와 Google Cloud Hyperdisk를 사용할 수 있습니다.

  • Persistent Disk 볼륨은 표준 하드 디스크 드라이브(HDD) 또는 솔리드 스테이트 드라이브(SSD)로 제공됩니다. 균형 있는 영구 디스크와 SSD 영구 디스크의 경우, PD 비동기 복제는 두 Google Cloud 리전 간 SAP 데이터의 비동기 복제를 제공합니다.
  • 하이퍼디스크 익스트림 볼륨은 SSD Persistent Disk 볼륨보다 더 높은 최대 IOPS 및 처리량 옵션을 제공합니다.
  • 기본적으로 Compute Engine은 Persistent Disk 및 Hyperdisk 볼륨 내부의 콘텐츠를 포함하여 고객 저장 콘텐츠를 암호화합니다. 디스크 암호화 및 가능한 암호화 옵션에 대한 자세한 내용은 디스크 암호화 정보를 참조하세요.
Google Cloud 콘솔

Compute Engine 리소스를 관리하는 브라우저 기반 도구입니다.

템플릿을 사용하여 필요한 모든 Compute Engine 리소스와 인스턴스를 설명합니다. Google Cloud 콘솔에서 수행되므로 리소스를 개별적으로 만들고 구성하거나 종속 항목을 파악할 필요가 없습니다.

Cloud Storage 복제를 통해 내구성과 안정성을 높이기 위해 SAP 데이터베이스 백업을 Cloud Storage에 저장할 수 있습니다.
Cloud Monitoring

Compute Engine, 네트워크, 영구 스토리지 디스크의 배포, 성능, 업타임, 상태를 확인할 수 있습니다.

Monitoring은 Google Cloud에서 측정항목, 이벤트, 메타데이터를 수집하고 이를 사용하여 대시보드, 차트, 알림으로부터 유용한 정보를 생성합니다. Monitoring을 통해 무료로 Compute 측정항목을 모니터링할 수 있습니다.

IAM

Google Cloud 리소스의 권한을 통합적으로 제어할 수 있습니다.

IAM을 사용하면 VM과 영구 스토리지 디스크의 생성, 수정, 삭제 그리고 네트워크 생성 및 수정을 포함하여 VM에서 제어 영역 작업을 수행할 수 있는 사용자를 제어할 수 있습니다.

Filestore

Google Cloud의 고성능 완전 관리형 NFS 파일 스토리지입니다.

멀티 영역 고가용성 배포의 경우 99.99%의 가용성 SLA를 제공하는 Filestore Enterprise를 사용하는 것이 좋습니다. Filestore 서비스 등급에 대한 자세한 내용은 서비스 등급을 참조하세요.

NetApp Cloud Volumes ONTAP

Compute Engine VM 인스턴스에 직접 배포하고 관리하는 전체 기능을 갖춘 스마트 스토리지 솔루션입니다.

NetApp Cloud Volumes ONTAP에 대한 자세한 내용은 Cloud Volumes ONTAP 개요를 참조하세요.

Google Cloud NetApp Volumes

NetApp Cloud Volumes ONTAP을 기반으로 하고 Google Cloud에서 제공되는 완전 관리형 NFS 및 SMB 파일 스토리지 솔루션입니다.

리전에 따라 여러 서비스 레벨 중에서 선택할 수 있습니다. 자세한 내용은 서비스 수준을 참조하세요.

설계 고려사항

이 섹션에서는 이 참조 아키텍처를 사용하여 보안, 안정성, 작업 효율, 비용, 성능에 대한 특정 요구사항을 충족하는 아키텍처를 개발하는 데 도움이 되는 안내를 제공합니다.

네트워킹

네트워킹 관점에서 SAP S/4HANA 시스템을 배포하는 방법에는 여러 가지가 있으며 네트워크 배포 방법은 가용성, 복원력, 성능에 상당한 영향을 줍니다. 앞에서 언급했듯이 Virtual Private Cloud(VPC)는 Google Cloud 내에서 호스팅되는 안전하고 격리된 비공개 네트워크입니다. VPC는 Google Cloud에서 전역적이므로 인터넷으로 통신하지 않아도 단일 VPC를 여러 리전으로 확장할 수 있습니다.

일반적인 SAP 배포는 HA 시스템 인스턴스를 동일 리전의 여러 영역에 배치하여 낮은 지연 시간을 제공하는 동시에 복원력을 보장합니다. 서브넷은 Google Cloud 기능으로 인해 여러 영역에 걸쳐 있을 수 있습니다. 또한 클러스터의 가상 IP(VIP) 주소가 HA 시스템 인스턴스와 동일한 범위에 있을 수 있으므로 이러한 기능은 SAP 클러스터링을 간소화합니다. 이 구성은 내부 애플리케이션 부하 분산기를 사용하여 유동 IP를 보호하며 애플리케이션 레이어(ASCS 및 ERS) 및 SAP HANA 데이터베이스 레이어(SAP HANA 기본 및 보조)의 HA 클러스터링에 적용할 수 있습니다.

네트워크를 빌드하고 SAP S/4HANA 시스템을 인프라와 연결하는 방법에는 여러 가지가 있습니다.

  • VPC 네트워크 피어링은 2개의 VPC 네트워크를 연결하여 각 네트워크의 리소스가 서로 통신할 수 있게 해줍니다. VPC 네트워크는 동일한 Google Cloud 프로젝트, 동일한 조직의 다른 프로젝트 또는 심지어 다른 조직의 다른 프로젝트에서 호스팅될 수도 있습니다. VPC 네트워크 피어링은 각각 자체 서브넷을 사용하는 두 VPC 네트워크 간에 직접 연결을 설정하여 피어링된 VPC의 리소스 간 비공개 통신을 사용 설정합니다.

  • 공유 VPC는 조직이 여러 프로젝트의 리소스를 공통 VPC 네트워크에 연결할 수 있게 해주는 Google Cloud 기능입니다. 공유 VPC를 사용하는 시스템은 내부 IP 주소를 사용하여 효율적이고 안전하게 통신할 수 있습니다. 호스트 프로젝트의 서브넷, 경로, 방화벽과 같은 네트워크 리소스를 중앙에서 관리하는 동시에 개별 리소스를 만들고 관리하는 관리 책임을 서비스 프로젝트에 위임할 수 있습니다. 이렇게 분리하면 네트워크 관리가 간소화되고 조직 전체에 일관된 보안 정책이 적용됩니다.

SAP 시스템의 경우 일반적으로 환경 유형별로 리소스를 그룹화하는 것이 좋습니다. 예를 들어 프로덕션 환경에서는 적절한 격리를 제공하기 위해 비프로덕션 환경과 컴퓨팅 리소스를 공유하면 안 되지만 프로젝트 간의 공통 연결 레이어를 위해 공유 VPC를 사용할 수 있습니다. 독립 VPC를 사용하고 VPC 피어링을 사용하여 프로젝트를 연결할 수도 있습니다.

네트워크를 설계하는 동안 먼저 공유 VPC 네트워크가 포함된 호스트 프로젝트부터 시작합니다. 서비스 프로젝트가 공유 VPC에 첨여하도록 추가 서비스 프로젝트를 호스트 프로젝트에 연결할 수 있습니다. 필요에 따라 SAP S/4HANA를 단일 VPC 또는 여러 공유 VPC에 배포할 수 있습니다. 두 시나리오는 네트워크 제어, SAP 환경 격리, 네트워크 검사 측면에서 다릅니다.

  • 시나리오 1: 단일 공유 VPC에 SAP S/4HANA 배포하기 그러면 네트워크 간의 격리를 줄이는 대신 배포를 간소화하고 관리 오버헤드를 줄일 수 있습니다.
  • 시나리오 2: 여러 공유 VPC에 SAP S/4HANA를 배포합니다. 그러면 복잡성과 관리 오버헤드가 증가하는 대신 네트워크 격리가 증가하고 보안이 강화됩니다.

또한 하이브리드 접근 방식을 사용할 수 있습니다. 예를 들어 프로덕션 환경에 하나의 공유 VPC를 사용하고 모든 비프로덕션 시스템에 하나의 공유 VPC를 사용할 수 있습니다. 자세한 내용은 Google Cloud 기반 SAP의 일반 체크리스트에서 "네트워킹" 섹션을 참조하세요.

단일 장애점

SAP S/4HANA 시스템에는 시스템 가용성에 영향을 줄 수 있는 일반적인 단일 장애점이 있습니다.

  • Message Server 및 Enqueue Server와 같은 SAP Central Services
  • SAP 애플리케이션 서버
  • SAP HANA 데이터베이스
  • SAP Web Dispatcher(시스템에 대한 HTTP/HTTPS 액세스를 위한 프런트엔드로 사용되는 경우)
  • NFS와 같은 공유 스토리지

이러한 단일 장애점의 영향을 줄이기 위한 여러 옵션이 있으며 이러한 옵션에는 고가용성 솔루션, 복제 서비스를 사용하여 시스템을 배포하거나 장애로부터 시스템을 보호하는 다른 기능을 사용하는 것이 포함됩니다. SAP S/4HANA 시스템을 계획할 때는 이러한 단일 장애점을 연구하고 그에 따라 계획을 세우는 것이 좋습니다. 단일 장애점 관리를 위해 사용할 수 있는 대체 솔루션에 대한 개요는 이 가이드에서 다음 섹션을 참조하세요.

가용성 및 연속성

SAP S/4HANA 구현 계획 단계에서 시스템의 가용성과 연속성을 정의하기 위해 다음과 같은 데이터 포인트를 지정해야 합니다.

  • 서비스 수준 목표 (SLO): 서비스 수준 지표(SLI)로 측정되는 서비스 수준의 목표 값 또는 값 범위입니다. 예를 들면 성능, 가용성, 안정성 등이 있습니다.
  • 서비스 수준 지표(SLI): 서비스 성능을 측정하는 데 도움이 되는 지연 시간과 같은 측정항목입니다. 이는 제공되는 서비스 수준의 일부 측면에 대한 신중하게 정의된 정량적 측정입니다.
  • 서비스수준계약(SLA): 서비스 수준 목표(SLO)라는 측정 가능한 용어로 제공되는 서비스에 대한 계약을 정의하는 두 당사자(제공업체, 고객) 간의 서비스 계약입니다.
  • 복구 시간 목표(RTO): 데이터 손실 이슈와 해결 사이에 허용되는 최대 기간입니다.
  • 복구 지점 목표 (RPO): 복구 지점 목표(RPO)는 심각한 손상을 입히지 않고 시간 내에 측정된 손실될 수 있는 최대 데이터 양입니다. 이는 사실상 데이터 손실 발생 후 영향을 받은 데이터의 상태를 복구해야 하는 시점을 의미합니다.

데이터 포인트와 모든 이해관계자 간에 합의된 값에 따라 SAP S/4HANA 시스템은 고가용성 또는 재해 복구와 같은 기능에 의존합니다.

  • 고가용성(HA): 비즈니스 연속성 목표를 지원하는 동시에 필요 시 사용자가 데이터 및 서비스를 사용할 수 있게 하는 시스템의 기능입니다. 이 기능을 달성하는 일반적인 방법은 하드웨어 중복, 네트워크 중복, 데이터 센터 중복을 포함한 중복을 사용 설정하는 것입니다.
  • 재해 복구(DR): 다른 하드웨어 및/또는 물리적 위치에서 안정적이고 예측 가능한 복구 방법을 통해 예기치 않은 중단으로부터 시스템을 보호하는 기능입니다.

고가용성 및 재해 복구는 모두 호환되지만 서로 다른 사례와 상황에 적용됩니다. 예를 들어 HA 솔루션을 사용하면 시스템 요소 중 하나에 예기치 않은 다운타임이나 중단이 발생하는 경우 사용자를 방해하지 않고 작업을 계속할 수 있습니다. 서비스 중단이 발생한 순간부터 DR 솔루션이 해당 시스템의 장애 요소를 다른 위치에서 시작할 때까지 중단이 발생한다는 것을 제외하면 DR 솔루션에 대해서도 마찬가지입니다.

다음 섹션에서는 Google Cloud에서 SAP S/4HANA 시스템을 계획 및 배포할 때 사용 가능한 여러 옵션들에 대한 개요를 제공합니다.

SAP S/4HANA에 지원되는 머신 유형

Google Cloud는 SAP에서 인증된 Compute Engine VM 인스턴스 유형을 제공하며, 이는 SAP S/4HANA를 배포할 때 크기 요구사항을 충족합니다. Google Cloud의 크기 조정 및 지원되는 머신 유형에 대한 자세한 내용은 다음 페이지를 참조하세요.

Google Cloud의 SAP HANA용 커스텀 머신 유형도 SAP 인증을 받았습니다. 메모리 대 vCPU 비율을 최소 1:6.5 이상으로 유지하면 vCPU가 64개 미만인 SAP HANA 인스턴스를 실행할 수 있습니다.

SAP 애플리케이션에 대해 인증된 Compute Engine 가상 머신의 SAPS 번호를 보려면 SAP 참고 2456432 - Google Cloud 기반 SAP 애플리케이션: 지원되는 제품 및 Google Cloud 머신 유형 SAP 참고를 확인하세요.

SAP 자체 웹사이트에서도 SAP HANA용으로 인증된 Google Cloud 구성 목록을 제공합니다. 자세한 내용은 인증 및 지원되는 SAP HANA 하드웨어 디렉터리를 참조하세요.

리전 및 영역 계획

VM 배포 시 리전과 영역을 선택해야 합니다. 리전은 리소스를 실행할 수 있는 특정한 지리적 위치이며 서로 상대적으로 가까운 하나 이상의 데이터 센터 위치에 해당합니다. 각 리전에는 중복 연결, 전원, 냉각 기능을 갖춘 하나 이상의 영역이 있습니다.

전체 리전과 영역에서 사전 구성된 디스크 이미지 및 디스크 스냅샷과 같은 전역 리소스에 액세스할 수 있습니다. 리전별 외부 고정 IP 주소와 같은 리전별 리소스는 동일한 리전에 있는 리소스를 통해서만 액세스될 수 있습니다. VM 및 디스크와 같은 영역 리소스는 같은 영역에 위치한 리소스를 통해서만 액세스될 수 있습니다. 자세한 내용은 전역, 리전, 영역별 리소스를 참조하세요.

Google Cloud 리전 및 영역

VM의 리전 및 영역을 선택할 때는 다음 사항을 고려하세요.

  • 사용자 및 내부 리소스 위치(예: 데이터 센터 또는 기업 네트워크). 지연 시간 단축을 위해 사용자 및 리소스와 가까운 위치를 선택해야 합니다.
  • 해당 리전 및 영역에서 사용할 수 있는 CPU 플랫폼. 예를 들어 Intel의 Broadwell, Haswell, Skylake, Ice Lake 프로세서는 Google Cloud 기반 SAP NetWeaver 워크로드에 대해 지원됩니다.
  • SAP Application Server 및 데이터베이스가 동일한 리전에 있는지 확인합니다.

SAP S/4HANA를 위한 스토리지 옵션

다음은 SAP S/4HANA 및 SAP HANA와 함께 사용할 수 있도록 SAP가 인증한 Google Cloud에서 제공하는 스토리지 옵션입니다.

Google Cloud의 스토리지 옵션에 대한 일반적인 정보는 스토리지 옵션을 참조하세요.

Persistent Disk

  • 표준 영구 디스크(pd-standard): 표준 하드 디스크 드라이브(HDD)에서 지원되는 순차적 읽기-쓰기 작업을 처리하는 데 효율적이고 경제적인 블록 스토리지이지만 높은 속도의 무작위 초당 입출력 작업수(IOPS)를 처리하는 데는 최적화되어 있지 않습니다.
  • SSD 영구 디스크(pd-ssd): 솔리드 스테이트 드라이브 (SSD)에서 지원되는 안정적인 고성능 블록 스토리지를 제공합니다.
  • 균형 있는 영구 디스크(pd-balanced): 비용 효율적이고 안정적인 SSD 기반 블록 스토리지를 제공합니다.
  • 익스트림 영구 디스크(pd-extreme): SSD 기반: 더 큰 Compute Engine 머신 유형의 경우 pd-ssd보다 높은 최대 IOPS 및 처리량 옵션을 제공합니다. 자세한 내용은 익스트림 영구 디스크를 참조하세요.

하이퍼디스크

  • 하이퍼디스크 익스트림(hyperdisk-extreme): SSD 기반 Persistent Disk 볼륨보다 더 높은 최대 IOPS 및 처리량 옵션을 제공합니다. IOPS를 프로비저닝하여 필요한 성능을 선택하면 처리량이 결정됩니다. 이는 주로 SAP HANA 데이터베이스의 /hana/data/hana/log 볼륨을 호스팅하는 데 사용됩니다. 자세한 내용은 Google Cloud Hyperdisk 정보를 참조하세요.

  • 하이퍼디스크 균형(hyperdisk-balanced): 대부분의 워크로드에 가장 적합합니다. 하이퍼디스크 익스트림의 성능이 필요하지 않은 데이터베이스에 사용하는 것이 좋습니다. 하이퍼디스크 균형 볼륨을 사용하여 /hana/data/hana/log 디렉터리를 호스팅할 수 있습니다. IOPS 및 처리량을 프로비저닝하여 필요한 성능을 선택할 수 있습니다. 자세한 내용은 Google Cloud Hyperdisk 정보를 참조하세요.

Persistent Disk 및 하이퍼디스크는 높은 내구성을 위해 설계되었습니다. 데이터 무결성을 위해 데이터를 중복 저장합니다. 각 Persistent Disk 볼륨의 저장용량은 최대 64TB까지 설정할 수 있으므로 다수의 디스크 배열을 관리하지 않고도 대용량의 논리 볼륨을 생성할 수 있습니다. 하이퍼디스크 볼륨은 사용하는 유형에 따라 최대 64TB의 스토리지를 허용합니다. 한 가지 주요 기능은 Persistent Disk 및 하이퍼디스크 볼륨이 자동으로 암호화되어 데이터를 보호하는 것입니다.

기본적으로 각 Compute Engine VM 인스턴스에는 생성되는 즉시 운영체제를 포함하는 단일 루트 Persistent Disk 또는 하이퍼디스크를 할당합니다. 필요 시 VM 인스턴스에 스토리지 옵션을 더 추가할 수 있습니다.

SAP 구현의 경우 SAP 디렉터리 구조 및 스토리지 옵션에서 권장되는 스토리지 옵션을 검토하세요.

파일 공유 솔루션

Google Cloud에서 다음을 포함한 여러 파일 공유 솔루션을 사용할 수 있습니다.

  • Filestore: 리전별 가용성이 있는 Google Cloud 고성능 완전 관리형 NFS 파일 스토리지입니다.
  • Google Cloud NetApp Volumes: Google Cloud의 완전 관리형 NFS 또는 SMB 파일 스토리지 솔루션입니다.
  • NetApp Cloud Volumes ONTAP: Compute Engine VM에서 직접 배포 및 관리하는 완전 관리형 스마트 스토리지 솔루션입니다.

Google Cloud 기반 SAP S/4HANA용 파일 공유 솔루션에 대한 자세한 내용은 Google Cloud 기반 SAP용 파일 공유 솔루션을 참조하세요.

객체 스토리지를 위한 Cloud Storage

Cloud Storage는 유형이나 형식에 상관없이 파일을 저장하는 객체 스토리지입니다. 저장용량이 무제한이나 다름없기 때문에 프로비저닝이나 용량 추가에 대해 걱정할 필요 없습니다. Cloud Storage의 객체에는 파일 데이터 및 관련 메타데이터를 포함하며, 크기는 최대 5테라바이트에 이릅니다. Cloud Storage 버킷은 객체를 무제한으로 저장할 수 있습니다.

Cloud Storage는 백업 파일을 저장하는 용도로 사용되는 경우가 가장 많습니다. 예를 들어 Cloud Storage는 SAP HANA 데이터베이스 백업을 저장하기에 적합합니다. 데이터베이스 백업 계획에 대한 자세한 내용은 데이터베이스 백업 및 복구를 참조하세요. 그 밖에 마이그레이션 프로세스에서도 Cloud Storage를 사용할 수 있습니다.

또한 백업 및 DR 서비스를 백업 및 재해 복구 작업을 위한 중앙 집중식 솔루션으로 사용할 수 있습니다. 이 서비스는 SAP HANA를 포함하여 광범위한 데이터베이스를 지원합니다. 자세한 내용은 Google Cloud를 사용하여 백업 및 재해 복구 솔루션을 참조하세요.

Cloud Storage 옵션은 필요한 데이터 액세스 주기에 따라 선택합니다. 자주 액세스하는 경우(예: 한 달에 여러 번) Standard Storage 클래스를 선택합니다. 액세스 횟수가 비교적 적다면 Nearline 또는 Coldline Storage를 선택하세요. 액세스 가능성이 낮은 보관처리된 데이터의 경우 Archive Storage를 선택합니다.

SAP 디렉터리 구조 및 스토리지 옵션

다음 표에서는 Google Cloud의 SAP HANA 데이터베이스 및 SAP ABAP 인스턴스용 Linux 디렉터리 구조를 설명합니다.

  • SAP HANA의 Linux 디렉터리 구조에 권장되는 스토리지 옵션은 다음과 같습니다.

    SAP HANA 디렉터리 Google Cloud의 권장 스토리지 옵션
    /usr/sap 균형 있는 영구 디스크
    /hana/data SSD 기반 영구 디스크 또는 하이퍼디스크
    /hana/log SSD 기반 영구 디스크 또는 하이퍼디스크
    /hana/shared* 균형 있는 영구 디스크
    /hanabackup* 균형 있는 영구 디스크

    분산형 배포에서 /hana/shared/hanabackup은 Filestore와 같은 NFS 솔루션을 사용하는 네트워크 파일 시스템으로 마운트할 수도 있습니다.

    SAP가 SAP HANA와 함께 사용하도록 인증한 영구 디스크 스토리지에 대한 자세한 내용은 SAP HANA용 영구 디스크 스토리지를 참조하세요.

  • SAP ABAP 인스턴스의 Linux 디렉터리 구조에 권장되는 스토리지 옵션은 다음과 같습니다.

    디렉터리 Google Cloud의 권장 스토리지 옵션
    /sapmnt 균형 있는 영구 디스크
    /usr/sap 균형 있는 영구 디스크

    분산형 배포에서 /sapmnt는 또한 Filestore와 같은 NFS 솔루션을 사용하는 네트워크 파일 시스템으로 마운트할 수도 있습니다.

    SAP가 SAP ABAP 인스턴스와 함께 사용하도록 인증한 영구 디스크 스토리지에 대한 자세한 내용은 SAP 애플리케이션용 영구 디스크 스토리지를 참조하세요.

SAP S/4HANA용 OS 지원

Google Cloud에서 SAP NetWeaver용 운영체제(OS)를 선택할 때는 SAP 인증을 받은 OS 버전인지 그리고 SAP, OS 제공업체, GCP에서 모두 지원하는 OS 버전인지 확인해야 합니다.

또한 결정할 때 다음 사항을 고려해야 합니다.

  • Google Cloud에서 지정된 OS 버전 사용 여부. Compute Engine에서 제공하는 OS 이미지는 Google Cloud에서 작동하도록 구성되어 있습니다. Google Cloud에서 OS를 사용할 수 없는 경우 사용자 OS 이미지(BYOI) 및 라이선스를 사용할 수 있습니다. BYOI OS 이미지는 Compute Engine에서 커스텀 이미지라고 합니다.
  • 지정된 OS 버전에 사용할 수 있는 라이선스 옵션. OS 버전에 주문형 라이선스 옵션이 있는지 또는 OS 공급업체에서 BYOS(Bring-Your-Own-Subscription)가 필요한지 검토합니다.
  • 지정된 OS 버전에 통합된 고가용성 기능이 Google Cloud에 사용 설정되었는지 여부.
  • SLES for SAP 및 RHEL for SAP 이미지의 약정 사용 할인 옵션.

Google Cloud에서 SAP NetWeaver와 함께 사용하도록 SAP 인증을 받은 운영체제는 다음과 같습니다.

다음 가이드에서 SAP S/4HANA 및 SAP HANA에 대한 특정 OS 버전 및 호환성 관련 정보를 찾을 수 있습니다.

SAP HANA 빠른 다시 시작 옵션

SAP HANA 2.0 SP04 이상의 경우 Google에서는 SAP HANA 빠른 다시 시작 옵션 사용을 강력하게 권장합니다.

이 옵션은 Google Cloud에서 제공하는 sap_hana 또는 sap_hana_ha, 버전 202309280828 이상의 Terraform 모듈을 사용하여 SAP HANA를 배포할 때 자동으로 사용 설정됩니다. SAP HANA 빠른 다시 시작을 수동으로 사용 설정하는 방법에 대한 자세한 내용은 SAP HANA 빠른 다시 시작 사용 설정을 참조하세요.

SAP HANA 빠른 다시 시작은 SAP HANA가 종료되지만 운영체제는 계속 실행되는 경우 다시 시작하는 시간을 줄입니다. 다시 시작 시간을 줄이기 위해 SAP HANA는 SAP HANA 영구 메모리 기능을 활용하여 tmpfs 파일 시스템에 매핑된 열 저장 테이블의 MAIN 데이터 프래그먼트를 DRAM에 보존합니다.

또한 Compute Engine 메모리 최적화 머신 유형인 M2 및 M3 계열의 VM에서 SAP HANA 빠른 재시작은 메모리에서 수정 불가능한 오류가 발생하면 복구 시간을 개선합니다. 자세한 내용은 SAP HANA 빠른 재시작 옵션을 참조하세요.

SAP HANA용 배포 아키텍처

SAP HANA는 시스템의 데이터베이스 역할을 하므로 모든 SAP S/4HANA 시스템의 핵심 구성요소입니다. SAP HANA 데이터베이스를 배포할 때 사용할 수 있는 두 가지 가능한 아키텍처는 수직 확장수평 확장입니다.

수직 확장 아키텍처

다음 다이어그램은 Google Cloud에서 SAP HANA의 수직 확장 아키텍처를 보여줍니다. 다이어그램에서 Google Cloud에 배포된 모습과 디스크 레이아웃을 주목하세요. Cloud Storage를 사용하여 /hanabackup에 있는 로컬 백업을 백업할 수 있습니다. 단, 이 마운트는 데이터 마운트보다 크거나 같도록 크기를 조절해야 합니다.

Google Cloud에서 SAP HANA 수직 확장 시스템 배포를 위한 아키텍처 다이어그램입니다.

수평 확장 아키텍처

SAP HANA용 수평 확장 아키텍처는 하나의 마스터 호스트와 다수의 작업자 호스트, 그리고 선택적으로 하나 이상의 대기 호스트로 구성됩니다. 각 호스트는 고대역폭 네트워킹을 사용하여 선택한 머신 유형에서 최대 32Gbps 또는 최대 100Gbps의 속도로 노드 간 데이터 전송을 지원하는 네트워크를 통해 서로 연결됩니다.

특히 온라인 분석 처리(OLAP)를 사용할 때 워크로드 수요가 증가하면 다중 호스트 스케일아웃 아키텍처가 부하를 모든 호스트로 분산시킬 수 있습니다.

다음 다이어그램은 Google Cloud에서 SAP HANA의 수평 확장 아키텍처를 보여줍니다.

Google Cloud에서 SAP HANA 수평 확장 시스템 배포를 위한 아키텍처 다이어그램입니다.

SAP S/4HANA용 배포 아키텍처

아키텍처 섹션에서 언급한 대로 Google Cloud에서 SAP S/4HANA를 배포할 때 사용할 수 있는 배포 아키텍처는 여러 가지가 있습니다.

2계층 아키텍처

이 아키텍처는 중앙 집중식 배포 섹션에서 제공됩니다. 다음 다이어그램은 Compute Engine VM에서 실행되는 SAP S/4HANA용 2계층 아키텍처에 대한 몇 가지 세부정보를 나타낸 것입니다.

Google Cloud 기반 Compute Engine VM에서 SAP S/4HANA용 2계층 아키텍처

3계층 아키텍처

이 아키텍처는 분산형 배포 섹션에서 제공됩니다. 이 아키텍처를 사용하여 고가용성 SAP S/4HANA 시스템을 배포할 수 있습니다. 다음 다이어그램은 Compute Engine VM에서 실행되는 SAP S/4HANA용 3계층 아키텍처에 대한 몇 가지 세부정보를 보여줍니다.

Google Cloud 기반 Compute Engine VM의 SAP S/4HANA용 3계층 아키텍처

이 아키텍처에서 SAP S/4HANA 시스템은 각각 별도의 VM에 호스팅된 여러 NetWeaver Application Server(AS)로 작업을 분산시킵니다. 모든 NetWeaver AS 노드는 별도의 VM에 호스팅된 동일한 데이터베이스를 공유합니다. 모든 NetWeaver AS 노드는 SAP NetWeaver 프로필이 호스팅되는 공유 파일 시스템을 마운트하고 액세스합니다. 이 공유 파일 시스템은 모든 노드 또는 지원되는 파일 공유 솔루션에서 공유되는 영구 디스크 볼륨에서 호스팅됩니다.

보안, 개인정보 보호, 규정 준수

이 섹션에서는 Google Cloud에서 SAP S/4HANA를 실행하기 위한 보안, 개인 정보 보호, 규정 준수에 대한 정보를 제공합니다.

규정 준수 및 주권 제어

데이터 상주, 액세스 제어, 지원 담당자 또는 규제 요건에 따라 SAP 워크로드를 실행해야 하는 경우 Assured Workloads를 사용할 계획을 세워야 합니다. Assured Workloads는 클라우드 환경의 품질을 저하시키지 않고 Google Cloud에서 규정을 준수하는 안전한 워크로드를 실행하는 데 도움이 됩니다. 자세한 내용은 Google Cloud 기반 SAP의 규정 준수 및 주권 제어를 참조하세요.

네트워킹 및 네트워크 보안

네트워킹 및 네트워크 보안을 계획할 때 다음 섹션의 정보를 고려하세요.

최소 권한 모델

첫 번째 방어선 중 하나는 네트워크와 VM에 연결할 수 있는 대상을 제한하는 것입니다. VPC 방화벽 규칙을 사용하여 이를 수행합니다. 기본적으로 액세스를 허용하는 규칙을 만들지 않으면 VM에 대한 모든 트래픽은 방화벽에 의해 차단되며, 이는 다른 VM에서 들어오는 트래픽의 경우에도 마찬가지입니다. 하지만 각 프로젝트와 함께 자동으로 생성되고 기본 방화벽 규칙을 가지는 기본 네트워크는 예외입니다.

VPC 방화벽 규칙을 만들면 지정된 포트 집합에서 모든 트래픽을 특정 소스 IP 주소로 제한할 수 있습니다. 액세스가 필요한 특정 IP 주소, 프로토콜, 포트로 액세스를 제한하려면 최소 권한 모델을 따르세요. 예를 들어 항상 배스천 호스트를 설정하고 해당 호스트에서만 SAP NetWeaver 시스템에 SSH 통신을 허용합니다.

커스텀 네트워크 및 방화벽 규칙

네트워크를 사용하여 게이트웨이 IP와 네트워크에 연결된 VM의 네트워크 범위를 정의할 수 있습니다. 각 Compute Engine 네트워크는 IPv4 프로토콜을 사용합니다. 각 Google Cloud 프로젝트에는 구성 및 방화벽 규칙이 사전 설정되어 있는 기본 네트워크가 제공되지만, 최소 권한 모델에 따라 커스텀 서브네트워크와 방화벽 규칙을 추가하는 것이 좋습니다. 기본적으로 새로 생성된 네트워크에는 방화벽 규칙이 없으므로 네트워크 액세스 권한이 없습니다.

네트워크의 일부를 격리하거나 다른 요구사항을 충족시키고자 하는 경우 2개 이상의 서브네트워크를 추가할 수 있습니다. 자세한 내용은 네트워크 및 서브넷을 참조하세요.

방화벽 규칙은 전체 네트워크와 네트워크에 있는 모든 VM에 적용됩니다. 같은 네트워크의 여러 서브네트워크에 있는 VM 간에 트래픽을 허용하는 방화벽 규칙을 추가할 수 있습니다. 또한 네트워크 태그를 사용하여 특정 대상 VM에 적용하도록 방화벽을 구성할 수 있습니다.

SAP는 특정 포트에 대한 액세스를 요구하기 때문에 SAP에서 지정한 포트에 대한 액세스를 허용하는 방화벽 규칙을 추가해야 합니다.

경로

경로는 단일 네트워크에 연결된 전역 리소스입니다. 사용자가 만든 경로는 네트워크에 있는 모든 VM에 적용됩니다. 즉, 외부 IP 주소를 요구하지 않고도 같은 네트워크의 여러 서브네트워크에 있는 VM 간에 트래픽을 전달하는 경로를 추가할 수 있습니다.

외부에서 인터넷 리소스에 액세스하는 경우, 외부 IP 주소가 없는 VM을 실행하고 다른 VM을 NAT 게이트웨이로 구성합니다. 이렇게 구성하려면 NAT 게이트웨이를 SAP 인스턴스의 경로로 추가해야 합니다.

배스천 호스트 및 NAT 게이트웨이

보안 정책에 진정한 내부 VM이 필요한 경우, VM이 인터넷에 연결될 수 있도록 네트워크와 해당 경로에 NAT 프록시를 수동으로 설정해야 합니다. SSH를 사용하면 완전한 내부 VM 인스턴스에 직접 연결할 수 없습니다.

이러한 내부 머신에 연결하려면 외부 IP 주소가 있는 배스천 인스턴스를 설정한 후 이를 통해 터널링해야 합니다. VM에 외부 IP 주소가 없으면 네트워크의 다른 VM 또는 관리형 VPN 게이트웨이를 통해서만 연결할 수 있습니다. 신뢰할 수 있는 인바운드 연결(배스천 호스트) 또는 네트워크 이그레스(NAT 게이트웨이)의 릴레이 역할을 수행하도록 VM을 네트워크에 프로비저닝할 수 있습니다. 이러한 연결을 설정하지 않고 보다 투명하게 연결하려면 관리형 VPN 게이트웨이 리소스를 사용하면 됩니다.

인바운드 연결을 위한 배스천 호스트

배스천 호스트는 사설망 VM이 포함된 네트워크에서 외부 진입점 역할을 수행합니다. 이 호스트는 단일 요새 지점 또는 감사 지점이 될 수 있으며, 이 호스트를 시작 또는 중지시켜 인터넷에서 인바운드 SSH 통신을 사용 설정 또는 중지할 수 있습니다.

SSH 시나리오의 배스천 호스트

먼저 배스천 호스트에 연결하면 SSH를 통해 외부 IP 주소가 없는 VM에 액세스할 수 있습니다. 배스천 호스트의 완벽한 강화는 이 문서의 범위를 벗어나지만 다음을 비롯한 몇 가지 초기 조치를 취할 수 있습니다.

  • 배스천과 통신할 수 있는 소스 IP의 CIDR 범위를 제한합니다.
  • 배스천 호스트에서만 사설 VM에 대한 SSH 트래픽을 허용하도록 방화벽 규칙을 구성합니다.

기본적으로 VM의 SSH는 비공개 키를 사용하여 인증되도록 구성됩니다. 배스천 호스트를 사용할 때는 우선 배스천 호스트에 로그인한 다음 대상 비공개 VM에 로그인합니다. 이러한 2단계 로그인으로 인해 대상 VM의 비공개 키를 배스천 호스트에 저장하는 대신 SSH 에이전트 전달을 통해 대상 VM에 연결하는 것이 좋습니다. 배스천은 키 쌍의 절반인 공개 부분에만 직접 액세스할 수 있으므로 배스천과 대상 VM 모두에 대해 동일한 키-값 쌍을 사용하는 경우에도 이 작업을 수행해야 합니다.

아웃바운드 데이터 전송을 위한 NAT 게이트웨이

VM에 외부 IP 주소가 할당되어 있지 않으면 다른 Google Cloud 서비스를 포함한 외부 서비스에 직접 연결할 수 없습니다. 이러한 VM이 인터넷의 서비스에 연결할 수 있도록 NAT 게이트웨이를 설정하고 구성할 수 있습니다. NAT 게이트웨이는 네트워크에 있는 다른 VM을 대신하여 트래픽을 라우팅할 수 있는 VM입니다. NAT 게이트웨이는 네트워크마다 1개씩 사용합니다. VM이 1개인 NAT 게이트웨이는 가용성이 높지 않기 때문에 VM이 다수일 경우 높은 트래픽 처리량을 지원하지 못합니다. NAT 게이트웨이 역할을 하도록 VM을 설정하는 방법은 해당 운영체제의 배포 가이드를 참조하세요.

Cloud VPN

Cloud VPN을 사용하면 IPsec을 사용하는 VPN 연결을 통해 기존 네트워크를 Google Cloud에 안전하게 연결할 수 있습니다. 한쪽 VPN 게이트웨이에서 두 네트워크 사이에 전송되는 트래픽을 암호화하면 이후 다른 쪽 VPN 게이트웨이에서 이를 복호화합니다. 인터넷에서 전송되는 데이터가 보호됩니다. 경로에 인스턴스 태그를 사용하여 VPN으로 트래픽을 보낼 수 있는 VM을 동적으로 제어할 수 있습니다. Cloud VPN 터널 비용은 월간 고정 요금에 아웃바운드 데이터 전송에 대한 표준 요금이 합쳐져 청구됩니다. 같은 프로젝트의 두 네트워크를 연결하더라도 아웃바운드 데이터 전송에 대한 표준 요금이 여전히 청구됩니다. 자세한 내용은 다음을 참고하세요.

Cloud Storage 버킷 보안

Cloud Storage를 사용하여 데이터와 로그 볼륨의 백업을 호스팅하는 경우, 전송 중 데이터를 보호하려면 VM에서 Cloud Storage로 데이터를 전송할 때 TLS(HTTPS)를 사용해야 합니다.

Cloud Storage는 저장 데이터를 자동으로 암호화하지만, 자체 키 관리 시스템을 가지고 있으면 대신 자체 암호화 키를 지정할 수도 있습니다.

이메일 알림 한도

사용자 시스템과 Google 시스템의 악용을 막기 위해 Google Cloud는 Compute Engine에서 이메일을 전송할 때 몇 가지 제한 사항을 적용합니다. 이는 온프레미스 시스템과 비교하여 특정 구성이 필요하므로 SAP NetWeaver ABAP 시스템의 SCOT 트랜잭션에 영향을 줍니다.

SCOT 구성에 대한 정보를 포함한 자세한 내용은 인스턴스에서 이메일 보내기를 참조하세요.

Google Cloud 기반 SAP 환경의 보안 리소스에 대한 자세한 내용은 다음을 참조하세요.

안정성

이 섹션에서는 Google Cloud에서 SAP S/4HANA를 실행하기 위한 안정성과 관련된 정보를 제공합니다.

고가용성 및 재해 복구

고가용성(HA) 및 재해 복구(DR)는 장애 발생 시 비즈니스 연속성을 유지하는 데 필요한 기술, 엔지니어링 방식, 설계 원칙의 집합입니다. 이러한 접근 방식은 단일 장애 지점을 제거하고 시스템이나 구성요소가 중단된 후 운영을 신속하게 재개하여 비즈니스 중단을 최소화하는 기능을 제공하는 방식으로 작동합니다. 오류 복구는 장애가 발생한 구성요소로 인해 서비스 중단이 발생한 경우 운영을 복구하고 재개하는 프로세스입니다.

예를 들어 사용 가능한 HA 및 DR 도구는 다음과 같습니다.

다음은 이러한 도구 중 몇 가지에 대한 추가 세부사항입니다.

  • 여러 영역에 Linux 클러스터링: 여러 영역에 Linux 클러스터를 설정하면 지정된 리전에서 발생하는 구성요소 오류로부터 보호할 수 있습니다.

    SAP NetWeaver 애플리케이션 레이어에서는 여러 영역에 Linux 클러스터를 배포하여 장애가 ASCS에 미치는 영향을 줄이고, 서로 다른 영역의 두 노드 간에 가용성을 높일 수 있습니다. 그러면 Linux 클러스터는 기본 노드에 문제가 있거나 유지보수가 수행되는 경우 ASCS를 대기 노드로 이동합니다. 또한 Enqueue Replication Server를 사용하여 프로세스가 기본 노드에서 대기 노드로 승격된 경우 Enqueue Server가 대기 노드에서 Enqueue 테이블 콘텐츠를 유지하도록 Enqueue 테이블의 콘텐츠를 복제할 수 있습니다.

    SAP HANA 데이터베이스 레이어에서는 활성/수동 구성이나 활성/활성 구성을 사용하여 여러 영역에 Linux 클러스터를 배포할 수 있습니다. 두 경우 모두 각각 자체 SAP HANA 데이터베이스가 있는 개별 영역에 Compute Engine 인스턴스 두 개 설정부터 시작합니다.

    • 활성/수동 구성: 한 인스턴스를 클러스터의 기본 노드(활성)로 구성하고 다른 인스턴스를 보조 노드(수동)로 구성합니다. SAP HANA System Replication(SR)을 사용하여 기본 노드가 실패하면 보조 노드가 기본 노드 역할을 넘겨받도록 구성합니다. HANA SR을 구성 및 설정하는 방법에 대한 자세한 내용은 HANA 시스템 복제를 참조하세요.
    • 활성/활성 구성(읽기 지원): 두 인스턴스를 모두 활성으로 구성하지만 보조 노드를 읽기 전용으로 구성합니다. 이 설정은 지속적인 로그 재생을 기반으로 합니다. 현재 읽기/쓰기 노드를 가리키는 가상 IP(VIP)가 구성됩니다. 자세한 내용은 활성/활성(읽기 지원)을 참조하세요.

    또한 SAP HANA 시스템 복제를 재해 복구 솔루션으로 사용할 수도 있습니다. 기본 데이터베이스는 기본 데이터베이스가 오프라인 상태가 되는 경우 사용할 수 있는 대기 데이터베이스에 콘텐츠를 복제하므로 기본 데이터베이스의 서비스가 복원될 때까지 SAP 시스템이 계속 작동할 수 있습니다. 이 경우 보조 노드 승격은 자동으로 수행되지 않으며 수동으로 수행해야 합니다. SAP HANA 측에서 HA와 DR을 모두 결합하여 복원력과 가용성을 높일 수도 있습니다. 자세한 내용은 다음을 참조하세요.

  • 라이브 마이그레이션: 소프트웨어 또는 하드웨어 업데이트와 같은 호스트 시스템 이벤트가 발생하더라도 VM 인스턴스가 계속 실행되도록 Compute Engine에서 라이브 마이그레이션이 제공됩니다. 이러한 상황에서 Compute Engine은 실행 중인 인스턴스를 재부팅하지 않고 동일한 영역의 다른 호스트로 라이브 마이그레이션을 수행합니다. 이 메커니즘은 원래 인스턴스의 VM 상태를 복제하므로, 새 인스턴스가 준비될 때 원래 인스턴스의 메모리가 사전 로드되어 있습니다.

    드물게 라이브 마이그레이션이 수행되지 않으면 오류가 발생한 가상 머신은 같은 영역에 있는 새 하드웨어에서 자동으로 다시 시작됩니다. 자세한 내용은 유지보수 이벤트 중 라이브 마이그레이션 프로세스를 참조하세요.

비용 최적화

이 섹션에서는 라이선스, 할인, 워크로드 크기 예측에 대한 정보를 제공합니다.

라이선스

SAP 고객은 기존 라이선스를 사용하여 Bring Your Own License(사용자 라이선스 사용, BYOL) 모델로 Google Cloud에 SAP S/4HANA를 배포할 수 있습니다. Google Cloud는 프로덕션 및 비프로덕션 사용 사례 모두에서 BYOL 모델을 지원합니다. 운영체제 라이선스는 Compute Engine 가격에 포함되어 있습니다.

또는 자체 OS 이미지 및 라이선스를 사용할 수 있습니다. 자세한 내용은 커스텀 OS 이미지를 참조하세요.

할인

Google Cloud의 사용한 만큼만 지불 가격 책정 모델을 사용하면 사용한 서비스에 대한 요금만 지불하면 됩니다. 특정 크기나 서비스를 사용할 필요가 없으며 필요에 따라 사용을 변경하거나 중지할 수 있습니다. 예측 가능한 워크로드를 위해 Compute Engine은 VM 사용 가격 책정을 대폭 할인하는 대신 계약을 체결하여 인프라 비용을 절감하는 데 도움이 되는 약정 사용 할인(CUD)을 제공합니다.

Google Cloud는 약정이라고도 하는 약정 사용 계약을 구매하는 대가로 이러한 할인을 제공합니다. 약정을 구매하면 최소 리소스 사용량 또는 1년 또는 3년의 지정된 기간 동안 최소 지출 금액을 약정합니다. 이러한 할인을 통해 SAP S/4HANA 시스템에서 사용하는 해당 리소스에 대한 월 청구액을 줄일 수 있습니다. 자세한 내용은 약정 사용 할인(CUD)을 참조하세요.

크기 추정

다음 리소스는 Google Cloud로 마이그레이션하기 전에 SAP 시스템에 대한 크기 추정을 수행하는 방법에 대한 정보를 제공합니다.

운영 효율성

이 섹션에서는 Google Cloud에서 SAP S/4HANA의 운영 효율성을 최적화하는 방법에 대한 정보를 제공합니다.

백업 및 복구

시스템 장애, 데이터 손상 또는 다른 문제 발생 시 복구할 수 있도록 애플리케이션 서버와 데이터베이스의 백업을 정기적으로 만듭니다.

백업

다음을 포함하여 Google Cloud에서 SAP HANA 데이터를 백업하는 다양한 옵션이 있습니다.

Cloud Storage에 백업

버전 3.0부터 SAP용 Google Cloud 에이전트는 Backint 기능을 지원하므로 SAP HANA가 Cloud Storage에서 직접 데이터베이스 백업을 백업하고 복구할 수 있습니다. 이 새로운 기능은 Compute Engine VM 인스턴스, 베어메탈 솔루션 서버, 온프레미스 서버 또는 기타 클라우드 플랫폼에서 실행되는 SAP HANA 인스턴스에 사용할 수 있으므로 백업에 영구 디스크 스토리지를 사용하지 않고도 Cloud Storage에 직접 백업하고 복구할 수 있습니다. 자세한 내용은 SAP HANA 운영 가이드를 참조하세요.

이 에이전트 기능의 SAP 인증에 대한 자세한 내용은 SAP 참고 2031547 - SAP 인증 타사 백업 도구 및 관련 지원 프로세스 개요를 참조하세요.

다음 다이어그램은 SAP용 Google Cloud 에이전트의 Backint 기능을 사용할 때의 백업 흐름을 보여줍니다.

SAP용 Google Cloud 에이전트를 사용하여 SAP HANA 데이터를 Cloud Storage에 백업하는 방법을 보여주는 다이어그램

디스크에 백업

Compute Engine Persistent Disk 볼륨과 함께 기본 SAP HANA 백업 및 복구 기능을 사용하고 백업의 장기 스토리지용으로 Cloud Storage 버킷을 사용할 수 있습니다.

정상적인 운영 시나리오에서 SAP HANA는 일정한 저장 간격으로 메모리에서 디스크로 데이터를 자동으로 저장합니다. 또한 모든 데이터 변경사항이 redo 로그 항목으로 캡처됩니다. redo 로그 항목은 각 데이터베이스 트랜잭션이 커밋된 후 디스크에 기록됩니다.

SAP HANA 2.0 이상에서는 SAP HANA Cockpit을 사용하여 SAP HANA 백업을 만듭니다.

다음 다이어그램은 SAP HANA용 백업 기능의 흐름을 보여줍니다.

SAP HANA 데이터를 영구 스토리지 디스크에 백업하는 방법을 보여주는 다이어그램

스냅샷을 사용하여 디스크 백업

백업 전략에 추가할 수 있는 또 다른 옵션은 Compute Engine의 디스크 스냅샷 기능을 사용하여 전체 디스크에 대한 스냅샷을 만드는 것입니다. 예를 들어 재해 복구 시나리오에 사용할 수 있도록 /hanabackup 디렉터리를 호스팅하는 디스크의 예약 스냅샷을 만들 수 있습니다. 디스크 스냅샷을 사용하여 SAP HANA 데이터 볼륨을 백업 및 복구할 수도 있습니다. 애플리케이션 일관성을 유지하기 위해 대상 볼륨에 변경사항이 없을 때 스냅샷을 만들어야 합니다. 스냅샷은 블록 수준에서 생성됩니다.

첫 번째 스냅샷 이후에 생성되는 스냅샷은 증분 스냅샷이며 다음 다이어그램과 같이 증분 블록 변경사항만 저장합니다.

SAP용 Google Cloud 에이전트 버전 3.0 이상을 사용하는 경우 에이전트의 디스크 스냅샷 기능을 사용하여 SAP HANA에 대해 백업을 만들고 복구를 수행할 수 있습니다. 자세한 내용은 SAP HANA용 디스크 스냅샷 기반 백업 및 복구를 참조하세요.

디스크 스냅샷을 사용하여 SAP HANA 데이터 백업을 보여주는 다이어그램

복구

SAP HANA의 복구 도구를 사용하면 최근 시점 또는 특정 시점으로 복구할 수 있으며, 이러한 도구를 사용하여 새로운 시스템으로 복원하거나 데이터베이스 복사본을 만들 수 있습니다. 데이터베이스가 작동하는 동안에 실행할 수 있는 백업과 달리 데이터베이스가 종료된 상태에서만 복구 도구를 사용할 수 있습니다. 다음 중에서 적절한 옵션을 선택할 수 있습니다.

  • 다음 리소스를 사용하여 가장 최신 상태로 복원합니다.
    • 전체 백업 또는 스냅샷
    • 로그 백업
    • 계속 사용할 수 있는 Redo 로그 항목
  • 과거 특정 시점으로 복원합니다.
  • 지정된 전체 백업으로 복원합니다.
모니터링

Google Cloud는 Compute Engine VM 인스턴스 및 베어메탈 솔루션 서버에서 실행되는 SAP 워크로드를 모니터링하고 지원하기 위해 SAP용 에이전트를 제공합니다.

SAP에서 규정한 대로 SAP의 지원을 받고 SAP에서 서비스수준계약(SLA)을 충족하도록 하려면 SAP 시스템이 있는 모든 Compute Engine VM 인스턴스와 베어메탈 솔루션 서버에 SAP용 Google Cloud 에이전트를 설치해야 합니다. 기본 요건 지원에 대한 자세한 내용은 SAP 참고 SAP Note 2456406 - SAP on Google Cloud Platform: 기본 요건 지원을 참조하세요.

따라서 Linux에서 SAP 호스트 에이전트 측정항목의 필수 수집 외에도 SAP용 Google Cloud 에이전트에는 프로세스 모니터링 측정항목, 워크로드 관리자 평가 측정항목, SAP HANA 모니터링 측정항목의 수집과 같은 선택적인 기능이 포함됩니다. SAP 워크로드에 워크로드 관리와 같은 제품 및 서비스를 사용 설정하는 이러한 기능을 선택할 수 있습니다.

성능 최적화

이 섹션에서는 크기 조정 및 네트워크 구성을 통해 SAP S/4HANA 워크로드 성능을 최적화하는 방법에 대한 정보를 제공합니다.

크기 조정

구현 유형을 기반으로 다양한 크기 조정 옵션을 사용할 수 있습니다. 새로운 개발 구현인 경우 SAP Quick Sizer 도구를 사용하는 것이 좋습니다. 자세한 내용은 SAP의 크기 조정 페이지를 참조하세요. SAP는 현재 온프레미스 솔루션을 Google Cloud로 마이그레이션하는 특정 솔루션과 도구에 대한 가이드도 제공합니다. 예를 들어 인증 및 지원되는 SAP HANA 하드웨어 디렉터리 및 SAP 참고 SAP Note 2456432 - Google Cloud 기반 SAP 애플리케이션: 지원되는 제품 및 Google Cloud 머신 유형을 참조하세요. SAP와 Google Cloud는 서로 다른 단위를 사용하여 IOPS(초당 입력/출력 작업 수)를 측정합니다. SAP 크기 조정 요구사항을 적절한 크기의 Google Cloud 인프라로 변환하려면 SI(시스템 통합업체) 파트너에게 문의하세요.

SAP ECC에서 S/4HANA로 기존 시스템을 마이그레이션하기 전에 SAP Note 1872170 - ABAP on HANA sizing report(S/4HANA, Suite on HANA...)에 설명된 대로 /SDF/HDB_SIZING 보고서를 실행하는 것이 좋습니다. 이 크기 조정 보고서는 소스 시스템의 현재 메모리와 처리 요구를 분석하고 S/4HANA로 이동하는 데 필요한 요구사항 정보를 제공합니다.

네트워크 구성

Compute Engine VM 네트워크 기능은 네트워크 인터페이스(NIC) 또는 IP 주소가 아닌 머신 계열에 따라 결정됩니다.

VM 인스턴스는 머신 유형에 따라 2~32Gbps 네트워크 처리량이 가능합니다. 또한 특정 머신 유형은 최대 100Gbps의 처리량을 지원하므로 Tier_1 네트워크 구성으로 Google Virtual NIC(gVNIC) 인터페이스 유형을 사용해야 합니다. 이러한 처리량 속도를 달성하는 기능은 트래픽 방향과 대상 IP 주소의 유형에 따라 달라집니다.

Compute Engine VM 네트워크 인터페이스는 물리적 및 소프트웨어 정의 네트워크 구성요소를 사용하는 중복되고 복원력이 우수한 네트워크 인프라를 통해 지원됩니다. 이러한 인터페이스는 기본 플랫폼의 중복성과 복원력을 상속합니다. 여러 가상 NIC를 트래픽 분리에 사용할 수 있지만 추가적인 복원력 또는 성능 이점은 제공하지 않습니다.

단일 NIC는 Compute Engine에서 SAP HANA 배포에 필요한 성능을 제공합니다. 특정 사용 사례, 보안 요구사항 또는 환경설정에는 인터넷 트래픽, 내부 SAP HANA 시스템 복제 트래픽, 특정 네트워크 정책 규칙의 이점을 얻을 수 있는 기타 흐름과 같이 트래픽 분리를 위한 추가 인터페이스가 필요할 수도 있습니다. 애플리케이션에서 제공하는 트래픽 암호화를 사용하고 최소 권한 방화벽 정책에 따라 네트워크 액세스를 보호하여 액세스를 제한하는 것이 좋습니다.

네트워크 설계의 일부로 초기에 트래픽을 분리해야 하는 필요성을 고려하고 VM을 배포할 때 추가 NIC를 할당합니다. 각 네트워크 인터페이스를 다른 VPC 네트워크에 연결해야 합니다. 네트워크 인터페이스 수는 필요한 격리 수준에 따라 선택할 수 있으며 vCPU가 8개 이상인 VM에 최대 8개의 인터페이스가 허용됩니다.

예를 들어 SAP NetWeaver 애플리케이션 서버 및 커스텀 애플리케이션과 같은 SAP HANA SQL 애플리케이션 클라이언트에 대해 VPC 네트워크를 정의하고 SAP HANA 시스템 복제 같은 서버 간 트래픽에 대해 별도의 VPC 네트워크를 정의할 수 있습니다. 세그먼트가 너무 많으면 네트워크 문제의 관리 및 해결이 복잡해질 수 있습니다. 나중에 마음이 바뀌면 Compute Engine 머신 이미지를 사용하여 연결된 모든 구성, 메타데이터, 데이터를 유지하면서 VM 인스턴스를 다시 만들 수 있습니다.

자세한 내용은 다음을 참고하세요.

배포

이 섹션에서는 Google Cloud 기반 SAP S/4HANA를 배포하는 것과 관련된 정보를 제공합니다.

중요한 배포 전 SAP Note

Google Cloud 기반 SAP S/4HANA 시스템을 배포하기 전에 다음 SAP Note를 읽어보세요. 또한 SAP 구현을 시작하기 전에 SAP Marketplace에서 업데이트된 제품 설치 가이드 및 참고 사항을 확인하세요.

배포 자동화

Google Cloud 기반 SAP S/4HANA를 설치하려면 다음 배포 옵션을 사용하면 됩니다.

  • 고가용성(HA) 배포로 분산된 배포의 경우 워크로드 관리자에서 가이드 배포 자동화 도구를 사용할 수 있습니다. 이 도구를 사용하면 Google Cloud 콘솔에서 지원되는 SAP 워크로드를 직접 구성 및 배포하고 동등한 Terraform 및 Ansible 코드를 생성 및 다운로드할 수 있습니다. 자세한 내용은 가이드 배포 자동화 정보를 참조하세요.
  • SAP HANA의 중앙 집중식 배포 또는 분산형 배포에 대해 Google Cloud에서 제공되는 Terraform 구성을 사용할 수 있습니다. 자세한 내용은 SAP HANA 시나리오의 배포 가이드를 참조하세요.

다음 단계