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

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

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Symptoms

СОБЫТИЕ Вы
получили уведомление о событии, указывающее на то, что один или несколько узлов восстановлены после сбоя. Информация о сбое записывается в файл, расположенный в папке /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

Cause

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

Resolution

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

*Для поиска и устранения неисправностей установите соединение 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

Additional Information

Примечание.
  • Это новое уведомление о событии включено в состав накопительных исправлений для 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'

Affected Products

PowerScale OneFS

Products

Isilon
Article Properties
Article Number: 000184828
Article Type: Solution
Last Modified: 18 Sept 2025
Version:  15
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.