Андрей

Ответы в темах

Просмотр 18 веток ответов
  • Автор
    Сообщения
    • #10750
      Андрей
      Участник

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

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

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

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

      Тоже сталкивался с подобной проблемой. Попробуйте внимательно поглядеть на таблицу марштрутизации (netstat -C) – возможно проблема кроется там. В моем случае все разрешилось коррекцией шлюза по умолчанию (чтоб находился в одной сетке с целевыми системами) – пинги пошли ровно и без пропусков; можно еще, наверное, явно прописать маршруты.

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

      Вывод cldump или cltopinfo можно увидеть??

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

      Вот!! Что и требовалось доказать..AIX тоже иногда требует перезагрузки 😆

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

      При запуске (перезапуске) системы cfgmgr делается автоматом.

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

      Очень как-то хитро у вас зеркала LV rootvg разнесены по PV rootvg. Проще было бы 2 hdisk-a зеркалировать в другие 2 hdisk-a (к примеру). Я бы по выводу lsvg -M rootvg составил карту размещения по hdisk-ам LV rootvg и их зеркал. Стало бы ясно где и что находится.

      Если есть возможность, можно еще раз перегрузиться..возможно проблема уйдет.

      Можно попробывать, если на hdisk2 нет критичных LV, сделать chpv или chdev (описанный вами выше..только сомнительно, что это даст положительный эффект, раз уж диск пометился как missing). Можно еще попробывать удалить этот диск из rootvg и добавить его потом снова …и синхронизировать rootvg (но это при наличии для находящихся на нем LV – зеркал с других hdisk-ов – опять же проанализировав вывод lsvg -M rootvg).
      Но это все на свой страх и риск. Или подождать других вариантов решения от гуру этого форума.

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

      а еще, если можно lsvg -l rootvg…с зеркалированием rootvg не очень понятно что у вас. И по выводу lsvg -M rootvg можно посмотреть, что у вас на hdisk-ах rootvg находится.

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

      Покажите вывод lsvg rootvg и lsvg -p rootvg…

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

      По поводу одинаковых имен нод есть такое предположение:
      При остановке серверов, не были остановлены приложения и сервисы HACMP, т.е при shutdown-е (скорее всего первой команду дали на апсовой ноде) кластер начал перемещение ресурсных групп. Обычно в скриптах при переезде меняют имя ноды, на которую перемещаются апсы (для их корректной работы). При возвращении группы апсов на домашнюю ноду, в скриптах опять же обратно меняется имя ноды, на которой они были. В данном случае, видимо этого не произошло, т.к. останов был всех разделов (+ с ошибками).
      1) Имя ноды и хоста поменять можно принудительно для начала (командами uname и hostname).
      2) Проверить скрипты для старта/стопа/переезда RG.
      3) Проверить конфигурацию и доступность дисковых ресурсов (что-то там не так с конфигурацией SAN).
      4) Как и написал уже Дмитрий – запустить разделы и, не стартовав HACMP, самостоятельно попытаться активировать VG, смонтировать FS. Посмотреть что получится. Только предварительно проверить где и какие VG должны быть и какие диски видны.
      5) Если все удачно пройдет – проделать то же самое, но с запуском HACMP.

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

      Не совсем понятно что именно не получается и почему (выводы команд приложить было бы неплохо).
      Можно сделать немного по другому.
      1) Создание VG, LV и файловой системы (через SMIT).
      2) Импорт VG на всех узлах кластера, где это необходимо .
      2) Включиь созданную VG в состав требуемой ресурсной группы
      4) Верификация и синхронизация кластера.

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

      ЛСД (ЛСД-25, LSD, нем. Lysergsäurediethylamid) — диэтиламид d-лизергиновой кислоты.

      “…Отдельные психологические эффекты могут заключаться в усиленном восприятии цветов, дышащих или плавающих поверхностей вещей и обстановки (стен, пола, потолка) с переливающимися, ползающими формами, чрезвычайно сложных красочных двигающихся узоров, возникающих за закрытыми глазами, ощущении измененного течения времени, восприятии вещей или лиц людей, видоизменяющих форму, деперсонализации (потеря ощущения собственного «Я»), и иногда весьма интенсивные и жестокие переживания, описываемые как собственное перерождение или испытание смерти…”

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

      Ссылка: https://www.aixportal.ru/component/option,com_fireboard/Itemid,164/func,view/id,629/catid,10/

      В данной ветке форума уже рассматривался подобный вопрос.

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

      Для создания загрузочных бэкапных дисков с последующей записью их в винде нужно создать их в формате ISO. Затем пишите их с помощью Nero Burning ROM (меню: Recorder – Прожечь образ). Все прекрасно запишется и будет работать (при условии, что все сделали правильно :)).

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

      Всё оказалось гораздо проще. Через некоторое время интерфейс (после восстановления физического соединения) поднялся самостоятельно.

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

      Спасибо, Дмитрий.
      Такая мысль тоже была, но кластер продуктовый, не сильно хочется на лету менять конфигурацию.
      Просто была надежда, вдруг есть тайные народные рецепты ))

      Подождем тех.окна и рестарт сервисов сделаем. Должно помочь.
      Линк рабочий. Cвязисты линию проверяли и на модемах адекватная индикация присутствует.

      а логи лежат в /var/ha/log/nim.topsvcs.tty0*

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

      Еще немного о файле протокола ошибок:

      errdemon -s размер-протокола – изменение размера данного файла.

      Указанный максимальный размер файла протокола будет сохранен в базе данных конфигурации протокола ошибок. После этого будет автоматически перезапущен демон ведения протокола ошибок. Если установленное ограничение меньше текущего размера файла протокола, то текущий файл переименовывается путем добавления суффикса .old , после чего создается новый файл с указанным ограничением. Заданный объем памяти резервируется для файла протокола ошибок и недоступен для других файлов. В связи с этим не следует устанавливать очень большое ограничение. Однако если размер протокола будет очень маленьким, то из него преждевременно может быть удалена важная информация. После того как размер файла протокола достигает указанного ограничения, начинается новый цикл записи, то есть самые старые записи заменяются на новые.

      В общем AIX Information Center (в разделе Работа с протоколом ошибок) и man по соответствующим командам.

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

      Более того, если я не ошибаюсь, система удаляет те записи об аппаратных ошибках, которые старше 90 дней. Записи о программных ошибках удаляются через 30 дней.

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

      Такое ощущение, что к машинкам примаплено только по одному LUN -> при попытке varyonvg VG с другого LUN и не происходит ничего.

Просмотр 18 веток ответов