IBM Cloud Docs
Red Hat Enterprise Linux 고가용성 애드온 클러스터에서 SAP HANA 스케일업 시스템 복제 구성하기

Red Hat Enterprise Linux 고가용성 애드온 클러스터에서 SAP HANA 스케일업 시스템 복제 구성하기

다음 정보는 SAP HANA 스케일업 시스템 복제를 관리하기 위한 Red Hat Enterprise Linux (RHEL) 고가용성 애드온 클러스터의 구성에 대해 설명합니다. 클러스터는 가상 서버 인스턴스를 IBM® Power® Virtual Server 의 가상 서버 인스턴스를 클러스터 노드로 사용합니다.

이 지침은 RHEL HA 애드온 클러스터의 성능 최적화 시나리오에서 단일 데이터베이스 배포를 위해 SAP HANA 스케일업 시스템 복제를 자동화하는 방법을 설명합니다.

이 정보는 Power Virtual Server 에서 SAP HANA 의 고가용성 배포를 계획 중인 아키텍트 및 전문가를 위한 것입니다.

시작하기 전에

SAP 애플리케이션을 위한 고가용성 구현하기(IBM Power Virtual Server 참조)에 나와 있는 일반 요구 사항, 제품 설명서, 지원 문서 및 SAP 참고 사항을 검토하세요.

전제조건

  • Red Hat 고가용성 클러스터는 Power Virtual Server 의 가상 서버 인스턴스 두 개에 배포됩니다.
  • 가상 서버 인스턴스는 범위 내의 SAP HANA 시스템에 대한 하드웨어 및 리소스 요구 사항을 충족해야 합니다. 배포 계획 수립 문서의 가이드라인을 따르세요.
  • 가상 서버 인스턴스의 호스트 이름은 SAP HANA 요구 사항을 충족해야 합니다.
  • SAP HANA 가 두 가상 서버 인스턴스 모두에 설치되어 있고 SAP HANA 시스템 복제가 구성되어 있습니다. SAP HANA 설치 및 HANA 시스템 복제 설정은 Power Virtual Server 환경에만 적용되는 것이 아니므로 표준 절차를 따라야 합니다.
  • SAP HANA 및 HA 구성을 위한 리소스 에이전트를 설치하는 데 필요한 리포지토리를 사용하려면 유효한 RHEL for SAP 애플리케이션 또는 RHEL for SAP 솔루션 구독이 필요합니다.

IBM 에서 RHEL HA 애드온 클러스터에서 SAP HANA 시스템 복제 구성하기 Power Virtual Server

이 지침은 Red Hat 제품 설명서 및 IBM Power Virtual Server 참고 자료의 SAP 애플리케이션을 위한 고가용성 구현에 나와 있는 문서를 기반으로 합니다.

환경 변수 준비

설정을 단순화하려면 두 노드 모두에서 루트에 대해 다음 환경 변수를 준비하세요. 이러한 환경 변수는 이 정보에서 이후 운영 체제 명령과 함께 사용됩니다.

두 노드에서 다음 환경 변수를 설정합니다.

# General settings
export SID=<SID>            # SAP HANA System ID (uppercase)
export sid=<sid>            # SAP HANA System ID (lowercase)
export INSTNO=<INSTNO>      # SAP HANA instance number

# Cluster node 1
export NODE1=<HOSTNAME_1>   # Virtual server instance hostname
export DC1="Site1"          # HANA System Replication site name

# Cluster node 2
export NODE2=<HOSTNAME_2>   # Virtual server instance hostname
export DC2="Site2"          # HANA System Replication site name

# Single zone
export VIP=<IP address>     # SAP HANA System Replication cluster virtual IP address

# Multizone region
export CLOUD_REGION=<CLOUD_REGION>       # Multizone region name
export APIKEY="APIKEY or path to file"   # API Key of the IBM Cloud IAM ServiceID for the resource agent
export API_TYPE="private or public"      # Use private or public API endpoints
export IBMCLOUD_CRN_1=<IBMCLOUD_CRN_1>   # Workspace 1 CRN
export IBMCLOUD_CRN_2=<IBMCLOUD_CRN_2>   # Workspace 2 CRN
export POWERVSI_1=<POWERVSI_1>           # Virtual server instance 1 id
export POWERVSI_2=<POWERVSI_2>           # Virtual server instance 2 id
export SUBNET_NAME="vip-${sid}-net"      # Name which is used to define the subnet in IBM Cloud
export CIDR="CIDR of subnet"             # CIDR of the subnet containing the service IP address
export VIP="Service IP address"          # IP address in the subnet
export JUMBO="true or false"             # Enable Jumbo frames

단일 영역 구현을 위한 추가 환경 변수 설정하기

가상 IP 주소 예약하기의 정보를 검토하고 SAP HANA 시스템 복제 클러스터를 위한 가상 IP 주소를 예약합니다. VIP 환경 변수를 예약된 IP 주소로 설정합니다.

멀티존 지역 구현을 위한 추가 환경 변수 설정하기

고가용성 클러스터 구성을 위한 매개변수 수집 섹션에 설명된 대로 CLOUD_REGION, APIKEY, IBMCLOUD_CRN_?, POWERVSI_? 변수를 설정합니다. API_TYPE 변수를 private 로 설정하여 비공개 엔드포인트를 통해 IBM Cloud IAM 및 IBM Power Cloud API와 통신합니다.

SUBNET_NAME 변수에는 서브넷의 이름이 포함됩니다. CIDR 변수는 서브넷에 대한 클래스 없는 도메인 간 라우팅(CIDR) 표기법을 <IPv4_address>/number 형식으로 나타냅니다. VIP 변수는 가상 IP 주소 리소스의 IP 주소이며 서브넷의 CIDR 에 속해야 합니다. MTU 크기가 큰 서브넷을 사용하려면 JUMBO 변수를 true 으로 설정하세요.

다음은 다중 영역 지역 구현에 필요한 추가 환경 변수를 설정하는 방법의 예입니다.

export CLOUD_REGION="eu-de"
export IBMCLOUD_CRN_1="crn:v1:bluemix:public:power-iaas:eu-de-2:a/a1b2c3d4e5f60123456789a1b2c3d4e5:a1b2c3d4-0123-4567-89ab-a1b2c3d4e5f6::"
export IBMCLOUD_CRN_2="crn:v1:bluemix:public:power-iaas:eu-de-1:a/a1b2c3d4e5f60123456789a1b2c3d4e5:e5f6a1b2-cdef-0123-4567-a1b2c3d4e5f6::"
export POWERVSI_1="a1b2c3d4-0123-890a-f012-0123456789ab"
export POWERVSI_2="e5f6a1b2-4567-bcde-3456-cdef01234567"
export APIKEY="@/root/.apikey.json"
export API_TYPE="private"
export SUBNET_NAME="vip-mha-net"
export CIDR="10.40.11.100/30"
export VIP="10.40.11.102"
export JUMBO="true"

SAP HANA 리소스 에이전트 설치

다음 명령을 실행하여 SAP HANA 시스템 복제를 위한 RHEL HA 애드온 리소스 에이전트를 설치합니다.

dnf install -y resource-agents-sap-hana

SAP HANA 시스템 시작하기

SAP HANA 을 시작하고 HANA 시스템 복제가 활성화되어 있는지 확인합니다. 자세한 내용은 2.4 을 참조하세요. SAP HANA 시스템 복제 상태 확인.

두 노드에서 다음 명령을 실행합니다.

sudo -i -u ${sid}adm -- HDB start

sudo -i -u ${sid}adm -- <<EOT
    hdbnsutil -sr_state
    HDBSettings.sh systemReplicationStatus.py
EOT

SAP HANA srConnectionChanged( ) 후크 활성화

SAP HANA 의 최신 버전은 SAP HANA 에서 특정 이벤트에 대한 알림을 보낼 수 있도록 후크를 제공합니다. 자세한 내용은 HA/DR 공급자 구현하기를 참조하세요.

srConnectionChanged( ) 훅은 클러스터에서 조치가 필요한 HANA 시스템 복제의 상태 변경을 감지하는 클러스터의 기능을 개선합니다. 목표는 우발적인 탈취를 방지하여 데이터 손실과 손상을 방지하는 것입니다.

모든 SAP HANA 인스턴스에서 srConnectionChanged( ) 훅 활성화하기

  1. 클러스터를 중지합니다.

    NODE1 에서 다음 명령을 실행합니다.

    pcs cluster stop --all

  2. 각 HANA 인스턴스의 /hana/shared/myHooks 디렉터리에 resource-agents-sap-hana 패키지에서 제공하는 후크 스크립트를 설치하고 필요한 소유권을 설정합니다.

    두 노드에서 다음 명령을 실행합니다.

    mkdir -p /hana/shared/myHooks

    cp /usr/share/SAPHanaSR/srHook/SAPHanaSR.py /hana/shared/myHooks

    chown -R ${sid}adm:sapsys /hana/shared/myHooks

  3. 각 HANA 노드에서 global.ini 파일을 업데이트하여 후크 스크립트를 활성화합니다.

    두 노드에서 다음 명령을 실행합니다.

    sudo -i -u ${sid}adm -- <<EOT
    python \$DIR_INSTANCE/exe/python_support/setParameter.py \
      -set SYSTEM/global.ini/ha_dr_provider_SAPHanaSR/provider=SAPHanaSR \
      -set SYSTEM/global.ini/ha_dr_provider_SAPHanaSR/path=/hana/shared/myHooks \
      -set SYSTEM/global.ini/ha_dr_provider_SAPHanaSR/execution_order=1 \
      -set SYSTEM/global.ini/trace/ha_dr_saphanasr=info
EOT

  4. 변경된 파일을 확인합니다.

    두 노드에서 다음 명령을 실행합니다.

    cat /hana/shared/${SID}/global/hdb/custom/config/global.ini

  5. SAP HANA OS 사용자에 대한 sudo 설정을 만듭니다.

    srConnectionChanged( ) 훅이 실행될 때 ${sid}adm 사용자 스크립트가 노드 속성을 업데이트할 수 있도록 하려면 다음 sudo 설정이 필요합니다.

    두 노드에서 다음 명령을 실행합니다.

    필요한 sudo 별칭과 사용자 사양이 포함된 파일을 만듭니다.

    cat >> /etc/sudoers.d/20-saphana << EOT
Cmnd_Alias DC1_SOK = /usr/sbin/crm_attribute -n hana_${sid}_site_srHook_${DC1} -v SOK -t crm_config -s SAPHanaSR
Cmnd_Alias DC1_SFAIL = /usr/sbin/crm_attribute -n hana_${sid}_site_srHook_${DC1} -v SFAIL -t crm_config -s SAPHanaSR
Cmnd_Alias DC2_SOK = /usr/sbin/crm_attribute -n hana_${sid}_site_srHook_${DC2} -v SOK -t crm_config -s SAPHanaSR
Cmnd_Alias DC2_SFAIL = /usr/sbin/crm_attribute -n hana_${sid}_site_srHook_${DC2} -v SFAIL -t crm_config -s SAPHanaSR
${sid}adm ALL=(ALL) NOPASSWD: DC1_SOK, DC1_SFAIL, DC2_SOK, DC2_SFAIL
Defaults!DC1_SOK, DC1_SFAIL, DC2_SOK, DC2_SFAIL !requiretty
EOT

    권한을 조정하고 구문 오류를 확인합니다.

    chown root:root /etc/sudoers.d/20-saphana

    chmod 0440 /etc/sudoers.d/20-saphana

    cat /etc/sudoers.d/20-saphana

    visudo -c

visudo -c 명령으로 보고된 모든 문제는 반드시 수정해야 합니다.

  1. 후크가 작동하는지 확인합니다.

    • 두 HANA 인스턴스를 모두 다시 시작하고 후크 스크립트가 예상대로 작동하는지 확인합니다.
    • HANA 인스턴스 중지 등의 작업을 수행하여 훅을 트리거합니다.
    • 훅이 추적 파일에 로깅한 내용이 있는지 확인합니다.

    두 노드에서 다음 명령을 실행합니다.

    HANA 인스턴스를 중지합니다.

    sudo -i -u ${sid}adm -- HDB stop

    HANA 인스턴스를 시작합니다.

    sudo -i -u ${sid}adm -- HDB start

    훅이 일부 메시지를 추적 파일에 기록했는지 확인합니다.

    sudo -i -u ${sid}adm -- sh -c 'grep "ha_dr_SAPHanaSR.*crm_attribute" $DIR_INSTANCE/$VTHOSTNAME/trace/nameserver_* | cut -d" " -f2,3,5,17'

    후크가 작동하는지 확인한 후 HA 클러스터를 다시 시작할 수 있습니다.

  2. 클러스터를 시작합니다.

    NODE1 에서 다음 명령을 실행합니다.

    클러스터를 시작합니다.

    pcs cluster start --all

    클러스터의 상태를 확인합니다.

    pcs status --full

일반 클러스터 속성 구성

초기 테스트 및 포스트 프로덕션 중에 리소스 장애 조치를 방지하려면 리소스 고착성 및 마이그레이션 임계값 매개변수에 대해 다음과 같은 기본값을 설정하세요.

자체 정의된 값으로 기본값을 재정의하는 리소스에는 기본값이 적용되지 않는다는 점에 유의하세요.

NODE1 에서 다음 명령을 실행합니다.

pcs resource defaults update resource-stickiness=1000

pcs resource defaults update migration-threshold=5000

복제된 SAPHanaTopology 리소스 만들기

리소스는 SAPHanaTopology 리소스는 각 노드에서 SAP HANA 시스템 복제의 상태와 구성을 수집합니다. 또한 SAP HANA 인스턴스를 시작, 중지 및 모니터링하는 데 필요한 로컬 SAP HostAgent를 시작하고 모니터링합니다.

NODE1 에서 다음 명령을 실행합니다.

리소스를 만듭니다 SAPHanaTopology 리소스를 생성합니다.

pcs resource create SAPHanaTopology_${SID}_${INSTNO} SAPHanaTopology \
    SID=${SID} InstanceNumber=${INSTNO} \
    op start timeout=600 \
    op stop timeout=300 \
    op monitor interval=10 timeout=600 \
    clone clone-max=2 clone-node-max=1 interleave=true

다음 명령을 실행하여 구성 및 클러스터 상태를 확인합니다.

pcs resource config SAPHanaTopology_${SID}_${INSTNO}

pcs resource config SAPHanaTopology_${SID}_${INSTNO}-clone

pcs status --full

홍보 가능한 SAPHana 리소스 만들기

SAPHana 리소스는 HANA 시스템 복제 노드로 구성된 두 개의 SAP HANA 인스턴스를 관리합니다.

NODE1 에서 다음 명령을 실행하여 SAPHana 리소스를 생성합니다.

pcs resource create SAPHana_${SID}_${INSTNO} SAPHana \
    SID=${SID} InstanceNumber=${INSTNO} \
    PREFER_SITE_TAKEOVER=true \
    DUPLICATE_PRIMARY_TIMEOUT=7200 \
    AUTOMATED_REGISTER=false \
    op start timeout=3600 \
    op stop timeout=3600 \
    op monitor interval=61 role="Unpromoted" timeout=700 \
    op monitor interval=59 role="Promoted" timeout=700 \
    op promote timeout=3600 \
    op demote timeout=3600 \
    promotable notify=true clone-max=2 clone-node-max=1 interleave=true

구성 및 클러스터 상태를 확인합니다.

pcs resource config SAPHana_${SID}_${INSTNO}

pcs status --full

가상 IP 주소 클러스터 리소스 만들기

시나리오에 따라 다음 섹션 중 하나로 진행합니다:

단일 영역 환경에서 가상 IP 주소 클러스터 리소스 만들기

예약된 IP 주소를 사용하여 가상 IP 주소 클러스터 리소스를 만듭니다. 이 가상 IP 주소는 SAP HANA 시스템 복제 기본 인스턴스에 연결하는 데 사용됩니다.

다음 명령을 사용하여 가상 IP 주소 클러스터 리소스를 만듭니다.

pcs resource create vip_${SID}_${INSTNO} IPaddr2 ip=$VIP

구성된 가상 IP 주소 클러스터 리소스 및 클러스터 상태를 확인합니다.

pcs resource config vip_${SID}_${INSTNO}

pcs status --full

클러스터 리소스 제약 조건 만들기 섹션으로 진행합니다.

멀티존 리전 환경에서 가상 IP 주소 클러스터 리소스 만들기

가상 IP 주소 리소스에 대한 다중 영역 RHEL HA 애드온 클러스터 준비하기 섹션의 모든 단계를 완료했는지 확인합니다.

pcs resource describe powervs-subnet 명령을 실행하여 리소스 에이전트 매개 변수에 대한 정보를 얻습니다.

NODE1 에서 다음 명령을 실행하여 powervs-subnet 클러스터 리소스를 만듭니다.

pcs resource create vip_${SID}_${INSTNO} powervs-subnet \
    api_key=${APIKEY} \
    api_type=${API_TYPE} \
    cidr=${CIDR} \
    ip=${VIP} \
    crn_host_map="${NODE1}:${IBMCLOUD_CRN_1};${NODE2}:${IBMCLOUD_CRN_2}" \
    vsi_host_map="${NODE1}:${POWERVSI_1};${NODE2}:${POWERVSI_2}" \
    jumbo=${JUMBO} \
    region=${CLOUD_REGION} \
    subnet_name=${SUBNET_NAME} \
    op start timeout=720 \
    op stop timeout=300 \
    op monitor interval=60 timeout=30

API_TYPE 을 public 으로 설정하는 경우 proxy 매개변수도 지정해야 합니다.

pcs resource config 명령을 실행하기 전에 클러스터의 두 가상 서버 인스턴스가 모두 Active 상태와 OK 상태인지 확인합니다.

구성된 가상 IP 주소 리소스 및 클러스터 상태를 확인합니다.

pcs resource config vip_${SID}_${INSTNO}

샘플 출력:

# pcs resource config vip_MHA_00
Resource: vip_MHA_00 (class=ocf provider=heartbeat type=powervs-subnet)
  Attributes: vip_MHA_00-instance_attributes
    api_key=@/root/.apikey.json
    api_type=private
    cidr=10.40.11.100/30
    crn_host_map=cl-mha-1:crn:v1:bluemix:public:power-iaas:eu-de-2:**********************************:************************************::;cl-mha-2:crn:v1:bluemix:public:power-iaas:eu-
        de-1:**********************************:************************************::
    ip=10.40.11.102
    jumbo=true
    proxy=http://10.30.40.4:3128
    region=eu-de
    subnet_name=vip-mha-net
    vsi_host_map=cl-mha-1:************************************;cl-mha-2:************************************
  Operations:
    monitor: res_vip_MHA_00-monitor-interval-60
      interval=60
      timeout=60
    start: res_vip_MHA_00-start-interval-0s
      interval=0s
      timeout=720
    stop: res_vip_MHA_00-stop-interval-0s
      interval=0s
      timeout=300

pcs status --full

다음 예는 다중 영역 리전 설정에서 SAP HANA 시스템 복제 클러스터의 샘플 출력입니다.

# pcs status --full
Cluster name: SAP_MHA
Status of pacemakerd: 'Pacemaker is running' (last updated 2024-07-31 11:37:49 +02:00)
Cluster Summary:
  * Stack: corosync
  * Current DC: cl-mha-2 (2) (version 2.1.5-9.el9_2.4-a3f44794f94) - partition with quorum
  * Last updated: Wed Jul 31 11:37:50 2024
  * Last change:  Wed Jul 31 11:37:31 2024 by root via crm_attribute on cl-mha-1
  * 2 nodes configured
  * 7 resource instances configured

Node List:
  * Node cl-mha-1 (1): online, feature set 3.16.2
  * Node cl-mha-2 (2): online, feature set 3.16.2

Full List of Resources:
  * fence_node1	(stonith:fence_ibm_powervs):	 Started cl-mha-1
  * fence_node2	(stonith:fence_ibm_powervs):	 Started cl-mha-2
  * Clone Set: SAPHanaTopology_MHA_00-clone [SAPHanaTopology_MHA_00]:
    * SAPHanaTopology_MHA_00	(ocf:heartbeat:SAPHanaTopology):	 Started cl-mha-2
    * SAPHanaTopology_MHA_00	(ocf:heartbeat:SAPHanaTopology):	 Started cl-mha-1
  * Clone Set: SAPHana_MHA_00-clone [SAPHana_MHA_00] (promotable):
    * SAPHana_MHA_00	(ocf:heartbeat:SAPHana):	 Unpromoted cl-mha-2
    * SAPHana_MHA_00	(ocf:heartbeat:SAPHana):	 Promoted cl-mha-1
  * vip_MHA_00	(ocf:heartbeat:powervs-subnet):	 Started cl-mha-1

Node Attributes:
  * Node: cl-mha-1 (1):
    * hana_mha_clone_state            	: PROMOTED
    * hana_mha_op_mode                	: logreplay
    * hana_mha_remoteHost             	: cl-mha-2
    * hana_mha_roles                  	: 4:P:master1:master:worker:master
    * hana_mha_site                   	: SiteA
    * hana_mha_sra                    	: -
    * hana_mha_srah                   	: -
    * hana_mha_srmode                 	: syncmem
    * hana_mha_sync_state             	: PRIM
    * hana_mha_version                	: 2.00.075.00
    * hana_mha_vhost                  	: cl-mha-1
    * lpa_mha_lpt                     	: 1722418651
    * master-SAPHana_MHA_00           	: 150
  * Node: cl-mha-2 (2):
    * hana_mha_clone_state            	: DEMOTED
    * hana_mha_op_mode                	: logreplay
    * hana_mha_remoteHost             	: cl-mha-1
    * hana_mha_roles                  	: 4:S:master1:master:worker:master
    * hana_mha_site                   	: SiteB
    * hana_mha_sra                    	: -
    * hana_mha_srah                   	: -
    * hana_mha_srmode                 	: syncmem
    * hana_mha_sync_state             	: SOK
    * hana_mha_version                	: 2.00.075.00
    * hana_mha_vhost                  	: cl-mha-2
    * lpa_mha_lpt                     	: 30
    * master-SAPHana_MHA_00           	: 100

Migration Summary:

Tickets:

PCSD Status:
  cl-mha-1: Online
  cl-mha-2: Online

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

클러스터 리소스 제약 조건 만들기 섹션으로 진행합니다.

클러스터 리소스 제약 조건 만들기

SAPHanaTopology 리소스를 시작하기 전에 SAPHanaTopology 리소스가 시작되었는지 확인하세요.

가상 IP 주소는 'SAPHana'의 기본 리소스가 실행되는 노드에 있어야 합니다.

  1. 리소스 제약 조건을 만들어 "SAPHana" 앞에 "SAPHanaTopology" 을 시작하도록 합니다. 이 제약 조건은 이러한 리소스의 시작 순서를 지정합니다.

    NODE1 에서 다음 명령을 사용하여 SAPHanaTopology 주문 제약 조건을 생성합니다:

    pcs constraint order SAPHanaTopology_${SID}_${INSTNO}-clone \
    then SAPHana_${SID}_${INSTNO}-clone symmetrical=false

    구성을 확인하십시오.

    pcs constraint

  2. 리소스 제약 조건을 만들어 가상 IP 주소를 기본 IP 주소와 코로케이션합니다. 이 제약 조건은 가상 IP 주소 리소스를 기본으로 승격된 SAPHana 리소스와 코로케이션합니다.

    NODE1 에서 다음 명령을 실행하여 가상 IP 주소 코로케이션 제약 조건을 생성합니다.

    pcs constraint colocation add vip_${SID}_${INSTNO} \
    with Promoted SAPHana_${SID}_${INSTNO}-clone 2000

    구성 및 클러스터 상태를 확인합니다.

    pcs constraint

    샘플 출력:

    # pcs constraint
Location Constraints:
Ordering Constraints:
  start SAPHanaTopology_HDB_00-clone then start SAPHana_HDB_00-clone (kind:Mandatory) (non-symmetrical)
Colocation Constraints:
  vip_HDB_00 with SAPHana_HDB_00-clone (score:2000) (rsc-role:Started) (with-rsc-role:Promoted)
Ticket Constraints:

    클러스터 상태를 확인합니다.

    pcs status --full

    승격된 클러스터 노드에서 클러스터 서비스 IP 주소가 활성 상태인지 확인합니다.

    ip addr show

SAP HANA srServiceStateChanged( ) 후크 활성화(선택 사항)

SAP HANA 에는 indexserver 을 모니터링하는 기능이 내장되어 있습니다. 문제가 발생하면 SAP HANA 프로세스를 중지했다가 다시 시작하여 자동으로 복구를 시도합니다. 프로세스를 중지하거나 충돌 후 정리하려면 Linux 커널이 프로세스에 할당된 모든 메모리를 해제해야 합니다. 대규모 데이터베이스의 경우 이 정리 작업에 시간이 오래 걸릴 수 있습니다. 이 기간 동안 SAP HANA 은 계속 운영되며 새로운 고객 요청을 수락합니다. 그 결과 SAP HANA 시스템 복제가 동기화되지 않을 수 있습니다. indexserver 인스턴스의 재시작 및 복구가 완료되기 전에 SAP HANA 인스턴스에서 다른 오류가 발생하면 데이터 일관성이 위험해집니다.

srServiceStateChanged() 훅에 대한 ChkSrv.py 스크립트는 이러한 상황에 반응하여 전체 SAP HANA 인스턴스를 중지하여 더 빠르게 복구할 수 있습니다. 클러스터에서 automated failover 이 활성화되어 있고 보조 노드가 정상 상태이면 인수 작업이 시작됩니다. 그렇지 않으면 복구가 로컬에서 계속되어야 하지만 SAP HANA 인스턴스의 강제 재시작으로 복구 속도가 빨라집니다.

SAP HANA srServiceStateChanged() 후크는 resource-agents-sap-hana 버전 0.162.3 이상에서 사용할 수 있습니다.

후크 스크립트는 인스턴스의 이벤트를 분석하고, 이벤트 세부 정보에 필터를 적용하고, 결과에 따라 작업을 트리거합니다. SAP HANA 에 의해 중지되었다가 다시 시작되는 SAP HANA indexserver 프로세스와 인스턴스 종료 중에 중지되는 프로세스를 구분합니다.

action_on_lost 매개변수의 구성에 따라 훅은 다른 작업을 수행합니다:

무시
이 작업은 단순히 이벤트 및 의사 결정 정보를 로그 파일에 기록합니다.
중지
이 작업은 sapcontrol 명령을 사용하여 SAP HANA 인스턴스를 정상적으로 중지합니다.
강제 종료
이 작업은 기본 신호 9를 사용하여 HDB kill-<signal> 명령을 트리거합니다. 신호를 구성할 수 있습니다.

중지 작업과 삭제 작업 모두 SAP HANA 인스턴스가 중지되며, 삭제 작업이 약간 더 빠릅니다.

모든 SAP HANA 인스턴스에서 srServiceStateChanged( ) 훅 활성화하기

srServiceStateChanged() 훅은 SAP HANA 이 두 노드에서 실행되는 동안 추가할 수 있습니다.

  1. 각 HANA 인스턴스에 대해 resource-agents-sap-hana 패키지에서 제공하는 후크 스크립트를 /hana/shared/myHooks 디렉터리에 설치하고 필요한 소유권을 설정합니다.

    두 노드에서 다음 명령을 실행합니다.

    cp /usr/share/SAPHanaSR/srHook/ChkSrv.py /hana/shared/myHooks

    chown ${sid}adm:sapsys /hana/shared/myHooks/ChkSrv.py

  2. 각 SAP HANA 노드에서 global.ini 파일을 업데이트하여 후크 스크립트를 활성화합니다.

    두 노드에서 다음 명령을 실행합니다.

    sudo -i -u ${sid}adm -- <<EOT
    python \$DIR_INSTANCE/exe/python_support/setParameter.py \
      -set SYSTEM/global.ini/ha_dr_provider_ChkSrv/provider=ChkSrv \
      -set SYSTEM/global.ini/ha_dr_provider_ChkSrv/path=/hana/shared/myHooks \
      -set SYSTEM/global.ini/ha_dr_provider_ChkSrv/execution_order=2 \
      -set SYSTEM/global.ini/ha_dr_provider_ChkSrv/action_on_lost=stop \
      -set SYSTEM/global.ini/trace/ha_dr_chksrv=info
EOT

    이 예제에서 action_on_lost 매개 변수는 stop 으로 설정되어 있으며 기본 설정은 ignore 입니다. stop_timeout (기본값: 20 초) 및 kill_signal (기본값: 9)를 선택적으로 설정할 수 있습니다.

  3. ChkSrv.py 후크 활성화

    두 노드에서 다음 명령을 실행하여 HA-DR 공급자를 다시 로드합니다.

    sudo -i -u ${sid}adm -- hdbnsutil -reloadHADRProviders

  4. 훅이 일부 메시지를 추적 파일에 기록했는지 확인합니다.

    두 노드에서 다음 명령을 실행합니다.

    sudo -i -u ${sid}adm -- sh -c 'grep "ha_dr_ChkSrv" $DIR_INSTANCE/$VTHOSTNAME/trace/nameserver_* | cut -d" " -f2,3,6-'

보조 인스턴스의 자동 등록 활성화

운영 요구 사항에 따라 AUTOMATED_REGISTER 파라미터를 설정해야 합니다. 이전 기본 SAP HANA 인스턴스의 상태로 되돌릴 수 있는 기능을 유지하려면 AUTOMATED_REGISTER=false 을 사용하여 이전 기본 인스턴스를 새 보조 인스턴스로 자동 등록하지 않도록 합니다.

클러스터에서 트리거된 테이크오버 후 데이터에 문제가 발생하는 경우 AUTOMATED_REGISTER 을 false 으로 설정하면 수동으로 되돌릴 수 있습니다.

AUTOMATED_REGISTER 이 true 으로 설정된 경우 이전 기본 SAP HANA 인스턴스는 자동으로 보조로 등록되며 이전 기록에서는 활성화할 수 없습니다. AUTOMATED_REGISTER=true 의 장점은 장애가 발생한 노드가 클러스터에 다시 나타나면 고가용성 기능이 자동으로 다시 설정된다는 점입니다.

현재로서는 클러스터를 완전히 테스트하고 장애 조치 시나리오가 예상대로 작동하는지 확인할 때까지 기본값 false 을 AUTOMATED_REGISTER 으로 유지하는 것이 좋습니다.

pcs resource update 명령은 리소스 속성을 수정하는 데 사용되며 pcs resource update SAPHana_${SID}_${INSTNO} AUTOMATED_REGISTER=true 은 속성을 true 로 설정합니다.

테스트 SAP HANA 시스템 복제 클러스터

클러스터 구성을 철저히 테스트하여 클러스터가 올바르게 작동하는지 확인하는 것이 중요합니다. 다음 정보는 몇 가지 샘플 장애 조치 테스트 시나리오를 제공하지만 테스트 시나리오의 전체 목록은 아닙니다.

예를 들어 각 테스트 사례에 대한 설명에는 다음 정보가 포함됩니다.

  • 테스트 중인 구성 요소
  • 테스트에 대한 설명
  • 장애 조치 테스트를 시작하기 전 사전 요구 사항 및 클러스터 상태
  • 테스트 절차
  • 예상 동작 및 결과
  • 복구 프로시저

테스트 1 - 기본 데이터베이스 인스턴스의 장애 테스트

다음 정보를 사용하여 기본 데이터베이스 인스턴스의 장애를 테스트합니다.

테스트 1 - 설명

NODE1 에서 실행 중인 기본 HANA 데이터베이스 인스턴스의 충돌을 시뮬레이션합니다.

테스트 1 - 전제 조건

  • HANA 시스템 복제를 위한 기능적인 2노드 RHEL HA 애드온 클러스터입니다.
  • 두 클러스터 노드 모두 활성 상태입니다.
  • NODE1 및 NODE2 에서 시작되는 클러스터입니다.
  • AUTOMATED_REGISTER=false 로 구성된 클러스터 리소스 SAPHana_${SID}_${INSTNO}.
  • SAP HANA 시스템 복제 상태를 확인합니다:
    • 기본 SAP HANA 데이터베이스가 다음에서 실행 중입니다 NODE1
    • 보조 SAP HANA 데이터베이스가 다음에서 실행 중입니다 NODE2
    • HANA 시스템 복제가 활성화되고 동기화됨

테스트 1 - 테스트 절차

${sid}adm 사용자로 시그킬 신호를 보내 SAP HANA 기본을 크래시합니다.

NODE1 에서 다음 명령을 실행합니다.

sudo -i -u ${sid}adm -- HDB kill-9

테스트 1 - 예상되는 동작

  • SAP HANA NODE1 의 기본 인스턴스가 충돌합니다.
  • 클러스터는 중지된 기본 HANA 데이터베이스를 감지하고 리소스를 failed 로 표시합니다.
  • 이 클러스터는 NODE2 의 보조 HANA 데이터베이스를 새로운 기본 데이터베이스로 승격합니다.
  • 클러스터는 NODE1 에서 가상 IP 주소를 해제하고 NODE2 의 새 기본 주소에서 이를 획득합니다.
  • SAP NetWeaver 와 같은 애플리케이션이 SAP HANA 의 테넌트 데이터베이스에 연결되어 있는 경우 애플리케이션은 자동으로 새 기본 데이터베이스에 다시 연결됩니다.

테스트 1 - 복구 절차

클러스터 리소스 SAPHana_${SID}_${INSTNO} 가 AUTOMATED_REGISTER=false 로 구성되어 있으므로 클러스터는 장애가 발생한 HANA 데이터베이스를 다시 시작하지 않으며 새 기본 데이터베이스에 대해 등록하지 않습니다. 즉, 새 기본 계정( NODE2 )의 상태에도 보조 계정 상태가 '연결 시간 초과'로 표시됩니다.

이전 기본 계정을 새 보조 계정으로 다시 등록하려면 다음 명령을 사용합니다.

NODE1 에서 다음 명령을 실행합니다.

sudo -i -u ${sid}adm -- <<EOT
    hdbnsutil -sr_register \
      --name=${DC1} \
      --remoteHost=${NODE2} \
      --remoteInstance=00 \
      --replicationMode=sync \
      --operationMode=logreplay \
      --online
EOT

시스템 복제 상태를 확인합니다:

sudo -i -u ${sid}adm -- <<EOT
    hdbnsutil -sr_state
    HDBSettings.sh systemReplicationStatus.py
EOT

수동 등록 및 리소스가 새로 고쳐지면 새 보조 인스턴스가 다시 시작되고 동기화 상태(SOK)로 표시됩니다.

NODE1 에서 다음 명령을 실행합니다.

pcs resource refresh SAPHana_${SID}_${INSTNO}

pcs status --full

테스트 2 - 기본 데이터베이스를 실행 중인 노드의 장애 테스트

다음 정보를 사용하여 기본 데이터베이스를 실행 중인 노드의 장애를 테스트합니다.

테스트 2 - 설명

기본 HANA 데이터베이스를 실행하는 노드의 충돌을 시뮬레이션합니다.

테스트 2 - 준비

클러스터 리소스 SAPHana_${SID}_${INSTNO} 가 AUTOMATED_REGISTER=true 로 구성되어 있는지 확인합니다.

NODE1 에서 다음 명령을 실행합니다.

pcs resource update SAPHana_${SID}_${INSTNO} AUTOMATED_REGISTER=true

pcs resource config SAPHana_${SID}_${INSTNO}

테스트 2 - 전제 조건

  • HANA 시스템 복제를 위한 기능적인 2노드 RHEL HA 애드온 클러스터입니다.
  • 두 노드 모두 활성 상태입니다.
  • 클러스터는 NODE1 및 NODE2 에서 시작됩니다.
  • SAP HANA 시스템 복제 상태를 확인합니다.
    • 기본 SAP HANA 데이터베이스가 다음에서 실행 중입니다 NODE2
    • 보조 SAP HANA 데이터베이스가 다음에서 실행 중입니다 NODE1
    • HANA 시스템 복제가 활성화되고 동기화됨

테스트 2 - 테스트 절차

크래시 시스템 요청을 보내 NODE2 에서 기본 크래시를 발생시킵니다.

NODE2 에서 다음 명령을 실행합니다.

sync; echo c > /proc/sysrq-trigger

테스트 2 - 예상되는 동작

  • NODE2 종료됩니다.
  • 클러스터는 실패한 노드를 감지하고 해당 상태를 OFFLINE 로 설정합니다.
  • 이 클러스터는 NODE1 의 보조 HANA 데이터베이스를 새로운 기본 데이터베이스로 승격합니다.
  • 클러스터는 새 기본값의 NODE1 에서 가상 IP 주소를 얻습니다.
  • SAP NetWeaver 와 같은 애플리케이션이 SAP HANA 의 테넌트 데이터베이스에 연결되어 있는 경우 애플리케이션은 자동으로 새 기본 데이터베이스에 다시 연결됩니다.

테스트 2 - 복구 절차

IBM Cloud® 콘솔에 로그인하고 NODE2 인스턴스를 시작합니다. NODE2 을 다시 사용할 수 있을 때까지 기다린 다음 클러스터 프레임워크를 다시 시작합니다.

NODE2 에서 다음 명령을 실행합니다.

pcs cluster start

pcs status --full

클러스터 리소스 SAPHana_${SID}_${INSTNO} 가 AUTOMATED_REGISTER=true 로 구성되어 있으므로 NODE2 이 클러스터에 다시 가입하고 이전 기본 리소스가 보조 리소스로 다시 등록되면 SAP HANA 이 다시 시작됩니다.

테스트 3 - 보조 데이터베이스 인스턴스의 장애 테스트

다음 정보를 사용하여 보조 데이터베이스 인스턴스의 장애를 테스트합니다.

테스트 3 - 설명

보조 HANA 데이터베이스의 충돌을 시뮬레이션합니다.

테스트 3 - 전제 조건

  • HANA 시스템 복제를 위한 기능적인 2노드 RHEL HA 애드온 클러스터입니다.
  • 두 노드 모두 활성 상태입니다.
  • 클러스터는 NODE1 및 NODE2 에서 시작됩니다.
  • 클러스터 리소스 SAPHana_${SID}_${INSTNO} 는 AUTOMATED_REGISTER=true 로 구성됩니다.
  • SAP HANA 시스템 복제 상태를 확인합니다:
    • 기본 SAP HANA 데이터베이스가 다음에서 실행 중입니다 NODE1
    • 보조 SAP HANA 데이터베이스가 다음에서 실행 중입니다 NODE2
    • HANA 시스템 복제가 활성화되고 동기화됨

테스트 3 - 테스트 절차

사용자 ${sid}adm 로 시그킬 신호를 전송하여 SAP HANA 세컨더리 크래시.

NODE2 에서 다음 명령을 실행합니다.

sudo -i -u ${sid}adm -- HDB kill-9

테스트 3 - 예상되는 동작

  • SAP HANA NODE2 충돌이 발생합니다.
  • 클러스터는 중지된 보조 HANA 데이터베이스를 감지하고 리소스를 failed 로 표시합니다.
  • 클러스터가 보조 HANA 데이터베이스를 다시 시작합니다.
  • 클러스터가 시스템 복제가 다시 동기화되었음을 감지합니다.

테스트 3 - 복구 절차

보조 HANA 인스턴스가 시작되고 다시 동기화될 때까지 기다린 다음(SOK), pcs status 에 표시된 대로 실패한 리소스 작업을 정리합니다.

NODE2 에서 다음 명령을 실행합니다.

pcs resource refresh SAPHana_${SID}_${INSTNO}

pcs status --full

테스트 4 - SAPHana 리소스를 다른 노드로 수동으로 이동하는 테스트

다음 정보를 사용하여 SAPHana 리소스를 다른 노드로 수동으로 이동하는 것을 테스트합니다.

테스트 4 - 설명

클러스터 명령을 사용하여 유지 관리 목적으로 기본 인스턴스를 다른 노드로 이동합니다.

테스트 4 - 전제 조건

  • HANA 시스템 복제를 위한 기능적인 2노드 RHEL HA 애드온 클러스터입니다.
  • 두 노드 모두 활성 상태입니다.
  • 클러스터는 NODE1 및 NODE2 에서 시작됩니다.
  • 클러스터 리소스 SAPHana_${SID}_${INSTNO} 는 AUTOMATED_REGISTER=true 로 구성됩니다.
  • SAP HANA 시스템 복제 상태를 확인합니다:
    • 기본 SAP HANA 데이터베이스가 다음에서 실행 중입니다 NODE1
    • 보조 SAP HANA 데이터베이스가 다음에서 실행 중입니다 NODE2
    • HANA 시스템 복제가 활성화되고 동기화됨

테스트 4 - 테스트 절차

pcs resource move 명령을 사용하여 SAP HANA 기본 노드를 다른 노드로 이동합니다.

NODE1 에서 다음 명령을 실행합니다.

pcs resource move SAPHana_${SID}_${INSTNO}-clone

테스트 4 - 예상 동작

  • 클러스터는 리소스를 이동하기 위해 위치 제약 조건을 생성합니다.
  • 클러스터는 보조 HANA 데이터베이스로의 트라이오버를 트리거합니다.
  • SAP NetWeaver 와 같은 애플리케이션이 SAP HANA 의 테넌트 데이터베이스에 연결되어 있는 경우 애플리케이션은 자동으로 새 기본 데이터베이스에 다시 연결됩니다.

테스트 4 - 복구 절차

향후 자동 장애 조치를 허용하려면 자동으로 생성된 위치 제약 조건을 제거해야 합니다.

기본 HANA 인스턴스가 활성화될 때까지 기다렸다가 제약 조건을 제거합니다.

클러스터는 HANA 데이터베이스를 새 보조 인스턴스로 등록하고 시작합니다.

NODE1 에서 다음 명령을 실행합니다.

pcs constraint

pcs resource clear SAPHana_${SID}_${INSTNO}-clone

pcs constraint

pcs status --full