Updated: December 10, 2024
NOTE:
Due to the deprecation of the SmartStorageConfig data model and the adoption of the PLDM for RDE standard by HPE iLO and storage device providers, this blog post is deprecated.
Refer to the Storage data models documentation section for up to date information concerning Redfish storage management.
Introduction
Integrated Lights-Out (iLO) is an HPE ProLiant and Synergy server-embedded technology that delivers the core foundation for server intelligence along with out-of-band and in-band management facilities. This technology is a combination of the iLO ASIC that is part of the server board and the firmware that powers the ASIC. Out of the box, HPE iLO simplifies server setup, provides access to server health information, and enables server management at scale, including basic remote administration. Different generations of ProLiant Servers carry different versions of the iLO ASIC.
In HPE ProLiant and Synergy Gen10 servers, HPE iLO 5 introduced the management of storage controllers via its graphical user interface and via the Redfish RESTful API standard. Although videos already exist that cover the graphical user interface, I wanted to address this feature with a pure Redfish API approach, bypassing the iLOrest interface tool and its SmartController
macro commands.
In this article you start by learning how to cleanup and prepare a SmartRAID (SR) storage Controller for receiving a configuration with one or more logical drives using an HPE proprietary OEM process. Then, on this fresh environment, you will learn how to create a simple RAID array configuration prior to more complex ones.
Foreword
I've used the Postman API development to illustrate our examples. This should give you the ability to implement these raw examples using your own preferred language.
The reader should have the knowledge of HTTP request methods like GET
, PUT
and PATCH
.
Moreover, it is assumed that the reader knows how to manage Redfish sessions as described in the HPE Redfish API Reference documentation. More hints for managing iLO sessions with Redfish can be found in this article.
Storage data models
The Redfish standard defines a storage
data model as part of the ComputerSystem
resource type under the /redfish/v1/Systems/{item}/
URI. With the implementation of new standards, like the Platform Level Data Model for Redfish Device Enablement (PLDM for RDE), this model is fully operational in terms of read, write and event operations against modern external provider devices. Starting at Gen10 and Gen10 Plus (firmware 2.30+), HPE servers can take advantage of it. Note that it is the only storage data model implemented in Gen11 servers and beyond.
HPE initially developed the SmartStorage
Redfish OEM data model for HPE ProLiant DL580 Gen8 servers, before any Redfish specification was published. This model supports inventory (GET) and monitoring (Events) features only.
In HPE ProLiant Gen10, the SmartStorageConfig
resource was added to support the system's configuration. This OEM model uses a proprietary API that only supports the SmartRAID (SR) line of HPE storage controllers.
Note: The HPE OEM
SmartStorageConfig
data model is removed in HPE Gen11 servers.Note: This article focuses only on the HPE OEM
SmartStorageConfig
data model.
As stated earlier, HPE Gen10 and Gen10 Plus servers implement the description and the configuration of their Smart Storage SR devices respectively in the SmartStorage
and SmartStorageConfigX
(X is being an ID number) entry points of the same ComputerSystem
type. When multiple controllers are present in a system,
a SmartStorage/ArrayControllers/{item}/
entry point is present for each controller description and a SmartStorageConfigX
entry point exits for the configuration entry points. Note that {item}
and X
are not correlated.
Since the infrastructure used for this article contains only HPE storage devices and the iLO 5 firmware version is below 2.30, the Storage
DMTF URI is not populated. Only the SmartStorage
and SmartStorageConfigX
locations are populated. The following picture shows the URIs of four disk drives in the first controller of our infrastructure. Their properties can be obtained with a simple GET
request.
If you only need the physical location of the disks to use for your logical drives, you can GET
them from the SmartStorageConfig
location as shown below. Note that for the first controller found in the system, the X
ID number is omitted.
Storage controller configuration process
As described in my previous blog, Master the Redfish Server States to improve your monitoring and management applications, and to be sure the configuration process happens smoothly, you should first verify that your managed systems are not at the UEFI/System Utilities
level. Being in the Off
state is a good state to start.
Modification of Bios and storage controller configurations are performed in two stages as explained in the Setting Bios and Storage Controller Properties with Redfish article. The first stage consists of setting the required parameters in the "pending settings area" of the Redfish data model (/redfish/v1/Systems/{item}/SmartStorageConfig/Settings/
). During the next server reboot, parameters in the "pending settings area", after validation, are transferred to the "current configuration" at /redfish/v1/Systems/{item}/SmartStorageConfig/
.
Upon reboot, and once the server has finished its Pre-OS Tasks (POST), you should check carefully whether the modifications have been accepted as the current configuration.
The DataGuard property
The management of HPE Smart Storage devices requires a proper understanding of the DataGuard
property part of the SmartStorageConfig
sub-tree. The value of this attribute "indicates whether or not data destructive actions are allowed" as explained in the API Reference documentation.
This property is set in the pending settings (SmartStorageConfig/Settings
) along with the directives to be performed by the Smart Storage device (i.e. Logical Volume Creation, Deletion...). During the next POST, the firmware checks its value and performs, or does not perform, the requested directives.
If the value is Strict
, which is the default value when not changed in the pending settings, the firmware denies any destructive data action (create/delete logical drives or clear drive metadata....).
If the value is set to Disabled
, destructive data actions are allowed. Finally, when the value is Permissive
, only destructive data actions are allowed on the specified objects.
Refer to the iLO RESTful API documentation for more information.
Storage controller and physical disks preparation
Imagine you just received a bunch of brand new servers or you want to re-deploy servers for a new project. In this context, you would want to remove completely the entire storage configuration as well as all meta data stored in the physical drives to get a clean Smart Storage subsystem.
The HPE OEM storage subsystem models logical drives as a JSON collection stored in an array of objects represented like: "LogicalDrives": [{ld-1},{ld-2,...{ld-n}]
. Each ld-i
of this array contains the necessary properties to describe precisely the corresponding logical drive.
The following screenshot shows the LogicalDrives
array containing one element and its attributes. In it, you can see that this logical drive is a RAID 0 made of a single data drive (1I:3:1
).
Removing all logical drives
Removing all the logical drives of an HPE SR Smart Storage Controller is equivalent to the removal of all the elements of the LogicalDrives
array. In practice, you need to request an empty array to the Redfish server.
Since this action is data destructive, you must disable the DataGuard
property to make sure the firmware allows this operation during the next reboot/POST of the system.
The next screenshot contains all the necessary information to complete this remove operation: Perform an HTTP PUT
to the pending settings (SmartStorageConfig/Settings/
):
Clearing disk drives configuration metadata
HPE Smart Array RAID uses a reserved area at the end of each physical drive to store information about the logical drive configuration they are part of. When the Smart Storage Administrator (SSA) application or Redfish is used to delete a logical drive, the metadata is cleaned up. However, if drives are moved around, there may be leftover metadata on the drives. The controller may show a failed logical drive or keep the drive from being presented to the OS. The ClearConfigurationMetadata
action with the DataGuard
property disabled using the PATCH
method can be used to remedy this problem.
If you want to perform a single request removing all the logical drives and clearing the metadata, you have to perform a PUT
of the pending settings with the following body:
{ "Actions": [ { "Action": "ClearConfigurationMetadata" } ], "LogicalDrives": [], "DataGuard": "Disabled" }
Removing a single/specific logical drive
To delete a specific logical drive you have to send a PUT
request to the SmartStorageConfig/settings
(pending settings). This request must contain the unique identifier of the desired logical drive as well as the DataGuard
property set to Permissive
to avoid the removal of other logical drives, if any:
Sanitizing / disk drives
In addition to the removal of logical drives and the meta data cleanup of physical drives, you may want to erase / sanitize a list of physical drives. To perform this (long) operation, send the following PATCH
action with the correct list of the drives to erase, separated by a comma. Don't forget to disabled the DataGuard
property as well:
The ErasePattern
property supports the following values:
SanitizeRestrictedBlockErase SanitizeUnrestrictedBlockErase SanitizeRestrictedOverwrite SanitizeUnrestrictedOverwrite SanitizeRestrictedCryptoScramble SanitizeUnrestrictedCryptoScramble OnePass TwoPass ThreePass
As mentioned above, the sanitize process is extremely long and you can retrieve the erase status in the disk drive properties under the SmartStorage
sub-tree:
Logical drive creation
Logical drives can be created using the PUT
method. In some circumstances a PATCH
can be used. To keep things simple, I'll only use the PUT
method.
For this section, start with the clean infrastructure generated previously to create a 100GB RAID1 logical drive with a Roaming
spare drive.
Then, add a RAID0 Logical drive located on a single hard disk without spare drive and spanning the entire disk (300GB).
Finally, add a second logical drive of 50 GB in the RAID1 array created earlier.
While this scenario may not be completely realistic, the goal here is to more didactic than realistic.
First logical drive creation
In this clean context, you just need to send a PUT
request to the SmartStorageConfig/settings
(pending settings) with the properties of the desired logical drive as an element of the LogicalDrives
array and the DataGuard
value set to Disabled
.
The following picture shows the entire body of the PUT
request with the mandatory properties in green boxes: DataGuard
, DataDrives
list, Raid
type, SpareDrives
list and SpareRebuildMode
. Other properties will be defaulted if not supplied.
A 200
return status with a SystemResetRequired
"Error"
message indicates that the remote SmartArray pending settings has been changed.
Upon reboot of the server, you should verify that the current configuration contains only the Success
message. This ensures that the configuration happened effectively.
Creating more logical drives
Now, I would like to show you how to add a logical drive without altering the existing configuration. This operation could be noted "=+
" in high level programming languages. I will use this analogy to build the body of the corresponding PUT
request.
The "=
" portion of this process is performed by copying the entire SmartStorageConfig
current configuration into the body of a PUT
request. The remote iLO Redfish server is smart enough to keep only needed properties.
The "+
" part consists of adding the desired logical drive into the LogicalDrives
array and changing the DataGuard
value.
The body of this PUT
request is now ready to be sent to the SmartStorageConfig/settings
(pending settings) of the managed iLO.
Again and again, you must check the return status, reboot if it is Ok
, and verify that the current configuration contains only a single Success
message to be sure that your modification was made.
Adding a logical drive in an existing disk array
This last exercise consists of adding a RAID0 logical drive of 50GB in the first storage array that was created earlier. This array has a capacity of 300GB and, only 100GB are consumed with logical drive RAID1-1-100
.
As I showed you in the previous section you have to perform a "=+
" operation including a modification of the DataGuard
property and the addition of a logical drive.
The following screenshot shows the characteristics of the added RAID0 logical drive. It mentions its size as well as the DataDrives
list and the spare drive used in the storage array created for the RAID1 logical drive in my first example. This ensures the creation of the desired logical drive in the right place.
After reboot, the requested RAID0 logical drive is visible in the current configuration. Note that the SpareRebuildMode
has been automatically adjusted to Dedicated
since Roaming
is not a valid value anymore.
Conclusion
Redfish is a powerful, open source method of being able to manage systems. With a RESTful interface, it is designed to leverage existing internet standards and tool chains, making it usable by both amateurs as well as professionals.The ability of managing HPE Smart Storage with Redfish is a major step forward to the full control of HPE Gen10 and future servers using a single RESTful API.
Make sure you continue to follow my blog posts on HPE DEV for more hints on working with Redfish in HPE environments. You can connect with me in the Redfish channel on Slack for specific questions.
Related
Accessing iLO Redfish APIs and HPE OneView APIs on Ansible AWX
Feb 9, 2021Automate boot from SAN target configurations using Redfish
Jun 1, 2023
Benefits of the Platform Level Data Model for Firmware Update Standard
Jun 7, 2022