다음을 통해 공유

Pacemaker 클러스터 서비스 및 리소스에 대한 시작 문제 해결

적용 대상: ✔️ Linux VM

이 문서에서는 RHEL(RedHat Enterprise Linux) Pacemaker 클러스터 리소스 또는 서비스의 시작 문제의 가장 일반적인 원인에 대해 설명하고 문제를 식별하고 해결하기 위한 지침을 제공합니다.

시나리오 1: 쿼럼으로 인해 클러스터 서비스를 시작할 수 없습니다.

시나리오 1의 증상

  • 클러스터 노드는 클러스터를 다시 시작한 후 클러스터에 조인하지 않습니다.

  • 노드는 .로 UNCLEAN (offline)보고됩니다.

  • 현재 DC는 .로 NONE보고됩니다.

    sudo pcs status

    Cluster name: my_cluster
Status of pacemakerd: 'Pacemaker is running' (last updated 2024-06-25 16:34:49 -04:00)
Cluster Summary:
* Stack: corosync
* **Current DC: NONE**
* Last updated: Tue Jun 25 14:34:49 2024
* Last change:  Tue Jun 25 14:29:51 2024 by root via cibadmin on node-0
* 2 nodes configured
* 9 resource instances configured

Node List:
* **Node node-0: UNCLEAN (offline)**
* **Node node-1: UNCLEAN (offline)**

  • sudo pcs quorum status 는 다음 오류 메시지를 반환합니다.

    sudo pcs quorum status

    Error: Unable to get quorum status: Unable to start votequorum status tracking: CS_ERR_BAD_HANDLE
Check for the error: Corosync quorum is not configured in /var/log/messeges:
Jun 16 11:17:53 node-0 pacemaker-controld[509433]: error: Corosync quorum is not configured

시나리오 1의 원인

VoteQuorum 서비스는 corosync 프로젝트의 구성 요소입니다. 분할 브레인 시나리오를 방지하기 위해 이 서비스를 필요에 따라 부동 동기화 클러스터의 노드에 로드할 수 있습니다. 클러스터의 모든 시스템에는 이 쿼럼을 달성하기 위해 특정 수의 투표가 제공됩니다. 이렇게 하면 대부분의 투표가 캐스팅되는 경우에만 클러스터 작업이 발생할 수 있습니다. 모든 노드 또는 노드가 없는 경우 서비스가 로드되어야 합니다. 서비스가 클러스터 노드의 하위 집합에 로드되는지에 대한 결과는 불확실합니다.

다음 /etc/corosync/corosync.conf 설정은 Corosync 내에서 VoteQuorum 서비스를 사용하도록 설정합니다.

quorum {
    provider: corosync_votequorum
}

VoteQuorum 에서 구성 /etc/corosync/corosync.conf을 읽습니다. 일부 값은 런타임에 변경할 수 있으며 다른 값은 corosync 시작 시만 읽습니다. 이러한 값은 클러스터에 참여하는 모든 노드에서 일관성을 유지하는 것이 중요합니다. 그렇지 않으면 투표 쿼럼 동작을 예측할 수 없습니다.

시나리오 1에 대한 해결 방법

  1. 변경하기 전에 백업 또는 스냅샷이 있는지 확인합니다. 자세한 내용은 Azure VM 백업을 참조하세요.

  2. 에서 누락된 쿼럼 섹션을 확인합니다 /etc/corosync/corosync.conf. 에서 사용할 수 있는 백업과 기존 corosync.conf 백업을 비교합니다 /etc/corosync/.

  3. 클러스터를 유지 관리 모드로 전환합니다.

    sudo pcs property set maintenance-mode=true

  4. 에서 변경 내용을 업데이트합니다 /etc/corosync/corosync.conf.

    2노드 클러스터의 예:

    sudo cat /etc/corosync/corosync.conf

    totem {
version: 2
cluster_name: my_cluster
transport: knet
token: 30000
crypto_cipher: aes256
crypto_hash: sha256
cluster_uuid: afd62fe2045b43b9a102de76fdf4659a
}
nodelist {
node {
    ring0_addr: node-0
    name: node-0
    nodeid: 1
}

node {
    ring0_addr: node-1
    name: node-1
    nodeid: 2
}
}

**quorum {
provider: corosync_votequorum
two_node: 1
}**

logging {
to_logfile: yes
logfile: /var/log/cluster/corosync.log
to_syslog: yes
timestamp: on
}

  5. 유지 관리 모드에서 클러스터를 제거합니다.

    sudo pcs property set maintenance-mode=false

  6. 클러스터 동기화:

    sudo pcs cluster sync

  7. corosync를 다시 로드합니다.

    sudo pcs cluster reload corosync

시나리오 2: 클러스터 VIP 리소스의 문제

시나리오 2의 증상

Pacemaker에서 가상 IP 리소스(IPaddr2 리소스)가 시작되거나 중지되지 않았습니다.

다음 오류 항목이 로그인됩니다./var/log/pacemaker.log

25167 IPaddr2(VIP)[16985]:    2024/09/07_15:44:19 ERROR: Unable to find nic or netmask.
25168 IPaddr2(VIP)[16985]:    2024/09/07_15:44:19 ERROR: [findif] failed

다음을 실행하는 sudo pcs status동안 오류를 관찰할 수도 있습니다.

sudo pcs status

vip_HN1_03_start_0 on node-1 'unknown error' (1): call=30, status=complete, exit-reason='[findif] failed', last-rc-change='Thu Jan 07 17:25:52 2025', queued=0ms, exec=57ms

시나리오 2의 원인

  1. 리소스를 시작할 IPAddr2 NIC(네트워크 어댑터)를 선택하려면 패키지에 IPaddr2 포함된 resource-agents 함수를 /usr/lib/ocf/resource.d/heartbeat/IPaddr2 호출 findif() 합니다.

  2. 올바른 네트워크 어댑터는 리소스에 IPAddr2 설정된 옵션(예: ip 필수) cidr_netmask및 broadcast.

    예:

    설정을 확인합니다.IPaddr2

    sudo pcs resource show vip_HN1_03

    Resource: vip_HN1_03 (class=ocf provider=heartbeat type=IPaddr2)
Attributes: ip=172.17.10.10 cidr_netmask=24 nic=ens6
Operations: start interval=0s timeout=20s (vip_HN1_03-start-timeout-20s)
            stop interval=0s timeout=20s (vip_HN1_03-stop-timeout-20s)
            monitor interval=10s timeout=20s (vip_HN1_03-monitor-interval-10s)

  3. 정보를 수동으로 확인 NIC 합니다. 이 예제에서는 IP 주소 및 netmask를 기반으로 경로 테이블에서 성공적으로 찾을 ens6 수 있습니다.

    sudo ip -o -f inet route list match 172.17.10.10/24 scope link

    172.17.10.0/24 dev ens6 proto kernel src 172.17.10.7

  4. 다운된 NIC (ens6) 상황에서는 정보를 수동으로 찾을 NIC 수 없으며 이로 인해 [findif] 실패할 수 있습니다. 바꾸기 172.17.10.10/24 및 ens6 적절하게.

    sudo ip link set ens6 down

    sudo ip -o -f inet route list match 172.17.10.10/24 scope link

시나리오 2에 대한 해결 방법

일치하는 VIP 경로가 기본 라우팅 테이블에 없는 경우 Pacemaker 리소스의 이름을 지정 NIC 하여 검사를 무시하도록 구성할 수 있습니다.

  1. 변경하기 전에 백업 또는 스냅샷이 있는지 확인합니다. 자세한 내용은 Azure VM 백업을 참조하세요.

  2. 클러스터를 유지 관리 모드로 전환합니다.

    sudo pcs property set maintenance-mode=true

  3. 리소스를 NIC 업데이트합니다.

    sudo pcs resource update vip_HN1_03 nic=ens6

  4. 리소스를 다시 NIC 시작합니다.

    sudo pcs resource restart vip_HN1_03

    vip_HN1_03 successfully restarted

  5. 에서 클러스터를 제거합니다.maintenance-mode

    sudo pcs property set maintenance-mode=false

  6. 리소스를 확인합니다.IP

    sudo pcs resource show vip_HN1_03

    Warning: This command is deprecated and will be removed. Please use 'pcs resource config' instead.
Resource: vip_HN1_03 (class=ocf provider=heartbeat type=IPaddr2)
  Attributes: cidr_netmask=32 ip=172.17.223.36 nic=vlan10
  Meta Attrs: resource-stickiness=INFINITY
  Operations: monitor interval=10s timeout=20s (vip_HN1_03-monitor-interval-10s)
              start interval=0s timeout=20s (vip_HN1_03-start-interval-0s)
              stop interval=0s timeout=20s (vip_HN1_03-stop-interval-0s)

이 시나리오에 대한 자세한 내용은 Pacemaker에 표시된 "오류: [findif] 실패" Red Hat 문서를 참조하세요.

시나리오 3: SAP HANA의 문제(고성능 분석 어플라이언스)

시나리오 3, 증상 1: SAP HANA DB가 시작되지 않고 알 수 없는 오류가 생성됩니다.

SAP HANA DB는 시작되지 않으며 오류 메시지를 반환합니다 unknown error .

  1. /var/log/messages 로그 섹션에서 항목이 SRHOOK=SFAIL 기록됩니다. 클러스터 노드가 동기화되지 않은 것을 나타냅니다.

  2. 보조 클러스터 노드가 WAITING4PRIM 상태입니다.

    sudo pcs status --full

    * Node node-0 (1):
    + hana_XXX_clone_state              : PROMOTED  
    + hana_XXX_sync_state               : PRIM      
    + hana_XXX_roles                    : 2:P:master1:master:worker:slave

* Node node-1 (2):
    + hana_XXX_clone_state              : WAITING4PRIM  
    + hana_XX_sync_state                : SFAIL      
    + hana_XXX_roles                    : 2:S:master1:master:worker:slave

  3. 실행할 sudo pcs status때 클러스터 상태는 다음과 같이 표시됩니다.

    sudo pcs status

    2 nodes configured
8 resources configured

Online: [ node-0 node-1 ]

Full list of resources:

  rsc_st_azure	(stonith:fence_azure_arm):	Started node-1
  Clone Set: cln_SAPHanaTopology [rsc_SAPHanaTopology]
      Started: [ node-0 node-1 ]
  Master/Slave Set: msl_SAPHana [rsc_SAPHana]
      Master: [ node-1 ]
      Slave:  [ node-0 ]
  Resource Group: g_ip_HN1_HBD00
      vip_HN1_HBD00	(ocf::heartbeat:IPaddr2):	Started node-0 
      nc_HN1_HBD00	(ocf::heartbeat:azure-lb):	Started node-0 


Failed Resource Actions:
* rsc_SAPHana_monitor_61000 on node-0 'unknown error' (1): call=32, status=complete, exitreason='',
    last-rc-change='Sat May 22 09:29:20 2021', queued=0ms, exec=0ms
* rsc_SAPHana_start_0 on node-1 'not running' (7): call=55, status=complete, exitreason='',
    last-rc-change='Sat May 22 09:36:32 2021', queued=0ms, exec=3093ms

시나리오 3의 원인, 증상 1

주 노드와 보조 노드 간에 오류가 있는 경우 Pacemaker는 SYN SAP HANA 리소스를 시작할 수 없습니다.

sudo SAPHanaSR-showAttr

Global cib-time                 maintenance
--------------------------------------------
global Fri Aug 23 11:47:32 2024 false

Hosts	clone_state	lpa_fh9_lpt	node_state	op_mode	        remoteHost  	  roles		            score	 site   srmode	sync_state	version         vhost
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
node-0	DEMOTED		10		online		logreplay	node-1 	4:S:master1:master:worker:master	5	SITEA	syncmem	SOK	2.00.046.00.1581325702	node-0
node-1	PROMOTED	1693237652	online		logreplay	node-0 	4:P:master1:master:worker:master	150	SITEA	syncmem	PRIM	2.00.046.00.1581325702	node-1

시나리오 3, 증상 1에 대한 해결 방법

주 클러스터 노드와 보조 클러스터 노드 간에 오류가 있는 SYN 경우 Pacemaker에서 SAP HANA 리소스를 시작할 수 없습니다. 이 문제를 완화하려면 주 노드와 보조 노드 간에 수동으로 사용하도록 설정 SYN 해야 합니다.

Important

2단계, 3단계 및 4단계는 SAP 관리자 계정을 사용하여 수행해야 합니다. 이러한 단계는 SAP 시스템 ID를 사용하여 복제를 수동으로 중지, 시작 및 다시 사용하도록 설정하기 때문입니다.

  1. 변경하기 전에 백업 또는 스냅샷이 있는지 확인합니다. 자세한 내용은 Azure VM 백업을 참조하세요.

  2. 클러스터를 유지 관리 모드로 전환합니다.

    sudo pcs property set maintenance-mode=true

  3. SAP HANA DB 및 프로세스 상태를 확인합니다.

    a. 주 노드와 보조 노드가 모두 SAP 데이터베이스 및 관련 SAP 프로세스를 실행하고 있는지 확인합니다. 하나는 주 노드로, 다른 하나는 보조 노드로 작동해야 합니다. 이렇게 하면 두 노드의 데이터베이스가 동기화된 상태로 유지됩니다.

    b. 각 노드에서 실행 HDB info 하여 노드에서 실행되는 SAP 관련 프로세스를 확인합니다. SAP 관리자는 필요한 프로세스가 두 노드에서 실행 중임을 확인할 수 있어야 합니다.

    HDB info

    USER        PID   PPID %CPU    VSZ   RSS COMMAND
a00adm     5183   5178  0.0  87684  1804 sshd: a00adm@pts/0
a00adm     5184   5183  0.0  14808  3624  \_ -sh
a00adm     5994   5184  0.0  13200  1824      \_ /bin/sh /usr/sap/A00/HDB00/HDB info
a00adm     6019   5994  0.0  26668  1356          \_ ps fx -U a00adm -o user,pid,ppid,pcpu,vsz,rss,args
a00adm     5369      1  0.0  20932  1644 sapstart pf=/usr/sap/A00/SYS/profile/A00_HDB00_node-0
a00adm     5377   5369  1.8 582944 292720  \_ /usr/sap/A00/HDB00/node-0/trace/hdb.sapA00_HDB00 -d -nw -f /usr/sap/A00/HDB00/node-0/daemon.ini pf=/usr/sap/A00/SYS/profile/A00_HDB00_node-0
a00adm     5394   5377  9.3 3930388 1146444      \_ hdbnameserver
a00adm     5548   5377 21.3 2943472 529672      \_ hdbcompileserver
a00adm     5550   5377  4.4 2838792 465664      \_ hdbpreprocessor
a00adm     5571   5377 91.6 7151116 4019640      \_ hdbindexserver
a00adm     5573   5377 21.8 4323488 1203128      \_ hdbxsengine
a00adm     5905   5377 18.9 3182120 710680      \_ hdbwebdispatcher
a00adm     2104      1  0.0 428748 27760 /usr/sap/A00/HDB00/exe/sapstartsrv pf=/usr/sap/A00/SYS/profile/A00_HDB00_node-0 -D -u a00adm
a00adm     2004      1  0.0  31844  2352 /usr/lib/systemd/systemd --user
a00adm     2008   2004  0.0  63796  2620  \_ (sd-pam)

    c. SAP DB 및 서비스가 노드에서 활성화되지 않은 경우 SAP 관리자에게 문의하여 SAP DB 서비스를 검토하고 중지하는 것이 좋습니다. 먼저 보조 노드에서 그리고 주 노드에서 다음을 수행하는 것이 좋습니다.

    sudo HDB stop

    또는:

    sudo sapcontrol -nr <SAPInstanceNo> -function stop

    d. 중지 작업이 완료되면 주 노드에서 HANA DB를 시작한 다음 보조 노드에서 시작합니다. 적절하게 수정 <SAPInstanceNo> 합니다.

    sudo HDB start

    또는:

    sudo sapcontrol -nr <SAPInstanceNo> -function start

  4. 데이터베이스 노드가 아직 동기화되지 않은 경우 SAP 관리자는 SAP 로그를 검토하여 데이터베이스 노드가 올바르게 동기화되었는지 확인하여 문제를 해결해야 합니다.

    참고

    SAP 관리자는 프로세스에서 데이터베이스 데이터가 손실되지 않도록 주 노드로 지정해야 하는 노드와 보조 노드를 결정해야 합니다.

  5. 복제를 사용하도록 설정한 후 SAP 시스템 관리자 계정을 사용하여 시스템 복제 상태를 확인합니다. 이 경우 사용자 관리자 계정은 .입니다 hn1adm.

    주 노드에서 전체 시스템 복제 상태가 되는지 확인합니다 ACTIVE.

    데이터베이스 노드가 아직 동기화되지 않은 경우 SAP 관리자는 SAP 로그를 검토하여 데이터베이스 노드가 올바르게 동기화되었는지 확인하여 문제를 해결해야 합니다.

    sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"

    | Host   | Port  | Service Name | Volume ID | Site ID | Site Name | Secondary | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
|        |       |              |           |         |           | Host      | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details | 
| ------ | ----- | ------------ | --------- | ------- | --------- | --------- | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
| node-0 | 30007 | xsengine     |         2 |       1 | node-0    | sapn2     |     30007 |         2 | node-1     | YES          | SYNC        | ACTIVE      |                |
| node-0 | 30001 | nameserver   |         1 |       1 | node-0    | sapn2     |     30001 |         2 | node-1     | YES          | SYNC        | ACTIVE      |                |
| node-0 | 30003 | indexserver  |         3 |       1 | node-0    | sapn2     |     30003 |         2 | node-1     | YES          | SYNC        | ACTIVE      |                |

status system replication site "2": ACTIVE
overall system replication status: ACTIVE

Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  mode: PRIMARY
  site id: 1
  site name: node-0

  6. 다음 명령을 실행하여 SAP HANA 시스템 복제 상태를 다시 확인합니다.

    sudo SAPHanaSR-showAttr

    Global cib-time                 maintenance
--------------------------------------------
global Mon Oct 14 10:25:51 2024 false

Hosts	clone_state	lpa_fh9_lpt	node_state	op_mode	        remoteHost  	  roles		            score	 site   srmode	sync_state	version         vhost
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
node-0	DEMOTED		10		online		logreplay	node-1 	4:S:master1:master:worker:master	5	SITEA	syncmem	SOK	2.00.046.00.1581325702	node-0
node-1	PROMOTED	1693237652	online		logreplay	node-0 	4:P:master1:master:worker:master	150	SITEA	syncmem	PRIM	2.00.046.00.1581325702	node-1

  7. SAP 관리자 계정을 종료한 다음 유지 관리 모드에서 클러스터를 제거합니다.

    sudo pcs property set maintenance-mode=false

  8. Pacemaker 클러스터 리소스가 성공적으로 실행되고 있는지 확인합니다.

시나리오 3, 증상 2: 복제 실패로 인해 SAP HANA가 시작되지 않음

SAP HANA 리소스에서 시작 오류가 발생하며 해당 특성이 hana_xxx_roles 표시됩니다 1:N:master1::worker:. 상태는 N 리소스가 동기화되지 않았으며 독립 실행형 모드에서 실행 중임을 나타냅니다. 데이터베이스 리소스는 노드의 주 리소스나 보조 리소스가 아닙니다.

명령을 node attributes 실행 sudo pcs status --full 하면 상태는 다음과 같이 표시됩니다.

sudo pcs status --full

Node Attributes:
  * Node: node-0 (1):
    * hana_XXX_clone_state            : UNDEFINED
    * hana_XXX_op_mode			          : logreplay
    * hana_XXX_remoteHost             : node-1
    * hana_XXX_roles                  : 1:N:master1::worker:
    * hana_XXX_site                   : SITE1    
    * hana_XXX_srah                   : -        
    * hana_XXX_srmode                 : sync     
    * hana_XXX_version                : 2.00.079.00
    * hana_XXX_vhost                  : node-0
    * lpa_XXX_lpt                     : 10       
  * Node: node-1 (2):
    * hana_XXX_clone_state            : UNDEFINED
    * hana_XXX_op_mode                : logreplay
    * hana_XXX_remoteHost             : node-0
    * hana_XXX_roles                  : 4:N:master1:master:worker:master
    * hana_XXX_site                   : SITE2
    * hana_XXX_sra                    : -        
    * hana_XXX_srah                   : -        
    * hana_XXX_srmode                 : sync     
    * hana_XXX_sync_state		          : PRIM     
    * hana_XXX_version			          : 2.00.079.00
    * hana_XXX_vhost				          : node-1
    * lpa_XXX_lpt				              : 1733552029
    * master-SAPHana_XXX_00		        : 150

이 마이그레이션 요약은 SAP HANA 리소스(SAPHana_XXX_00)가 두 노드(node-0 및 node-1)에서 시작되지 못했음을 나타냅니다. 실패 횟수는 1000000(무한대)으로 설정됩니다.

sudo pcs status

Migration Summary:
  * Node: node-0 (1):
    * SAPHana_XXX_00: migration-threshold=1000000 fail-count=1000000 last-failure='Sat Dec  7 15:17:16 2024'
  * Node: node-1 (2):
    * SAPHana_XXX_00: migration-threshold=1000000 fail-count=1000000 last-failure='Sat Dec  7 15:48:57 2024'

Failed Resource Actions:
  * SAPHana_XXX_00_start_0 on node-1 'not running' (7): call=74, status='complete', last-rc-change='Sat Dec  7 15:17:14 2024', queued=0ms, exec=1715ms
  * SAPHana_XXX_00_start_0 on node-0 'not running' (7): call=30, status='complete', last-rc-change='Sat Dec  7 15:49:12 2024', queued=0ms, exec=1680ms

시나리오 3의 원인, 증상 2

이 문제는 클러스터가 유지 관리 모드에 있는 동안 데이터베이스를 수정(수동으로 중지 또는 시작, 복제 일시 중지 등)하는 경우에 자주 발생합니다.

시나리오 3, 증상 2에 대한 해결 방법

참고

1~5단계는 SAP 관리자가 수행해야 합니다.

  1. 변경하기 전에 백업 또는 스냅샷이 있는지 확인합니다. 자세한 내용은 Azure VM 백업을 참조하세요.

  2. 클러스터를 유지 관리 모드로 전환합니다.

    sudo pcs property set maintenance-mode=true

  3. 주 노드의 클러스터 외부에서 데이터베이스를 수동으로 시작합니다.

    sudo HDB start

  4. 주 노드에서 복제를 시작합니다. 적절하게 대체 <site id> 합니다.

    sudo hdbnsutil -sr_enable --name=<site id>

  5. 보조 노드에서 복제를 초기화합니다. <Instance ##> <side id> 필요에 따라 대체<primary node>합니다.

    sudo hdbnsutil -sr_register --remoteHost=<primary node> --remoteInstance=<Instance ##> --replicationMode=syncmem --name=<site id>

  6. 보조 노드의 클러스터 외부에서 데이터베이스를 수동으로 시작합니다.

    sudo HDB start

  7. 복제가 예상대로 실행되고 있는지 확인합니다. 이렇게 하려면 두 노드에서 다음 명령을 실행합니다.

    sudo hdbnsutil -sr_state

  8. 유지 관리 모드에서 클러스터를 제거합니다.

    sudo pcs property set maintenance-mode=false

  9. SAP HANA 리소스의 실패 횟수를 지웁합니다. SAP Pacemaker 클러스터 설정으로 대체 <SAPHana resource name> 합니다.

    sudo pcs resource cleanup <SAPHana resource name>

이 시나리오에 대한 자세한 내용은 다음 Red Hat 문서를 참조하세요. SAPHana Resource Experiencing Start Failures with hana_xxx_roles Reporting N(독립 실행형)'.

시나리오 3, 증상 3: HDbdaemon 문제로 인해 SAP HANA 리소스가 시작되지 않음

표시된 것처럼 오류 메시지와 함께 SAP HANA 리소스 시작 실패:

'FAIL: process hdbdaemon HDB Daemon not running'

SAP HANA Pacemaker 클러스터 리소스 장애 조치(failover) 오류도 발생하므로 이 sudo pcs status --full 명령을 사용하여 이 오류를 볼 수도 있습니다.

Failed Resource Actions:
  * SAPHana_XXX_00_start_0 on node-0 'error' (1): call=44, status='complete', exitreason='', last-rc-change='2024-07-07 06:15:45 -08:00', queued=0ms, exec=51659ms

시나리오 3의 원인, 증상 3

로그를 검토하면 /var/log/messages 다음 오류로 인해 시작되지 않았음을 나타냅니다 hbddaemon .

Jun  7 02:25:09 node-0 SAPHana(SAPHana_XXX_00)[12336]: ERROR: ACT: SAPHana Instance ECR-HDB00 start failed: #01201.03.2024 02:25:09#012WaitforStarted#012FAIL: process hdbdaemon HDB Daemon not running
Jun  7 02:25:09 node-0 SAPHana(SAPHana_XXX_00)[12336]: INFO: RA ==== end action start_clone with rc=1 (0.154.0) (25s)====
Jun  7 02:25:09 node-0 pacemaker-execd[8567]: notice: SAPHana_XXX_00_start_0[12336] error output [ tput: No value for $TERM and no -T specified ]
Jun  7 02:25:09 node-0 pacemaker-execd[8567]: notice: SAPHana_XXX_00_start_0[12336] error output [ tput: No value for $TERM and no -T specified ]
Jun  7 02:25:09 node-0 pacemaker-execd[8567]: notice: SAPHana_XXX_00_start_0[12336] error output [ tput: No value for $TERM and no -T specified ]
Jun  7 02:25:09 node-0 pacemaker-execd[8567]: notice: SAPHana_XXX_00_start_0[12336] error output [ Error performing operation: No such device or address ]
Jun  7 02:25:09 node-0 pacemaker-controld[8570]: notice: Result of start operation for SAPHana_XXX_00 on node-0: error
Jun  7 02:25:09 node-0 pacemaker-controld[8570]: notice: node-0-SAPHana_XXX_00_start_0:33 [ tput: No value for $TERM and no -T specified\ntput: No value for $TERM and no -T specified\ntput: No value for $TERM and no -T specified\nError performing operation: No such device or address\n ]
Jun  7 02:25:09 node-0 pacemaker-attrd[8568]: notice: Setting fail-count-SAPHana_XXX_00#start_0[node-0]: (unset) -> INFINITY
Jun  7 02:25:09 node-0 pacemaker-attrd[8568]: notice: Setting last-failure-SAPHana_XXX_00#start_0[node-0]: (unset) -> 1709288709

시나리오 3, 증상 3에 대한 해결 방법

다음 Red Hat 문서를 참조하세요. SAPHana Resource Start Failure with Error 'FAIL: process hdbdaemon HDB Daemon not running'.

시나리오 4: ASCS 및 ERS 리소스에 영향을 주는 문제

시나리오 4의 증상

ASCS 및 ERS 인스턴스는 클러스터 제어에서 시작할 수 없습니다. 로그는 /var/log/messages 다음 오류를 나타냅니다.

Jun  9 23:29:16 nodeci SAPRh2_10[340480]: Unable to change to Directory /usr/sap/RH2/ERS10/work. (Error 2 No such file or directory) [ntservsserver.cpp 3845]
Jun  9 23:29:16 nodeci SAPRH2_00[340486]: Unable to change to Directory /usr/sap/Rh2/ASCS00/work. (Error 2 No such file or directory) [ntservsserver.cpp 3845]

시나리오 4의 원인

잘못된 InstanceName 특성으로 START_PROFILE 인해 ASCS 및 ERS와 같은 SAP 인스턴스가 클러스터 제어에서 시작되지 않았습니다.

시나리오 4에 대한 해결 방법

참고

이 해결 방법은 별도의 파일인 START_PROFILE 경우 InstanceName 적용할 수 있습니다.

  1. 변경하기 전에 백업 또는 스냅샷이 있는지 확인합니다. 자세한 내용은 Azure VM 백업을 참조하세요.

  2. 클러스터를 유지 관리 모드로 전환합니다.

    sudo pcs property set maintenance-mode=true

  3. 파일에서 pf(profile) 경로를 확인합니다./usr/sap/sapservices

    sudo cat /usr/sap/sapservices

    LD_LIBRARY_PATH=/usr/sap/RH2/ASCS00/exe:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH;/usr/sap/RH2/ASCS00/exe/sapstartsrv pf=/usr/sap/RH2/SYS/profile/START_ASCS00_nodeci -D -u rh2adm
LD_LIBRARY_PATH=/usr/sap/RH2/ERS10/exe:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH;/usr/sap/RH2/ERS10/exe/sapstartsrv pf=/usr/sap/RH2/ERS10/profile/START_ERS10_nodersvi -D -u rh2adm

  4. 클러스터 구성 리소스 에이전트의 InstanceNameSAPInstance 특성 값과 START_PROFILE 특성을 수정합니다.

    예:

    sudo pcs resource update ASCS_RH2_ASCS00 InstanceName=RH2_ASCS00_nodeci START_PROFILE=/usr/sap/RH2/SYS/profile/START_ASCS00_nodeci

    RH2_ASCS00_nodeci 및 /usr/sap/RH2/SYS/profile/START_ASCS00_nodeci을 해당 값으로 바꿉니다.

    sudo pcs resource update ERS_RH2_ERS10 InstanceName=RH2_ERS10_nodersvi START_PROFILE=/usr/sap/RH2/ERS10/profile/START_ERS10_nodersvi

    RH2_ERS10_nodersvi 및 /usr/sap/RH2/ERS10/profile/START_ERS10_nodersvi을 해당 값으로 바꿉니다.

  5. 유지 관리 모드에서 클러스터를 제거합니다.

    sudo pcs property set maintenance-mode=false

시나리오 5: 펜스 노드가 클러스터에 다시 가입되지 않음

시나리오 5의 증상

펜싱 작업이 완료되면 영향을 받는 노드는 일반적으로 Pacemaker 클러스터에 다시 가입되지 않으며, 수동으로 클러스터를 온라인으로 복원하기 시작하지 않는 한 Pacemaker 및 Corosync 서비스가 모두 중지된 상태로 유지됩니다.

시나리오 5의 원인

노드가 펜스로 연결되고 다시 시작되고 클러스터 서비스를 다시 시작한 후에는 다음과 같은 We were allegedly just fenced메시지가 표시됩니다. 이로 인해 Pacemaker 및 Corosync 서비스가 종료되고 클러스터가 시작되지 않습니다. Node1은 node2에 대해 STONITH 작업을 시작합니다. 에서 03:27:23네트워크 문제가 해결되면 node2는 Corosync 멤버 자격을 다시 연결합니다. 따라서 node1에 표시된 /var/log/messages 것처럼 새 2노드 멤버 자격이 설정됩니다.

Feb 20 03:26:56 node1 corosync[1722]:  [TOTEM ] A processor failed, forming new configuration.
Feb 20 03:27:23 node1 corosync[1722]:  [TOTEM ] A new membership (1.116f4) was formed. Members left: 2
Feb 20 03:27:24 node1 corosync[1722]:  [QUORUM] Members[1]: 1
...
Feb 20 03:27:24 node1 pacemaker-schedulerd[1739]: warning: Cluster node node2 will be fenced: peer is no longer part of the cluster
...
Feb 20 03:27:24 node1 pacemaker-fenced[1736]: notice: Delaying 'reboot' action targeting node2 using  for 20s
Feb 20 03:27:25 node1 corosync[1722]:  [TOTEM ] A new membership (1.116f8) was formed. Members joined: 2
Feb 20 03:27:25 node1 corosync[1722]:  [QUORUM] Members[2]: 1 2
Feb 20 03:27:25 node1 corosync[1722]:  [MAIN  ] Completed service synchronization, ready to provide service.

Node1은 node2에 표시된 /var/log/messages 것처럼 node2가 성공적으로 다시 시작되었다는 확인을 받았습니다.

Feb 20 03:27:46 node1 pacemaker-fenced[1736]: notice: Operation 'reboot' [43895] (call 28 from pacemaker-controld.1740) targeting node2 using xvm2 returned 0 (OK)

STONITH 작업을 완전히 완료하려면 시스템에서 모든 노드에 확인 메시지를 전달해야 했습니다. node2가 그룹에 03:27:25 다시 가입했고, 토큰 및 합의 시간 제한이 만료되지 않아 node2에서 제외된 새 멤버 자격이 아직 형성되지 않았기 때문에 시작 후 node2가 클러스터 서비스를 다시 시작할 때까지 확인 메시지가 지연됩니다. 메시지를 받으면 node2는 해당 메시지가 펜스된 것을 인식하고 결과적으로 다음과 같이 해당 서비스를 종료합니다.

/var/log/messages node1:

Feb 20 03:29:02 node1 corosync[1722]:  [TOTEM ] A processor failed, forming new configuration.
Feb 20 03:29:10 node1 corosync[1722]:  [TOTEM ] A new membership (1.116fc) was formed. Members joined: 2 left: 2
Feb 20 03:29:10 node1 corosync[1722]:  [QUORUM] Members[2]: 1 2
Feb 20 03:29:10 node1 pacemaker-fenced[1736]: notice: Operation 'reboot' targeting node2 by node1 for pacemaker-controld.1740@node1: OK
Feb 20 03:29:10 node1 pacemaker-controld[1740]: notice: Peer node2 was terminated (reboot) by node1 on behalf of pacemaker-controld.1740: OK
...
Feb 20 03:29:11 node1 corosync[1722]:  [CFG   ] Node 2 was shut down by sysadmin
Feb 20 03:29:11 node1 corosync[1722]:  [TOTEM ] A new membership (1.11700) was formed. Members left: 2
Feb 20 03:29:11 node1 corosync[1722]:  [QUORUM] Members[1]: 1
Feb 20 03:29:11 node1 corosync[1722]:  [MAIN  ] Completed service synchronization, ready to provide service.

/var/log/messages in node2:

Feb 20 03:29:11 [1155] node2 corosync notice  [TOTEM ] A new membership (1.116fc) was formed. Members joined: 1
Feb 20 03:29:11 [1155] node2 corosync notice  [QUORUM] Members[2]: 1 2
Feb 20 03:29:09 node2 pacemaker-controld  [1323] (tengine_stonith_notify)  crit: We were allegedly just fenced by node1 for node1!

시나리오 5에 대한 해결 방법

Crosync 서비스에 대한 시작 지연을 구성합니다. 이 일시 중지는 새 CPG(Closed Process Group) 멤버 자격을 구성하고 펜스 노드를 제외할 수 있는 충분한 시간을 제공하므로 완료 메시지가 멤버 자격의 모든 노드에 도달하도록 하여 STONITH 다시 시작 프로세스를 완료할 수 있습니다.

이 효과를 얻으려면 다음 명령을 실행합니다.

  1. 클러스터를 유지 관리 모드로 전환합니다.

    sudo pcs property set maintenance-mode=true

  2. 클러스터의 모든 노드에 시스템화된 드롭인 파일을 만듭니다.

  • Corosync 파일을 편집합니다. 
    sudo systemctl edit corosync.service
  • 다음 줄을 추가합니다. 
    [Service]
ExecStartPre=/bin/sleep 60
  • 파일을 저장하고 텍스트 편집기를 종료한 후 시스템 관리자 구성을 다시 로드합니다. 
    sudo systemctl daemon-reload
  1. 유지 관리 모드에서 클러스터를 제거합니다.
sudo pcs property set maintenance-mode=false

자세한 내용은 수동 개입 없이 펜스 노드가 클러스터에 다시 가입하지 못하는 경우를 참조 하세요.

다음 단계

추가 도움말을 보려면 다음 지침을 사용하여 지원 요청을 엽니다. 요청을 제출할 때 문제 해결을 위해 클러스터의 모든 노드에서 SOS 보고서를 첨부합니다.

도움을 요청하십시오.

질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.

타사 정보 고지 사항

이 문서에 나와 있는 다른 공급업체 제품은 Microsoft와 무관한 회사에서 제조한 것입니다. Microsoft는 이들 제품의 성능이나 안정성에 관하여 명시적이든 묵시적이든 어떠한 보증도 하지 않습니다.