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

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

Просмотр 5 веток ответов
  • Автор
    Сообщения
    • #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, всегда пожалуйста 🙂

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

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