In my work, I often experience obsessions about the lack of information about the infrastructure, and with the increase in the number of serviced servers, this turns into a real torture. Even when I was administering in small organizations, I always wanted to know what was where, where it was stuck, which of the people was responsible for which piece of hardware or service, and most importantly, to fix the changes in this to everyone. When you come to a new place and are faced with some kind of incident, it takes a lot of time to find this information. Next, I will tell you what I had to face in RuVDS, and how I solved the problem indicated in the title.
Background
As an enterprise admin, I had little experience in the data center, but I saw RackTables out of the corner of my eye. It clearly showed a rack with all the servers, UPSs, switches and all the connections between them. RuVDS did not have such a system, but only Excel / paper files with information about servers, some of their components, rack numbers, etc. With this approach, it is very difficult to track changes for small components. But the most important and frequently replaced consumable for servers is disks. It is very important to keep up to date information about the health of the drives and their strategic reserve. If a drive crashes out of the RAID array and is not quickly replaced, this can ultimately lead to fatal consequences. Therefore, we really need a system that tracks the location of disks and their condition in order to understandwhat we may not be enough and what models need to be purchased.
To the rescue came GLPI, an open source product designed to improve the performance of IT departments and bring them to the ideals of ITIL. In addition to equipment inventory and rack management, it has a knowledge base, service desk, document management and much more. GLPI has many plugins, including FusionInventory and OCS Inventory, that allow you to automatically collect information about computers and other devices through agent installation and SNMP. You can read more about installing GLPI and plugins in other articles, best of all - the official documentation . You can install it on our hosting on a ready-made LAMP template .
However, after deploying the agent, we will open the computer components in GLPI and see this:
The problem is that none of the plugins can see the physical disk information in LSI RAID arrays. After seeing how this issue was solved for monitoring in Zabbix using the PowerShell script lsi-raid.ps1, I decided to write a similar one for transferring information to GLPI.
Data about disks in the array can be obtained using utilities from the controller manufacturer, in the case of LSI, this is StorCLI. From it you can get data in JSON format, parse it and pass it into the GLPI API. The disks will be linked to computers that FusionInventory has already created. On repeated execution, the script will update data across disks and add new ones. The Send-RAIDtoGLPI.ps1 script itself is located here on GitHub . Next, I'll show you how to use it.
What is required
- GLPI 9.5.1 ( )
- FusionInventory Windows
- Windows 2012 R2 ( ) , management-VM , PowerShell 4
- MegaRAID
- PowerShell — PSGLPI
- GLPI Admin API, UserToken AppToken
An important point. For some reason, GLPI has 2 different entities for the disk model, but there is no "media type" property. Therefore, to record the properties of HDD and SSD, I decided to use the drop-down list "Hard disk models" (front / devicemodel.php? Itemtype = DeviceHardDriveModel). The script needs these values in the GLPI database, otherwise it will not be able to write data about the disk model. Therefore, you must first enter the HDD, then the SSD into this empty list, so that the IDs of these elements in the database are 1 and 2. If there are others, then replace the corresponding IDs in this line of the Send-RAIDtoGLPI.ps1 script after HDD and SSD instead of 1 and 2 :
deviceharddrivemodels_id = switch ($MediaType) { "HDD" { "1" }; "SSD" { "2" }; default { "" } }If you don’t want to bother with this, or you use this drop-down list differently, you can simply remove this line from the script.
You also need to add statuses for disks to the "Item Statuses" (/front/state.php). I added the statuses "MediaError" (there was at least one disk access error) and "OK", a line in the script where their IDs are passed, "2" for "OK" and "1" for "MediaError":
states_id = switch ($MediaError) { 0 { "2" }; { $_ -gt 0 } { "1" } }These statuses are needed for convenience, if you do not need these properties, you can also delete this line entirely.
In the script itself, do not forget to specify the variables for yours. $ GlpiCreds must contain the URL to the GLPI API Server, UserToken and AppToken.
What's in the script
Because of the cumbersome JSON parsing and the sheet of ifs, the script is hard to read, so I will describe its logic here.
At the first start on the host, the script goes through all controllers and searches for disks in the GLPI database by serial numbers, if it does not find it, it searches for a model. If it doesn’t find a model either, it adds the model of the new disk to GLPI and enters this disk into the database.
Each new pass the script will try to find new disks, but it cannot delete the missing ones, therefore, you will have to do it manually.
Deployment example
The script repository contains the Deploy-Send-RAIDtoGLPI.ps1 script that will download the ZIP archive with the necessary files from our GLPI server and deploy them to each host.
After copying the files, the script will install the FusionInventory agent running as a daily task and create the same task for our script. After a successful implementation, we will finally be able to see the disks in the Components section of the computer in GLPI.
Result
Now, going to GLPI in the menu "Settings" -> "Components" -> "Hard drives", we can click on the models of drives and see their number in order to understand what we need to purchase.
