У сваёй працы я часта зведваю абсесіі з нагоды недахопу інфармацыі аб інфраструктуры, а пры павелічэнні парка абслугоўваных сервераў гэта ператвараецца ў сапраўднае катаванне. Нават калі я адмініў у маленькіх арганізацыях, мне заўсёды хацелася ведаць, што дзе стаіць, куды ўваткнута, хто з людзей за якую жалязяку ці сэрвіс адказвае, і самае галоўнае - фіксаваць змены ў гэтым усім. Калі прыходзіш у новае месца і сутыкаешся з якім-небудзь інцыдэнтам, безліч часу ідзе менавіта на пошук гэтай інфармацыі. Далей я раскажу, з чым мне прыйшлося сутыкнуцца ў 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 навошта-то ёсць 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