Locking resources

REST API Reference Guide for Virtual Storage Platform 5000, Virtual Storage Platform E Series, and Virtual Storage Platform G/F Series

Version
93-07-0x
90-09-0x
88-08-10
Audience
anonymous
Part Number
MK-98RD9014-17
If multiple REST API clients simultaneously attempt to perform operations on the same resource, unexpected configuration changes might be performed, with results other than those anticipated. In the REST API, the user can lock the resource group allocated to them so that other users cannot change the configurations of resources in the locked resource group.

The REST API controls locks on a session basis. All resources of the resource group allocated to the user who generated a session are locked. When the resource group allocated to you is locked by another user, you cannot obtain a lock for the resource group.

Only the session used for the request that locked a resource can run a configuration-change request for the locked resource. If one user account generated multiple sessions, a configuration-change request cannot be run if the specified session is different from the session used to lock the resource. (If the specified session is different, even if it is generated by the same user account, the session cannot run the configuration-change request.)

However, operations that do not change the configurations of the resources on the storage system, such as a change of a pair status and operations for the REST API server, can be run without being affected by exclusive control by locking. The following operations are not affected by locking:
  • Generating or discarding a session
  • Getting information

    Note that, when you obtain information by specifying query parameters, you might not be able to obtain the correct information because the operation might be affected by configuration-change operations performed by other REST API clients or by the storage management software. To obtain the correct information, be sure to lock the relevant resources before performing the operation.

  • Sending the ping command to a specified host
  • Setting the priority levels of ALUA paths
  • Splitting, resynchronizing, or restoring ShadowImage pairs (for each copy pair or in units of copy groups)
  • Splitting, resynchronizing, or restoring Thin Image pairs (for each snapshot or in units of snapshot groups)

    Creating, deleting, assigning secondary volumes to, or unassigning secondary volumes from Thin Image pairs (including operations in units of snapshot trees)

  • Registering or deleting remote storage system information on the REST API server
  • Splitting, resynchronizing, or taking over TrueCopy pairs or Universal Replicator pairs (for each copy pair, or in units of copy groups)
  • Operations related to information about an iSCSI target of a port on an external storage system (obtaining information, performing a login test)
  • Uploading the files required for initial configuration
  • Updating the cache of storage system configuration information

When a single user account uses multiple sessions, only one of the sessions can be used to lock resources.

When operations are complete and the resources no longer need to be locked, run the API command for unlocking the resource group. If the session used for locking is discarded, the locked resource group will be unlocked at the same time. If the session is discarded due to a session timeout, the locked resource group will also be unlocked at the same time.

Tip:
  • A session timeout occurs even when an asynchronous processing API operation is being run. If you want to continue to lock the resources while an asynchronous processing API operation is being run, prevent a session timeout by taking a measure, such as periodically issuing the request that checks the job status.
  • If you want to forcibly unlock resources because a REST API client unexpectedly continues to lock the resources or the token is lost, either wait until the session times out or forcibly discard the session by using a user who belongs to the Administrator user group (built-in user group) .
  • If the locked user information (such as the role and resource group) is changed while the resource is being locked, the changes are applied to operations after the resource is unlocked.

Operation flow for running API requests by using the lock functionality

The following table describes the operation flow for running API requests by locking resource groups.

Step

Operation

Item to be specified for the Authorization header

1

Generate a session.

User ID and password

2

Lock the resource group.

The token of the session generated in step 1

3

Perform operations on the locked resource.

The token of the session generated in step 1

4

Unlock the resource group.

The token of the session generated in step 1

5

Discard the session.

The token of the session generated in step 1

Operation flow for running API requests by using the lock functionality (for remote copy)

For copy operations between storage systems (remote copy), to perform operations to change configurations of a copy group or the resources in a copy group by locking the target resources, lock the resources of both the local and remote storage systems. To lock the both resources and perform operations on the locked resources, specify the token of the session of each storage system for the Authorization header and the Remote-Authorization header. Note that the Remote-Authorization header is used only for the API commands that are used for the following object types:
  • remote-mirror-copygroups
  • remote-mirror-copypairs
  • remote-storages

The following table describes the operation flow for when the resources of both the local and remote storage systems are locked.

Step

Storage system on which operations are performed

Operation

Item to be specified for the Authorization header

1

Local storage system

Generate a session.

User ID and password for the local storage system

2

Remote storage system

Generate a session.

Specify at least 60 seconds for the timeout time of a session generated on the remote storage system.

User ID and password for the remote storage system

3

Local storage system

Lock the resource group.

The token of the session generated in step 1

4

Remote storage system

Lock the resource group.

The token of the session generated in step 2

5

Local storage system

Perform operations on a copy group or the resources in a copy group.

The token of the session generated in step 1

Also, specify the token of the session generated in step 2 for the Remote-Authorization header.

6

Local storage system

Unlock the resource group.

The token of the session generated in step 1

7

Remote storage system

Unlock the resource group.

The token of the session generated in step 2

8

Local storage system

Discard the session.

The token of the session generated in step 1

9

Remote storage system

Discard the session.

The token of the session generated in step 2

Tip:

If creation of a remote copy pair is run, the initial copy processing for creating a pair on the storage system might take a long time. In this case, if resources are locked until the pair is created, other clients cannot use the resources of the resource group for a long time. Resources do not need to be locked by the REST API after the storage system accepts the request that creates a pair. Therefore, when you create a remote pair, we recommend that you unlock the resources after the job status is changed to "StorageAccepted".