Defining object storage classes

You can use up to four object storage classes for applications with different performance and redundancy requirements. The first storage class is set automatically during the S3 cluster creation. The other three classes you can define manually by using the ostor-ctl set-storage-class command.

Once a storage class is created, use the ostor-ctl cfg-storage command to change its redundancy settings. With this command, you can modify all storage classes, including the first one.

Prerequisites

• The S3 cluster is created, as described in Creating the S3 cluster.

To create a storage class

1. Obtain the password for your storage cluster. For example:

   # vinfra cluster password show
   +----------+---------+
   | Field    | Value   |
   +----------+---------+
   | id       | 1       |
   | name     | cluster |
   | password | W3HMNq  |
   +----------+---------+
   

2. Find out the ID of the object storage volume. For example:

   # ostor-ctl get-config -V
   VOL_ID             TYPE     STATE
   0100000000000002   OBJ     READY

3. Define a storage class specifying its numeric ID, the number of object servers it will include, and the required redundancy settings. When prompted, enter the password obtained in step 1. For example, to create the storage class 1 with 2 object servers and the redundancy scheme of 2 replicas for tier 1, run:

   # ostor-ctl set-storage-class -s /mnt/vstorage/vols/ostor/ -V 0100000000000002 \
   -C 1 -O 2 --vstorage-attr "replicas=2:1 tier=1"
   Please enter password for 'ostor-private.svc.vstoragedomain.':
   Storage 1 class is successfully assigned to services

   This command requires the following parameters:

   -s, --storage <path>

   The path to the object storage directory

   -V, --vol <id>

   The volume ID obtained in step 2

   -C, --storage-class {1,2,3}

   The storage class ID. Can accept the following values: 1, 2, 3.

   -O, --os-count <number>

   The number of object servers to create

   --vstorage-attr <attribute>

   Redundancy settings, where you can specify the desired tier, failure domain, and data redundancy scheme. Refer to the vstorage set-attr help message.

   The S3 APIs that use the x-amz-storage-class header can specify one of the following storage classes: standard, type_1, type_2, or type_3.

4. Check that the new storage class is set. For example, for the storage class 1, run:

   # vstorage get-attr /mnt/vstorage/vols/ostor/0100000000000002/services/sc1/
   connected to MDS#1
   Path: 'vstorage://hciHeat/vols/ostor/0100000000000002/services/sc1'
   Attributes:
     directory
     client-ssd-cache=1
     replicas=2:1
     failure-domain=host
     failure-domain.int=1
     tier=1
     chunk-size=268435456
   

To change redundancy settings of a storage class

Use the ostor-ctl cfg-storage command. For example:

# ostor-ctl cfg-storage -r /mnt/vstorage/vols/ostor/0100000000000002/ -C 1 \
--vstorage-attr "replicas=3:2 tier=0"

This command requires the following parameters:

-r, --root <path>

The path to the initialized shared storage

-C, --storage-class {0,1,2,3}

The storage class ID. Can accept the following values: 0, 1, 2, 3. The default value is 0.

--vstorage-attr <attributes>

Redundancy settings, where you can specify the desired tier, failure domain, and data redundancy scheme. Refer to the vstorage set-attr help message.