Իմ աշխատանքում ես հաճախ եմ ունենում ենթակառուցվածքի մասին տեղեկատվության պակասի մոլուցքներ, և սպասարկվող սերվերների քանակի աճով դա վերածվում է իրական խոշտանգումների: Անգամ փոքր կազմակերպություններում ադմինիստրատոր եղած ժամանակ միշտ ուզում էի իմանալ, թե որտեղ է, որտեղ է միացված, որ մարդիկ են պատասխանատու սարքավորման կամ ծառայության համար, և որ ամենակարևորն է՝ արձանագրել փոփոխություններ այս ամենում: Երբ դուք գալիս եք նոր վայր և բախվում որևէ միջադեպի, շատ ժամանակ է ծախսվում այս տեղեկատվությունը փնտրելու համար: Հաջորդը, ես ձեզ կասեմ, թե ինչի հետ բախվեցի RuVDS-ում և ինչպես լուծեցի վերնագրում նշված խնդիրը:
նախապատմությանը
Որպես ձեռնարկության ադմինիստրատոր, ես տվյալների կենտրոնում աշխատելու փոքր փորձ ունեի, բայց ես տեսա RackTables-ը: Այն հստակ ցույց տվեց դարակը բոլոր սերվերներով, UPS-ով, անջատիչներով և նրանց միջև եղած բոլոր կապերով: RuVDS-ը չուներ նման համակարգ, այլ միայն Excel/paper ֆայլեր՝ սերվերների, դրանց որոշ բաղադրիչների, դարակների համարների և այլնի մասին տեղեկություններով։ Այս մոտեցմամբ շատ դժվար է հետևել փոքր բաղադրիչների փոփոխություններին: Բայց սերվերների համար ամենակարևոր և հաճախ փոխարինվող սպառվող նյութերը սկավառակներն են: Շատ կարևոր է պահպանել արդի տեղեկատվություն սկավառակների կարգավիճակի և դրանց ռազմավարական պահուստի վերաբերյալ: Եթե սկավառակը ձախողվի RAID զանգվածից և արագ չփոխարինվի, դա, ի վերջո, կարող է հանգեցնել ճակատագրական հետևանքների: Հետևաբար, մեզ իսկապես անհրաժեշտ է համակարգ, որը կհետևի սկավառակների գտնվելուն ու դրանց վիճակին, որպեսզի հասկանանք, թե ինչն է մեզ բացակայում և որ մոդելները պետք է գնենք:
Օգնության հասավ GLPI-ն՝ բաց կոդով արտադրանք, որը նախատեսված է ՏՏ բաժինների աշխատանքը բարելավելու և նրանց ITIL իդեալներին համապատասխանեցնելու համար: Բացի սարքավորումների գույքագրման և դարակների կառավարումից, այն ունի գիտելիքների բազա, սպասարկման սեղան, փաստաթղթերի կառավարում և շատ ավելին: GLPI-ն ունի բազմաթիվ պլագիններ, ներառյալ FusionInventory և OCS Inventory, որոնք թույլ են տալիս ավտոմատ կերպով տեղեկատվություն հավաքել համակարգիչների և այլ սարքերի մասին գործակալների տեղադրման և SNMP-ի միջոցով: Դուք կարող եք ավելին կարդալ GLPI-ի և պլագինների տեղադրման մասին այլ հոդվածներում, ամենալավը՝ պաշտոնական փաստաթղթեր. Դուք կարող եք տեղադրել այն մեր հոսթինգում պատրաստի կաղապարի վրա Լամպ.
Այնուամենայնիվ, գործակալը տեղակայելուց հետո մենք կբացենք համակարգչային բաղադրիչները GLPI-ում և կտեսնենք սա.
Խնդիրն այն է, որ պլագիններից ոչ մեկը չի կարող տեսնել LSI RAID զանգվածների ֆիզիկական սկավառակների մասին տեղեկությունները: Տեսնելով, թե ինչպես է այս խնդիրը լուծվում Zabbix-ում մոնիտորինգի համար՝ օգտագործելով PowerShell սկրիպտը lsi-raid.ps1 Ես որոշեցի գրել նմանատիպ մեկը՝ տեղեկատվություն GLPI-ին փոխանցելու համար:
Զանգվածի սկավառակների մասին տվյալները կարելի է ստանալ՝ օգտագործելով կարգավորիչ արտադրողի կոմունալ ծառայությունները, LSI-ի դեպքում սա StorCLI-ն է: Դրանից դուք կարող եք ստանալ տվյալներ JSON ձևաչափով, վերլուծել դրանք և փոխանցել GLPI API-ին: Մենք սկավառակները կկապենք համակարգիչների հետ, որոնք արդեն ստեղծել է FusionInventory-ն: Երբ նորից գործարկվի, սցենարը կթարմացնի սկավառակների տվյալները և կավելացնի նորերը: Սցենարն ինքնին Send-RAIDtoGLPI.ps1 է այստեղ՝ GitHub-ում. Հաջորդը ես ձեզ կասեմ, թե ինչպես օգտագործել այն:
Հաշիվ GLPI-ում ադմինիստրատորի պրոֆիլով` UserToken-ի և AppToken-ի կողմից ստեղծված API-ի միջոցով թույլտվության համար
Կարևոր կետ. Ինչ-ինչ պատճառներով, GLPI-ն ունի 2 տարբեր միավորներ սկավառակի մոդելի համար, սակայն «մեդիա տիպի» հատկություն չկա: Ուստի HDD-ի և SSD-ի հատկությունները ձայնագրելու համար ես որոշեցի օգտագործել «Hard Drive Models» բացվող ցանկը (front/devicemodel.php?itemtype=DeviceHardDriveModel): Սցենարը պետք է ունենա այս արժեքները GLPI տվյալների բազայում, հակառակ դեպքում այն չի կարողանա տվյալներ գրել սկավառակի մոդելի մասին: Հետևաբար, այս դատարկ ցուցակում պետք է նախ HDD, ապա SSD ավելացնել, որպեսզի տվյալների բազայում այս տարրերի ID-ները լինեն 1 և 2: HDD և SSD՝ իրենց համապատասխան ID-ների 1-ի և 1-ի փոխարեն.
Եթե դուք չեք ցանկանում անհանգստանալ սրա հետ կամ այլ կերպ եք օգտագործում այս բացվող ցուցակը, կարող եք պարզապես հեռացնել այս տողը սցենարից:
Դուք նաև պետք է «Element Statuses» (/front/state.php) սկավառակների համար կարգավիճակներ ավելացնեք: Ես ավելացրեցի «MediaError» (կար առնվազն մեկ սկավառակի մուտքի սխալ) և «OK» կարգավիճակները, մի տող սկրիպտում, որտեղ փոխանցվում են նրանց ID-ները, «2»՝ «OK» և «1»՝ «MediaError»-ի համար.
Այս կարգավիճակները անհրաժեշտ են հարմարության համար, եթե ձեզ հարկավոր չեն այս հատկությունները, կարող եք նաև ամբողջությամբ ջնջել այս տողը:
Բուն սկրիպտում մի մոռացեք ուղղել փոփոխականները ձերը: $GlpiCreds-ը պետք է պարունակի GLPI API սերվերի, UserToken-ի և AppToken-ի URL-ը:
Ինչ է գրված սցենարում
Ծանր JSON-ի վերլուծության և դատարկ եթե-ների պատճառով սցենարը դժվար է կարդալ, ուստի ես այստեղ նկարագրելու եմ դրա տրամաբանությունը:
Հոսթի վրա առաջին անգամ գործարկվելիս սկրիպտը անցնում է բոլոր կարգավորիչներով և որոնում է սկավառակներ GLPI տվյալների բազայում ըստ սերիական համարների, եթե այն չի գտնում, ապա փնտրում է մոդելը: Եթե մոդելը չի գտնում, ավելացնում է նոր սկավառակի մոդելը GLPI-ին և մուտքագրում է այս սկավառակը տվյալների բազա:
Յուրաքանչյուր նոր անցում սկրիպտը կփորձի հայտնաբերել նոր սկավառակներ, բայց չգիտի, թե ինչպես հեռացնել բաց թողնվածները, այնպես որ դուք ստիպված կլինեք դա անել ձեռքով:
Տեղակայման օրինակ
Սցենարների պահոցը պարունակում է Deploy-Send-RAIDtoGLPI.ps1 սկրիպտը, որը մեր GLPI սերվերից կներբեռնի ZIP արխիվ՝ անհրաժեշտ ֆայլերով և կտեղակայի դրանք յուրաքանչյուր հոսթին:
Ֆայլերը պատճենելուց հետո սկրիպտը կտեղադրի FusionInventory գործակալը, որպեսզի գործարկվի որպես ամենօրյա առաջադրանք և ստեղծի նույն առաջադրանքը մեր սցենարի համար: Հաջող ներդրումից հետո մենք վերջապես կկարողանանք տեսնել GLPI համակարգչի Components բաժնում դրայվները:
Արդյունք
Այժմ, անցնելով «Կարգավորումներ» -> «Բաղադրիչներ» - «Կոշտ սկավառակներ» ցանկի GLPI, մենք կարող ենք սեղմել սկավառակների մոդելների վրա և տեսնել դրանց քանակը՝ հասկանալու համար, թե ինչ է մեզ անհրաժեշտ գնել: