null

Первичная диагностика событий FMD-8000-0W наблюдаемых на CoolThreads-системах Sun.

Цель данной статьи -  краткое описание процедуры самостоятельной первичной диагностики  FMA сообщений типа FMD-8000-0W, часто встречающихся в последнее время при эксплуатации серверов семейства CoolThreads, и вызывающих большое количество вопросов у пользователей.

В первую очередь рассмотрим, что представляет собой  FMA и какие основные функции выполняет.
Среда FMA (Fault Management Architecture), являющаяся частью ОС начиная с Solaris 10, предназначена для автоматического обнаружения
аппаратных и программных сбоев/неисправностей, их регистрации и проведения каких-либо упреждающих действий с целью возможности продолжения работы всей системы в целом. Последнее свойство FMA определяет то, почему в некоторой документации можно увидеть альтернативное название FMA - PSH (Predictive Self Healing, дословно  "предиктивное самоизлечение"). Анализ результатов FMA-диагностики имеет немаловажную роль при поиске возможной неисправности в системе или причины сбоя в большинстве случаев.

Сервис FMA в общем случае имеет модульную структуру,  при этом каждый модуль  представляет собой отдельную единицу выполняющую свою ограниченную роль в диагностике конкретного элемента системы. Данное свойство позволяет использовать FMA в различных платформах начиная от рабочих станции до серверов High-End класса, меняя лишь состав модулей и, соответственно, состав DE (Diagnosis Engine). В частности FMA нашло широкое применение и в линейке серверов Sun Fire 12K-25K, как дополнительное средство самодиагностики, и в линейке OPL-серверов M3000-M9000 как основное средство. В CoolThreads-системах представленных моделями Sun Fire T1000/T2000 и Sun Fire T5120/5220/5140/5240/5440 реализация FMA достаточно простая и стандартная для серверов начального уровня, однако имеет свои особенности с точки зрения анализа результатов этой "самодиагностики".  Как известно,  FMA  имеет два  собственных накопительных лога расположенных в /var/fm/fmd,  errlog и fltlog - ошибки накопленные в процессе эксплуатации системы и история продиагностированных сбоев, при этом уведомления о последних попадают в /var/adm/messages. Так как логи хранятся в бинарном виде, то для их просмотра  используются стандартные FMA-утилиты, такие как  fmadm и fmdump c набором подкоманд/ключей для получения нужного вывода :  

- fmadm
            faulty - текущие активные сбои
            config - текущая конфигурация загруженных модулей
- fmdump
        без параметров - вывод содержимого fltlog
    -v(-V) - детализация вывода
    -e -  вывод содержимого errlog вместо fltlog
        -u  - вывод только для конкретного UUID (Universal Unique Identifier) сбоя   


В первую очередь определим - с чего необходимо начать при проведении диагностики с помощью FMA.

Как уже ранее упоминалось, любое событие о автоматически  продиагностированном сбое отражается в системных логах ОС Solaris в /var/adm/messages и обычно имеет примерно следующей вид:
 
SUNW-MSG-ID: FMD-8000-0W, TYPE: Defect, VER: 1, SEVERITY: Minor
EVENT-TIME: Thu Feb 26 13:56:58 EDT 2010
PLATFORM: SUNW,SPARC-Enterprise-T5220, CSN: -, HOSTNAME: tr46-79
SOURCE: fmd-self-diagnosis, REV: 1.0
EVENT-ID: 80cc52e1-42ec-68ad-81de-aa8c30d006f5
DESC: The Solaris Fault Manager received an event from a component to which no
automated diagnosis software is currently subscribed.  Refer to
http://sun.com/msg/FMD-8000-0W for more information.
AUTO-RESPONSE: Error reports from the component will be logged for examination
by Sun. IMPACT: Automated diagnosis and response for these events will not
occur. REC-ACTION: Run pkgchk -n SUNWfmd to ensure that fault management
software is installed properly.  Contact Sun for support.

Что необходимо выделить из данного сообщения ? Во-первых - идентификатор события SUNW-MSG-ID, в данном примере его значение FMD-8000-0W. Во - вторых поле DESC, где можно найти краткое описание события со ссылкой на более подробную статью, доступную по ссылке http://sun.com/msg/SUNW-MSG-ID, в-третьих поле REC-ACTION, где можно почерпнуть соответствующие событию рекомендации.
Дальнейшие шаги по диагностике заключаются в более глубоком изучении проблемы при помощи вышеназванных FMA-утилит fmadm и fmdump.

Собственно, указанное в качестве примера событие FMD-8000-0W явлется одним из наиболее распространенных.  Данное событие может логироваться как единичный случай, так и в "комплекте" с  событиями другого типа. Согласно полю DESC - данное  событие FMA  связано с тем, что FMA-сервис не может корректно обработать полученное сообщение об ошибке. Согласно полному описанию по ссылке  http://sun.com/msg/FMD-8000-0W имеем следующее  :

"
<cut>
Details

    The Fault Manager receives error reports from numerous sub-systems and arranges for the appropriate fault diagnosis and automated responses.

    The Message ID: FMD-8000-0W indicates that the Fault Manager received an error report it did not expect. This can indicate a mismatch in the versions of various software components, a misconfiguration of the system, automated diagnosis software may not have been loaded or be currently available, or a defect in the software.

    For SPARC based systems running Solaris 10, the kernel patch 127111 and Solaris FMA patch 119578 are particularly critical and should be examined. Ensure that any dependencies documented in the patch README files are noted and addressed.

<cut>
 
    The recommended actions for the system administrator are:

           1.) Run  pkgchk -n SUNWfmd  to confirm that there are no errors, ensuring that the fault management software is installed properly.

           2.) Ensure the latest firmware/patches are installed on the system.

           3.)  Check the NOTE below for issues that may be particular to your platform.

           4.)  If the failure persists, error telemetry will have to be examined by your Authorized Service Provider.


    NOTE

<cut>

    For 'Sun Fire T1000, Sun Fire T2000, Netra T2000, Sun SPARC Enterprise T5120,and T5220' systems, please make sure that the software and firmware patch levels are as follows:

    1.) Solaris 5.10: kernel patch 127111-08 or higher

    2.) Solaris 5.10: FMA Patch 119578-30 or higher

    3.) System firmware:

    T5120 and T5220 firmware patch 127580-05 or higher

    T2000 firmware patch 127576-03 or higher

    Netra T20000 firmware patch 127578-03 or higher

    T1000 firmware patch 127577-03 or higher "
<cut>
"

Как правило, данные рекомендации оказыватся не применимы, так как pkgchk -n SUNWfmd отрабатывает без ошибок, а установленные патчи в системе имеют гораздо более новые ревизии чем рекомендуется.

При рассморении логов FMA мы можем увидеть следующее  :

Вывод fmadm faulty  :

--------------- ------------------------------------  -------------- ---------
TIME            EVENT-ID                              MSG-ID         SEVERITY
--------------- ------------------------------------  -------------- ---------
Feb 26 13:56:58 80cc52e1-42ec-68ad-81de-aa8c30d006f5  FMD-8000-0W    Minor

Fault class : defect.sunos.fmd.nosub

Description : The Solaris Fault Manager received an event from a component to
              which no automated diagnosis software is currently subscribed.
              Refer to http://sun.com/msg/FMD-8000-0W for more information.

Response    : Error reports from the component will be logged for examination
              by Sun.

Impact      : Automated diagnosis and response for these events will not occur.

Action      : Run pkgchk -n SUNWfmd to ensure that fault management software is
              installed properly.  Contact Sun for support.


Вывод fmdump -Vu 80cc52e1-42ec-68ad-81de-aa8c30d006f5 :



TIME                 UUID                                 SUNW-MSG-ID
Feb 26 13:56:58.5493 80cc52e1-42ec-68ad-81de-aa8c30d006f5  FMD-8000-0W

  TIME                 CLASS                                 ENA
 Feb 26 13:53:10.2261 ereport.fm.ferg.invalid               0x0004c30f65469502

nvlist version: 0
        version = 0x0
        class = list.suspect
        uuid = 80cc52e1-42ec-68ad-81de-aa8c30d006f5
        code = FMD-8000-0W
        diag-time = 1268644235 525363
        de = (embedded nvlist)
        nvlist version: 0
                version = 0x0
                scheme = fmd
                authority = (embedded nvlist)
                nvlist version: 0
                        version = 0x0
                        product-id = SUNW,SPARC-Enterprise-T5220
                        server-id =  tr46-79
                (end authority)

                mod-name = fmd-self-diagnosis
                mod-version = 1.0
        (end de)

        fault-list-sz = 0x1
        fault-list = (array of embedded nvlists)
        (start fault-list[0])
        nvlist version: 0
                version = 0x0
                class = defect.sunos.fmd.nosub
                certainty = 0x64
        (end fault-list[0])

        fault-status = 0x1
        __ttl = 0x1
        __tod = 0x4b9df98b 0x20be6e58



Вывод fmdump -eVu 80cc52e1-42ec-68ad-81de-aa8c30d006f5 :

TIME                           CLASS
Feb 26 2010 13:53:10.226110400 ereport.fm.ferg.invalid
nvlist version: 0
        class = ereport.fm.ferg.invalid
        ena = 0x4c59f63489002
        info = Bad service error report type(0)
        raw-data = 0x0 0x6 0x1c2b6697a24db4 0x0 0x2ebc8259 0x3e002422030607 0x1fd8807e262b2849 0x24400001200 0x4 0xfffffffff0208338 0x4003000000 0x0 0x0 0x0 0xef0000000000011f 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0xc3e1a569 0x0 0xffffffff 0xfff0e04c00 0x34 0xa 0x0 0x0 0x1 0xffffffffffffffff 0xffffffffffffffff 0xffffffffffffffff 0xffffffffffffffff 0xffffffffffffffff 0xffffffffffffffff 0xffffffffffffffff 0xffffffffffffffff 0xffffffffffffffff 0xffffffffffffffff 0xffffffffffffffff 0xffffffffffffffff 0xfff0e04008 0xfff0e04990 0x5a963c1e 0x1000c3e1a569 0x300020000 0x5000000000000 0x40000000000000 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x3 0x808 0x104000000000000 0x323031302d30332d 0x31352030383a3530 0x3a33362e32343620 0x2c204d415820 0x54657374696e672e 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x3531313134313530 0x1301030101 0x0 0xfff0e00388 0xfff0e04108 0xfff0e04149 0xfff0e00140 0xfff0e01e80 0x0 0x0 0x808000000000000 0xfff0e04400 0x180020000000000 0x0 0x0 0x0 0x0 0xffffffff 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
        __ttl = 0x0
        __tod = 0x4b9df5ed 0xd7a2bc0
 

Очевидно, что на первый взгляд мы не можем сделать какое-либо заключение о характере проблемы, определиться - аппаратный это или программный сбой и какие системные компоненты вовлечены в сбой, так как автоматическая диагностика FMA не была выполнена.
Собственно, как уже ранее упоминалось, причиной такого поведения является то, что  FMA-сервис не может корректно обработать полученное сообщение, а имеенно - для которого отсутствует соответствующий обработчик (DE - Diagnosis Engine). Возникает рад вопросов : каким образом определить причину ошибки в данном случае ? Что означает событие ereport.fm.ferg.invalid ?
    
Особенностью реализации FMA на CoolThreads - серверах является тот  факт, что все события регистрируются и передаются для обработки в FMA-сервис операционной системы при помощи сервисного процессора (SP). Утилита, которая генерирует ereports события на сервисном процессоре имеет название FERG - FMA Ereport Generator (заметим, что эта аббревиатура попадает в определение класса события "ereport.fm.ferg.invalid"). FERG в свою очередь получает данные ошибки в "сыром" виде от так называемого гипервизора -  SER (Service Error Reports) и конвертирует их  в FMA-совместимые события (ereport). При этом существует несколько типов различных SER, определяющих источник ошибки (процессор, подсистема ввода-вывода и тд.). В случае, когда FERG не может распознать данных от SER регистрируется событие ferg.invalid, которое в свою очередь пересылается в FMA-сервис ОС Последний генерирует событие о невозможности диагностики по причине отстутствия соответствующей DE (FMD-8000-0W). Прошу обратить внимание, что со стороны сервисного процессора никаких сбоев зарегистрировано не будет (в выводе команды ALOM "showfaults" сбой не будет отображаться), сервисная LED индикация не будет  активирована.

Очевидно, что в данном случае необходима "ручная" диагностика. Для этого потребуется указанные вывод утилит, в особенности  вывод  fmdump -eVu <UUID> - ведь именно этот вывод содержит сырые данные полученные от гипервизора SER с указанием его типа (их можно увидеть в поле "raw-data =....."). К сожалению, информации о методах  декодирования этих данных нет в открытом доступе, и в этом случае потребуется участие в диагностике производителя.
 

Назад

Коротко о себе:

Работаю в компании TUNE-IT в качестве инженера и преподавателя.

В сферу профессиональных интересов входит все,  что связано с "большими" и не очень серверами и СХД от Sun Microsystems/Oracle и кластерами на их основе, но по долгу службы занимаюсь чаще всего их диагностикой и ремонтом... 

Делюсь опытом и  наработанными навыками в рамках курсов по  соответствующим направлениям.

Ничего не найдено. n is 0