LSI RAID-massiivide inventuur GLPI-s

Oma töös tunnen sageli muret infrastruktuuri teabe puudumise üle ja kui serverite arv suureneb, muutub see tõeliseks piinamiseks. I even when I administered in small organizations, I always wanted to know where everything was placed, where it was plugged in, who was responsible for which hardware or service, and most importantly — to keep track of all these changes. When you arrive at a new place and encounter some incident, a lot of time is spent just searching for this information. Next, I will share what I've encountered at RuVDS and how I resolved the issue mentioned in the title.

Eelalugu

Olles ettevõtte administraator, oli mul vähe kogemusi andmekeskustes, kuid nurga pealt nägin RackTables'i. Seal oli selgelt esitatud rack koos kõigi serverite, UPS'ide, lülititega ja kõikide ühendustega nende vahel. RuVDS-is ei olnud sarnast süsteemi, vaid ainult Exceli/paberifailid serverite, nende osade, rack-numbrite ja muu sarnase teabega. Sellise lähenemisega on väga raske jälgida muudatusi ja väiksemaid komponente. Lõppude lõpuks on serverite kõige olulisem ja sageli vahetatav tarvik — kettad. On äärmiselt oluline hoida ajakohast teavet kettaste seisundi ja strateegilise varu kohta. Kui ketas kaob RAID-massiivis ja sellele ei ole kiiret asendust, võib see lõpuks põhjustada tõsiseid tagajärgi. Seetõttu on meil väga vajalik süsteem, mis jälgib kettaste asukohta ja seisundit, et mõista, millest võib puudust tunda ja milliseid konkreetseid mudeleid on vaja osta.

GLPI, avatud lähtekoodiga toode, on loodud IT-osakondade töö parandamiseks ja ITILi ideaalide saavutamiseks. See sisaldab varase inventeerimist ja teenuse juhtimist, samuti teadmusbaasi, teenusekeskust, dokumentide haldust ja palju muud. GLPI-l on palju pluginaid, sealhulgas FusionInventory ja OCS Inventory, mis võimaldavad automaatselt koguda teavet arvutite ja muude seadmete kohta agentide ja SNMP kaudu. Täiendavaid juhiseid GLPI ja pluginade installimiseks leiate teistest artiklitest, parim on — ametlikus dokumentatsioonis. Saate selle meie hostimises installida valmis šabloonile LAMP.

Kuid pärast agendi juurutamist avame GLPI-s arvuti komponendid ja näeme järgmist:

Probleem on selles, et ükski pluginitest ei saa näha füüsiliste ketaste teavet LSI RAID-massiivides. Nägin, kuidas see probleem on lahendatud Zabbixis PowerShelli skripti abil lsi-raid.ps1 otsustasin kirjutada analoogse skripti info edastamiseks GLPI-sse.
Andmete diskide kohta RAID-massiivis saab hankida tootja tööriistade abil, LSI puhul on see StorCLI. Sealt saab andmed JSON-formaadis, mida saab töötlema panna ja edastada GLPI API-le. Diskid seotakse arvutitega, mille on juba loonud FusionInventory. Uuesti skripti käivitamisel värskendab see andmeid diskide kohta ja lisab uusi. Skript Send-RAIDtoGLPI.ps1 asub siin GitHubis. Järgmisena selgitan, kuidas seda kasutada.

Mida on vaja

1. GLPI versioon 9.5.1 (sellel testiti)
2. Plugin FusionInventory ja agent Windowsi all
3. Windows 2012 R2 (ja uuem) külalissüsteemina või management-VM, millesse on ühendatud kontroller, PowerShell versioon 4 või uuem
4. Paigaldatud MegaRAID draiver
5. PowerShelli moodul — PSGLPI
6. GLPI-s konto Admin profiiliga API kaudu autentimiseks, genereeritud UserToken ja AppToken

Oluline tähelepanek. GLPI-s on mingil põhjusel kaks erinevat üksust ketta mudeli jaoks, kuid ei ole omadust „andmekandja tüüp”. Seetõttu otsustasin HDD ja SSD omaduse salvestamiseks kasutada rippmenüüd „Ketasemud” (front/devicemodel.php?itemtype=DeviceHardDriveModel). Skripti toimimiseks on vajalik, et GLPI andmebaasis oleks need väärtused, vastasel juhul ei saa see ketasmudelist andmeid salvestada. Seetõttu tuleb kõigepealt lisada see tühi loend HDD ja seejärel SSD, et nende elementide ID-d andmebaasis oleksid 1 ja 2. Kui tuleb teisi, siis asendage selle skripti Read-RAIDtoGLPI.ps1 pärast HDD ja SSD kohaliku ID-iga: 1 ja 2.

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

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

Samuti tuleb lisada ketaste olekud „Elemendi olekud” (/front/state.php). Olen lisanud olekud „MediaError” (kui esines vähemalt üks ketta juurde pääsemise viga) ja „OK”, rida skripti, kus nende ID-d edastatakse, „2” „OK” jaoks ja „1” „MediaError” jaoks:

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

Needless statuses are for convenience; if you don't need these properties, you can remove this line entirely.

Don't forget to specify your variables in the script. $GlpiCreds must contain the URL to the GLPI API server, UserToken, and AppToken.

What’s in the script

Due to bulky JSON parsing and a multitude of if statements, the script is hard to read, so I will describe its logic here.

During the first run on the host, the script scans all controllers and searches for disks in the GLPI database by serial numbers; if it doesn't find any, it searches for the model. If it doesn't find the model either, it adds the new disk model to GLPI and records this disk in the database.

With each new pass, the script will attempt to detect new disks, but it cannot remove those that are missing, so this will have to be done manually.

Deployment example

In the script repository, there is a script Deploy-Send-RAIDtoGLPI.ps1, which will download a ZIP archive with the necessary files from our GLPI server and deploy them on each host.

Failide kopeerimise järel installib skript FusionInventory agendi, mis käivitub igapäevase ülesandena, ning loob sellele ülesande ka meie skripti jaoks. Pärast eduka juurutamise lõpetamist näeme lõpuks kompuutri «Komponendid» osas kettaid GLPI-s.

Tulemus

Nüüd, kui sisse logime GLPI-sse menüüs «Seaded» -> «Komponendid» -> «Ketas», saame klõpsata ketaste mudelitel ja vaadata nende arvu, et mõista, mida meil on vaja osta.

Allikas: habr.com