SAP HANA, S/4HANA 및 NetWeaver 기반 SAP 애플리케이션용 Red Hat HA Solutions
초록
보다 포괄적 수용을 위한 오픈 소스 용어 교체
Red Hat은 코드 및 문서에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 향후 릴리스를 통해 단계적으로 구현될 예정입니다. 언어를 더 포괄적으로 만드는 방법에 대한 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.
Red Hat 문서에 관한 피드백 제공
문서 개선을 위한 의견에 감사드립니다. 어떻게 개선할 수 있는지 알려주십시오.
특정 문구에 대한 의견 제출
- Multi-page HTML 형식으로 설명서를 보고 페이지가 완전히 로드된 후 오른쪽 상단 모서리에 피드백 버튼이 표시되는지 확인합니다.
- 커서를 사용하여 주석 처리할 텍스트 부분을 강조 표시합니다.
- 강조 표시된 텍스트 옆에 표시되는 피드백 추가 버튼을 클릭합니다.
- 의견을 추가하고 제출을 클릭합니다.
1장. 소개
SAP 프로덕션 애플리케이션을 실행하는 조직의 경우 고가용성 구성에 배포하여 미션 크리티컬 애플리케이션에 가장 높은 가동 시간을 보장하는 것이 중요합니다. Red Hat HA Solutions for SAP HANA, S/4HANA 및 NetWeaver 기반 SAP 애플리케이션을 통해 Red Hat은 업계 최고의 Red Hat Enterprise Linux 고가용성 클러스터 프레임워크를 기반으로 고가용성 SAP 환경을 설정하기 위한 솔루션을 제공합니다.
Red Hat Enterprise Linux 고가용성 애드온은 중요한 프로덕션 서비스에 대한 안정성, 확장성 및 가용성을 제공하는 pacemaker 기반 클러스터를 구성하는 데 필요한 모든 패키지를 제공합니다. 이 외에도 Red Hat HA Solutions for SAP HANA, S/4HANA 및 NetWeaver 기반 SAP 애플리케이션을 사용하면 고가용성 SAP HANA, S/4HANA 및 NetWeaver 기반 SAP 애플리케이션을 설정 및 구성할 수 있으므로 SAP 환경에서 계획 및 계획되지 않은 다운타임을 줄일 수 있습니다.
2장. SAP HANA를 위한 HA 솔루션
2.1. SAP HANA 시스템 복제 자동화
SAP HANA System Replication (HSR)은 비즈니스 연속성을 지원하는 고가용성 및 재해 복구 기능입니다. HANA 시스템 복제를 사용하면 SAP HANA 데이터베이스를 복사하여 하나 이상의 위치에 지속적으로 동기화할 수 있습니다. 데이터는 RTO (Recoverd recovery time objective)를 최소화하기 위해 보조 시스템에 지속적으로 사전 로드됩니다.
그러나 SAP HANA에는 HANA 시스템 복제 설정에 포함된 구성 요소에서 문제가 발생하는 경우 장애 조치(failover)를 자동으로 트리거하는 메커니즘이 포함되어 있지 않습니다. 그러나 타사 클러스터 솔루션을 사용하여 HANA System Replication 환경의 상태를 모니터링하고 장애가 발견되면 장애 조치를 트리거할 수 있습니다.
RHEL에서 Red Hat Enterprise Linux HA 애드온을 사용하여 장애 조치를 자동화할 수 있습니다. Red Hat은 단일 시스템 SAP HANA 설정(Scale-up) 또는 확장 가능한 다중 시스템 SAP HANA 설정(Scale-out) 모두에 대해 HA 솔루션을 제공합니다.
2.2. SAP HANA 스케일 업 시스템 복제 자동화에 지원되는 시나리오
| 지원되는 시나리오 | 참고 |
|---|---|
| 보조 사이트는 클라이언트/애플리케이션 서버에 대해 활성 상태가 아닙니다. | |
| 보조 사이트 (Cost-Optimized)에서 실행 중인 CloudEvent/test 인스턴스 지원; Prod의 장애 조치 중에 먼저 shutdown/Test 인스턴스가 종료됩니다. | |
| 보조 HANA 인스턴스는 읽기 전용 문의를 수행할 수 있습니다. | |
| 다중 계층 시스템 복제는 가능하지만 3차 사이트를 클러스터에서 관리할 수 없습니다. |
2.2.1. 지원 정책
2.2.2. performance>-<d
Performance> -<d 시나리오에서는 보조 HANA 데이터베이스가 테이블을 메모리로 사전 로드하도록 구성되어 있으므로 일반적으로 시간이 매우 빠릅니다. 그러나 보조 HANA 데이터베이스는 시스템 복제 전용이며 클라이언트 문의를 허용하지 않으므로 하드웨어 비용 측면에서 비용이 많이 듭니다.
2.2.2.1. 구성 가이드
- 온프레미스: RHEL HA 애드온을 사용하여 SAP HANA 스케일업 시스템 복제 자동화
- AWS: AWS(Amazon Web Services)에서 RHEL HA 애드온을 사용하여 SAP HANA 스케일 업 시스템 복제 구성
- Azure: Red Hat Enterprise Linux의 Azure VM에서 SAP HANA의 고가용성
- GCP(Google Cloud Platform): RHEL에서 SAP HANA를 위한 HA 클러스터 구성 가이드
- IBM Power System Virtual Server: RHEL HA 애드온 클러스터에서 SAP HANA 스케일 업 시스템 복제 구성
2.2.3. Cost>-<d
Cost> -<d 시나리오는 보조 사이트에서 추가 TEST/QA HANA 데이터베이스를 지원하여 클라이언트 문의를 제공합니다. 하드웨어 리소스를 TEST/QA 인스턴스에 할당해야 하므로 Production HANA 데이터베이스를 사전 로드할 수 없습니다. 가져오기 전에 TEST/QA 인스턴스를 종료하여 할당된 하드웨어 리소스를 해제하고 기본 인스턴스가 되도록 승격될 보조 HANA 인스턴스에 다시 할당해야 합니다. 따라서 사용 시간이 Performance>-<d 설정보다 길습니다.
2.2.3.1. 구성 가이드
- 온프레미스: RHEL HA 애드온을 사용하여 비용 최적화 SAP HANA 스케일업 시스템 복제 자동화
- IBM Power System Virtual Server: RHEL HA 애드온 클러스터에서 SAP HANA 비용 최적화 스케일-업 시스템 복제 구성
2.2.4. Active/Active(Read Enabled)
보조 HANA 인스턴스는 읽기 전용 쿼리를 사용할 수 있습니다. 이 설정은 보조 사이트에서 두 번째 가상 IP를 지원합니다.
자세한 내용은 Active/Active(Read-Enabled) HANA 시스템 복제 설정을 위한 보조 가상 IP 주소 추가 를 참조하십시오.
2.2.5. 다중 계층 시스템 복제
다중 계층 시스템 복제는 가능하지만 3차 사이트를 클러스터에서 관리할 수 없습니다.
3차 사이트에 대한 인수는 수동으로 트리거되어야 하며, 3차 사이트로 이동한 후 환경을 이전 상태로 되돌려야 하는 경우 클러스터가 비활성화된 동안 HANA 시스템 복제 설정을 재구성하는 모든 단계를 수동으로 수행해야 합니다. 클러스터가 관리해야 하는 HANA 인스턴스에서 HANA 시스템 복제 설정이 다시 제대로 작동하는지 확인한 후 클러스터를 다시 활성화할 수 있습니다.
2.2.5.1. 구성 가이드
- IBM Power System Virtual Server: RHEL HA 애드온 클러스터에서 SAP HANA 다중 계층 시스템 복제 구성
2.3. SAP HANA 스케일 아웃 시스템 복제 자동화에 지원되는 시나리오
| 지원되는 시나리오 | 설명 |
|---|---|
| 보조 사이트는 클라이언트/애플리케이션 서버에 활성 상태가 아닙니다. | |
| 보조 HANA 인스턴스는 읽기 전용 문의를 수행할 수 있습니다. | |
| 기본 HANA 인스턴스가 여러 보조 HANA 인스턴스에 복제됨 |
2.3.1. 지원 정책
2.3.2. Performance GovCloudd HANA Scale-Out System Replication HA 설정에 대한 구성 가이드
2.3.3. Active/Active (Read Enabled) HANA 스케일 아웃 시스템 복제
HANA 2.0에서 보조 인스턴스는 읽기 전용 문의를 수행할 수 있습니다. 이 설정은 보조 사이트에서 두 번째 가상 IP를 지원합니다. 자세한 내용은 Red Hat Enterprise Linux HA Solution for SAP HANA Scale Out 및 System Replication 에서 "Adding a secondary virtual IP address resource for Active/Active (Read-Enabled) setup"을 참조하십시오.
자세한 내용은 Active/Active(Read-Enabled) 를 참조하십시오.
2.3.4. 다중 대상 시스템 복제(Scale-Out)
클러스터 환경에서 HANA 2.0 SPS 04 Multi Target Replication이 지원됩니다. 기본 사이트는 보조 사이트로 복제되며 추가 가용성 요구 사항을 충족하기 위해 추가 보조 사이트로 복제됩니다. 실패의 관점에서 이 추가 세 번째 사이트는 이전 보조 사이트인 새로운 기본 사이트에 자동으로 등록됩니다.
자세한 내용은 다음을 참조하십시오.
3장. ABAP 플랫폼 1809 이상을 기반으로 하는 S/4HANA 용 HA 솔루션
3.1. 독립 실행형 Enqueue Server 2 (ENSA2)
독립 실행형 Enqueue Server Application Server의 구성 요소인 Application Server ABAP는 잠금 테이블의 고가용성과 해당 항목을 보장하는 메커니즘입니다.
독립 실행형 Enqueue Server는 NetWeaver 7.51 이후 2 세대로 발전했으며 Standalone Enqueue Server 2 또는 ENSA2로 알려져 있습니다. ENSA2에서는 ASCS가 실패하면 클러스터의 별도의 노드에서 시작하고 enqueue 복제기 2에서 잠금 항목을 복사할 수 있습니다.
ABAP 플랫폼 1809 이상에서는 Standalone Enqueue Server 2(ENSA2)가 기본 설치가 되었습니다.
3.2. 지원되는 시나리오
| 지원되는 시나리오 | 설명 |
|---|---|
| 멀티 노드 클러스터 | ENSA2 ASCS에서 "follow" ERS가 필요하지 않기 때문에 다중 노드 클러스터를 가능하게 합니다. |
| 2-node 클러스터 | 업그레이드된 2-노드 클러스터는 ENSA1에서 ENSA2로 전환하도록 설정을 쉽게 조정할 수 있습니다. |
새로운 설치로 인해 멀티 노드 클러스터 또는 2 노드 클러스터 중 하나를 선택하여 아키텍처를 설계할 수 있습니다. 다음은 일반적인 3-노드 클러스터의 아키텍처 다이어그램입니다. 물론 고객의 데이터 센터 요구 사항 또는 필요에 따라 더 많은 노드를 추가할 수 있습니다.
3.3. 지원 정책
3.4. 구성 가이드
- 온프레미스: Pacemaker에서 독립 실행형 Enqueue Server 2(ENSA2)를 사용하여 SAP S/4HANA ASCS/ERS 구성
- AWS: AWS(Amazon Web Services)에서 SAP S/4HANA ASCS/ERS ENSA2 구성
- GlusterFS가 있는 Azure: GlusterFS를 사용하는 Red Hat Enterprise Linux에서 SAP NetWeaver의 Azure Virtual Machines 고가용성
- NetApp: Azure Virtual Machines의 SAP NetWeaver on Red Hat Enterprise Linux with Azure NetApp Files for SAP applications
- Azure with NFS: Azure Files의 NFS가 있는 Red Hat Enterprise Linux의 Azure VM에서 SAP NetWeaver의 고가용성
- GCP: RHEL에서 SAP NetWeaver용 HA 클러스터 구성 가이드
- IBM Power System Virtual Server: RHEL HA 애드온 클러스터에서 SAP S/4HANA (ASCS 및 ERS)의 고가용성 구성
3.5. 비용 최적화 SAP S/4HANA HA 설정 (HANA System Replication 및 ENSA2 결합)
S/4HANA의 현재 버전에서는 동일한 시스템에서 HANA 및 ABAP Application Server 인스턴스를 실행할 수도 있습니다. 이를 통해 HANA System Replication 및 ENSA2를 모두 동일한 클러스터 노드에서 실행되는 단일 클러스터에서 관리하는 "비용 조정" S/4HANA를 설정할 수 있습니다.
자세한 내용은 RHEL HA 애드온을 사용하여 Cost-Optimized SAP S/4HANA HA 클러스터(HANA System Replication + ENSA2) 구성을 참조하십시오.
4장. ABAP 플랫폼 1709 이상을 기반으로 NetWeaver 또는 S/4 용 HA 솔루션
4.1. 독립 실행형 Enqueue Server 1 (ENSA1)
기존의 ENSA1(Standalone Enqueue Server)을 사용하는 경우 ASCS 인스턴스는 활성 ERS 인스턴스가 실행 중인 클러스터 노드를 장애 조치해야 하며 ERS 인스턴스가 종료되고 온라인 상태가 실행될 때 ASCS 인스턴스가 실행 중인 노드로 이동해야 합니다. 이는 ASCS 인스턴스가 ERS 인스턴스에서 Enqueue 잠금 테이블의 복사본을 유지 관리하여 활성 트랜잭션의 인 큐 잠금을 계속 추적할 수 있는 공유 메모리에 액세스해야 하기 때문입니다. ENSA1은 Pacemaker에서 2-노드 클러스터 구성으로 지원됩니다. 주로 ASCS 인스턴스가 ERS 인스턴스를 "follow"해야 한다는 제한 때문입니다.
4.2. 지원되는 시나리오
| 지원되는 시나리오 | 설명 |
|---|---|
| 노드 클러스터 두 개 | ENSA1의 경우 ASCS 인스턴스는 항상 ERS 인스턴스가 실행 중인 노드로 이동해야 합니다. |
| ABAP/Java Dual-Stack | 모든 RHEL 7.x 릴리스의 Master/Slave Resources 지원 |
4.2.1. ABAP/Java Dual-Stack
ABAP/JAVA Dual-Stack은 Master/Slave 방법론을 사용하여 지원됩니다. 이는 모든 RHEL 7.x 마이너 릴리스에서 지원됩니다. 설정 가이드를 따르십시오: Configure (A)SCS/ERS SAPInstance cluster resource.
그러나 SAP는 더 이상 ABAP 및 JAVA 인스턴스가 동일한 gRPC를 공유하는 이중 스택 설정을 권장하지 않으므로 Dual-Stack Split 을 수행하는 것이 좋습니다. 따라서 ABAP 및 JAVA 스택에서 별도의 gRPCs를 사용합니다. 이러한 설정을 통해 독립 실행형 접근 방식을 사용하여 ABAP 스택에 대한 ASCS/ERS 인스턴스 및 JAVA 스택에 대한 SCS/ERS 인스턴스를 관리할 수 있습니다. 각 인스턴스에 대해 별도의 리소스 그룹을 구성하고 환경의 각 부분에 대해 별도의 gRPC를 기반으로 적절한 제약 조건을 설정해야 합니다. 구성 가이드를 참조하십시오. RHEL 7.5 이상 및 RHEL 8에서 독립 실행형 리소스로 SAP NetWeaver ASCS/ERS ENSA1 구성.
4.3. 지원 정책
RHEL 고가용성 클러스터에 대한 지원 정책 - 클러스터에서 SAP NetWeaver 관리에서 참조하십시오.
4.4. 구성 가이드
- 온프레미스: RHEL 7.5+ 및 RHEL 8에서 독립 실행형 리소스로 SAP NetWeaver ASCS/ERS ENSA1 구성
- AWS: AWS(Amazon Web Services)에서 SAP NetWeaver ASCS/ERS ENSA1 구성
- Azure: GlusterFS를 사용하는 Red Hat Enterprise Linux에서 SAP NetWeaver용 Azure Virtual Machines 고가용성
- Azure: SAP 애플리케이션용 Azure NetApp Files를 사용하여 Red Hat Enterprise Linux에서 SAP NetWeaver의 SAP Virtual Machines 고가용성
- Azure: Azure 파일에서 NFS가 포함된 Red Hat Enterprise Linux의 Azure VM에서 SAP NetWeaver의 고가용성
- GCP: RHEL에서 SAP NetWeaver용 HA 클러스터 구성 가이드