HACMP и странное выключение ноды при FC failover

Главная Форумы High Availability PowerHA (HACMP) HACMP и странное выключение ноды при FC failover

Просмотр 3 веток ответов
  • Автор
    Сообщения
    • #17544
      terminus
      Участник

      Добрый день товарищи.

      Есть HACMP кластер из двух LPAR на разных серверах. Версия AIX 6100-06-05-1115, версия HACMP 6.1.0 SP5.

      Инфраструктура SAN и Ethernet продублированы. SAN построен на NPIV через два VIOS (внутри каждой AIX LPAR установлен SDDPCM). Сеть построена на дублированом SEA через два VIOS.

      В прошлый раз пропадало электричество в дата центре и выключался один FC и один Ethernet свитч. Все остальные LPAR с AIX и Suse Linux пережили это выключение без проблем, но вот две ноды с HACMP отреагировали странно.

      В HACMP используется две concurent VG – одна с данными, а вторая как heartbeat hdisk для кластера.

      В момент когда произошло выключение питания, кластер на активной ноде самоубился, форсировано отмонтировал все VG и выключил LPAR после чего группа ресурсов была перенята оставшемся участником (выдержка из лога AIX на сбойнувшей ноде):

      1) propal fc link cherez vios nr2:

      LABEL: FCP_ERR12
      IDENTIFIER: 26623394

      Date/Time: Sun Jan 6 01:25:58 GMT+02:00 2013
      Sequence Number: 5126
      Machine Id:
      Node Id: node02
      Class: H
      Type: TEMP
      WPAR: Global
      Resource Name: fscsi1
      Resource Class:
      Resource Type:
      Location:

      Description
      COMMUNICATION PROTOCOL ERROR

      Recommended Actions
      PERFORM PROBLEM DETERMINATION PROCEDURES

      2) upal NIM hb servis cherez en1

      LABEL: TS_NIM_ERROR_STUCK_
      IDENTIFIER: 3D32B80D

      Date/Time: Sun Jan 6 01:26:09 GMT+02:00 2013
      Sequence Number: 5127
      Machine Id:
      Node Id: node02
      Class: S
      Type: PERM
      WPAR: Global
      Resource Name: topsvcs

      Description
      NIM thread blocked

      Probable Causes
      A thread in a Topology Services Network Interface Module (NIM) process
      was blocked
      Topology Services NIM process cannot get timely access to CPU
      The system clock was set forward

      User Causes
      Excessive memory consumption is causing high memory contention
      Excessive disk I/O is causing high memory contention
      The system clock was manually set forward

      Recommended Actions
      Examine I/O and memory activity on the system
      Reduce load on the system
      Tune virtual memory parameters
      Call IBM Service if problem persists

      Failure Causes
      Excessive virtual memory activity prevents NIM from making progress
      Excessive disk I/O traffic is interfering with paging I/O

      Recommended Actions
      Examine I/O and memory activity on the system
      Reduce load on the system
      Tune virtual memory parameters
      Call IBM Service if problem persists

      Detail Data
      DETECTING MODULE
      rsct,nim_control.C,1.39.1.41,7916
      ERROR ID
      6BUfAx.FO9uE/RZL/F.6e.1……………….
      REFERENCE CODE

      Thread which was blocked
      netmon thread
      Interval in seconds during which process was blocked
      50
      Interface name
      en1

      3) upal GSD:

      LABEL: GS_XSTALE_PRCLM_ER
      IDENTIFIER: 657D8FFA

      Date/Time: Sun Jan 6 01:26:09 GMT+02:00 2013
      Sequence Number: 5128
      Machine Id:
      Node Id: node02
      Class: O
      Type: PERM
      WPAR: Global
      Resource Name: grpsvcs

      Description
      Group Services daemon exit to re-join the domain

      Probable Causes
      Topology Services daemon reports inconsistent node down and up events

      Failure Causes
      Network has been a temporal problem

      Recommended Actions
      Verify that Group Services daemon has been restarted
      Call IBM Service if problem persists

      Detail Data
      DETECTING MODULE
      RSCT,NsMsg.C,1.81,1099
      ERROR ID
      6uzMTZ/FO9uE/W4U/F.6e.1……………….
      REFERENCE CODE

      DIAGNOSTIC EXPLANATION
      Got a non-stale Proclaim message from my NS(domId=3.9). He must have deleted me, so I’m exiting to c

      4) stali otkluchatsa VolumeGruppi i failovie sistemi:

      LABEL: LVM_GS_CONNECTIVITY
      IDENTIFIER: DB14100E

      Date/Time: Sun Jan 6 01:26:09 GMT+02:00 2013
      Sequence Number: 5129
      Machine Id:
      Node Id: node02
      Class: U
      Type: PERM
      WPAR: Global
      Resource Name: LIBLVM
      Resource Class: NONE
      Resource Type: NONE
      Location:

      Description
      Group Services detected a failure

      Probable Causes
      Unable to establish communication with Cluster daemons

      Failure Causes
      Concurrent Volume Group forced offline

      Recommended Actions
      CHECK ERROR LOG FOR ADDITIONAL RELATED ENTRIES
      IF PROBLEM PERSISTS, CONTACT APPROPRIATE SERVICE REPRESENTATIVE

      Detail Data
      Volume Group ID
      00F6 CB76 0000 4C00 0000 0132 7220 F71A
      MAJOR/MINOR DEVICE NUMBER
      0023 0000
      SENSE DATA
      0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

      4.1)

      LABEL: LVM_SA_QUORCLOSE
      IDENTIFIER: CAD234BE

      Date/Time: Sun Jan 6 01:26:09 GMT+02:00 2013
      Sequence Number: 5130
      Machine Id:
      Node Id: node02
      Class: H
      Type: UNKN
      WPAR: Global
      Resource Name: LVDD
      Resource Class: NONE
      Resource Type: NONE
      Location:

      Description
      QUORUM LOST, VOLUME GROUP CLOSING

      Probable Causes
      PHYSICAL VOLUME UNAVAILABLE

      Detail Data
      MAJOR/MINOR DEVICE NUMBER
      8000 0023 0000 0000
      QUORUM COUNT
      2
      ACTIVE COUNT
      65535
      SENSE DATA
      0000 0000 0000 09F5 00F6 CB76 0000 4C00 0000 0132 7220 F71A 00F6 CB76 7220 F6EE

      4.2)

      LABEL: TS_STOP_ST
      IDENTIFIER: 6D19271E

      Date/Time: Sun Jan 6 01:26:11 GMT+02:00 2013
      Sequence Number: 5166
      Machine Id:
      Node Id: node02
      Class: O
      Type: INFO
      WPAR: Global
      Resource Name: topsvcs

      Description
      Topology Services daemon stopped

      Probable Causes
      Daemon stopped by SRC
      Daemon stopped by signal

      User Causes
      Daemon stopped by user

      Recommended Actions
      Confirm that this is desirable

      Detail Data
      DETECTING MODULE
      rsct,comm.C,1.156,690
      ERROR ID
      6SQG4h/HO9uE/FzP.F.6e.1……………….
      REFERENCE CODE
      6UpNEL07sstE/5GJ1F.6e.1……………….
      Topology Services daemon stopped by:
      Signal SIGTERM

      4.3) poslednee soobshenie

      LABEL: J2_USERDATA_EIO
      IDENTIFIER: EA88F829

      Date/Time: Sun Jan 6 01:26:11 GMT+02:00 2013
      Sequence Number: 5171
      Machine Id:
      Node Id: node02
      Class: O
      Type: INFO
      WPAR: Global
      Resource Name: SYSJ2

      Description
      USER DATA I/O ERROR

      Probable Causes
      ADAPTER HARDWARE OR MICROCODE
      DISK DRIVE HARDWARE OR MICROCODE
      SOFTWARE DEVICE DRIVER
      STORAGE CABLE LOOSE, DEFECTIVE, OR UNTERMINATED

      Recommended Actions
      CHECK CABLES AND THEIR CONNECTIONS
      INSTALL LATEST ADAPTER AND DRIVE MICROCODE
      INSTALL LATEST STORAGE DEVICE DRIVERS
      IF PROBLEM PERSISTS, CONTACT APPROPRIATE SERVICE REPRESENTATIVE

      Detail Data
      JFS2 MAJOR/MINOR DEVICE NUMBER
      0022 0002
      FILE SYSTEM DEVICE AND MOUNT POINT
      /dev/oracle-u01-LV, /u01

      У кого-нибудь было что-то похожее? 🙁

    • #17547
      andrewk
      Участник

      кластер не смог достучаться до HB-диска, посчитал, что он отвалился, и отвалился сам в свою очередь. проверьте, что у Вас HB-диск действительно виден по двум путям. будет возможность – попробуйте вручную “убить” первый путь и посмотреть, работает ли диск нормально через второй. кроме этого (из области слухов) – некоторые таймауты в драйвере VFC составляют до 70 сек.

    • #17550
      terminus
      Участник

      hb hdisk доступен через несколько путей.

      [code]
      node01

      # lspv
      hdisk3 00f6cb768553xxxx rootvg active
      hdisk1 00f6cb767220yyyy HB-vm01-vm02-VG concurrent
      hdisk2 00f6cb76ff19zzzz oracle-u01-VG concurrent

      # pcmpath query device 1

      DEV#: 1 DEVICE NAME: hdisk1 TYPE: 2145 ALGORITHM: Load Balance
      SERIAL: xxxxx76802848117C000000000000005
      ==========================================================================
      Path# Adapter/Path Name State Mode Select Errors
      0* fscsi0/path0 OPEN NORMAL 49 0
      1 fscsi0/path1 OPEN NORMAL 170454 1
      2* fscsi1/path2 OPEN NORMAL 63 0
      3 fscsi1/path3 OPEN NORMAL 169403 3

      # lspath -l hdisk1
      Enabled hdisk1 fscsi0
      Enabled hdisk1 fscsi0
      Enabled hdisk1 fscsi1
      Enabled hdisk1 fscsi1

      node02

      # lspv
      hdisk3 00f6cb777653xxxx rootvg active
      hdisk1 00f6cb767220yyyy HB-vm01-vm02-VG concurrent
      hdisk2 00f6cb76ff19zzzz oracle-u01-VG concurrent

      # pcmpath query device 1

      DEV#: 1 DEVICE NAME: hdisk1 TYPE: 2145 ALGORITHM: Load Balance
      SERIAL: xxxxx76802848117C000000000000005
      ==========================================================================
      Path# Adapter/Path Name State Mode Select Errors
      0* fscsi0/path0 OPEN NORMAL 14 0
      1 fscsi0/path1 OPEN NORMAL 79935 0
      2* fscsi1/path2 OPEN NORMAL 21 0
      3 fscsi1/path3 OPEN NORMAL 79888 1

      # lspath -l hdisk1
      Enabled hdisk1 fscsi0
      Enabled hdisk1 fscsi0
      Enabled hdisk1 fscsi1
      Enabled hdisk1 fscsi1

      [/code]

      как-нибудь потом попытаюсь сделать failover еще раз (не могу сейчас эксперементировать на продукции)

      Что интересно – когда мы только-только ввели дублированный FC, мы проверяли как HACMP будет обрабатывать ситуацию failover FC и во время тестов все происходило без проблем. А в этот раз, получается, наложилась недоступность как FC так и Ethernet…

      вот параметры hb диска:
      [code]# lsattr -El hdisk1
      PCM PCM/friend/sddpcm PCM True
      PR_key_value none Reserve Key True
      algorithm load_balance Algorithm True
      clr_q no Device CLEARS its Queue on error True
      dist_err_pcnt 0 Distributed Error Percentage True
      dist_tw_width 50 Distributed Error Sample Time True
      flashcpy_tgtvol no Flashcopy Target Lun False
      hcheck_interval 60 Health Check Interval True
      hcheck_mode nonactive Health Check Mode True
      location Location Label True
      lun_id 0x1000000000000 Logical Unit Number ID False
      lun_reset_spt yes Support SCSI LUN reset True
      max_coalesce 0x40000 Maximum COALESCE size True
      max_transfer 0x40000 Maximum TRANSFER Size True
      node_name 0x5005076802xxxxxx FC Node Name False
      pvid xxxxxx767220f6ee0000000000000000 Physical volume identifier False
      q_err yes Use QERR bit True
      q_type simple Queuing TYPE True
      qfull_dly 2 delay in seconds for SCSI TASK SET FULL True
      queue_depth 20 Queue DEPTH True
      recoverDEDpath no Recover DED Failed Path True
      reserve_policy no_reserve Reserve Policy True
      retry_timeout 120 Retry Timeout True
      rw_timeout 60 READ/WRITE time out value True
      scbsy_dly 20 delay in seconds for SCSI BUSY True
      scsi_id 0x10200 SCSI ID False
      start_timeout 180 START unit time out value True
      timeout_policy fail_path Timeout Policy True
      unique_id yyyyyy005076802848117C00000000000000504214503IBMfcp Device Unique Identification False
      ww_name 0x5005076802yyyyyy FC World Wide Name False
      [/code]

    • #17639
      MIkhail
      Участник

      Вам необходимо полностью проверить конфигурацию топологии кластера, настройки сетевых интерфейсов и параметры netmon.cfg, параметры доступа к дискам массива, возможно если у вас не верный мапинг в NPIV на VIOS, путей в партиции будет два, а смотрят в одну фабрику.
      То что произошло у вас, это пропала сеть и доступ HB дику, HACMP посчитал что нода кончилась и начал реконфигурацию, вам надо смотреть не errpt, а /var/hacmp/log/hacmp.out и множество других файлов в директории /var/hacmp, там вся необходимая информация которой в errpt нет.

Просмотр 3 веток ответов
  • Для ответа в этой теме необходимо авторизоваться.