🥇Инвентаризация RAID-массивов LSI в GLPI

В своей работе я часто испытываю обсессии по поводу нехватки информации об инфраструктуре, а при увеличении парка обслуживаемых серверов это превращается в настоящую пытку. Даже когда я админил в маленьких организациях, мне всегда хотелось знать, что где стоит, куда воткнуто, кто из людей за какую железку или сервис отвечает, и самое главное — фиксировать изменения в этом всем. Когда приходишь в новое место и сталкиваешься с каким-нибудь инцидентом, уйма времени уходит именно на поиск этой информации. Далее я расскажу, с чем мне пришлось столкнуться в RuVDS, и как решил проблему, обозначенную в заголовке.

Предыстория

Будучи энтерпрайзным админом, я имел мало опыта работы в дата-центре, но краем глаза увидел RackTables. В нём наглядно была представлена стойка со всеми серверами, ИБП, коммутаторами и всеми соединениями между ними. В RuVDS не было подобной системы, а только Excel/бумажные файлы с информацией о серверах, их некоторых компонентах, номерами стоек и и.п. При таком подходе очень тяжело отслеживать изменения и за мелкими компонентами. А ведь самый главный и часто сменяемый расходный материал у серверов — это диски. Очень важно поддерживать актуальную информацию о состоянии дисков и их стратегический запас. Если диск вылетит из RAID-массива и ему не будет быстрой замены, это в итоге может привести к фатальным последствиям. Поэтому нам очень нужна система, отслеживающая местонахождение дисков и их состояние, чтобы понять, чего нам может не хватить и какие именно модели нужно закупить.

На помощь пришел GLPI, продукт с открытым исходным кодом, созданный для улучшения работы ИТ-отделов и доведения их до идеалов ITIL. В нем, помимо инвентаризации оборудования и менеджмента стоек, есть база знаний, сервис-деск, управление документами и многое другое. У GLPI есть множество плагинов, в том числе FusionInventory и OCS Inventory, которые позволяют автоматически собирать информацию о компьютерах и других устройствах посредством установки агентов и по SNMP. Подробнее про установку GLPI и плагинов вы можете почитать в других статьях, лучше всего — официальной документации. Можно установить его у нас на хостинге на уже готовый шаблон LAMP.

Однако, после деплоя агента мы откроем компоненты компьютера в GLPI и увидим это:

Проблема в том, что ни один из плагинов не может увидеть информацию о физических дисках в RAID-массивах LSI. Увидев, как этот вопрос решен для мониторинга в Zabbix с помощью PowerShell-скрипта lsi-raid.ps1 я решил написать аналогичный для передачи инфы в GLPI.
Данные о дисках в массиве можно получить с помощью утилит от производителя контроллера, в случае с LSI это StorCLI. Из нее можно получить данные в формате JSON, распарсить и прокинуть их в API GLPI. Диски будем привязывать к компьютерам, которые уже создал FusionInventory. При повторном выполнении скрипт будет обновлять данные по дискам и добавлять новые. Сам скрипт Send-RAIDtoGLPI.ps1 лежит вот тут на GitHub. Далее я расскажу, как им воспользоваться.

Что потребуется

GLPI версии 9.5.1 (на этой тестировалось)
Плагин FusionInventory и агент под Windows
Windows 2012 R2 (и выше) в качестве хостовой системы, либо management-VM с проброшенным в нее контроллером, PowerShell версии 4 или выше
Установленный драйвер MegaRAID
Модуль для PowerShell — PSGLPI
Учетка в GLPI с профилем Admin для авторизации через API, сгенерированные UserToken и AppToken

Важный момент. В GLPI зачем-то есть 2 разных сущности для модели диска, но нет свойства «тип носителя». Поэтому для записи свойства HDD и SSD я решил использовать выпадающий список «Модели жестких дисков» (front/devicemodel.php?itemtype=DeviceHardDriveModel). Для скрипта необходимо наличие в базе GLPI этих значений, иначе он не сможет записать данные о модели диска. Поэтому нужно занести в этот пустой список сначала HDD, затем SSD, чтобы ID этих элементов в базе получились 1 и 2. Если будут другие, то замените в этой строчке скрипта Send-RAIDtoGLPI.ps1 после HDD и SSD вместо 1 и 2 соответствующие им ID:

deviceharddrivemodels_id = switch ($MediaType) { "HDD" { "1" }; "SSD" { "2" }; default { "" } }

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

Также нужно добавить статусы для дисков в «Статусы элементов» (/front/state.php). Я добавил статусы «MediaError» (была хоть одна ошибка обращения к диску) и «OK», строчка в скрипте, где передаются их ID, «2» для «ОК» и «1» для «MediaError»:

states_id = switch ($MediaError) { 0 { "2" }; { $_ -gt 0 } { "1" } }

Эти статусы нужны для удобства, если вам эти свойства не нужны, можете также удалить эту строчку целиком.

В самом скрипте не забудьте указать переменные на ваши. $GlpiCreds должен содержать URL до сервера API GLPI, UserToken и AppToken.

Что в скрипте

Из-за громоздкого JSON-парсинга и простыни if-ов скрипт плохо читается, поэтому опишу его логику здесь.

При первом запуске на хосте скрипт проходится по всем контроллерам и ищет диски в базе GLPI по серийным номерам, если не находит, ищет модель.Если не находит и модель, то добавляет модель нового диска в GLPI и заносит этот диск в базу.

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

Пример развертывания

В репозитории скрипта есть скрипт Deploy-Send-RAIDtoGLPI.ps1, который скачает ZIP-архив с необходимыми файлами с нашего сервера GLPI и развернет их на каждом хосте.

После копирования файлов скрипт установит агент FusionInventory с запуском в виде ежедневной задачи и создаст такую же задачу для нашего скрипта. После успешного внедрения мы наконец сможем увидеть диски в разделе «Компоненты» компьютера в GLPI.

Результат

Теперь, зайдя в GLPI в меню «Настройки» -> «Компоненты» -> «Жесткие диски», мы можем щелкать по моделям дисков и смотреть их количество, чтобы понять, что нам нужно закупить.

Источник: habr.com