Подія: Вузол оговтався від паніки. Інформація про паніку записана у файл: var tmp panic

Summary: У цій статті пояснюється, як користувачі та технічна підтримка повинні керувати подіями або повідомленнями «Вузол відновився після паніки». Перегляньте всі частини статті, перш ніж діяти. ...

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 для точної причини паніки.

Resolution

Щоб розпочати усунення неполадок, спочатку переконайтеся, що вузол відновився після панічної події та не не працює та не відключений.

*Щоб усунути неполадки, відкрийте SSH-з'єднання з вузлом і увійдіть за допомогою облікового запису "root".
Виконайте наступну команду, щоб підтвердити, що вузол знову приєднався до кластера: 
# isi status
Об'єкт isi status команда повертає виведені дані, подібні до наведених нижче. Якщо вузол успішно приєднався до кластера, у стовпці «Здоров'я» не відображається «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/ для збору належної інформації про паніку.

Після отримання журналів технічна підтримка має переглянути та проаналізувати деталі Panic Stack. Вони визначають, чи відповідає панічний стек будь-якій відомій проблемі або статті в базі знань. Якщо деталі Panic Stack не збігаються з відомою проблемою або наявною статтею бази знань, проблема передається для подальшої оцінки. Технічна підтримка визначає, які дії потрібні, такі як заміна обладнання, виправлення коду, оновлення прошивки або інші заходи щодо пом'якшення наслідків.

* Якщо вузол все ще не працює, необхідно виконати додаткове усунення несправностей, щоб повернути вузол в мережу. Зверніться до служби технічної підтримки Isilon, якщо вам потрібна допомога.

Більш детальну інформацію можна знайти в статті 55936: Ісілон OneFS: Повідомлення про подію: Вузол в автономному режимі - ідентифікатор події: 200010001, 300010003, 399990001, 900160001, 910100006, 400150007

Additional Information

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

Примітка: Ця функція може спричиняти хибні тривоги через попередні панічні події, ядра або мінідампи, які можуть бути на кластері до встановлення 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 каталог кожного вузла для будь-якого файлу core або minidumps. Видаліть або створіть резервну копію після отримання схвалення.
  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.