LSI RAID-massiivide inventuur GLPI-s

Oma töös kogen tihti järjepidevat muret teabe puudumise üle infrastruktuuri osas ning suureneva serverite arvu korral muutub see tõeliseks piinaks. Isegi kui ma töötasin väikestes organisatsioonides, soovis ma alati teada, mis kus asub, kuhu on midagi ühendatud, kes vastutab millise riistvara või teenuse eest ning mis kõige tähtsam - fikseerida kõik muudatused selles osas. Uude kohta tulles ja silmitsi seistes mõne probleemiga, kulub tohutult aega just selle teabe leidmiseks. Järgnevalt räägin, millega ma RuVDS-is silmitsi seisma pidin ja kuidas ma lahendasin artikli pealkirjas väljendatud probleemi.

Eellugu

Olles ettevõtte tasemel administraator, oli mul vähe kogemusi andmekeskustes, kuid nägin korra silmanurgast RackTables'i. Seal oli selgelt esitatud kapp koos kõigi serverite, UPS-ide, lülitite ja nende vaheliste ühendustega. RuVDS-is sellist süsteemi ei olnud, vaid ainult Exceli/paberifailid serverite, nende osade, rackide numbrite jne kohta. Sellise lähenemisega on väga raske jälgida muudatusi ja töötada väikeste komponentidega. Ning peamine ja tihti vahetatav tarvik serverite puhul on kettad. Väga oluline on hoida ajakohast teavet ketaste oleku ja nende strateegilise varu kohta. Kui ketas kaob RAID-massiivist ja ei ole kiiret asendust, võib see lõppkokkuvõttes põhjustada katastroofilisi tagajärgi. Seetõttu on meil hädasti vaja süsteemi, mis jälgib ketaste asukohta ja nende seisundit, et mõista, millest võib puudust tunda ja milliseid mudeleid tuleb soetada.

Abiks tuli GLPI, avatud lähtekoodiga toode, mis on loodud IT-osakondade töö parandamiseks ja viimiseks ITIL-i ideaalidesse. Lisaks seadmete inventuurimisele ja rackide haldamisele on seal teadmusbaas, teeninduslaud, dokumentide haldamine ja palju muud. GLPI-l on palju pluginaid, sealhulgas FusionInventory ja OCS Inventory, mis võimaldavad automaatselt koguda teavet arvutite ja teiste seadmete kohta agentide ja SNMP kaudu. GLPI ja pluginate paigaldamise kohta saate rohkem lugeda teistes artiklites, kõige parem on - ametlikust dokumentatsioonist. Saame selle paigaldada meie hostingus juba valmis šabloonile LAMP.

Kuid pärast agendi deployimist avame GLPI-s arvuti komponendid ja näeme sellist pilti:

Probleem on selles, et ükski pistikprogramm ei saa LSI RAID-massiivide füüsiliste ketaste teavet näha. Olen näinud, kuidas see küsimus Zabbixis PowerShelli skripti abil lahendatakse. lsi-raid.ps1 otsustasin kirjutada sarnase, et edastada teavet GLPI-le.
Massiivi ketaste teavet saab tootja kontrolleri utiliitide abil, LSI puhul on see StorCLI. Sellega saab andmed JSON-formaadis, tõlgendada ja saata GLPI API-sse. Ketast seome arvutitega, mille on juba loonud FusionInventory. Skripti korduva käivitamise korral uuendab see ketaste andmeid ja lisab uusi. Ise skript Send-RAIDtoGLPI.ps1 asub siin GitHubis. Jätkan edasise kasutamise õpetamisega.

Mida on vaja

1. GLPI versioon 9.5.1 (testimiseks kasutatakse seda versiooni)
2. Pistikprogramm FusionInventory ja agent Windowsi jaoks
3. Windows 2012 R2 (ja uuem) hostimisoperatsioonisüsteemina või management-VM, millel on kontroller ühendatud, PowerShelli versioon 4 või uuem
4. Installeeritud MegaRAID draiver
5. PowerShelli moodul — PSGLPI
6. GLPIs peab olema Admini profiiliga konto liidese kaudu autentimiseks, genereeritud UserToken ja AppToken

Oluline punkt. GLPIs on mingil põhjusel 2 erinevat moodulit ketaste jaoks, kuid pole omadust „kandja tüüp”. Seetõttu otsustasin ketaste omaduste HDD ja SSD registreerimiseks kasutada rippmenüüd „Ketta mudelid” (front/devicemodel.php?itemtype=DeviceHardDriveModel). Skripti jaoks on vajalik, et GLPIs oleks need väärtused olemas, vastasel juhul ei saa ta ketta mudeli andmeid salvestada. Seetõttu tuleb esmalt sisestada HDD ja seejärel SSD tühjasse nimekirja, et nende elementide ID-d oleksid andmebaasis 1 ja 2. Kui on teisi, asendage see rida skriptis Send-RAIDtoGLPI.ps1 pärast HDD ja SSD vastavate ID-idega 1 ja 2.

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

Kui te ei soovi sellega vaeva näha või kasutate seda rippmenüüd muul viisil, võite selle rea skriptist lihtsalt kustutada.

Peate ka lisama ketaste staatuseid „Elemendi staatused” (front/state.php). Olen lisanud staatuse „MediaError” (kui on olnud vähemalt üks ketta ligipääsu tõrge) ja „OK”, ridu skriptis, kus edastatakse nende ID-d, „2” „OK” jaoks ja „1” „MediaError” jaoks:

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

Need staatuseid on mugavuse huvides, kui need omadused pole vajalikud, võite ka selle rea täielikult kustutada.

Ärge unustage skriptis oma muutujaid märkida. $GlpiCreds peab sisaldama GLPI API serveri URL-i, UserToken'i ja AppToken'i.

Mis on skriptis

Skripti suur JSON-parsimine ja pikk if-ute sisemine struktuur muudavad selle lugemise keerukaks, seetõttu kirjeldan selle loogikat siin.

Esimese käivitamise ajal läbib skript kõik kontrollerid ja otsib GLPI andmebaasist kettaid seerianumbrite põhjal. Kui seerianumbrit ei leita, otsitakse mudelit. Kui ka mudelit ei leita, lisatakse uue ketta mudel GLPI-sse ja ketas kantakse andmebaasi.

Iga järgmise käivitusega üritab skript avastada uusi kettaid, kuid puuduvate eemaldamine ei ole tema võimekuses, seega tuleb see teha käsitsi.

Näidis rakendusest

Skripti reposse on lisatud skript Deploy-Send-RAIDtoGLPI.ps1, mis tõmbab vajalikud failid ZIP-arhivina meie GLPI serverist ja paigaldab need igale hostile.

Failide kopeerimise järel installib skript FusionInventory agenti, mis seadistatakse igapäevaseks ülesandeks, ja loob sarnase ülesande meie skripti jaoks. Pärast edukat rakendamist saame lõpuks näha kettaid GLPI-s arvuti 'Komponendid' jaos.

Tulemus

Nüüd, kui siseneme GLPI-sse ja valime menüüst 'Seaded' -> 'Komponendid' -> 'Kõvakettad', saame klõpsata ketaste mudelitel ja näha nende arvu, et mõista, mida peame ostma.

Allikas: habr.com