I mit arbejde oplever jeg ofte tvangstanker omkring manglen på information om infrastrukturen, og med en stigning i antallet af servere, der betjenes, bliver dette til reel tortur. Selv da jeg var administrator i små organisationer, ville jeg altid vide, hvad der var hvor, hvor det var tilsluttet, hvilke personer der var ansvarlige for hvilket stykke hardware eller service, og vigtigst af alt, at registrere ændringer i alt dette. Når du kommer til et nyt sted og støder på en hændelse, bruges der meget tid på at søge efter denne information. Dernæst vil jeg fortælle dig, hvad jeg skulle stå over for i RuVDS, og hvordan jeg løste problemet angivet i titlen.
forhistorie
Som virksomhedsadministrator havde jeg kun lidt erfaring med at arbejde i et datacenter, men jeg fik et glimt af RackTables. Det viste tydeligt racket med alle servere, UPS, switche og alle forbindelser mellem dem. RuVDS havde ikke sådan et system, men kun Excel/papirfiler med information om servere, nogle af deres komponenter, racknumre mv. Med denne tilgang er det meget vanskeligt at spore ændringer i små komponenter. Men de vigtigste og hyppigst udskiftede forbrugsstoffer til servere er diske. Det er meget vigtigt at vedligeholde ajourførte oplysninger om status for diske og deres strategiske reserve. Hvis et drev fejler fra et RAID-array og ikke hurtigt udskiftes, kan dette i sidste ende føre til fatale konsekvenser. Derfor har vi virkelig brug for et system, der sporer diskenes placering og deres tilstand for at forstå, hvad vi kan mangle, og hvilke modeller vi skal købe.
Til undsætning kom GLPI, et open source-produkt designet til at forbedre IT-afdelingernes ydeevne og bringe dem op til ITIL-idealer. Ud over udstyrslager og rackstyring har den en videnbase, servicedesk, dokumenthåndtering og meget mere. GLPI har mange plugins, herunder FusionInventory og OCS Inventory, som giver dig mulighed for automatisk at indsamle oplysninger om computere og andre enheder gennem agentinstallation og SNMP. Du kan læse mere om installation af GLPI og plugins i andre artikler, bedst af alt - . Du kan installere det på vores hosting på en færdiglavet skabelon .
Men efter at have implementeret agenten, åbner vi computerkomponenterne i GLPI og ser dette:
Problemet er, at ingen af plugins kan se information om de fysiske diske i LSI RAID-arrays. Efter at have set, hvordan dette problem er løst til overvågning i Zabbix ved hjælp af et PowerShell-script Jeg besluttede at skrive en lignende for at overføre information til GLPI.
Data om diskene i arrayet kan fås ved hjælp af hjælpeprogrammer fra controllerproducenten; i tilfælde af LSI er dette StorCLI. Fra det kan du få data i JSON-format, parse det og videregive det til GLPI API. Vi vil linke diskene til computere, som FusionInventory allerede har oprettet. Når det udføres igen, vil scriptet opdatere dataene på diskene og tilføje nye. Selve scriptet Send-RAIDtoGLPI.ps1 er . Næste vil jeg fortælle dig, hvordan du bruger det.
Hvad vil blive krævet
- version 9.5.1 (testet på denne)
- plugin og agent til Windows
- Windows 2012 R2 (og nyere) som et værtssystem eller en management-VM med en controller indsat i den, PowerShell version 4 eller nyere
- Installeret MegaRAID driver
- Modul til PowerShell -
- Konto i GLPI med Admin-profil til godkendelse via API genereret af UserToken og AppToken
Vigtigt punkt. Af en eller anden grund har GLPI 2 forskellige entiteter til diskmodellen, men der er ingen "medietype"-egenskab. Derfor besluttede jeg at bruge "Hard Drive Models"-rullelisten for at optage HDD- og SSD-egenskaberne (front/devicemodel.php?itemtype=DeviceHardDriveModel). Scriptet skal have disse værdier i GLPI-databasen, ellers vil det ikke være i stand til at skrive data om diskmodellen. Derfor skal du først tilføje HDD, derefter SSD til denne tomme liste, så ID'erne for disse elementer i databasen er 1 og 2. Hvis der er andre, så udskift i denne linje af scriptet Send-RAIDtoGLPI.ps1 efter HDD og SSD i stedet for 1 og 2 deres tilsvarende ID'er:
deviceharddrivemodels_id = switch ($MediaType) { "HDD" { "1" }; "SSD" { "2" }; default { "" } }Hvis du ikke vil genere dette, eller du bruger denne rulleliste anderledes, kan du blot fjerne denne linje fra scriptet.
Du skal også tilføje statusser for diskene i "Element Statuses" (/front/state.php). Jeg tilføjede statussen "MediaError" (der var mindst én diskadgangsfejl) og "OK", en linje i scriptet, hvor deres ID'er overføres, "2" for "OK" og "1" for "MediaError":
states_id = switch ($MediaError) { 0 { "2" }; { $_ -gt 0 } { "1" } }Disse statusser er nødvendige for nemheds skyld; hvis du ikke har brug for disse egenskaber, kan du også slette denne linje helt.
I selve scriptet, glem ikke at pege variablerne til dine. $GlpiCreds skal indeholde URL'en til GLPI API-serveren, UserToken og AppToken.
Hvad står der i manuskriptet
På grund af besværlig JSON-parsing og tomme ifs er scriptet svært at læse, så jeg vil beskrive dets logik her.
Når det først startes på værten, gennemgår scriptet alle controllere og søger efter diske i GLPI-databasen efter serienumre; hvis det ikke finder det, søger det efter modellen. Hvis det ikke finder modellen, tilføjer det model af den nye disk til GLPI og indtaster denne disk i databasen.
Hvert nyt pass vil scriptet forsøge at opdage nye diske, men det ved ikke, hvordan man fjerner manglende diske, så du bliver nødt til at gøre det manuelt.
Eksempel på implementering
Script-lageret indeholder scriptet Deploy-Send-RAIDtoGLPI.ps1, som vil downloade et ZIP-arkiv med de nødvendige filer fra vores GLPI-server og implementere dem til hver vært.
Efter kopiering af filerne vil scriptet installere FusionInventory-agenten til at køre som en daglig opgave og oprette den samme opgave til vores script. Efter vellykket implementering vil vi endelig være i stand til at se drevene i sektionen Komponenter på computeren i GLPI.
Outcome
Nu, ved at gå til GLPI i menuen "Indstillinger" -> "Komponenter" -> "Harddiske", kan vi klikke på drevmodellerne og se deres antal for at forstå, hvad vi skal købe.
Kilde: www.habr.com