Expanding storage pool

Virtual Storage Platform One SDS Block Storage Administrator Guide
Version
1.17.x
Audience
anonymous
Part Number
MK-24VSP1SDS002-04
CAUTION:

  • When a storage pool is expanded, the CPU usage of the storage node increases due to the internal processing. This might temporarily degrade host I/O performance.

  • When you use Data at rest encryption in the cloud model for which BYOL is selected as a pricing model or in the bare metal model, verify that you already performed the procedure for enabling the encryption environment settings and the procedure for enabling the storage pool encryption settings described in Overview of Data at rest encryption. If you completed setup according to the VSP One SDS Block Setup and Configuration Guide for your model, the procedure for enabling the encryption environment settings and procedure for enabling the storage pool encryption settings have already been completed. After you have completed the procedures described in this section, encryption environment settings and storage pool encryption settings cannot be changed.

Note:

(Cloud) In Multi-AZ configuration, the tiebreaker node, which does not have capacity (no drives exist), does not need to be confirmed in step 6.

  • Required role: Storage

  1. Before you add drives, verify the logical capacity, free capacity, and ID of the intended storage pool.

    If you use the CLI to specify a storage pool by name, check the name of the storage pool.

    REST API: GET /v1/objects/pools

    CLI: pool_list

  2. Obtain a list of drives to verify the ID of the drives to be added to the storage pool.

    REST API: GET /v1/objects/drives

    CLI: drive_list

    Tip:

    A drive whose status is "Offline" is not incorporated into the storage pool. You can verify the drive status from drive information.

  3. If you want to change the rebuild capacity policy and the tolerable number of drive failures for the storage pool, see Editing storage pool settings to perform necessary operation.
    CAUTION:

    • To be able to edit storage pool settings, the degree of redundancy of user data must not be low. If the degree of redundancy of user data is low, perform the recovery procedure, and then edit storage pool settings.

    • If you change the rebuild capacity policy after expanding storage pools, sufficient rebuild capacity might not be secured. Therefore, if you want to change the rebuild capacity policy, do so before expanding storage pools.

    • (Cloud) When the Floating base license is applied, note the following:

      • In some cases, changing the tolerable number of drive failures exceeds the licensed capacity of the AWS License Manager license. Before performing following procedure, see Estimating the storage pool capacity to confirm the consumed amount of a license (Cloud) to calculate the storage pool capacity after changing the tolerable number of drive failures. Then, verify whether the storage pool logical capacity is within the licensed capacity of the AWS License Manager license. Also, when estimating the required licensed capacity, round up the storage pool logical capacity to the unit of TiB.

        When multiple storage clusters share the AWS License Manager license, round up the storage pool logical capacity of each storage cluster to the unit of TiB first, and then sum the total to verify that the total logical capacity is within the licensed capacity of the AWS License Manager license.

        Example: If there are two storage clusters, one of which has 31.3 [TiB] and the other one has 47.7 [TiB] as storage pool logical capacity, round up those values to integers 32 [TiB] and 48 [TiB] respectively, and then sum the total as 80 [TiB].

        If the licensed capacity is insufficient, renew the license contract in AWS Marketplace.

      • The rebuild capacity policy cannot be changed from "Fixed."

  4. Expand the storage pool.

    Run either of the following commands with the ID of the intended storage pool and the IDs of all drives to be added specified.

    If you use the CLI, you can specify a name instead of the ID of the storage pool.

    REST API: POST /v1/objects/pools/<id>/actions/expand/invoke

    CLI: pool_expand

    Verify the job ID which is displayed after the command is run.

    CAUTION:

    To perform other operations, verify that the storage pool has been expanded as described in step 6 before doing so.

  5. Verify the state of the job by specifying the job ID.

    REST API: GET /v1/objects/jobs/<jobId>

    CLI: job_show

    If the job state is "Succeeded", the job is completed.

    Note:

    If rebuildStatus is "Error" due to insufficient capacity of the storage controller on the storage node with the new drive, the rebuild process is executed before the capacity allocation process to the controller that is executed next. If capacity to be allocated to a storage controller becomes depleted as a result of this Rebuild processing, capacity will not be allocated to the storage controller.

    Also, if the storage pool does not have sufficient rebuild capacity and the added drive capacity is replenished as the rebuild capacity, the internal processing of allocating capacity to the storage controller will not be performed. As a result, storage pool capacity will not be increased, an event log in step 6 will therefore not be output, and the logical and free capacity of the storage pool will be the same before and after this procedure.

    However, if the storage pool rebuild capacity policy is set to "Variable", the logical capacity and free capacity of the storage pool might increase even if the internal processing of allocating capacity to the storage controller is not performed.

    Subsequently, the capacity allocation process to storage controller, which is an internal process, is executed. Upon completion of these processes, capacity added by storage pool expansion becomes available.

    For the time required for capacity allocation processing to storage controllers, see Approximate processing time for allocating capacity to storage controllers (physical capacity) in this document.

  6. Obtain an event log to verify that the drive specified in step 4 is now available as storage pool capacity.

    REST API: GET /v1/objects/event-logs

    CLI: event_log_list

    Wait for the event log KARS16022-I or KARS16081-I to output as many existing storage nodes as possible. Until then, you may not be able to perform other operations.

    If as many event logs KARS16022-I or KARS16081-I as the number of storage nodes have been output, the storage pool has been expanded as specified.

    However, if a storage node failure occurs until as many KARS16022-I or KARS16081-I event logs as the number of the existing storage nodes are output, the storage pool might not be expanded. In this case, take action according to the VSP One SDS Block Troubleshooting Guide.

    If the event log KARS16046-I is output, the logical capacity (user-available capacity) could not be expanded because the capacity of the specified drive or the number of drives is insufficient. To expand the logical capacity, calculate the required capacity according to Capacity design when adding storage nodes, and then expand the storage pool according to Adding drives.

    CAUTION:

    If the write back mode with cache protection is enabled, you need to expand a storage pool for at least three drives for each storage node to configure logical capacity. Also, if you enable the write back mode with cache protection, you need to complete storage pool expansion for at least three drives for each storage node before enabling the mode. For details, see Enabling the write back mode with cache protection.

  7. Obtain information about the storage pool that has the newly-added drives.

    REST API: GET /v1/objects/pools

    CLI: pool_list

    Verify that the logical capacity and free capacity of the storage pool has increased as a result of adding the drives.

  8. Verify data movement subject to the storage controller.

    After expansion of the storage pool, user data is automatically moved so that the user data is stored evenly.

    After data moving starts, verify that the status of data moving (dataRebalanceStatus) becomes "Running" for a while, then changes to "Stopped" finally.

    You can verify the status of moving data (dataRebalanceStatus) and the progress rate [%] (dataRebalanceProgressRate) by using the following commands:

    Verify the status for all the storage controllers.

    REST API: GET /v1/objects/storage-controllers

    CLI: storage_controller_list

    You can skip this confirmation and perform the following step.

    Note:

    • The progress rate [%] (dataRebalanceProgressRate) is the ratio of the number of volumes whose data moving is completed against the total number of volumes subject to the storage controller. Updating the progress rate might take a long time depending on the volume capacity.

      You can estimate how long the data moving takes by using the following formula.

      (Used capacity of the storage pool managed by this storage controller1 × total logical capacity before adding storage nodes2 / total logical capacity after adding drives3) / 42 [MiB] × 2 [sec]

      1. The value of 1 is the following that is described in Managing storage controllers.

      　usedCapacity [MiB]: Consumed capacity [MiB] of storage pools managed by this storage controller

      (Bare metal) For the values of 2 and 3, see Capacity design (for HPEC 4D+1P) (Bare metal) , Capacity design (for HPEC 4D+2P), and Capacity design (for Mirroring) to calculate the total logical capacity after adding drives.

      (Cloud) For the values of 2 and 3, see Capacity design (for HPEC 4D+2P) or Capacity design (for Mirroring) to calculate the total logical capacity after adding drives.

      The required time varies according to the actual storage pool usage.

    • If one of the following events occurs during data movement, the processing status (dataRebalanceStatus) might become "Waiting."

      • The storage pool was expanded.

      • The volume was deleted.

      • The capacity of the storage pool managed by the storage controller was depleted.

      When the status of the data movement processing becomes "Waiting", the data movement is suppressed until the cause of the delay is resolved and the progress rate [%] (dataRebalanceProgressRate) becomes null. Once the cause of the delay is resolved, the data movement resumes. Progress rate [%] (dataRebalanceProgressRate) is recalculated and displayed from 0 again.

  9. (Bare metal) Back up the configuration information.

    Perform this step by referring to Backing up the configuration information (Bare metal).

    If you continue operations with other procedures, you must back up the configuration information after you have completed all operations.