이 예제에서 ASCS 및 ERS 리소스를 관리하는 데 SAPInstance 리소스 에이전트가 사용됩니다. SAPInstance 리소스 에이전트의 모든 작업은 SAP 시작 서비스 프레임워크 sapstartsrv 를 사용하여 수행됩니다.

이 리소스 에이전트는 각 클러스터 노드에서 SAP HANA System Replication의 상태 및 구성을 수집하고 있습니다. SAPHana 리소스 에이전트가 제대로 작동하려면 클러스터 노드 속성에 이 에이전트의 데이터가 있어야 합니다.

이 리소스는 SAP HANA 데이터베이스의 시작, 중지 및 재배치(failover)를 담당합니다. 이 리소스 에이전트는 SAPHanaTopology에서 수집한 정보를 가져와 작업을 수행하기 위해 SAP HANA 데이터베이스와 상호 작용하고 있음을 기반으로 합니다. 또한 클러스터 노드의 SAP HANA 상태에 대한 클러스터 노드 속성에 추가 정보를 추가합니다.

Filesystem용 Pacemaker 클러스터 resource-agent. NFS 또는 iSCSI 등에 의해 내보낸 공유 스토리지 매체에서 파일 시스템을 관리합니다.

가상 IPv4 및 IPv6 주소 및 별칭을 관리합니다.

각 노드의 클러스터에서 마운트할 수 있는 ASCS 및 ERS 인스턴스에 대해 별도의 SAN LUN 또는 NFS 내보내기가 있어야 합니다.

예를 들어 아래와 같이 'ASCS' 및 'ERS' 인스턴스가 각각 해당 노드에 인스턴스별 디렉터리가 있어야 합니다.

참고: 애플리케이션 서버의 경우 Application Server 인스턴스가 실행되는 노드에서 다음 디렉토리를 사용할 수 있어야 합니다.

인스턴스 디렉터리에 SAN LUN을 사용하는 경우 고객은 HA-LVM 을 사용하여 인스턴스 디렉토리를 한 번에 하나의 노드에만 마운트할 수 있어야 합니다.

NFS 내보내기를 사용하는 경우 디렉터리가 Azure NetApp Files 또는 Amazon EFS와 같은 NFS 파일 서버의 동일한 디렉터리 트리에 생성되는 경우 Filesystem 리소스를 구성할 때 force_unmount=safe 옵션을 사용해야 합니다. 이 옵션을 사용하면 내보내기가 생성되는 디렉터리 트리에서 실행 중인 모든 프로세스를 중지하지 않고 클러스터가 특정 NFS 내보내기에서 실행되는 프로세스만 중지하도록 합니다.

다음 마운트 지점은 ASCS, ERS, HANA 및 Application Servers 노드에서 사용할 수 있어야 합니다.

/sapmnt
/usr/sap/trans
/usr/sap/SID/SYS

공유 스토리지는 다음을 통해 수행할 수 있습니다.

이러한 마운트 지점은 클러스터를 시작하기 전에 클러스터에서 관리하거나 마운트해야 합니다.

다음 파일 시스템은 s4node1에 마운트되어야 합니다. 여기서 ASCS가 설치됩니다.

/usr/sap/S4H/ASCS20
/usr/sap/S4H/SYS
/usr/sap/trans
/sapmnt

s4ascs 의 가상 IP는 s4node1에서 활성화되어야 합니다.

설치 프로그램을 실행합니다.

[root@s4node1]# ./sapinst SAPINST_USE_HOSTNAME=s4ascs

High-Availability System 을 선택합니다.

다음 파일 시스템을 s4node2에 마운트해야 합니다. 여기서 ERS가 설치됩니다.

/usr/sap/S4H/ERS29 /usr/sap/S4H/SYS /usr/sap/trans /sapmnt

s4node2에서 s4ers 의 가상 IP를 활성화해야 합니다.

설치 프로그램을 실행합니다.

[root@s4node2]# ./sapinst SAPINST_USE_HOSTNAME=s4ers

High-Availability System 을 선택합니다.

이 예제에서는 다음 구성에 SAP HANA를 사용할 것입니다. 지원 정책에 따라 다른 지원되는 데이터베이스를 사용할 수도 있습니다.

SAP HANA SID: S4D
SAP HANA Instance number: 00

이 예에서 SAP HANA Database 서버는 hdblcm 명령줄 도구를 사용하여 두 노드에 설치할 수 있으며 Automated HANA System Replication은 Pacemaker 클러스터의 SAP HANA 시스템 복제 문서에 언급된 것과 동일한 방식으로 설정됩니다.
이 설정에서 ASCS 및 HANA 기본 인스턴스는 서로 독립적으로 장애 조치할 수 있으므로 ASCS와 기본 SAP HANA 인스턴스가 동일한 노드에서 실행되기 시작하는 상황이 발생합니다. 따라서 다른 노드의 오류가 발생할 경우 노드 모두에 ASCS/ERS 및 기본 SAP HANA 인스턴스에 사용할 수 있는 충분한 리소스 및 여유 메모리가 있는지 확인하는 것도 중요합니다.

이를 위해 SAP HANA 인스턴스는 특정 메모리 제한/제한으로 설정할 수 있으며 SAP HANA 환경에 따라 사용 가능한 옵션을 탐색하기 위해 SAP에 도달하는 것이 좋습니다. 일부 관련 링크는 다음과 같습니다.

ERS 인스턴스에서는 클러스터에서 관리되므로 enqueue 서버를 자동으로 재시작하지 못하도록 해당 프로필을 다음과 같이 수정해야 합니다. 변경 사항을 적용하려면 ERS 프로필 /sapmnt/S4H/profile/S4H_ERS29_s4ers 에서 다음 명령을 실행합니다.

[root]# sed -i -e 's/Restart_Program_00/Start_Program_00/'
/sapmnt/S4H/profile/S4H_ERS29_s4ers+

s4node1 및 s4node2 모두에서 /usr/sap/sapservices 파일에 다음 두 행이 주석 처리되었는지 확인합니다.

#LD_LIBRARY_PATH=/usr/sap/S4H/ERS29/exe:$LD_LIBRARY_PATH; export
LD_LIBRARY_PATH; /usr/sap/S4H/ERS29/exe/sapstartsrv
pf=/usr/sap/S4H/SYS/profile/S4H_ERS29_s4ers -D -u s4hadm
#LD_LIBRARY_PATH=/usr/sap/S4H/ASCS20/exe:$LD_LIBRARY_PATH; export
LD_LIBRARY_PATH; /usr/sap/S4H/ASCS20/exe/sapstartsrv
pf=/usr/sap/S4H/SYS/profile/S4H_ASCS20_s4ascs -D -u s4hadm

[root@s4node1 ~]# mkdir /usr/sap/S4H/ERS29/
[root@s4node1 ~]# chown s4hadm:sapsys /usr/sap/S4H/ERS29/

[root@s4node2 ~]# mkdir /usr/sap/S4H/ASCS20
[root@s4node2 ~]# chown s4hadm:sapsys /usr/sap/S4H/ASCS20

ASCS 및 ERS 인스턴스를 중지합니다. 인스턴스별 디렉터리를 다른 노드로 이동합니다.

[root@s4node1 ~]# umount /usr/sap/S4H/ASCS20
[root@s4node2 ~]# mount /usr/sap/S4H/ASCS20

[root@s4node2 ~]# umount /usr/sap/S4H/ERS29/
[root@s4node1 ~]# mount /usr/sap/S4H/ERS29/

다른 클러스터 노드에서 ASCS 및 ERS 인스턴스를 수동으로 시작한 다음 각각 수동으로 중지합니다.

모든 노드에서 SAP HostAgent가 동일한 버전이 있고 최소 버전 요구 사항을 충족하는지 확인합니다.

[root]# /usr/sap/hostctrl/exe/saphostexec -version

SAP HostAgent를 업그레이드/설치하려면 다음을 수행합니다. SAP OSS Note 1031096 을 따르십시오.

고가용성 시나리오에서 SAP 하드웨어의 주요 결정이 향상되었습니다. 각 클러스터 노드의 하드웨어 키를 기반으로 여러 SAP 라이센스 키를 설치해야 할 수 있습니다. 자세한 내용은 SAP OSS Note 11786 - Linux: 대체 방법에서 SAP 하드웨어 키를 생성합니다.

복제된 Filesystem 클러스터 리소스는 다음과 같이 모든 클러스터 노드의 외부 NFS 서버의 공유를 마운트하는 데 사용할 수 있습니다.

[root]# pcs resource create s4h_fs_sapmnt Filesystem \
device='<NFS_Server>:<sapmnt_nfs_share>' directory='/sapmnt' \
fstype='nfs' --clone interleave=true
[root]# pcs resource create s4h_fs_sap_trans Filesystem \
device='<NFS_Server>:<sap_trans_nfs_share>' directory='/usr/sap/trans' \
fstype='nfs' --clone interleave=true
[root]# pcs resource create s4h_fs_sap_sys Filesystem \
device='<NFS_Server>:<s4h_sys_nfs_share>' directory='/usr/sap/S4H/SYS' \
fstype='nfs' --clone interleave=true

Filesystem 리소스를 생성한 후 모든 노드에서 올바르게 시작되었는지 확인합니다.

[root]# pcs status
...
Clone Set: s4h_fs_sapmnt-clone [s4h_fs_sapmnt]
Started: [ s4node1 s4node2 ]
Clone Set: s4h_fs_sap_trans-clone [s4h_fs_sap_trans]
Started: [ s4node1 s4node2 ]
Clone Set: s4h_fs_sys-clone [s4h_fs_sys]
Started: [ s4node1 s4node2 ]
...

공유 파일 시스템을 클러스터에서 관리하지 않는 경우 pacemaker 서비스를 시작하기 전에 사용 가능한지 확인해야 합니다.
RHEL 7의 병렬화로 인해 공유 파일 시스템이 resource-agents-deps 대상에서 시작되었는지 확인해야 합니다. 이에 대한 자세한 내용은 문서 섹션 9.6에서 참조하십시오. Pacemaker에서 관리되지 않는 리소스 종속 항목 구성(Red Hat Enterprise Linux 7.4 이상).

다음은 NFS 파일 시스템용 리소스를 생성하는 예입니다.

[root]# pcs resource create s4h_fs_ascs20 Filesystem \
device='<NFS_Server>:<s4h_ascs20_nfs_share>' \
directory=/usr/sap/S4H/ASCS20 fstype=nfs force_unmount=safe \
--group s4h_ASCS20_group op start interval=0 timeout=60 \
op stop interval=0 timeout=120 \
op monitor interval=200 timeout=40

다음은 HA-LVM 파일 시스템에 대한 리소스를 생성하는 예입니다.

[root]# pcs resource create s4h_fs_ascs20_lvm LVM \
volgrpname='<ascs_volume_group>' exclusive=true \
--group s4h_ASCS20_group

[root]# pcs resource create s4h_fs_ascs20 Filesystem \
device='/dev/mapper/<ascs_logical_volume>' \
directory=/usr/sap/S4H/ASCS20 fstype=ext4 \
--group s4h_ASCS20_group

[root]# pcs resource create s4h_ascs20 SAPInstance \
InstanceName="S4H_ASCS20_s4ascs" \
START_PROFILE=/sapmnt/S4H/profile/S4H_ASCS20_s4ascs \
AUTOMATIC_RECOVER=false \
meta resource-stickiness=5000 \
--group s4h_ASCS20_group \
op monitor interval=20 on-fail=restart timeout=60 \
op start interval=0 timeout=600 \
op stop interval=0 timeout=600

참고:meta resource-stickiness=5000 은 ERS와 장애 조치(failover) 제약 조건의 균형을 조정하기 위해 여기에 있으므로 리소스가 시작된 노드에 남아 있고 클러스터 전체의 제어되지 않습니다.
가능한 경우 ASCS가 노드에 남아 있도록 그룹에 리소스 고정을 추가합니다.

[root]# pcs resource meta s4h_ASCS20_group resource-stickiness=3000

다음은 NFS 파일 시스템용 리소스를 생성하는 예입니다.

[root]# pcs resource create s4h_fs_ers29 Filesystem \
device='<NFS_Server>:<s4h_ers29_nfs_share>' \
directory=/usr/sap/S4H/ERS29 fstype=nfs force_unmount=safe \
--group s4h_ERS29_group op start interval=0 timeout=60 \
op stop interval=0 timeout=120 op monitor interval=200 timeout=40

다음은 HA-LVM 파일 시스템에 대한 리소스를 생성하는 예입니다.

[root]# pcs resource create s4h_fs_ers29_lvm LVM \
volgrpname='<ers_volume_group>' exclusive=true --group s4h_ERS29_group

[root]# pcs resource create s4h_fs_ers29 Filesystem \
device='/dev/mapper/<ers_logical_volume>' directory=/usr/sap/S4H/ERS29 \
fstype=ext4 --group s4h_ERS29_group

ERS 인스턴스 클러스터 리소스를 생성합니다.
참고: ENSA2 배포에서는 IS_ERS 속성이 선택 사항입니다. IS_ERS 에 대한 자세한 내용은 How does the IS_ERS attribute work on a SAP NetWeaver cluster with Standalone Enqueue Server (ENSA1 및 ENSA2) 에서 확인할 수 있습니다.

[root]# pcs resource create s4h_ers29 SAPInstance \
InstanceName="S4H_ERS29_s4ers" \
START_PROFILE=/sapmnt/S4H/profile/S4H_ERS29_s4ers \
AUTOMATIC_RECOVER=false \
--group s4h_ERS29_group \
op monitor interval=20 on-fail=restart timeout=60 \
op start interval=0 timeout=600 \
op stop interval=0 timeout=600

ASCS20 인스턴스 rh2_ascs20 은 장애 조치 전에 ERS가 실행되고 있는 노드에서 실행을 선호합니다.

# pcs constraint location rh2_ascs20 rule score=2000 runs_ers_RH2 eq 1

s4h_ERS29_group전에 s4h_ASCS20_group 을 시작하는 것이 좋습니다.

[root]# pcs constraint order start s4h_ASCS20_group then start \
s4h_ERS29_group symmetrical=false kind=Optional
[root]# pcs constraint order start s4h_ASCS20_group then stop \
s4h_ERS29_group symmetrical=false kind=Optional

공유 파일 시스템 /sapmnt 가 클러스터에서 관리하는 경우 다음 제약 조건에서는 파일 시스템을 사용할 수 있는 후에만 ASCS 및 ERS SAPInstance 리소스가 있는 리소스 그룹을 시작합니다.

[root]# pcs constraint order s4h_fs_sapmnt-clone then s4h_ASCS20_group
[root]# pcs constraint order s4h_fs_sapmnt-clone then s4h_ERS29_group