PowerStore REST API: Using Filtering to Fine Tune Your Queries
Fri, 11 Mar 2022 16:03:19 -0000
|Read Time: 0 minutes
The PowerStore REST API provides a powerful way to manage a PowerStore cluster, mainly when using one’s own scripts [3] or automation tools.
In some areas of PowerStore, almost all of its functionality is available when using the REST API – and sometimes even more when the required attributes are unavailable in the PowerStore Manager GUI.
A great place to start learning more about the REST API is the integrated SwaggerUI [2] which provides online documentation with test functionality on your system. SwaggerUI uses an OpenAPI definition. Some 3rd party tools can leverage the same OpenAPI definition, and can be downloaded from SwaggerUI. SwaggerUI is available on all PowerStore models and types by using https://<PowerStore>/swaggerui in your preferred browser.
When working with the PowerStore REST API it’s not always obvious how to query some attributes. For example, it’s easy to filter for a specific volume name to get id, size, and type of a volume or volumes when using “*” as wildcard:
To query for all volumes with “Test” somewhere in its name, we could use
name=like.*Test*
as the query string:
% curl -k -s -u user:pass -X GET "https://powerstore.lab/api/rest/volume?select=id,name,size,type&name=like.*Test*" | jq . [ { "id": "a6fa6b1c-2cf6-4959-a632-f8405abc10ed", "name": "TestVolume", "size": 107374182400, "type": "Primary" } ]
In that example, although we know that there are multiple snapshots for a particular volume, the REST API query that uses the parent volume name does not show the related snapshots. It’s because snapshots must not have the name of the parent volume in their name. From PowerStore Manager we know that this volume has three snapshots, but their names do not relate to the volume name:
How is it possible to get the same output with a REST API query? We know that everything in PowerStore is managed with IDs, and the API description in SwaggerUI shows that a volume could have an attribute parent_id underneath the protection_data section.
All volumes with a protection_data->>parent_id that is equal to the ID of our “TestVolume” show the related snapshots for the TestVolume. The key for the query is the following syntax for the underlying attributes:
protection_data->>parent_id=eq.a6fa6b1c-2cf6-4959-a632-f8405abc10ed
The resulting curl command to query for the snapshot volumes shows the same syntax to select “creator_type” from a nested resource:
% curl -k -s -u user:pass -X GET 'https://powerstore/api/rest/volume?select=id,name,protection_data->>creator_type,creation_timestamp&protection_data->>parent_id=eq.a6fa6b1c-2cf6-4959-a632-f8405abc10ed' | jq . [ { "id": "051ef888-a815-4be7-a2fb-a39c20ee5e43", "name": "2nd snap with new 1GB file", "creator_type": "User",
"creation_timestamp": "2022-02-03T15:35:53.920133+00:00" }, { "id": "23a26cb6-a806-48e9-9525-a2fb8acf2fcf", "name": "snap with 1 GB file", "creator_type": "User", "creation_timestamp": "2022-02-03T15:34:07.891755+00:00" }, { "id": "ef30b14e-daf8-4ef8-8079-70de6ebdb628", "name": "after deleting files", "creator_type": "User", "creation_timestamp": "2022-02-03T15:37:21.189443+00:00" } ]
Resources
For more white papers, blogs, and other resources about PowerStore, please visit our PowerStore Info Hub.
Related resources to this blog on the Info Hub:
- For a general PowerStore Manager overview, see Dell PowerStore Manager Overview
- To learn more about volumes and volume families: PowerStore: Snapshots and Thin Clones
- An alternative to REST API: What is PowerStoreCLI Filtering?
For some great video resources referenced in this blog, see:
- [1] Dell PowerStore REST API Part 1 - Introduction
- [2] Dell PowerStore REST API Part 2 - PowerStore SwaggerUI
- [3] Dell PowerStore REST API Part 3 - Python script example
See also this PowerStore product documentation:
Author: Robert Weilhammer, Principal Engineering Technologist
Related Blog Posts
PowerStore REST API: Using Filtering to Fine Tune Your Queries
Thu, 26 Jan 2023 17:40:56 -0000
|Read Time: 0 minutes
The PowerStore REST API provides a powerful way to manage a PowerStore cluster, mainly when using one’s own scripts [3] or automation tools.
In some areas of PowerStore, almost all of its functionality is available when using the REST API – and sometimes even more when the required attributes are unavailable in the PowerStore Manager GUI.
A great place to start learning more about the REST API is the integrated SwaggerUI [2] which provides online documentation with test functionality on your system. SwaggerUI uses an OpenAPI definition. Some 3rd party tools can leverage the same OpenAPI definition, and can be downloaded from SwaggerUI. SwaggerUI is available on all PowerStore models and types by using https://<PowerStore>/swaggerui in your preferred browser.
When working with the PowerStore REST API it’s not always obvious how to query some attributes. For example, it’s easy to filter for a specific volume name to get id, size, and type of a volume or volumes when using “*” as wildcard:
To query for all volumes with “Test” somewhere in its name, we could use
name=like.*Test*
as the query string:
% curl -k -s -u user:pass -X GET "https://powerstore.lab/api/rest/volume?select=id,name,size,type&name=like.*Test*" | jq . [ { "id": "a6fa6b1c-2cf6-4959-a632-f8405abc10ed", "name": "TestVolume", "size": 107374182400, "type": "Primary" } ]
In that example, although we know that there are multiple snapshots for a particular volume, the REST API query that uses the parent volume name does not show the related snapshots. It’s because snapshots must not have the name of the parent volume in their name. From PowerStore Manager we know that this volume has three snapshots, but their names do not relate to the volume name:
How is it possible to get the same output with a REST API query? We know that everything in PowerStore is managed with IDs, and the API description in SwaggerUI shows that a volume could have an attribute parent_id underneath the protection_data section.
All volumes with a protection_data->>parent_id that is equal to the ID of our “TestVolume” show the related snapshots for the TestVolume. The key for the query is the following syntax for the underlying attributes:
protection_data->>parent_id=eq.a6fa6b1c-2cf6-4959-a632-f8405abc10ed
The resulting curl command to query for the snapshot volumes shows the same syntax to select “creator_type” from a nested resource:
% curl -k -s -u user:pass -X GET 'https://powerstore/api/rest/volume?select=id,name,protection_data->>creator_type,creation_timestamp&protection_data->>parent_id=eq.a6fa6b1c-2cf6-4959-a632-f8405abc10ed' | jq . [ { "id": "051ef888-a815-4be7-a2fb-a39c20ee5e43", "name": "2nd snap with new 1GB file", "creator_type": "User",
"creation_timestamp": "2022-02-03T15:35:53.920133+00:00" }, { "id": "23a26cb6-a806-48e9-9525-a2fb8acf2fcf", "name": "snap with 1 GB file", "creator_type": "User", "creation_timestamp": "2022-02-03T15:34:07.891755+00:00" }, { "id": "ef30b14e-daf8-4ef8-8079-70de6ebdb628", "name": "after deleting files", "creator_type": "User", "creation_timestamp": "2022-02-03T15:37:21.189443+00:00" } ]
Resources
For more white papers, blogs, and other resources about PowerStore, please visit our PowerStore Info Hub.
Related resources to this blog on the Info Hub:
- For a general PowerStore Manager overview, see Dell PowerStore Manager Overview
- To learn more about volumes and volume families: PowerStore: Snapshots and Thin Clones
- An alternative to REST API: What is PowerStoreCLI Filtering?
For some great video resources referenced in this blog, see:
- [1] Dell PowerStore REST API Part 1 - Introduction
- [2] Dell PowerStore REST API Part 2 - PowerStore SwaggerUI
- [3] Dell PowerStore REST API Part 3 - Python script example
See also this PowerStore product documentation:
Author: Robert Weilhammer, Principal Engineering Technologist
Dell PowerStore – Easily Create a Metro Volume in Six Clicks
Thu, 04 May 2023 20:12:42 -0000
|Read Time: 0 minutes
In this short blog, I’ll walk you through the configuration of a metro volume and prove that it’s possible to enable a metro session in just six clicks, when the remote system and a standard volume are already setup.
A metro volume is a volume that runs a bi-directional synchronous replication between two different sites. Hosts using either side of a metro volume get active-active simultaneous access on both sides of the metro volume. The use case for a PowerStore metro volume is a vSphere Metro Storage Cluster (also known as a stretched cluster configuration) with VMware vSphere.
PowerStore metro volumes support a latency maximum of 5ms and a maximum distance of 80miles/100km. After the operator sets up a metro volume, PowerStore internally creates a metro session to control the replication between the two sites. When the remote system relationship is set up on PowerStore, and the volume is mapped to one or more hosts, it requires just six additional clicks to set up a metro session for a standard volume, as shown here:
1. Select the volume. 2. Navigate to PROTECT. 3. Select Configure Metro Volume.
|
|
4. Click the pull down to select the remote system. 5. Select the remote system. 6. Click CONFIGURE | |
To mitigate any performance impact on the source system for the new, unsynchronized metro volume, PowerStore immediately starts with asynchronous replication and switches into synchronous replication once the data is in sync. | |
Because a metro session replicates all IO synchronously, active-active host access is possible on both ends of the metro volume. Even during the initial synchronization, hosts can map the new volume on the replication destination but only get active paths when the metro session is in an active-active state.
|
When hosts are in a uniform configuration, active paths are provided by both participating PowerStore clusters. The following example shows a uniformly connected host that can access the metro volume in two storage networks (fabrics).
Here is the mapping of individual NICs in this example:
ESXi Host | NIC 1 | PowerStore-A | Node A Node B | C0:T0:L2 (Active I/O) C0:T1:L2 |
|
| PowerStore B | Node A Node B | C0:T2:L2 C0:T3:L2 |
| NIC2 | PowerStore-A | Node A Node B | C1:T0:L2 (Active I/O) C1:T1:L2 |
|
| PowerStore B | Node A Node B | C1:T2:L2 C1:T3:L2 |
Resources
Author: Robert Weilhammer, Principal Engineering Technologist
https://www.xing.com/profile/Robert_Weilhammer