Intro to Redfish API on Dell servers

By Al
With the advent of public cloud organisations of all sizes are more and more looking to implement the same agile operational models that the hyper-scale cloud providers offer. As we would say "cloud is not a destination but an operational model". To this end we have seen in the last few years a proliferation of RESTful API's to manage pretty much everything in the infrastructure world. In particular the Redfish API is the joint effort by all server manufacturers to provide an API through which to consistently manage any vendors hardware. This resulted in a DMTF industry standard

Dell servers have traditionally managed through the OpenManage tool or through the iDRAC and its "racadm" command line tools. The adoption of the Redfish API with 13G servers fitted with the "DRAC with Lifecycle Controller" offered a complete different approach. The root of the API is accessed through the iDRAC as follows:

https://<iDRAC IP>/redfish/v1/

The Redfish API itself is very well thought and uses JSON and ODATA to standardise the data format across vendors. From the root it branches out into several categories as shown below. Note how it distinguishes between systems and chassis. This opens up the possibility of managing rack mounts, chassis-based and eventually even composable systems with a single API.


The DMTF has created a number of mockups in their website which allow you to explore what the Redfish API looks like for systems as disparate as:
  • Rack-Mounted Server
  • Rack-Mounted Server with Local Storage
  • Bladed System
  • Simple SAS Fabric
  • Bladed Partitions
  • Composable System
You can check them out by yourself here:


The following video first provides a tour of the DRAC. In particular you can see CPU, RAM and Disk (physical and logical) information as well as the log. Then we run a Python script which leverages the "requests" library to query the same information by navigating the various branches of the API. As you will observe the information obtains that way matches what we see in the DRAC in first place. If you are interested in the script you can visit the companion Github repository. This repo was created during the Pied Piper program at DellEMC:

https://github.com/cermegno/Redfish-lesson

One of the coolest things of the Redfish API from my point of view is that it contains its own metadata. You can query this information to understand what each object in the API is. You will see that this is presented in an XML format

The video then shows how to examine the boot order of the server. This can also be changed in order to for example install a new OS in the system via PXE boot. To that end, at the end of the video I demonstrate how to use the Redfish API to restart the server. Without more preamble I leave you the video.



Comments

Post a Comment

Popular posts from this blog

Sending PowerStore alerts via SNMP

By Al
Image
In this previous article we discussed how to leverage PowerStore's powerful API to collect audit logs and send them to a Syslog server . We used Logstash to do that because of its extensive list of plugins Sometimes I come across organizations that still have a requirement to send storage array Alerts to SNMP. As in the Syslog case, ultimately most modern monitoring tools today support collecting information via REST API because that's the way the application world is going, i.e. the cloud native way ... it would be fun to see Prometheus monitoring Kubernetes via SNMP :) However there is still some requirement out there for SNMP traps, so we will explore how to do it. For simplicity we will use the same toolset that we used in the previous article. I encourage you to revisit quickly the article as we did an extensive introduction to Logstash, with practical examples as well as a description of the logs available in PowerStore. I won't cover those aspects in this article I
Read more

Sending PowerStore logs to Syslog

By Al
Image
In this article we will explore how to get the logs from a DellEMC PowerStore array to a Syslog server. For this purpose we will use the PowerStore’s REST API, which is a great piece of engineering and a joy to work with as a developer. If you want to learn more about the PowerStore REST API I strongly recommend you quickly skim through the 2 articles I have written about the REST API. Part 1 - http://anzpiper.blogspot.com/2020/08/intro-to-dellemc-powerstore-rest-api.html Part 2 - http://anzpiper.blogspot.com/2020/08/powerstore-rest-api-best-practices.html In particular the second article demonstrates the capabilities of the REST API query language. This is a great feature I will use heavily in the last section so I strongly recommend you read that one at least As a side note, Syslog was developed in 1980. So this year it has turn 40 years old! That is a long time by any measure ... many of my colleagues were not even born in 1980. But in the technology scale it looks even scarier. 198
Read more

Electronic Nose - eNose

By Al
Image
In the previous article I provided details on VeeFarm which was one of the best projects we saw in ANZ Pied Piper 2019 edition and one of the best projects in the history of the program. The program inspired me and others to work together to showcase a great idea and the Pied Piper program itself during our presales conference. An idea I suggested to enhance VeeFarm was an electronic nose that could be used to detect the optimal ripening of the produce to advise the owner that it is the right time to pick it up the produce. This is an idea I had in the backburner for a while but never found the time to work on. Vee gave me the perfect excuse. The electronic nose, or eNose for short, is a custom PCB that hosts a range of gas sensors. For the proof of concept, I used the cheap MQ sensors. These are designed mostly for hobbyists and makers and they barely cost $1 per sensor. As one could expect, tweaking and calibrating these sensors it is even harder than the most expensive counter
Read more