Событие: Узел восстановился после сбоя. Информация о критической ошибке записывается в файл: var tmp panic

Сводка: В этой статье объясняется, как пользователи и служба технической поддержки должны управлять событием или сообщениями «Node has Recover after a panic». Просмотрите все части статьи, прежде чем действовать. ...

Данная статья применяется к Данная статья не применяется к Эта статья не привязана к какому-либо конкретному продукту. В этой статье указаны не все версии продуктов.

Симптомы

СОБЫТИЕ Вы
получили уведомление о событии, указывающее на то, что один или несколько узлов восстановлены после сбоя. Информация о сбое записывается в файл, расположенный в папке /var/tmp/ на затронутых узлах.
Пример:
4.3394   03/12 18:02 W    4    53125     Node 4 has recovered from a panic. Info about panic is recorded in file: /var/tmp/panic.1615590175

Причина

Точные причины сбоя узла могут отличаться, но типичные причины могут быть следующими.
  • Сбой оборудования
  • Ошибка кода программного обеспечения
  • Неправильная конфигурация
Анализ журналов кластера должен быть выполнен с помощью PowerScale Support для выявления точной причины сбоя.

Разрешение

Чтобы приступить к устранению этой проблемы, сначала убедитесь, что узел восстановился после события сбоя и не находится в выключенном или автономном режиме.

*Для поиска и устранения неисправностей установите соединение SSH с узлом и войдите в систему с помощью учетной записи root.
Выполните следующую команду, чтобы подтвердить повторное присоединение узла к кластеру:
# isi status
Переменная isi status возвращает выходные данные, аналогичные следующим. Если узел успешно присоединен к кластеру, в столбце «Health» не отображается «D» (не работает):
                   Health  Throughput (bps)  HDD Storage      SSD Storage
ID |IP Address     |DASR |  In   Out  Total| Used / Size     |Used / Size
---+---------------+-----+-----+-----+-----+-----------------+-----------------
  1|10.16.141.226  | OK  | 553M| 3.2M| 557M|61.9T/ 106T( 59%)|        L3:  1.5T
  2|10.16.141.227  | OK  | 481M| 96.0| 481M|62.2T/ 106T( 59%)|        L3:  1.5T
  3|10.16.141.228  | OK  | 372k| 332k| 704k|62.3T/ 106T( 59%)|        L3:  1.5T
  4|10.16.141.229  | OK  |10.8M| 941k|11.7M|62.6T/ 106T( 59%)|        L3:  1.5T
  5|10.16.141.230  | OK  | 9.4M| 393k| 9.8M|62.6T/ 106T( 59%)|        L3:  1.5T
  6|10.16.141.231  | OK  | 7.3M|256.0| 7.3M|63.4T/ 106T( 60%)|        L3:  1.5T
---+---------------+-----+-----+-----+-----+-----------------+-----------------
Cluster Totals:          | 1.1G| 4.9M| 1.1G| 375T/ 634T( 59%)|        L3:  8.7T

     Health Fields: D = Down, A = Attention, S = Smartfailed, R = Read-Only
Соберите журналы, выполнив следующую команду, и предоставьте набор журналов в службу технической поддержки Isilon для анализа критической ошибки:
# isi_gather_info -f /var/tmp/
 
Примечание. /var/tmp/ Данные о сбоях не собираются в журнале по умолчанию, необходимо использовать isi_gather_info -f /var/tmp/ для сбора надлежащей информации о сбоях.

После получения журналов служба технической поддержки должна просмотреть и проанализировать сведения о стеке критической ошибки. Они определяют, соответствует ли стек критической ошибки какой-либо известной проблеме или статье базы знаний. Если сведения о стеке критической ошибки не соответствуют известной проблеме или существующей статье базы знаний, проблема передается на рассмотрение для дальнейшей оценки. Служба технической поддержки определяет, какие действия необходимо предпринять, например заменить оборудование, исправить код, обновить микропрограмму или другие меры по устранению рисков.

* Если узел все еще не работает, необходимо выполнить дополнительные действия по поиску и устранению неисправностей, чтобы вернуть узел в режим онлайн. Если вам требуется помощь, обратитесь в службу технической поддержки Isilon.

Подробнее см. в статье 55936: Isilon OneFS. Оповещение о событии: Узел в автономном режиме - Идентификатор события: 200010001, 300010003, 399990001, 900160001, 910100006, 400150007

Дополнительная информация

Примечание.
  • Это новое уведомление о событии включено в состав накопительных исправлений для OneFS v8.1.2.0, v8.2.2.0 и v9.1.0.5 за март 2021 г. Кластеры с версиями OneFS до накопительного исправления (RUP) за март 2021 г. не отправляют это уведомление о событии.
  • Эта функция включена в OneFS 9.2, 9.3, 9.4 и более поздних версиях.
  • Обновление инициирует событие, если OneFS обнаруживает перезагрузку из-за сбоя узла.
  • Это событие может включать в себя базовую информацию, например заголовки дампа ядра, которая поможет понять и устранить проблему.
  • Результирующая сервисная заявка домашнего вызова может включать дополнительную информацию в читаемом формате для сортировки и анализа.

Примечание. Эта функция может вызывать ложные оповещения из-за событий сбоя, ядер или минидампов, которые могут находиться в кластере до установки RUP за март 2021 г. OneFS может продолжать оповещать о старых файлах со сбоями, пока не будет удалена. Чтобы избежать ложных оповещений, выполните следующие действия.
  1. Очистите журнал сообщений, выполнив принудительную ротацию журналов. Эта функция не проверяет наличие информации о сбоях в ротируемых журналах в архиве gz, таких как messages.0.gz, messages.1.gz и т. д. Выполните следующую команду, чтобы выполнить ротацию /var/log/messages при обнаружении любых сбоев:
isi_for_array 'grep "panic @ time" /var/log/messages && newsyslog -F /var/log/messages'.
  1. Проверьте файл /var/crash каталог каждого узла для любого файла ядра или минидампа. Удалите или создайте резервную копию этих файлов после получения одобрения.
  2. Выполните следующую команду для очистки vmcore Файлы, расположенные в каталоге /var/crash на всех узлах.
isi_for_array 'find /var/crash/ -name "vmcore*" -delete'

Затронутые продукты

PowerScale OneFS

Продукты

Isilon
Свойства статьи
Номер статьи: 000184828
Тип статьи: Solution
Последнее изменение: 18 Sep 2025
Версия:  15
Получите ответы на свои вопросы от других пользователей Dell
Услуги технической поддержки
Проверьте, распространяются ли на ваше устройство услуги технической поддержки.