Progressively convert standard vaults into container

For systems with a large number of standard vaults, the IBM Cloud Object Storage System supports progressive migration and conversion of vaults over time.

About this task

To progressively convert a subset of the vaults deployed to an access pool, a System Administrator must utilize three access pools:
  1. An access pool for the standard vaults in Vault Mode
  2. An access pool for the conversion of standard vaults to container vaults
  3. An access pool for the converted container vaults in Container Mode

Procedure

  1. Specify the conversion options.
    1. To transfer the IP access control information from vault to container, check the “Migrate vault access control” option in the “Config Container Mode” Manager Web Interface or set “transferAllowedIpsToContainer” to true using “editContainerModeSettings.adm” Manager REST API; otherwise leave the option unchecked or set the value to false in the API, and the allowedIp remains in the vault.
    2. To transfer the hard quota from vault to container, check the “Migrate hard quota” option in the “Config Container Mode” Manager Web Interface or set “transferHardQuotaToContainer” to true using “editContainerModeSettings.adm” Manager REST API; otherwise leave the option unchecked or set the value to false in the API, and the hard quota remains in the vault
    3. To set restricted operation mode, check the “Create, configure, and delete containers using only the Service APIs” checkbox on the Container Mode Configuration page in the Manager Web Interface or “configureContainersViaServiceAPIOnly” to true using “editContainerModeSettings.adm” Manager REST API.
  2. Before conversion, optionally follow below step when performing progressive Vault Mode conversion on a subset or all of the vaults, otherwise, go to step 3. The progressive Vault Mode conversion uses AP1 to represent the access pool for vaults staying in the Vault Mode, AP2 for those in the Container Mode, and access pool AP3 to be shifted between the two Vault Mode.
    1. Ensure ap1 has been deployed to the subset of vaults to be converted.
    2. Add access pool ap3 to these vaults according to “Configure Vault” in Manager Web Interface or “editVaultAccess.adm” Manager REST API and pause for a couple of minutes to ensure the client traffic is switched to ap3.
    3. Use the same method to remove ap1 from these vaults; now only ap3 is deployed to the vaults pending conversion.
  3. Initiate conversion for a subset or all of vaults converting the access pool.
    1. When using Manager Web Interface, click on “Convert to Container Mode” on the specific access pool in Manager Web Interface.
    2. When using Manager API, execute the “systemContainerModeConfiguration.adm” to with “enable” set to true on the specific access pool.
    3. All of the vaults deployed to access pool are converted.
  4. Wait for the conversion to complete. Configuration requests to the Cloud Object Storage Manager are permitted again.
    1. During an ongoing vault to container conversion, the Cloud Object Storage Manager rejects all configuration requests. It is to ensure that the new containers have current metadata. The conversion can take several minutes.
    2. If the conversion fails, view the Conversion Failure Report. Resolve any failures and re-attempt the conversion.
    3. As result of the Vault Mode conversion, IBM COS
      1. Create a container for each vault. The new container's name matches the container vault's name as it is configured in the Cloud Object Storage Manager.
      2. Create a Storage Accounts for each account with permissions to a vault. Credentials are created for the storage account by using the access keys that are owned by the account.
      3. Identify bucket owner as the grantee chronologically granted with OWNER or READ/WRITE permission
      4. Transfer bucket and object ACL from standard vault to container.
      5. Transfer IP access control and hard quota to the destination according to conversion preference.
  5. Optional: Following the below steps post the conversion when performing progressive Vault Mode conversion.
    1. Add AP2 to the newly converted container vaults and pause for a couple of minutes to ensure client traffic is switched to AP2.
    2. Remove AP3 from these vault now, AP3 is not deployed to any vault and ready for next set of vaults conversion
  6. Optional: Repeat above steps to process additional subsets of vaults.
    1. Optional:
  7. Verify conversion results.

    A Service Admin uses Container Mode Service API to verify the result in Container Mode. An end user can use S3 API to verify bucket configuration and perform IO. Below is the expected result.

    • Storage Account Management Service API
      • “Account Listing” command returns the storage accounts for all users authorized to the standard vaults prior conversion.
      • “Specific Account Listing” returns the expected number of objects and usage, and one container shows up for each converted vault ( location constraint).
      • “Container Listing” command returns the expected usage and number of objects for the first container for the converted vault.
      • Usage
        • Need to wait about 20 minutes for the usage to be refreshed after conversion.
        • Note: it is expected that the usage in a container is slightly different from that in the standard vault.
    • Credentials Management Service API
      • “List Credentials” command returns the original credential for each account.
    • Container Resource Configuration Service API
      • “Retrieve Container Metadata” returns the bucket name, ACL, the bucket owner as the service instance (or storage account), the vault name as the storage location, and the optional IP Access control and hard quota based conversion decision. Note: There is no value in Cross Origin Region Support (CORS) or retention policy as part of the conversion. If later a bucket enables these features and specifies them using S3 “PUT Bucket CORS” or “PUT bucket protection” commands, then these value can be retrieved using this service API, IBM COS does not support specification on these parameters using service API.
      • Compare the ACL with the record user access information for the original standard vault. The users other than the bucket owner shall be granted explicitly in “acl” with the correct permission.
      • Verify that a new bucket can be created through the “Create a Bucket” service API command under the corresponding container vault and storage account.
      • Verify that a Service User can set and retrieve a container’s IP access control and hard quota using service API “Modify/Retrieve Container Metadata”
    • S3 API
      • Verify “Get Account” S3 operation returns only the containers owned by the account.
      • When restricted operation mode is set, verify that an end user cannot create a bucket, delete a bucket, set or retrieve ACL
      • Verify that S3 HEAD bucket operation does not return IP and hard quota information.

What to do next

After an access pool is converted, each of its deployed vaults will be container vaults. New I/O at the vault level is no longer possible on the vaults. Objects must be accessed by using container I/O methods, which require the use of account access keys. To ensure a smooth conversion, you should start the system by using access keys for vault I/O before you convert to Container Mode. Only container vaults can be deployed to the access pool.