I arbeidet mitt opplever jeg ofte tvangstanker om mangel på informasjon om infrastrukturen, og med en økning i antall servere som betjenes, blir dette til virkelig tortur. Selv når jeg var administrator i små organisasjoner, ønsket jeg alltid å vite hva som var hvor, hvor det var plugget inn, hvilke personer som var ansvarlige for hvilken maskinvare eller tjeneste, og viktigst av alt, å registrere endringer i alt dette. Når du kommer til et nytt sted og møter en hendelse, går det mye tid med å søke etter denne informasjonen. Deretter vil jeg fortelle deg hva jeg måtte møte i RuVDS, og hvordan jeg løste problemet angitt i tittelen.
forhistorie
Som bedriftsadministrator hadde jeg liten erfaring med å jobbe i et datasenter, men jeg fikk et glimt av RackTables. Den viste tydelig racket med alle servere, UPS, brytere og alle forbindelsene mellom dem. RuVDS hadde ikke et slikt system, men kun Excel/papir-filer med informasjon om servere, noen av deres komponenter, racknummer osv. Med denne tilnærmingen er det svært vanskelig å spore endringer i små komponenter. Men det viktigste og ofte erstattede forbruksmateriellet for servere er disker. Det er svært viktig å opprettholde oppdatert informasjon om statusen til diskene og deres strategiske reserve. Hvis en stasjon feiler fra et RAID-array og ikke raskt erstattes, kan dette til slutt føre til fatale konsekvenser. Derfor trenger vi virkelig et system som sporer plassering av disker og deres tilstand for å forstå hva vi kan gå glipp av og hvilke modeller vi må kjøpe.
Til unnsetning kom GLPI, et åpen kildekode-produkt designet for å forbedre ytelsen til IT-avdelinger og bringe dem opp til ITIL-idealer. I tillegg til utstyrslager og stativstyring har den en kunnskapsbase, servicedesk, dokumenthåndtering og mye mer. GLPI har mange plugins, inkludert FusionInventory og OCS Inventory, som lar deg automatisk samle inn informasjon om datamaskiner og andre enheter gjennom agentinstallasjon og SNMP. Du kan lese mer om installasjon av GLPI og plugins i andre artikler, best av alt - . Du kan installere det på vår hosting på en ferdig mal .
Etter å ha distribuert agenten, vil vi imidlertid åpne datamaskinkomponentene i GLPI og se dette:
Problemet er at ingen av pluginene kan se informasjon om de fysiske diskene i LSI RAID-arrayer. Etter å ha sett hvordan dette problemet er løst for overvåking i Zabbix ved hjelp av et PowerShell-skript Jeg bestemte meg for å skrive en lignende for å overføre informasjon til GLPI.
Data om diskene i arrayet kan fås ved hjelp av verktøy fra kontrolleren produsenten; i tilfelle av LSI er dette StorCLI. Fra den kan du hente data i JSON-format, analysere dem og sende dem til GLPI API. Vi vil koble diskene til datamaskiner som FusionInventory allerede har opprettet. Når det kjøres på nytt, vil skriptet oppdatere dataene på diskene og legge til nye. Selve skriptet Send-RAIDtoGLPI.ps1 er . Neste vil jeg fortelle deg hvordan du bruker den.
Hva vil være nødvendig
- versjon 9.5.1 (testet på denne)
- Plugg inn og agent for Windows
- Windows 2012 R2 (og høyere) som et vertssystem, eller en management-VM med en kontroller satt inn i den, PowerShell versjon 4 eller høyere
- Installert MegaRAID-driver
- Modul for PowerShell -
- Konto i GLPI med Admin-profil for autorisasjon via API generert av UserToken og AppToken
Viktig poeng. Av en eller annen grunn har GLPI 2 forskjellige enheter for diskmodellen, men det er ingen "medietype"-egenskap. Derfor, for å registrere HDD- og SSD-egenskapene, bestemte jeg meg for å bruke rullegardinlisten "Harddiskmodeller" (front/devicemodel.php?itemtype=DeviceHardDriveModel). Skriptet må ha disse verdiene i GLPI-databasen, ellers vil det ikke kunne skrive data om diskmodellen. Derfor må du først legge til HDD, deretter SSD til denne tomme listen, slik at ID-ene til disse elementene i databasen er 1 og 2. Hvis det er andre, erstatt i denne linjen i skriptet Send-RAIDtoGLPI.ps1 etter HDD og SSD i stedet for 1 og 2 deres tilsvarende IDer:
deviceharddrivemodels_id = switch ($MediaType) { "HDD" { "1" }; "SSD" { "2" }; default { "" } }Hvis du ikke vil bry deg med dette eller du bruker denne rullegardinlisten annerledes, kan du ganske enkelt fjerne denne linjen fra skriptet.
Du må også legge til statuser for diskene i "Element Statuses" (/front/state.php). Jeg la til statusene "MediaError" (det var minst én disktilgangsfeil) og "OK", en linje i skriptet der ID-ene deres overføres, "2" for "OK" og "1" for "MediaError":
states_id = switch ($MediaError) { 0 { "2" }; { $_ -gt 0 } { "1" } }Disse statusene er nødvendig for enkelhets skyld; hvis du ikke trenger disse egenskapene, kan du også slette denne linjen helt.
I selve skriptet, ikke glem å peke variablene til dine. $GlpiCreds må inneholde URL-en til GLPI API-serveren, UserToken og AppToken.
Hva står i manuset
På grunn av tungvint JSON-parsing og tomme hvis, er skriptet vanskelig å lese, så jeg vil beskrive logikken her.
Når det først ble lansert på verten, går skriptet gjennom alle kontrollerene og søker etter disker i GLPI-databasen etter serienumre; hvis det ikke finner det, leter det etter modellen. Hvis det ikke finner modellen, legger det til modell av den nye disken til GLPI og legger denne disken inn i databasen.
Hvert nytt pass vil skriptet prøve å oppdage nye disker, men det vet ikke hvordan det skal fjerne manglende disker, så du må gjøre det manuelt.
Implementeringseksempel
Skriptlageret inneholder Deploy-Send-RAIDtoGLPI.ps1-skriptet, som vil laste ned et ZIP-arkiv med de nødvendige filene fra GLPI-serveren vår og distribuere dem til hver vert.
Etter å ha kopiert filene, vil skriptet installere FusionInventory-agenten for å kjøre som en daglig oppgave og lage den samme oppgaven for skriptet vårt. Etter vellykket implementering vil vi endelig kunne se stasjonene i delen Komponenter på datamaskinen i GLPI.
Resultat
Nå, ved å gå til GLPI i "Innstillinger" -> "Komponenter" -> "Harddisker"-menyen, kan vi klikke på stasjonsmodellene og se antallet for å forstå hva vi trenger å kjøpe.
Kilde: www.habr.com