Я обещал рассказывать о разного рода необычном оборудовании с точки зрения мониторинга, и в этой статье будет рассказано о удаленном контроле достаточно распространённого массива виртуальных дисков HP EVA. Чтобы «потренироваться на кошечках» возьмём Hewlett-Packard EVA4400 с контроллером HSV300 и двумя дисковыми полками, благо он стоит через стенку и есть возможность брать все скриншоты и данные с живой системы.
Самое неожиданное в данном устройстве – это способ работы с SNMP. Иногда начинают говорить о том, что оно поддерживает SNMP и даже дают ссылку на документацию. Еще больше запутывает дело, что можно зайти в Command View / System Options / Configure Event Notification и увидеть, что оттуда можно скачать MIB для устройства.
Так вот – это не тот MIB. «Not Penny’s boat!».
HP сделало на данном устройстве только SNMP notifications, в просторечии – SNMP трапы, которые оно отправляет само на SNMP-сервер. Внешние SNMP запросы оно не обрабатывает — snmpwalk по нему прогуляться не сможет, увы.
Некто Pall Sigurdsson ( palli@opensource.is ) написал скрипт check_eva.py (качать здесь), который каким-то образом собирает асболютно все необходимые нам данные о состоянии системы, опрашивая контроллер устройства.
Если фокус объяснить, то вся магия пропадает. На самом деле скрипт работает через SSSU – это HP Storage System Scripting Utility.
Нам потребуется sssu_linux_x86. Найти ее можно на диске где у нас лежит сам софт управления EVA Command View или скачать с сайта HP (здесь или прямая ссылка — здесь ).
Это не самая новая версия утилиты (версия 6.0.2, 2007 год), но она работает. Более того, самая новая нам и не нужна.
Для работы плагина, на ОС, где развёрнут наш сервер мониторинга, потребуется сделать две вещи:
1.удостовериться, что у нас инсталлирован python
Если нет, то ставим его любимым способом для нашей ОС.
2. Инсталлировать утилиту SSSU (на самом деле скопировать в путь поиска и сделать симлинк в /usr/local/bin/, где её хочет найти скрипт).
Если у нас Red Hat Enterprise Linux 2.1, Red Hat Enterprise Linux 3 (x86), Red Hat Enterprise Linux 4 (x86), SUSE Linux Enterprise Server 10 (x86), SUSE Linux Enterprise Server 9 (x86), или любая другая система, которую поддерживает Hewlett-Packard, то дальнейшие шаги нам не потребуются, можно сразу переходить к разделу «Подготовка скрипта к работе».
Но так как мы простых путей не ищем, а система мониторинга у нас стоит на другой ОС (FreeBSD 9.0), то заодно разберемся как запустить бинарник Linux на FreeBSD. Здесь тоже нет ничего сложного, способ документирован.
По умолчанию бинарная совместимость с Linux во FreeBSD отключена. Чтобы ее включить, из под root вводим команду:
Чтобы она была активна при перезагрузке системы, тогда в /etc/rc.conf надо добавить:
Чтобы удостовериться, что KLD (kernel dynamic linker) загрузился, вводим:
linux.ko присутствует. После запуска утилиты, получаем ошибку:
Делаем по инструкции: cтавим эмулятор для библиотек linux:
Но sssu опять ругается, скорее всего, библиотек эмулятора мало, нужно что-то еще. Вводим:
ldd покажет зависимости от библиотек, а также наличие их в системе:
Не найдены библиотеки libpam.so.0 и libaudit.so.0. Можно посмотреть в каких они rpm лежат, например, через этот сайт — rpm.pbone.net. Поиск показыват, что libpam есть в rpm от Fedora: pam-0.79-8.i386.rpm, а libaudit.so.0 в rpm от Mandriva: libaudit0-1.7.13-9.1.3.i586.rpm. Скачиваем их к себе и достаем из rpm, при помощи rpm2cpio:
Потом копируем обе библиотеки в каталог, где лежат библиотеки совместимости с linux /compat/linux/lib, и сделаем симлинки, чтобы система знала какую подхватывать:
Запускаем, проверяем. Видим на мониторе:
Что нам и требовалось. Можете в неё зайти: Manager – указать IP или имя хоста EVA Command View, username, password – соответственно. Утилита работает.
sssu_linux_x86 надо положить в /usr/local/bin и сделать на нее симлинк, чтобы скрипт знал где ее искать:
Для FreeBSD всё.
Счастливые пользователи систем Linux, подложившие sssu_linux_x86 в путь поиска и сделавшие на нее симлинк, продолжают с этого места. Итак, у нас работает python и SSSU.
Запускаем скрипт его с ключом --help
С опциями у нас всё ясно:
Режимы:
Проверяем:
EVA отзывается.
Дальше детали варьируются от используемого конфигуратора, но эта последовательность шагов одинакова для nagios/icinga:
1.Создаем команду проверки.
Если не хотим светить пароли в конфигураторе, то в системном файле nagios/icinga под названием resource.cfg прописываем:
$USER7$ = user_name_for_EVA,
$USER8$= password_for_EVA
Номера – любые, какие у вас свободны.
Наша команда проверки имеет вид:
$USER1$/check_eva.py --host $HOSTADDRESS$ --username $USER7$ --password $USER8$ --mode $ARG1$
2.Потом для каждого режима запроса создаем сервисы, привязываем их к нашей команде проверки, у которых меняется лишь аргумент $ARG1$.
3.Назначаем сервисы на хосты напрямую или включаем их в темплейт, а темплейт назначаем на хосты (если стоек у нас много)
4.Сохраняем конфигурацию, дожидаемся, когда закончится опрос новых устройств:
Смотрим на картинку. Вся информация о нашей СХД как на ладони:
Серый цвет – это признак того, что на данной строке стоит курсор, там, на самом деле, тоже всё ОК.
1.Скрипт не будет работать с SSSU версии 10.2 и новее. Отлично работает с версиями 9.4 и древнее. Возможно, новые модели EVA не будут работать со старыми версиями SSSU — это не проверялось.
2.Автор давно не выходит на связь. Но исходный текст скрипта есть, так что всегда можно потратить немного времени и допилить под свои нужды. «Открытый софт != закрытый софт».
Иногда SSSU выдает ошибку невозможности создания https соединения. Перегрузите интерфейс управления на EVA
P.S. Очень бы хотелось, чтобы эксперты рассказали, можно ли добиться аналогичного результата в системе мониторинга zabbix и какая последовательность шагов нужна, если учесть, что в системе из коробки нет темплейтов под HP EVA, SSSU не входит в перечень поддерживаемых агентов, а по SNMP целевая система не отзывается.
Хинт: Проблему можно решить. Но другим, более длинным, способом.
Самое неожиданное в данном устройстве – это способ работы с SNMP. Иногда начинают говорить о том, что оно поддерживает SNMP и даже дают ссылку на документацию. Еще больше запутывает дело, что можно зайти в Command View / System Options / Configure Event Notification и увидеть, что оттуда можно скачать MIB для устройства.
Так вот – это не тот MIB. «Not Penny’s boat!».
HP сделало на данном устройстве только SNMP notifications, в просторечии – SNMP трапы, которые оно отправляет само на SNMP-сервер. Внешние SNMP запросы оно не обрабатывает — snmpwalk по нему прогуляться не сможет, увы.
Некто Pall Sigurdsson ( palli@opensource.is ) написал скрипт check_eva.py (качать здесь), который каким-то образом собирает асболютно все необходимые нам данные о состоянии системы, опрашивая контроллер устройства.
Секрет фокуса
Если фокус объяснить, то вся магия пропадает. На самом деле скрипт работает через SSSU – это HP Storage System Scripting Utility.
Нам потребуется sssu_linux_x86. Найти ее можно на диске где у нас лежит сам софт управления EVA Command View или скачать с сайта HP (здесь или прямая ссылка — здесь ).
Это не самая новая версия утилиты (версия 6.0.2, 2007 год), но она работает. Более того, самая новая нам и не нужна.
Для работы плагина, на ОС, где развёрнут наш сервер мониторинга, потребуется сделать две вещи:
1.удостовериться, что у нас инсталлирован python
icinga# python
Python 2.7.3 (default, Sep 11 2012, 11:58:26)
[GCC 4.2.1 20070831 patched [FreeBSD]] on freebsd9
Type "help", "copyright", "credits" or "license" for more information.
>>>
Если нет, то ставим его любимым способом для нашей ОС.
2. Инсталлировать утилиту SSSU (на самом деле скопировать в путь поиска и сделать симлинк в /usr/local/bin/, где её хочет найти скрипт).
Если у нас Red Hat Enterprise Linux 2.1, Red Hat Enterprise Linux 3 (x86), Red Hat Enterprise Linux 4 (x86), SUSE Linux Enterprise Server 10 (x86), SUSE Linux Enterprise Server 9 (x86), или любая другая система, которую поддерживает Hewlett-Packard, то дальнейшие шаги нам не потребуются, можно сразу переходить к разделу «Подготовка скрипта к работе».
Но так как мы простых путей не ищем, а система мониторинга у нас стоит на другой ОС (FreeBSD 9.0), то заодно разберемся как запустить бинарник Linux на FreeBSD. Здесь тоже нет ничего сложного, способ документирован.
Обеспечение бинарной совместимости FreeBSD с Linux.
По умолчанию бинарная совместимость с Linux во FreeBSD отключена. Чтобы ее включить, из под root вводим команду:
# kldload linux
Чтобы она была активна при перезагрузке системы, тогда в /etc/rc.conf надо добавить:
linux_enable="YES"
Чтобы удостовериться, что KLD (kernel dynamic linker) загрузился, вводим:
# kldstat
Id Refs Address Size Name
1 2 0xc0100000 16bdb8 kernel
7 1 0xc24db000 d000 linux.ko
linux.ko присутствует. После запуска утилиты, получаем ошибку:
icinga# ./sssu_linux_x86
ELF interpreter /lib/ld-linux.so.2 not found
Делаем по инструкции: cтавим эмулятор для библиотек linux:
# cd /usr/ports/emulators/linux_base-f10
# make install distclean
Но sssu опять ругается, скорее всего, библиотек эмулятора мало, нужно что-то еще. Вводим:
ldd sssu_linux_x86
ldd покажет зависимости от библиотек, а также наличие их в системе:
./sssu_linux_x86:
librt.so.1 => /lib/librt.so.1 (0x281c8000)
libpthread.so.0 => /lib/libpthread.so.0 (0x281d2000)
libdl.so.2 => /lib/libdl.so.2 (0x281ec000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x281f1000)
libm.so.6 => /lib/libm.so.6 (0x282a7000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x282d0000)
libc.so.6 => /lib/libc.so.6 (0x282df000)
/lib/ld-linux.so.2 (0x2819a000)
libpam.so.0 => not found
libaudit.so.0 => not found
Не найдены библиотеки libpam.so.0 и libaudit.so.0. Можно посмотреть в каких они rpm лежат, например, через этот сайт — rpm.pbone.net. Поиск показыват, что libpam есть в rpm от Fedora: pam-0.79-8.i386.rpm, а libaudit.so.0 в rpm от Mandriva: libaudit0-1.7.13-9.1.3.i586.rpm. Скачиваем их к себе и достаем из rpm, при помощи rpm2cpio:
rpm2cpio < pam-0.79-8.i386.rpm | cpio -ivd ./lib/libpam.so.0.79
rpm2cpio < libaudit0-1.7.13-9.1.3.i586.rpm | cpio –ivd
Потом копируем обе библиотеки в каталог, где лежат библиотеки совместимости с linux /compat/linux/lib, и сделаем симлинки, чтобы система знала какую подхватывать:
ln -s /compat/linux/lib/libpam.so.0.79 /compat/linux/lib/libpam.so.0
ln -s /compat/linux/lib/libaudit.so.0.0.0 /compat/linux/lib/libaudit.so.0
Запускаем, проверяем. Видим на мониторе:
SSSU for HP StorageWorks Command View EVA
Version: 6.0.2
Build: 5
Manager:
Что нам и требовалось. Можете в неё зайти: Manager – указать IP или имя хоста EVA Command View, username, password – соответственно. Утилита работает.
sssu_linux_x86 надо положить в /usr/local/bin и сделать на нее симлинк, чтобы скрипт знал где ее искать:
ln -s /usr/local/sbin/sssu_linux_x86 /usr/local/bin/sssu
Для FreeBSD всё.
Подготовка скрипта к работе.
Счастливые пользователи систем Linux, подложившие sssu_linux_x86 в путь поиска и сделавшие на нее симлинк, продолжают с этого места. Итак, у нас работает python и SSSU.
Запускаем скрипт его с ключом --help
icinga# ./check_eva.py --help
check_eva version 1.0
This plugin checks HP EVA Array with the sssu command
Usage: ./check_eva.py [OPTIONS]
OPTIONS:
[--host <host>]
[--username <user>]
[--password <password]
[--path </path/to/sssu>]
[--mode <mode>]
[--test]
[--debug]
[--help]
Valid modes are: check_systems, check_controllers, check_diskgroups, check_disks, check_diskshelfs, check_diskshelves
Example: ./check_eva.py --host commandview.example.net --username eva --password myPassword --mode check_systems
С опциями у нас всё ясно:
--host <адрес или имя хоста >
--username <Пользователь Command View>
--password <его пароль>
--path <путь до sssu, если она лежит не в пути поиска>
--mode <режим>
--test
--debug
--help
Режимы:
check_systems – общая информация о системе
check_controllers – информация о контроллерах
check_diskgroups – информация о дисковых группах
check_disks – информация о дисках
check_diskshelfs, check_diskshelves – информация о дисковых полках.
Проверяем:
icinga# ./check_eva.py --host ip.ad.dr.es --username user --password pass
OK - 1 objects found | '/Eva_totalstoragespace'=7539.91 '/Eva_usedstoragespace'=4737.25 '/Eva_availablestoragespace'=2802.66
/Eva = good (initialized_ok)
- licensestate = good
- systemtype = HSV300
- firmwareversion = 09534000
- nscfwversion = CR18CBlep-09534000
- totalstoragespace = 7539.91
- usedstoragespace = 4737.25
- availablestoragespace = 2802.66
EVA отзывается.
Дальше детали варьируются от используемого конфигуратора, но эта последовательность шагов одинакова для nagios/icinga:
1.Создаем команду проверки.
Если не хотим светить пароли в конфигураторе, то в системном файле nagios/icinga под названием resource.cfg прописываем:
$USER7$ = user_name_for_EVA,
$USER8$= password_for_EVA
Номера – любые, какие у вас свободны.
Наша команда проверки имеет вид:
$USER1$/check_eva.py --host $HOSTADDRESS$ --username $USER7$ --password $USER8$ --mode $ARG1$
2.Потом для каждого режима запроса создаем сервисы, привязываем их к нашей команде проверки, у которых меняется лишь аргумент $ARG1$.
3.Назначаем сервисы на хосты напрямую или включаем их в темплейт, а темплейт назначаем на хосты (если стоек у нас много)
4.Сохраняем конфигурацию, дожидаемся, когда закончится опрос новых устройств:
Смотрим на картинку. Вся информация о нашей СХД как на ладони:
Серый цвет – это признак того, что на данной строке стоит курсор, там, на самом деле, тоже всё ОК.
Известные ограничения
1.Скрипт не будет работать с SSSU версии 10.2 и новее. Отлично работает с версиями 9.4 и древнее. Возможно, новые модели EVA не будут работать со старыми версиями SSSU — это не проверялось.
2.Автор давно не выходит на связь. Но исходный текст скрипта есть, так что всегда можно потратить немного времени и допилить под свои нужды. «Открытый софт != закрытый софт».
Иногда SSSU выдает ошибку невозможности создания https соединения. Перегрузите интерфейс управления на EVA
P.S. Очень бы хотелось, чтобы эксперты рассказали, можно ли добиться аналогичного результата в системе мониторинга zabbix и какая последовательность шагов нужна, если учесть, что в системе из коробки нет темплейтов под HP EVA, SSSU не входит в перечень поддерживаемых агентов, а по SNMP целевая система не отзывается.
Хинт: Проблему можно решить. Но другим, более длинным, способом.
