Поделиться через

Устранение неполадок при запуске для служб кластеров Pacemaker и ресурсов

Область применения: ✔️ виртуальные машины Linux

В этой статье рассматриваются наиболее распространенные причины проблем с запуском в RedHat Enterprise Linux (RHEL) Pacemaker Cluster resources or services, а также приведены рекомендации по выявлению и устранению проблем.

Сценарий 1. Не удается запустить службу кластера из-за кворума

Симптом для сценария 1

  • Узел кластера не присоединяется к кластеру после перезапуска кластера.

  • Узлы сообщаются как UNCLEAN (offline).

  • Текущий контроллер домена сообщается как 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. Чтобы предотвратить сценарии разделения мозга, эта служба может быть при необходимости загружена на узлы кластера corosync. Каждая система в кластере получает определенное количество голосов для достижения этого кворума. Это гарантирует, что действия кластера могут выполняться только в том случае, если большинство голосов приведение. Каждый узел или ни один узел не должен загружать службу. Результаты неопределенны, если служба загружается в подмножество узлов кластера.

/etc/corosync/corosync.conf Следующий параметр включает службу VoteQuorum в corosync:

quorum {
    provider: corosync_votequorum
}

VoteQuorum считывает конфигурацию./etc/corosync/corosync.conf Некоторые значения можно изменить во время выполнения, а другие — только при запуске corosync. Важно, чтобы эти значения согласованы во всех узлах, участвующих в кластере. В противном случае поведение кворума голосования непредсказуемо.

Разрешение для сценария 1

  1. Перед внесением изменений убедитесь, что у вас есть резервная копия или моментальный снимок. Дополнительные сведения см. в разделе Резервное копирование виртуальных машин Azure.

  2. Проверьте отсутствие раздела кворума в /etc/corosync/corosync.conf. Сравните существующий corosync.conf с любой резервной копией, доступной в /etc/corosync/.

  3. Поместите кластер в режим обслуживания:

    sudo pcs property set maintenance-mode=true

  4. Обновите изменения в /etc/corosync/corosync.conf.

    Пример кластера с двумя узлами:

    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. Проблема в ресурсе ВИРТУАЛЬНЫХ IP-адресов кластера

Симптом для сценария 2

Виртуальный IP-ресурс (IPaddr2 ресурс) не запускается или останавливается в Pacemaker.

Войдите в систему /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 ресурс, IPaddr2 вызывает findif() функцию, как определено в /usr/lib/ocf/resource.d/heartbeat/IPaddr2 пакете resource-agents .

  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 не в таблице маршрутизации по умолчанию, можно указать NIC имя в ресурсе Pacemaker, чтобы его можно было настроить для обхода проверки:

  1. Перед внесением изменений убедитесь, что у вас есть резервная копия или моментальный снимок. Дополнительные сведения см. в разделе Резервное копирование виртуальных машин Azure.

  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)

Дополнительные сведения об этом сценарии см. в следующей статье Red Hat: error: [findif] failed(error: findif] failed( Pacemaker).

Сценарий 3. Проблема в SAP HANA (высокопроизводительный аналитический модуль)

Сценарий 3, симптом 1. База данных SAP HANA не запускается и создает неизвестная ошибка

База данных SAP HANA не запускается и возвращает сообщение об ошибке 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 не может запустить ресурс SAP HANA, если между основными и вторичными узлами возникают SYN сбои:

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

Ресурс SAP HANA не может быть запущен Pacemaker, если между основными и вторичными узлами кластера возникают SYN сбои. Чтобы устранить эту проблему, необходимо вручную включить SYN между основными и вторичными узлами.

Внимание

Действия 2, 3 и 4 должны выполняться с помощью учетной записи администратора SAP. Это связано с тем, что эти действия используют идентификатор системы SAP для остановки, запуска и повторного включения репликации вручную.

  1. Перед внесением изменений убедитесь, что у вас есть резервная копия или моментальный снимок. Дополнительные сведения см. в разделе Резервное копирование виртуальных машин Azure.

  2. Поместите кластер в режим обслуживания:

    sudo pcs property set maintenance-mode=true

  3. Проверьте состояние базы данных и процессов SAP HANA:

    a. Убедитесь, что первичные и вторичные узлы выполняют базу данных SAP и связанные процессы SAP. Один должен функционировать как основной узел и другой как вторичный. Это гарантирует, что базы данных на обоих узлах остаются синхронизированными.

    Б. Выполните на 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 не активны на узле, рекомендуется обратиться к администратору SAP, чтобы проверить и остановить службы SAP DB, сначала на вторичном узле, а затем на основном узле:

    sudo HDB stop

    или:

    sudo sapcontrol -nr <SAPInstanceNo> -function stop

    d. После завершения операции остановки запустите базу данных HANA в основном узле, а затем на вторичном узле. Измените <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 указывает, что ресурс не синхронизирован и работает в автономном режиме. Ресурс базы данных не является первичным или вторичным на любом узле.

При выполнении sudo pcs status --full команды node attributes состояние отображается следующим образом:

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.

  2. Поместите кластер в режим обслуживания:

    sudo pcs property set maintenance-mode=true

  3. Вручную запустите базу данных за пределами кластера на основном узле:

    sudo HDB start

  4. Запустите репликацию на основном узле. Замените <site id> соответствующим образом.

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

  5. Инициализация репликации на вторичном узле. Замените <primary node>и <side id><Instance ##> по мере необходимости.

    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. Замените <SAPHana resource name> настройку кластера SAP Pacemaker.

    sudo pcs resource cleanup <SAPHana resource name>

Дополнительные сведения об этом сценарии см. в следующей статье о Red Hat: ресурс SAPHana, в котором возникают сбои запуска с hana_xxx_roles отчетов N (автономная версия)".

Сценарий 3, симптом 3. Ресурс SAP HANA не запускается из-за проблем с hdbdaemon

Сбой запуска ресурсов SAP HANA с сообщением об ошибке, как показано ниже.

'FAIL: process hdbdaemon HDB Daemon not running'

Команда sudo pcs status --full также может использоваться для просмотра этой ошибки, так как она также привела к ошибке отработки отказа ресурсов кластера SAP HANA Pacemaker.

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 с ошибкой "FAIL: процесс hdbdaemon HDB Daemon не запущен".

Сценарий 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 атрибутов экземпляры SAP, такие как ASCS и ERS, не запускались под управлением кластера.

Разрешение для сценария 4

Примечание.

Это разрешение применимо, если InstanceName и START_PROFILE являются отдельными файлами.

  1. Перед внесением изменений убедитесь, что у вас есть резервная копия или моментальный снимок. Дополнительные сведения см. в разделе Резервное копирование виртуальных машин Azure.

  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. InstanceName Исправьте значения и START_PROFILE атрибуты в агенте SAPInstance ресурсов конфигурации кластера.

    Пример:

    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 инициирует действие STONITH против node2. При 03:27:23устранении проблемы с сетью узел 2 повторно присоединитесь к членству Corosync. Следовательно, устанавливается новое членство в двух узлах, как показано в /var/log/messages node1:

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, еще было сформировано из-за истечения срока действия маркера и времени ожидания консенсуса, сообщение подтверждения задерживается до тех пор, пока узел 2 не перезагрузит свои службы кластера после запуска. После получения сообщения 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 в узле 2:

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), чтобы исключить заборированный узел, чтобы процесс перезапуска STONITH был завершен, убедившись, что сообщение завершения достигает всех узлов в членстве.

Чтобы добиться этого эффекта, выполните следующие команды:

  1. Поместите кластер в режим обслуживания:

    sudo pcs property set maintenance-mode=true

  2. Создайте системный файл раскрывающегося списка на всех узлах в кластере:

  • Измените файл Corosync: 
    sudo systemctl edit corosync.service
  • Добавьте следующие строки: 
    [Service]
ExecStartPre=/bin/sleep 60
  • После сохранения файла и выхода из текстового редактора перезагрузите конфигурацию systemd manager: 
    sudo systemctl daemon-reload
  1. Удалите кластер из режима обслуживания:
sudo pcs property set maintenance-mode=false

Дополнительные сведения см. в разделе "Заборированный узел", не выполняя повторное присоединение кластера без ручного вмешательства.

Следующие шаги

Для получения дополнительной справки откройте запрос на поддержку, выполнив следующие инструкции. При отправке запроса подключите отчет SOS со всех узлов в кластере для устранения неполадок.

Свяжитесь с нами для получения помощи

Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.

Заявление об отказе от ответственности за сведения о продуктах сторонних производителей

В этой статье упомянуты программные продукты независимых производителей. Корпорация Майкрософт не дает никаких гарантий, подразумеваемых и прочих, относительно производительности и надежности этих продуктов.