Инвентаризация 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 в меню «Настройки» → «Компоненты» → «Жесткие диски», мы можем щелкать по моделям дисков и смотреть их количество, чтобы понять, что нам нужно закупить.
