У своїй роботі я часто відчуваю обсесію з приводу нестачі інформації про інфраструктуру, а при збільшенні парку серверів, що обслуговуються, це перетворюється на справжнє катування. Навіть коли я адмінив у маленьких організаціях, мені завжди хотілося знати, що де стоїть, куди встромлено, хто з людей за якусь залізницю чи сервіс відповідає, і найголовніше — фіксувати зміни в цьому всьому. Коли приходиш у нове місце і стикаєшся з яким-небудь інцидентом, багато часу йде саме на пошук цієї інформації. Далі я розповім, з чим мені довелося зіткнутися в RuVDS, і як вирішив проблему, зазначену у заголовку.
Передісторія
Будучи ентерпрайзним адміном, я мав мало досвіду роботи в дата-центрі, але краєм ока побачив RackTables. У ньому наочно була представлена стійка з усіма серверами, ДБЖ, комутаторами та всіма з'єднаннями між ними. У RuVDS не було подібної системи, а лише Excel/паперові файли з інформацією про сервери, їх деякі компоненти, номери стійок та т.п. За такого підходу дуже важко відстежувати зміни і за дрібними компонентами. Адже найголовніший витратний матеріал, що часто змінюється, у серверів — це диски. Дуже важливо підтримувати актуальну інформацію про стан дисків та їх стратегічний запас. Якщо диск вилетить з RAID-масиву і йому не буде швидкої заміни, це може призвести до фатальних наслідків. Тому нам дуже потрібна система, яка відстежує місцезнаходження дисків та їхній стан, щоб зрозуміти, чого нам може не вистачити та які саме моделі потрібно закупити.
На допомогу прийшов GLPI, продукт із відкритим вихідним кодом, створений для покращення роботи ІТ-відділів та доведення їх до ідеалів ITIL. У ньому, крім інвентаризації обладнання та менеджменту стійок, є база знань, сервіс-деск, управління документами та багато іншого. У GLPI є безліч плагінів, у тому числі FusionInventory та OCS Inventory, які дозволяють автоматично збирати інформацію про комп'ютери та інші пристрої за допомогою установки агентів і за SNMP. Докладніше про встановлення GLPI та плагінів ви можете почитати в інших статтях, найкраще — . Можна встановити його у нас на хостингу на готовий шаблон .
Однак після деплою агента ми відкриємо компоненти комп'ютера в GLPI і побачимо це:
Проблема в тому, що жоден із плагінів не може побачити інформацію про фізичні диски в RAID-масивах LSI. Побачивши, як це питання вирішено для моніторингу в Zabbix за допомогою PowerShell-скрипту я вирішив написати аналогічний передачі інформації в GLPI.
Дані про диски в масиві можна отримати за допомогою утиліт від виробника контролера, у разі LSI це StorCLI. З неї можна отримати дані у форматі JSON, розпарити та прокинути їх в API GLPI. Диски будемо прив'язувати до комп'ютерів, які вже створили FusionInventory. При повторному виконанні скрипт оновлюватиме дані по дисках і додаватиме нові. Сам скрипт Send-RAIDtoGLPI.ps1 лежить . Далі я розповім, як ним скористатися.
що потрібно
- версії 9.5.1 (на цьому тестувалося)
- плагін та агент під Windows
- Windows 2012 R2 (і вище) як хостова система, або management-VM з прокинутим в неї контролером, PowerShell версії 4 або вище
- Встановлений драйвер MegaRAID
- Модуль для PowerShell
- Облікові записи в GLPI з профілем Admin для авторизації через API, згенеровані UserToken і AppToken
Важливий момент. У GLPI навіщось є дві різні сутності для моделі диска, але немає властивості «тип носія». Тому для запису якості HDD і SSD я вирішив використовувати список «Моделі жорстких дисків» (front/devicemodel.php?itemtype=DeviceHardDriveModel). Для скрипту необхідна наявність у базі GLPI цих значень, інакше він зможе записати дані про моделі диска. Тому потрібно занести в цей порожній список спочатку HDD, потім SSD, щоб ID цих елементів у базі вийшли 2 і 1. Якщо будуть інші, то замініть у цьому рядку скрипта Send-RAIDtoGLPI.ps2 після HDD та SSD замість 1 і 1 відповідних їм 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 за серійними номерами, якщо не знаходить, шукає модель.
Кожен новий прохід скрипт намагатиметься виявити нові диски, але видаляти відсутні він не вміє, тому доведеться робити це вручну.
Приклад розгортання
У репозиторії скрипта є скрипт Deploy-Send-RAIDtoGLPI.ps1, який завантажить ZIP-архів із необхідними файлами з нашого сервера GLPI та розгорне їх на кожному хості.
Після копіювання файлів скрипт встановить агент FusionInventory із запуском у вигляді щоденного завдання та створить таке саме завдання для нашого скрипту. Після успішного впровадження ми нарешті зможемо побачити диски у розділі Компоненти комп'ютера в GLPI.
Результат
Тепер, зайшовши в GLPI в меню "Налаштування" -> "Компоненти" -> "Жорсткі диски", ми можемо клацати за моделями дисків і дивитися їх кількість, щоб зрозуміти, що нам потрібно закупити.
Джерело: habr.com