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


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

В этой теме 3 ответа, 3 участника, последнее обновление  MIkhail 4 года/лет, 11 мес. назад.

  • Автор
    Сообщения
  • #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 нет.

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