To mitigate the risk of data corruption during a double failure situation—where the array is degraded plus there is an abnormal system shutdown—commonly encountered in RAID5/6 configurations, journaling has been introduced. This feature ensures that incomplete IO operations are replayed upon service restart. Starting from version 1.6, each physical drive in newly created drive groups will automatically reserve a small range for journaling space, activating journaling automatically when the drive group enters a degraded state.
Journaling can be configured with three modes:
always_off: Journaling is disabled in both optimal and degraded states.
degraded_only (Default): Journaling is activated only when the drive group is degraded.
always_on: Journaling is active regardless of the drive group's state (optimal or degraded).
To modify the journaling attribute, use the drive group edit command. For instance, to enable journaling at all times:
To enable comprehensive NVMe RAID management capabilities, Graid Technology provides the 'SupremeRAID™ Management Console'. This web-based graphical user interface offers intuitive visualization and statistical reporting features, addressing the growing demand for visual management tools. The Console delivers real-time monitoring of RAID array status, detailed performance metrics, and streamlined configuration management. However, this feature is embedded in SupremeRAID™ with the default state set to disabled. To enable the Management Console, please follow these steps:
Check the license state, ensure it is in to 'APPLIED' to enable feature usage.
This release includes RESTful API services featuring HTTP response codes, CRUD functionalities, and specific status codes from our SupremeRAID™, simplifying third-party integration. We also offer Swagger-generated interactive documentation to help users test and understand our APIs effectively, please follow these steps to start:
This feature allows users to execute customized logic to unlock the physical drive before the SupremeRAID™ driver takes control. Users can specify a script path by adding sed_unlock_script=/path/to/script under the [global] section in the driver configuration file /etc/graid/graidserver.conf. During script execution, the device path (e.g., /dev/nvme#) and the NQN of the corresponding physical drive will be passed as the first and second arguments, respectively.
One use case is integrating with an external Key Management Server (KMS) and using drives that support the SED feature. Users can develop a script to retrieve the SED key from the KMS and unlock the SED drive before the SupremeRAID™ driver brings it up as a physical drive. This way, the SupremeRAID™ driver does not need to hold the key, thereby enhancing security.
Since NVMe drives are directly connected to the CPU, users can utilize SED management tools such as sedcli or sedutil for the complete management lifecycle of SED-supported drives. Thus, the SupremeRAID™ driver only needs to store the admin1 key to unlock the drive before taking control via the GPU. Periodic rotation of these keys is a common practice for enhancing data security, meaning users may need to rotate the admin1 and SID keys while the drive group is operational and under GPU control. This necessitates performing the operation through the SupremeRAID™ driver.
To facilitate this, we introduced a key replacement subcommand enabling users to replace keys during drive group operation. Here's an example of replacing the SID and admin1 key for a physical drive:
If the original key is present in the configuration file provided by the user, the SupremeRAID™ driver will replace the stored key; otherwise, it will only command the SSD to replace the SID and admin1 keys. This command also supports batch key replacement for multiple physical drives. For instance, to replace keys for 23 physical drives sharing the same keys:
Moreover, to simplify key storage for multiple NVMe drives before physical drive creation, we've slightly modified the edit SED key command. The command graidctl edit config sed has been changed to graidctl edit config sed_key, supporting three input methods:
If only the NQN is specified, the command will prompt the user to enter the keys, avoiding bash history records.
Specifying both the NQN and SED key facilitates scripting but requires caution regarding bash history.
The --input-file option allows importing multiple keys from a file.
SupremeRAID™ Linux Driver 1.6.0 Release Notes, Software, and Documentation
