I mitt arbete upplever jag ofta tvångstankar om bristen på information om infrastrukturen, och med en ökning av antalet servrar som serveras övergår detta till verklig tortyr. Även när jag var administratör i små organisationer ville jag alltid veta vad var var, var den var inkopplad, vilka personer som var ansvariga för vilken maskinvara eller tjänst, och viktigast av allt, att registrera förändringar i allt detta. När du kommer till en ny plats och stöter på en incident går det åt mycket tid med att söka efter denna information. Därefter kommer jag att berätta vad jag stötte på i RuVDS och hur jag löste problemet som anges i rubriken.
förhistoria
Som företagsadministratör hade jag liten erfarenhet av att arbeta i ett datacenter, men jag fick en glimt av RackTables. Det visade tydligt racket med alla servrar, UPS, switchar och alla anslutningar mellan dem. RuVDS hade inget sådant system utan endast Excel/pappersfiler med information om servrar, vissa av deras komponenter, racknummer osv. Med detta tillvägagångssätt är det mycket svårt att spåra förändringar i små komponenter. Men de viktigaste och ofta ersatta förbrukningsvarorna för servrar är diskar. Det är mycket viktigt att hålla uppdaterad information om status för diskar och deras strategiska reserv. Om en enhet misslyckas från en RAID-array och inte snabbt byts ut kan detta i slutändan leda till ödesdigra konsekvenser. Därför behöver vi verkligen ett system som spårar platsen för diskar och deras tillstånd för att förstå vad vi kan sakna och vilka modeller vi behöver köpa.
GLPI kom till undsättning, en öppen källkodsprodukt utformad för att förbättra prestanda för IT-avdelningar och föra dem till ITIL-ideal. Förutom utrustningsinventering och rackhantering har den en kunskapsbas, servicedesk, dokumenthantering och mycket mer. GLPI har många plugins, inklusive FusionInventory och OCS Inventory, som låter dig automatiskt samla in information om datorer och andra enheter genom agentinstallation och SNMP. Du kan läsa mer om att installera GLPI och plugins i andra artiklar, bäst av allt - . Du kan installera den på vår hosting på en färdig mall .
Men efter att ha distribuerat agenten kommer vi att öppna datorkomponenterna i GLPI och se detta:
Problemet är att ingen av plugins kan se information om de fysiska diskarna i LSI RAID-arrayer. Efter att ha sett hur det här problemet löses för övervakning i Zabbix med hjälp av ett PowerShell-skript Jag bestämde mig för att skriva en liknande för att överföra information till GLPI.
Data om diskarna i arrayen kan erhållas med hjälp av verktyg från styrenhetstillverkaren; i fallet med LSI är detta StorCLI. Från den kan du hämta data i JSON-format, analysera den och skicka den till GLPI API. Vi kommer att länka diskarna till datorer som FusionInventory redan har skapat. När det körs igen kommer skriptet att uppdatera data på diskarna och lägga till nya. Själva skriptet Send-RAIDtoGLPI.ps1 är . Nästa kommer jag att berätta hur du använder den.
Vad kommer att krävas
- version 9.5.1 (testad på denna)
- plugin och agent för Windows
- Windows 2012 R2 (och senare) som ett värdsystem, eller en management-VM med en styrenhet insatt i den, PowerShell version 4 eller högre
- Installerad drivrutin för MegaRAID
- Modul för PowerShell -
- Konto i GLPI med adminprofil för auktorisering via API genererat av UserToken och AppToken
Viktig poäng. Av någon anledning har GLPI 2 olika enheter för diskmodellen, men det finns ingen "media type"-egenskap. Därför, för att spela in egenskaperna för hårddisken och SSD, bestämde jag mig för att använda rullgardinsmenyn "Hårddiskmodeller" (front/devicemodel.php?itemtype=DeviceHardDriveModel). Skriptet måste ha dessa värden i GLPI-databasen, annars kommer det inte att kunna skriva data om diskmodellen. Därför måste du lägga till först hårddisk, sedan SSD till denna tomma lista, så att ID:n för dessa element i databasen är 1 och 2. Om det finns andra, ersätt sedan i den här raden av skriptet Send-RAIDtoGLPI.ps1 efter HDD och SSD istället för 1 och 2 deras motsvarande ID:n:
deviceharddrivemodels_id = switch ($MediaType) { "HDD" { "1" }; "SSD" { "2" }; default { "" } }Om du inte vill bry dig om detta eller om du använder den här rullgardinsmenyn på ett annat sätt, kan du helt enkelt ta bort den här raden från skriptet.
Du måste också lägga till statusar för diskarna i "Element Statuses" (/front/state.php). Jag lade till statusen "MediaError" (det fanns minst ett diskåtkomstfel) och "OK", en rad i skriptet där deras ID:n överförs, "2" för "OK" och "1" för "MediaError":
states_id = switch ($MediaError) { 0 { "2" }; { $_ -gt 0 } { "1" } }Dessa statusar behövs för enkelhetens skull; om du inte behöver dessa egenskaper kan du också ta bort den här raden helt.
I själva skriptet, glöm inte att peka variablerna till dina. $GlpiCreds måste innehålla URL:en till GLPI API-servern, UserToken och AppToken.
Vad står i manuset
På grund av krånglig JSON-parsning och tomma ifs är skriptet svårt att läsa, så jag kommer att beskriva dess logik här.
När det först startas på värden går skriptet igenom alla kontroller och söker efter diskar i GLPI-databasen med serienummer; om det inte hittar det letar det efter modellen. Om det inte hittar modellen lägger det till modell av den nya disken till GLPI och matar in denna disk i databasen.
Varje nytt pass kommer skriptet att försöka upptäcka nya diskar, men det vet inte hur man tar bort saknade, så du måste göra det manuellt.
Implementeringsexempel
Skriptförrådet innehåller skriptet Deploy-Send-RAIDtoGLPI.ps1, som laddar ner ett ZIP-arkiv med nödvändiga filer från vår GLPI-server och distribuerar dem till varje värd.
Efter att ha kopierat filerna kommer skriptet att installera FusionInventory-agenten för att köras som en daglig uppgift och skapa samma uppgift för vårt skript. Efter framgångsrik implementering kommer vi äntligen att kunna se enheterna i sektionen Komponenter på datorn i GLPI.
Resultat
Nu, genom att gå till GLPI i menyn "Inställningar" -> "Komponenter" -> "Hårddiskar", kan vi klicka på enhetsmodellerna och se deras kvantitet för att förstå vad vi behöver köpa.
Källa: will.com