проблемы после Dynamic Reconfiguration


Главная Форумы High Availability PowerHA (HACMP) проблемы после Dynamic Reconfiguration

В этой теме 5 ответов, 2 участника, последнее обновление  Дмитрий 6 года/лет, 11 мес. назад.

  • Автор
    Сообщения
  • #10371

    Андрей
    Участник

    Доброго времени суток!
    Возникла не очень приятная ситуация при проведении некоторых работ по динамической реконфигурации кластера (HACMP 5.4 2 ноды, AIX 5.3 TL11).
    Добавлялась еще одна ресурсная группа в кластер…в итоге clstat показывает — SubState: RECONFIG. При этом при всем…*старые* RG в онлайне и приклад работает. Новая RG так и не появилась.
    Верификация кластера тоже не проходит с сообщениями —

    *cldare: A lock for a Dynamic Reconfiguration event has been detected.
    Another such event cannot be run until the lock has been released.
    If no Dynamic Reconfiguration event is currently taking place, and the
    lock persists, it may be forcefully unlocked via the SMIT HACMP
    Problem Determination Tools,
    Release Locks Set By Dynamic Reconfiguration.
    *
    Попытки скинуть Release Locks Set By Dynamic Reconfiguration ни к чему не приводят…
    Будьте любезны..подтолкните в какую сторону копать дальше

  • #10686

    Дмитрий
    Участник

    Пост, конечно, старый, скорее всего, уже и сами починили (если да — напишите, как)… но вдруг поможет:
    скорее всего, операция прошла с ошибкой — надо смотреть по hacmp.out и cluster.log на ERROR, понять, в чём была ошибка, исправить ситеацию руками, а потом сбросить ошибку (smit hacmp ->problem determination -> reset from error event (название пункта примерно называю)) —> и внимательно следим, что происходит дальше по лог-файлам.

  • #10720

    Андрей
    Участник

    Да, с проблемой уже справились.
    В логах кластера была найдена запись о «зависшем» событии config_too_long и статусе ST_BARRIER.
    Процесс был убит kill-ом и была попытка сбросить ошибку, как и написал уважаемый Дмитрий.
    Правда это не привело к желаемым результатам.
    Обратились в техподдержку IBM. После анализа высланных им данных, инженеры поддержки предложили произвести все те действия которые производились до этого и если не поможет, то перезапустить кластер.
    Что в итоге и было сделано, благо технологическое окно оказалось поблизости 🙂

  • #10742

    Дмитрий
    Участник

    С ST_BARRIER как правило, тяжело бороться. Советую ещё раз изучить логи и посмотреть, какое событие зависло в config_too_long.
    Кстати, на вский случай: config_too_long — это само по себе не ошибка, это признак того, что некое событие «слишком долго (180 сек для быстрых событий и 360 для долгих)» работает (или же «слишком давно» выскочила ошибка event_error).
    Надо «лечить» не config_too_long, а причину зависания.
    (Может это Вы и сами знаете, но вдруг…)

    А исследовать причину надо, чтобы она больше не повторялась, ибо метод «выйти и войти» хорош, но не всегда подходит… 🙂

  • #10750

    Андрей
    Участник

    Да, Дмитрий, Вы безусловно правы. Событие, которое зависло в config_too_long найдено, правда пока не выявлена причина этого. На тестовом кластере подобная операция прошла без проблем. А тут кластер был продуктивный и надо было с ним что-то срочно решать. Спасибо за неравнодушие ))

  • #10764

    Дмитрий
    Участник

    Blackbat, всегда пожалуйста 🙂

    А что это за событие зависло?

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