|
|
Post by AMI_shirleyh on May 26, 2021 7:16:08 GMT
What kind of controllers should be populated inside StorageController Array(StorageControllers property) and StorageController Instance in the StorageControllers Collections(Controllers property) as both of them are available in the latest Schema Storage.1.9.0 ?
Storage.1.9.0
Case 1: "StorageControllers": {
"autoExpand": true,
"description": "The set of storage controllers that this resource represents.",
"items": {
"$ref": "#/definitions/StorageController"
},
"longDescription": "This property shall contain a set of the storage controllers that this resource represents.",
"readonly": true,
"type": "array"
}
Case 2: Controllers": {
"$ref": "http://redfish.dmtf.org/schemas/v1/StorageControllerCollection.json#/definitions/StorageControllerCollection",
"description": "The set of controllers instantiated by this storage subsystem.",
"longDescription": "This property shall contain a link to a resource collection of type StorageControllerCollection that contains the set of storage controllers allocated to this storage subsystem.",
"readonly": true,
"versionAdded": "v1_9_0"
}
|
|
|
|
Post by AMI_shirleyh on Jun 3, 2021 4:58:56 GMT
Can we add all types of Storage Controllers in StorageController Instance rather than array ?
|
|
|
|
Post by mraineri on Jun 3, 2021 12:21:44 GMT
The newer "Controllers" property was to address scalability concerns with the "StorageControllers" array within Storage. In NVMe (in particular NVMe-oF), controllers are created as hosts connect to the storage subsystem, and are destroyed as hosts disconnect. This means the StorageController array would grow and shrink over the course of time, which makes it very difficult to manage. While we've added the "Controllers" property to address this so new controller instances are their own resource, we haven't decided whether or not everything should migrate to the "Controllers" property. In all other storage use cases to date, the "StorageControllers" array is a fixed size; normally this is either a single controller or two redundant controllers, so using the "Controllers" property for this use case adds a bit of overhead.
We're certainly open to feedback in this space to see what others think the right path forward is.
|
|
|
|
Post by Richelle Ahlvers on Jun 3, 2021 16:17:44 GMT
From the broader storage ecosystem perspective - there are multiple different ways to model storage controllers, to reflect the different size and scale of types of controllers: For direct-attach configurations with hardware-based single (or dual) controllers, the Storage.StorageController model continues to make sense to use to model the storage controller. If there are a large number of controllers and/or the the controllers are logical or virtual, the StorageController.StorageController can be used instead (again, noting that this is a simple model. For more complex configurations, where sub-component modeling is required (e.g., external storage configurations): For these devices (such as EBOFs, arrays) the SNIA Swordfish team recommends instead that the controller be modeled as a computer system. This covers configurations such as SoC and black-box external array controller configurations consistently. As mraineri has already noted, for NVMe configurations, the StorageController.StorageController shall be used for the NVMe logical controllers: IO Controllers, Discovery Controllers, and Admin Controllers. |
|
|
|
Post by AMI_shirleyh on Jun 9, 2021 7:13:38 GMT
Thanks Raineri and Richelle for your replies. We will take it from here.
|
|
|
|
Post by igork on Jun 9, 2021 13:40:45 GMT
From the broader storage ecosystem perspective - there are multiple different ways to model storage controllers, to reflect the different size and scale of types of controllers: For direct-attach configurations with hardware-based single (or dual) controllers, the Storage.StorageController model continues to make sense to use to model the storage controller. If there are a large number of controllers and/or the the controllers are logical or virtual, the StorageController.StorageController can be used instead (again, noting that this is a simple model. For more complex configurations, where sub-component modeling is required (e.g., external storage configurations): For these devices (such as EBOFs, arrays) the SNIA Swordfish team recommends instead that the controller be modeled as a computer system. This covers configurations such as SoC and black-box external array controller configurations consistently. As mraineri has already noted, for NVMe configurations, the StorageController.StorageController shall be used for the NVMe logical controllers: IO Controllers, Discovery Controllers, and Admin Controllers. Hi, I still have a question. Let's say we have a system where there is a traditional controller and it also connected to external controllers. My understanding in that case we should just use the StorageController.StorageController for all controllers direct attached and external. Am I understand it correctly? Thank you, Igor |
|
|
|
Post by AMI_shirleyh on Jun 25, 2021 16:52:20 GMT
mraineri,
Can you please answer to Igork's question?
|
|
|
|
Post by mraineri on Jun 28, 2021 13:37:47 GMT
When you're mentioning an "external controller", are you talking about the case where a system is connected to a complex storage array that Richelle Ahlvers is mentioning? |
|
|
|
Post by igork on Jun 28, 2021 16:56:23 GMT
When you're mentioning an "external controller", are you talking about the case where a system is connected to a complex storage array that Richelle Ahlvers is mentioning? Yes, I mean a complex storage array. |
|
|
|
Post by mraineri on Jun 28, 2021 17:09:27 GMT
In that case, since you're modeling the server side of things, I would expect the storage subsystem would contain the controllers of the adapter that connects to the external storage system and the volumes presented to the server by the external storage system. I would certainly like others to weigh in on this since I have not personally thought about the end to end mapping of this type of connection.
|
|
