В некоторых случаях необходимо получить данные о "сервисной истории" компонентов midrange-серверов. Это информация может оказаться полезной при проведении диагностики и для оценки состояния компонентов.
Что подразумевается под историей компонентов в данном случае ? Во всех основных компонентах серверов таких как : процессорные платы, платы ввода-вывода, "репиторы" (Level 2 Repeater Board) и т.д. установлены специализированные элементы памяти SEEPROM - Serial Electrically Eraseable Programmable ROM (иногда можно встретить альтернативное название FRU ID - Field Replaceable Unit IDentifier). Основная задача этих SEEPROM(FRU ID) - хранение данных производителя. При этом, такие элементы могут иметь две области - статическую и динамическую : статическая область содержит данные о названии фактического производителя, номера детали по каталогу (так называемый "партийный номер"), дате и месте производства компонента, серийный номер и т.д., динамическая область содержит данные, накопленные в процессе эксплуатации при помощи системного контроллера сервера, такие как статистику POH - Power On Hours (данные о количестве часов "в работе" и счетчиков количества циклов выключение/включения компонентов, а также лог этих событий), и историю CHS - Component Health Status.
Для того, чтобы получить данные об истории CHS необходимо иметь доступ в сервисный режим системного контроллера, пароль для которого генерируется службой технической поддержки производителя. Предоставляется пароль обычно в рамках заявки на обслуживания, однако, в некоторых случаях получение пароля не возможно, к примеру, по причине отсутствия гарантии на оборудование.
Получение данных истории CHS, а также информацию о производстве компонента, статистику POH можно при помощи стандартной утилиты для сбора диагностических данных Sun Explorer Data Collector (пакет SUNWexplo) с указанием специализированного модуля "scextended" (строка запуска в общем случае - "<explorer_path>/bin/explorer -w default, scextended").
Данный модуль, в свою очередь, представляет собой shell-скрипт (исходный текст находится в <explorer_path>/tools/scextended) и использует утилиту rprtfru.sparc, входящую в пакет SUNWexplo, предназначенную для удаленного сбора данных с системного контроллера сервера. Соответствующий фрагмент скрипта выглядит следующим образом :
...
if [ -n "${FRU}" ]
then
OLD_LD_LIBRARY_PATH=$LD_LIBRARY_PATH
LD_LIBRARY_PATH=${EXP_LIB}
get_cmd "${EXP_HOME}/bin/rprtfru.`uname -p` -b ${SC_NAME}:XXXXXX -x" sc/${SC_NAME}/prtfru_-x
LD_LIBRARY_PATH=$OLD_LD_LIBRARY_PATH
fi
...
(Очевидно, сбор данных может производится и в ручную, при помощи запуска rprtfru.sparc с указанием необходимых ключей/параметров, описание которых можно просмотреть запустив утилиту без указания каких-либо параметров)
Результат сбора данных в рамках вышеупомянутого модуля scextended попадает в общий вывод утилиты Explorer в виде текстового XML -файла с именем prtfru_-x.out и располагается в директории <explorer_output_dir>/sc/<sc_hostname_or _ip>/ (например explorer.83080479.sf4800-2010.02.29.11.00/sc/10.40.128.16/ prtfru_-x.out). Данный файл может быть открыт при помощи обычного текстового редактора или при помощи какого-либо "специализированного" XML- редактора. К сожалению, инструменты производителя для преобразования данного файла в более "читабельный" вид в открытом доступе отсутствуют.
Приведем в качестве примера фрагмент вывода prtfru_-x.out для элемента RP2 (Repeater board) сервера Sun Fire 4800 :
[cut]
<Location name="RP2?Label=RP2">
<Container name="RP2">
<ContainerData>
<Segment name="SD">
<ManR>
<UNIX_Timestamp32 value="Sun Sep 9 10:18:24 MSD 2001"/>
<Fru_Description value="Repeater Board"/>
<Manufacture_Loc value="Celestica Kidsgrove,UNITED KINGDOM"/>
<Sun_Part_No value="5014953"/>
<Sun_Serial_No value="004664"/>
<Vendor_Name value="Celestica"/>
<Initial_HW_Dash_Level value="08"/>
<Initial_HW_Rev_Level value="50"/>
<Fru_Shortname value="RP"/>
</ManR>
<Fru_Type value="L2 Board"/>
<L2_BoardR>
<Board_Speed value="0096"/>
</L2_BoardR>
</Segment>
<Segment name="ID">
<UsageR>
<Number_of_Updates value="243"/>
<Last_Power_On value="Mon Jan 20 14:29:54 MSK 2003"/>
<Total_Errors value="0"/>
<Total_Inserts value="36"/>
<Total_Power_Ons_old value="115"/>
<Total_Time_On value="16787647"/>
</UsageR>
</Segment>
<Segment name="PE">
<Power_EventsR>
<Index_Power_EventsR>
<UNIX_Timestamp32 value="Wed Apr 16 13:58:27 MSD 2003"/>
<Event value="power_on"/>
</Index_Power_EventsR>
<Index_Power_EventsR>
<UNIX_Timestamp32 value="Fri Apr 25 15:19:55 MSD 2003"/>
<Event value="power_off"/>
</Index_Power_EventsR>
<Index_Power_EventsR>
<UNIX_Timestamp32 value="Wed Nov 11 12:20:54 MSK 2009"/>
<Event value="power_on"/>
</Index_Power_EventsR>
<Index_Power_EventsR>
<UNIX_Timestamp32 value="Wed Nov 11 20:14:57 MSK 2009"/>
<Event value="power_off"/>
</Index_Power_EventsR>
<Index_Power_EventsR>
<UNIX_Timestamp32 value="Wed Nov 11 22:12:18 MSK 2009"/>
<Event value="power_on"/>
</Index_Power_EventsR>
<Index_Power_EventsR>
<UNIX_Timestamp32 value="Tue Dec 29 12:25:57 MSK 2009"/>
<Event value="still_on"/>
</Index_Power_EventsR>
</Power_EventsR>
</Segment>
<Segment name="PS">
<Power_SummaryR>
<UNIX_Timestamp32 value="Tue Dec 29 12:25:57 MSK 2009"/>
<Total_Time_On value="3531872"/>
<Total_Power_Ons value="37"/>
<Total_Power_Offs value="28"/>
</Power_SummaryR>
</Segment>
<Segment name="FD">
<InstallationR>
<Index_InstallationR>
<UNIX_Timestamp32 value="Mon Jan 20 16:45:54 MSK 2003"/>
<Fru_Path value="/RP2"/>
<Parent_Part_Number value=""/>
<Parent_Serial_Number value=""/>
<Parent_Dash_Level value=""/>
<System_Id value="152M301A"/>
<System_Tz value="180"/>
<Geo_North value="0"/>
<Geo_East value="0"/>
<Geo_Alt value="0"/>
<Geo_Location value=""/>
</Index_InstallationR>
</InstallationR>
<Status_EventsR>
<Index_Status_EventsR>
<UNIX_Timestamp32 value="Thu Feb 7 06:39:34 MSK 2008"/>
<Old_Status value="00"/>
<New_Status value="20"/>
<Initiator value="SCAPP"/>
<Component value="0"/>
<Event_Code value="01000007 (unrecognized value)"/>
<Message value="1.SF4800.FAULT.ASIC.AR.ADR_PERR.10423005.19-2.2.5016178A44636"/>
</Index_Status_EventsR>
<Index_Status_EventsR>
<UNIX_Timestamp32 value="Thu Feb 7 06:40:17 MSK 2008"/>
<Old_Status value="20"/>
<New_Status value="20"/>
<Initiator value="SCAPP"/>
<Component value="0"/>
<Event_Code value="01000007 (unrecognized value)"/>
<Message value="1.SF4800.FAULT.ASIC.DX.SERD.SAF_IN_PAR_ERR.30223024.19-2.2.5016178A44636"/>
</Index_Status_EventsR>
<Index_Status_EventsR>
<UNIX_Timestamp32 value="Thu Mar 27 13:30:27 MSK 2008"/>
<Old_Status value="20"/>
<New_Status value="00"/>
<Initiator value="Field_Eng"/>
<Component value="0"/>
<Event_Code value="FE000000 (unrecognized value)"/>
<Message value="per case 70253873"/>
</Index_Status_EventsR>
</Status_EventsR>
</Segment>
<Segment name="TH">
<Temperature_HistoryR>
<UNIX_Timestamp32 value="Tue Dec 29 12:25:55 MSK 2009"/>
<Sensor value="0"/>
<Lowest value="99"/>
<Highest value="122"/>
<Latest value="112"/>
<Histogram>
<Index value="0"/>
<Index value="13"/>
<Index value="49428"/>
<Index value="11299"/>
<Index value="0"/>
<Index value="0"/>
<Index value="0"/>
<Index value="0"/>
<Index value="0"/>
<Index value="0"/>
</Histogram>
</Temperature_HistoryR>
</Segment>
<Segment name="ST">
<Status_CurrentR>
<UNIX_Timestamp32 value="Thu Mar 27 13:30:27 MSK 2008"/>
<Status value="00"/>
</Status_CurrentR>
</Segment>
</ContainerData>
</Container> <!-- RP2 -->
</Location> <!-- RP2?Label=RP2 -->
[cut]
Как видно из примера, структура XML в данном случае достаточно простая, и имеет очевидные наименования тэгов.
Рассмотрим основные из них :
<ManR> (Manufacture Record) - Cодержит записи производителя : партийный, серийный номер и т.д.
<UsageR> (Usage Record) - Статистика использования компонента, его "время жизни".
<Power_EventsR> (Power Events Records) - Логи зарегистрированных событий циклов выключения/включения питания.
<Power_SummaryR> (Power Summary) - Cтатистика POH.
<Status_EventsR> (Status Events Records) - История событий CHS.
В рамках этого тега каждое событие CHS регистрируется в виде вложенного тэга <Index_Status_EventsR> с указанием
даты и времени регистрации (тэг <UNIX_Timestamp32 value="[date &time]"/>) , значения текущего и нового статуса CHS (тэги <Old_Status value="[status]"/> и <New_Status value="[status]"/> ) , значения Auto-Diagnosis Message, генереруемого при помощи SCApp (см. <Message value="[message]" />), а также тип инициатора события (<Initiator value="[initiator]"/> ).
Заметим, что подобный вывод события CHS возможно получить только при помощи команды сервисного режима контроллера "showchs -v...". Все необходимыке значения в перечисленных вложеннных тегах находятся в легко читаемом текстовом виде за исключением <Old_Status ... /> и <New_Status ... /> : здесь значение "00" соответствует CHS-статусу "ОК", значение "20" - "SUSPECT", a "C0" - "FAULTY".
Структуры для остальных FRU- элементов серверов в файле prtfru_-x.out аналогичны рассмотренным выше.