This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Advanced Features

1 - Configuring ALUA

Asymmetric Logical Unit Access (ALUA) is a model that supports access to multiple target ports. In the multipathing state, ALUA presents active/passive volumes to the host and provides a port access status switchover interface to switch over the working controllers for volumes. For example, when a volume of a controller fails, you can set the status of ports on the controller to Unavailable. After the host multipathing software that supports ALUA detects the status, it switches subsequent I/Os from the failed controller to the peer controller.

1.1 - Configuring ALUA Using Helm

1.1.1 - Configuring ALUA Parameters for a Huawei Enterprise Storage Backend

For details about how to configure ALUA for Huawei enterprise storage, see the host connectivity guide of the corresponding product.

The ALUA configuration may vary according to the OS. Visit Huawei Technical Support, enter Host Connectivity Guide in the search box, and click the search button. In the search result, select the host connectivity guide for the desired OS. Configure ALUA according to the actual situation and the description in the guide. Huawei CSI will apply the configuration items you set to the initiator of the host on Huawei storage.

A node with a Pod provisioned does not proactively change ALUA information. The host ALUA configuration changes only after a Pod is provisioned again to the node.

ALUA Parameters for OceanStor V5 and OceanStor Dorado V3 Series

Table 1 lists the ALUA parameters supported by Huawei CSI for OceanStor V5 and OceanStor Dorado V3 series.

Table 1 ALUA parameters supported by Huawei CSI for OceanStor V5 and OceanStor Dorado V3 series

Parameter

Description

Remarks

HostName

Host name rule. This parameter is mandatory. You can use a regular expression.

The host name can be obtained by running the cat /etc/hostname command. It can be matched by using regular expressions. When HostName is set to *, the configuration takes effect on hosts with any name. For details, see Regular expression.

If the host name of a compute node matches multiple ALUA configuration options, they will be sorted based on the matching accuracy and the first ALUA configuration option will be used. For details about the sorting rules, see Rules for Matching ALUA Configuration Items with Host Names.

MULTIPATHTYPE

Multipathing type. This parameter is mandatory. The value can be:

  • 0: Third-party multipathing is not used.
  • 1: Third-party multipathing is used.

--

FAILOVERMODE

Initiator switchover mode. This parameter is conditionally mandatory. The value can be:

  • 0: early-version ALUA
  • 1: common ALUA
  • 2: ALUA not used
  • 3: special ALUA

This parameter needs to be specified only when third-party multipathing is used. Configure the initiator switchover mode by referring to the connectivity guide.

SPECIALMODETYPE

Special mode type of the initiator. This parameter is conditionally mandatory. The value can be:

  • 0: special mode 0
  • 1: special mode 1
  • 2: special mode 2
  • 3: special mode 3

This parameter needs to be specified only when the initiator switchover mode is special ALUA. Configure the special mode type of the initiator by referring to the connectivity guide.

PATHTYPE

Initiator path type. This parameter is conditionally mandatory. The value can be:

  • 0: preferred path
  • 1: non-preferred path

This parameter needs to be specified only when third-party multipathing is used. Configure the initiator path type by referring to the connectivity guide.

The following uses OceanStor 18500 V5 as an example to describe how to connect to Red Hat. For details about the host connectivity guide, see Huawei SAN Storage Host Connectivity Guide for Red Hat.

The following ALUA configuration example is recommended in the OceanStor 18500 V5 host connectivity guide for Red Hat in non-HyperMetro storage scenarios. In this example, the OS on compute node myhost01 in the Kubernetes cluster is RHEL 5.x, and that on other compute nodes is RHEL 7.x. According to the recommendation, the switchover mode of RHEL 5.x should be “ALUA not used”, and that of RHEL 7.x should be “common ALUA”.

storage: oceanstor-san
name: oceanstor-iscsi-155
urls:
  - https://192.168.129.155:8088
  - https://192.168.129.156:8088
pools:
  - StoragePool001
parameters:
  protocol: iscsi
  portals:
    - 192.168.128.120
    - 192.168.128.121
  ALUA:
    ^myhost01$:
      MULTIPATHTYPE: 1
      FAILOVERMODE: 2
      PATHTYPE: 0
    "*":
      MULTIPATHTYPE: 1
      FAILOVERMODE: 1
      PATHTYPE: 0

ALUA Parameters for OceanStor and OceanStor Dorado Series

Table 2 lists the ALUA parameters supported by Huawei CSI for OceanStor and OceanStor Dorado series.

By default, the initiator host access mode of OceanStor and OceanStor Dorado series storage is “balanced mode”. Therefore, you are advised not to configure ALUA parameters for OceanStor and OceanStor Dorado series storage.

Table 2 ALUA parameters for OceanStor and OceanStor Dorado series

Parameter

Description

Remarks

HostName

Host name rule. This parameter is mandatory. You can use a regular expression.

The host name can be obtained by running the cat /etc/hostname command. It can be matched by using regular expressions. When HostName is set to *, the configuration takes effect on hosts with any name. For details, see Regular expression.

If the host name of a compute node matches multiple ALUA configuration options, they will be sorted based on the matching accuracy and the first ALUA configuration option will be used. For details about the sorting rules, see Rules for Matching ALUA Configuration Items with Host Names.

accessMode

Host access mode. This parameter is mandatory. The value can be:

  • 0: balanced mode
  • 1: asymmetric mode

The balanced mode is recommended in non-HyperMetro scenarios. Currently, Huawei CSI does not support SAN HyperMetro scenarios. Exercise caution when using the asymmetric mode.

hyperMetroPathOptimized

Whether the path of the host on the current storage array is preferred in HyperMetro scenarios. The value can be:

  • 1: yes
  • 0: no

This parameter needs to be specified only when the host access mode is set to asymmetric.

Currently, Huawei CSI does not support SAN HyperMetro scenarios. Exercise caution when using the asymmetric mode.

The following uses OceanStor Dorado 18000 as an example to describe how to connect to Red Hat. For details about the host connectivity guide, see OceanStor Dorado and OceanStor Host Connectivity Guide for Red Hat.

The following ALUA configuration example is recommended in the OceanStor Dorado 18000 host connectivity guide for Red Hat in non-HyperMetro storage scenarios.

storage: "oceanstor-san"
name: "dorado-iscsi-155"
urls:
  - "https://192.168.129.155:8088"
  - "https://192.168.129.156:8088"
pools:
  - "StoragePool001"
parameters:
  protocol: "iscsi"
  portals:
    - "192.168.128.120"
    - "192.168.128.121"
  ALUA:
    "*":
      accessMode: 0

Rules for Matching ALUA Configuration Items with Host Names

  • If the configured host name rule exactly matches the host name of the service node, the ALUA configuration item corresponding to the host name rule is used.

    For example, the host name rule in configuration item 1 is * and that in configuration item 2 is ^myhost01$. If the host name of a compute node is myhost01, it exactly matches configuration item 2. In this case, Huawei CSI will apply the configuration information in configuration item 2 to the storage side.

  • If the configured host name rule does not exactly match the host name of the service node, the first ALUA configuration item matched by regular expressions is used.

    For example, the host name rule in configuration item 1 is myhost0[0-9] and that in configuration item 2 is myhost0[5-9]. In this case, configuration item 1 has a higher priority than configuration item 2. If the host name of a compute node is myhost06, both configuration items can be matched. In this case, Huawei CSI will apply the configuration information in configuration item 1 to the storage side.

1.1.2 - Configuring ALUA Parameters for a Distributed Storage Backend

For details about how to configure ALUA for Huawei distributed storage, see the host connectivity guide of the corresponding product.

The ALUA configuration may vary according to the OS. Visit Huawei Technical Support, enter Host Connectivity Guide in the search box, and click the search button. In the search result, select the host connectivity guide for the desired OS. Configure ALUA according to the actual situation and the description in the guide. Huawei CSI will apply the configuration items you set to the initiator of the host on Huawei storage.

A node with a Pod provisioned does not proactively change ALUA information. The host ALUA configuration changes only after a Pod is provisioned again to the node. In non-HyperMetro scenarios of distributed storage, you are advised to set the switchover mode to “disable ALUA” (default value). This is because the storage system is in active/active mode and “enables ALUA” is meaningless. Therefore, you are advised not to configure ALUA parameters for distributed storage.

Table 1 lists the ALUA parameters supported by Huawei CSI for distributed storage.

Table 1 ALUA parameters for distributed storage

Parameter

Description

Remarks

HostName

The value of HostName is the host name of a worker node, for example, HostName1 and HostName2.

The host name can be obtained by running the cat /etc/hostname command. It can be matched by using regular expressions. When HostName is set to *, the configuration takes effect on hosts with any name. For details, see Regular expression.

If the host name of a compute node matches multiple ALUA configuration options, they will be sorted based on the matching accuracy and the first ALUA configuration option will be used. For details about the sorting rules, see Rules for Matching ALUA Configuration Items with Host Names.

switchoverMode

Switchover mode. This parameter is mandatory. The value can be:

  • Disable_alua: disables ALUA.
  • Enable_alua: enables ALUA.

In non-HyperMetro scenario, you are advised to set the switchover mode to "disable ALUA". This is because the storage system is in active/active mode and "enables ALUA" is meaningless. Currently, Huawei CSI does not support SAN HyperMetro scenarios. Exercise caution when enabling ALUA.

pathType

Path type. This parameter is conditionally mandatory. The value can be:

  • optimal_path: preferred path
  • non_optimal_path: non-preferred path

This parameter is mandatory when the switchover mode is set to "enables ALUA".

Rules for Matching ALUA Configuration Items with Host Names

  • If the configured host name rule exactly matches the host name of the service node, the ALUA configuration item corresponding to the host name rule is used.

    For example, the host name rule in configuration item 1 is * and that in configuration item 2 is ^myhost01$. If the host name of a compute node is myhost01, it exactly matches configuration item 2. In this case, Huawei CSI will apply the configuration information in configuration item 2 to the storage side.

  • If the configured host name rule does not exactly match the host name of the service node, the first ALUA configuration item matched by regular expressions is used.

    For example, the host name rule in configuration item 1 is myhost0[0-9] and that in configuration item 2 is myhost0[5-9]. In this case, configuration item 1 has a higher priority than configuration item 2. If the host name of a compute node is myhost06, both configuration items can be matched. In this case, Huawei CSI will apply the configuration information in configuration item 1 to the storage side.

2 - Configuring Storage Topology Awareness

In the Kubernetes cluster, resources can be scheduled and provisioned based on the topology labels of nodes and the topology capabilities supported by storage backends.

Prerequisites

You need to configure topology labels on worker nodes in the cluster. The method is as follows:

  1. Use a remote access tool, such as PuTTY, to log in to any master node in the Kubernetes cluster through the management IP address.

  2. Run the following command to view information about worker nodes in the current cluster.

    kubectl get node

    The following is an example of the command output.

    NAME     STATUS   ROLES                      AGE   VERSION
node01   Ready    controlplane,etcd,worker   42d   v1.22.3
node02   Ready    worker                     42d   v1.22.3
node03   Ready    worker                     42d   v1.22.3

  3. Run the following command to configure a topology label for a worker node. In the preceding command, nodename indicates the name of a worker node. For details about the key and value parameters, see Table 1.

    kubectl label node <nodename> <key>=<value>

    Table 1 Parameter description

    Parameter

    Description

    Remarks

    <key>

    Unique identifier of a topology label.

    The value can be zone, region, or protocol.<protocol>.

    <protocol> can be set to iscsi, nfs, fc, or roce.

    <value>

    Value of a topology label.

    If key is set to zone or region, value is a user-defined parameter.

    If key is set to protocol.<protocol>, value is fixed at csi.huawei.com.

    • A topology label must start with topology.kubernetes.io. Topology label examples:
    • Example 1: topology.kubernetes.io/region=China-west
    • Example 2: topology.kubernetes.io/zone=ChengDu
    • Example 3: topology.kubernetes.io/protocol.iscsi=csi.huawei.com
    • Example 4: topology.kubernetes.io/protocol.fc=csi.huawei.com
    • A key in a topology label on a node can have only one value.
    • If multiple protocols are configured in a topology label on a node, when you configure a StorageClass, the StorageClass needs to meet only one of the protocols.
    • If both the region and the zone are configured in a topology label on a node, when you configure a StorageClass, the StorageClass must meet all filter criteria.

  4. Run the following command to view the label information about all worker nodes in the current cluster.

    kubectl get nodes -o=jsonpath='{range .items[*]}[{.metadata.name}, {.metadata.labels}]{"\n"}{end}' | grep --color "topology.kubernetes.io"

    The following is an example of the command output.

    [node01,"beta.kubernetes.io/arch":"amd64","beta.kubernetes.io/os":"linux","kubernetes.io/arch":"amd64","kubernetes.io/hostname":"node01","kubernetes.io/os":"linux","node-role.kubernetes.io/controlplane":"true","node-role.kubernetes.io/etcd":"true","node-role.kubernetes.io/worker":"true","topology.kubernetes.io/zone":"ChengDu"}]

2.1 - Configuring Storage Topology Awareness Using Helm

Procedure

  1. Use a remote access tool, such as PuTTY, to log in to any master node in the Kubernetes cluster through the management IP address.

  2. Go to the directory where the Helm project is located. If the previous Helm project cannot be found, copy the helm directory in the component package to any directory on the master node. For details about the component package path, see Table 1.

  3. Go to the backend service configuration directory /examples/backend/ and back up the backend.yaml file.

    cp backend.yaml backend.yaml.bak

  4. Run the **vi **backend.yaml command to open the file and configure topology awareness as required. The following is an example. After the modification is complete, press Esc and enter :wq! to save the modification.

    storage: "oceanstor-san"
name: "dorado-iscsi-155"
namespace: "huawei-csi"
urls:
  - "https://192.168.129.155:8088"
pools:
  - "StoragePool001"
parameters:
  protocol: "iscsi"
  portals:
    - "10.10.30.20"
    - "10.10.30.21"
supportedTopologies:
  - { "topology.kubernetes.io/region": "China-west", "topology.kubernetes.io/zone": "ChengDu" }
  - { "topology.kubernetes.io/region": "China-south","topology.kubernetes.io/zone": "ShenZhen" }
maxClientThreads: "30"

  5. Run the following command to delete the storage backend to be modified. In the command, dorado-iscsi-155 indicates the storage backend name.

    oceanctl delete backend dorado-iscsi-155 -n huawei-csi

  6. Run the following command to create a storage backend.

    oceanctl create backend -f ../examples/backend/backend.yaml -i yaml

    Enter the storage user name and password as prompted.

    Please enter this backend user name:admin
Please enter this backend password:

  7. Run the vi StorageClass.yaml command to modify the .yaml file. Press I or Insert to enter the insert mode and add related parameters in the .yaml file. For details about the parameters, see Table 1. After the modification is complete, press Esc and enter :wq! to save the modification.

    Add the following configuration items to the StorageClass.yaml file.

    • Example 1: Configure zone and region information in the StorageClass.

      kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: example-storageclass
provisioner: csi.huawei.com
parameters:
  volumeType: lun
  allocType: thin
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
  - key: topology.kubernetes.io/zone
    values:
    - ChengDu
  - key: topology.kubernetes.io/region
    values:
    - China-west

    • Example 2: Configure protocol information in the StorageClass.

      kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: protocol-example-storageclass
provisioner: csi.huawei.com
parameters:
  volumeType: lun
  allocType: thin
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
  - key: topology.kubernetes.io/protocol.iscsi
    values:
    - csi.huawei.com

    Table 1 Parameter description

    Parameter

    Description

    Remarks

    volumeBindingMode

    PersistentVolume binding mode, used to control the time when PersistentVolume resources are dynamically allocated and bound.

    You can set this parameter to WaitForFirstConsumer or Immediate.

    WaitForFirstConsumer: indicates that the binding and allocation of the PersistentVolume are delayed until a Pod that uses the PVC is created.

    Immediate: The PersistentVolume is bound and allocated immediately after a PVC is created.

    allowedTopologies.matchLabelExpressions

    Topology information label, which is used to filter CSI backends and Kubernetes nodes. If the matching fails, PVCs or Pods cannot be created.

    Both key and value must be configured in a fixed format.

    key: This parameter can be set to topology.kubernetes.io/zone or topology.kubernetes.io/region.

    topology.kubernetes.io/protocol.<protocol>: <protocol> indicates the protocol type and can be iscsi, fc, or nfs.

    value:

    If key is topology.kubernetes.io/zone or topology.kubernetes.io/region, value must be the same as the topology label set in the prerequisites.

    If key is topology.kubernetes.io/protocol.<protocol>, value is fixed at csi.huawei.com.

  8. Run the following command to create a StorageClass based on the .yaml file.

    kubectl create -f StorgeClass.yaml

  9. Use the StorageClass to create a PVC with the topology capability. For details, see PVC Parameters for Dynamic Volume Provisioning.

3 - PVC Change

This section describes how to use Huawei CSI to complete a PVC change.

3.1 - Enabling the PVC Change Feature

The PVC change feature is disabled by default during Huawei CSI installation. To use this feature, perform the following steps.

3.1.1 - Enabling the PVC Change Feature Using Helm

Prerequisites

  • You have installed Huawei CSI using Helm.
  • Huawei CSI v4.5.0 or later is used.

Procedure

  1. Use a remote access tool, such as PuTTY, to log in to any master node in the Kubernetes cluster through the management IP address.

  2. Run the following command to check whether the PVC change feature is enabled.

    helm-huawei-csi indicates the Helm chart name specified during installation, and huawei-csi indicates the Helm chart namespace specified during installation. For details about the component package path, see Table 1.

    helm get values helm-huawei-csi -n huawei-csi -a | grep volumeModify -A 1

    The following is an example of the command output.

    • If enabled: true is displayed in the command output, the feature is enabled. In this case, skip the following steps.
    • If enabled: false is displayed in the command output, perform the following steps to enable the PVC change feature.
    volumeModify:
  enabled: false

  3. Go to the /helm/esdk directory and run the following command to configure the volume change CRD.

    # kubectl apply -f ./crds/volume-modify/
customresourcedefinition.apiextensions.k8s.io/volumemodifyclaims.xuanwu.huawei.io configured
customresourcedefinition.apiextensions.k8s.io/volumemodifycontents.xuanwu.huawei.io configured

    If the command output contains Warning: resource customresourcedefinitions/volumemodifycontents.xuanwu.huawei.io is missing the kubectl.kubernetes.io/last-applied-configuration…, you can ignore it. This message is displayed because the kubectl create command instead of the kubectl apply command is used for installation by Helm.

  4. Run the following command to obtain the original service configuration file.

    helm get values helm-huawei-csi -n huawei-csi -a > ./update-values.yaml

  5. Run the vi update-values.yaml command to open the file obtained in 4 and modify the following configuration. After the modification is complete, press Esc and enter :wq! to save the modification.

    csiExtender:
  volumeModify:    
    enabled: true

  6. Run the following command to update Huawei CSI services.

    helm upgrade helm-huawei-csi ./ -n huawei-csi  -f ./update-values.yaml

  7. Run the following command to check whether the services are started.

    kubectl get pod -n huawei-csi

    The following is an example of the command output. In the preceding command, huawei-csi indicates the namespace for deploying Huawei CSI.

    NAME                                     READY     STATUS    RESTARTS   AGE
huawei-csi-controller-6dfcc4b79f-9vjtq   10/10     Running   0          24m
huawei-csi-node-tqs87                    3/3       Running   0          20m

3.1.2 - Enabling the PVC Change Feature Manually

Prerequisites

Huawei CSI has been manually installed.

Procedure

  1. Use a remote access tool, such as PuTTY, to log in to any master node in the Kubernetes cluster through the management IP address.

  2. Go to the manual/esdk working directory and run the following command to configure the volume change CRD.

    kubectl apply -f ./crds/volume-modify/

  3. Run the following command. For details about the component package path, see Table 1.

    kubectl apply -f ./deploy/huawei-csi-controller-extender.yaml

  4. Run the following command to check whether the services are started.

    kubectl get pod -n huawei-csi

    The following is an example of the command output. In the preceding command, huawei-csi indicates the namespace for deploying Huawei CSI.

    NAME                                     READY     STATUS    RESTARTS   AGE
huawei-csi-controller-6dfcc4b79f-9vjtq   10/10     Running   0          24m
huawei-csi-node-tqs87                    3/3       Running   0          24m

3.2 - Configuring PVC Changes

The PVC change feature is implemented using CRD. Related resources are described as follows.

Table 1 Resource description

NAME

APIVERSION

NAMESPACED

KIND

volumemodifyclaims

xuanwu.huawei.io/v1

false

VolumeModifyClaim

volumemodifycontents

xuanwu.huawei.io/v1

false

VolumeModifyContent

  • VolumeModifyClaim resources can be created, deleted, and queried, but cannot be updated.
  • VolumeModifyContent resources can only be queried and are used to display the change details of a single PVC. Do not manually create, delete, or modify the resources.
  • VolumeModifyContent resources are managed by VolumeModifyClaim. Do not manually manage VolumeModifyContent resources.

3.2.1 - Creating a PVC Change

Prerequisites

The storage backends associated with the PVC to be changed are HyperMetro storage backends. If they are not HyperMetro storage backends, configure them by following the instructions in Manually Updating a Storage Backend.

3.2.1.1 - Preparing a PVC Change File

PVC Change File Description

The sample template of the PVC change file is /examples/volumemodifyclaim.yaml. The following table lists the configuration items.

Table 1 Parameter description

Parameter

Description

Mandatory

Default Value

Remarks

apiVersion

API group, which is of the string type.

Yes

xuanwu.huawei.io/v1

The value is fixed at xuanwu.huawei.io/v1.

kind

Resource type, which is of the string type.

Yes

VolumeModifyClaim

The value is fixed at VolumeModifyClaim.

metadata.name

Name of a cluster resource object, which is of the string type.

Yes

-

The name must comply with the naming rules of a DNS subdomain name. The value can contain a maximum of 63 characters, including digits, lowercase letters, hyphens (-), and periods (.). It must start and end with a lowercase letter or digit.

spec.source.kind

Data source type, which is of the string type.

Yes

StorageClass

This parameter can only be set to StorageClass.

spec.source.name

Data source name, which is of the string type.

Yes

-

Only a StorageClass name can be configured.

spec.parameters.hyperMetro

Whether to change a common volume to a HyperMetro volume. Currently, the value can only be "true".

Yes

-

Only common storage volumes at the primary site can be changed to HyperMetro storage volumes.

spec.parameters.metroPairSyncSpeed

Data synchronization speed of a HyperMetro pair. The value ranges from 1 to 4.

The value can be:

  • 1: low
  • 2: medium
  • 3: high
  • 4: highest

No

-

This parameter is available only when spec.parameters.hyperMetro is set to "true".

Note:

  • If this parameter is not configured, the storage speed of the HyperMetro pair is determined by the storage device.
  • The highest synchronization speed may increase the host latency.

  • The spec.source.kind and spec.source.name parameters are used to specify the volume change scope. For example, if they are set to a StorageClass and the corresponding name respectively, all PVCs in the Bound state provisioned using the target StorageClass will be changed.
  • After all associated PVCs are changed, Huawei CSI will replace the original StorageClass and add the spec.parameters parameter of the VolumeModifyClaim so that the PVCs meet the StorageClass definition.

For details about the configuration in typical scenarios, see the following example:

Changing a Common Volume to a HyperMetro Volume

The following is an example of changing a common volume to a HyperMetro volume:

apiVersion: xuanwu.huawei.io/v1
kind: VolumeModifyClaim
metadata:
  name: myvmc
spec:
  source:
    kind: StorageClass
    name: mysc
  parameters:
    hyperMetro: "true"

3.2.1.2 - Creating a PVC Change Resource

This section describes how to create a PVC change resource based on a configured PVC change file.

  • Only the HyperMetro active-active (AA) mode is supported.
  • When a common volume is changed to a HyperMetro volume, only the storage volume at the primary site can be changed.
  • Do not use Huawei CSI to manage a PVC during PVC change resource creation.
  • Multiple VolumeModifyClaim resources cannot be created for the same PVC. If the target PVC needs to be changed for multiple times, perform the changes one by one.

Procedure

  1. Use a remote access tool, such as PuTTY, to log in to any master node in the Kubernetes cluster through the management IP address.

  2. Run the following command to create a PVC change.

    kubectl create -f volumemodifyclaim.yaml

  3. Query the creation result by following the instructions in Querying a PVC Change.

3.2.2 - Querying a PVC Change

This section describes how to use Kubectl to query the PVC change status. Currently, Huawei CSI provides the following APIs through CRD.

Querying a VolumeModifyClaim

To query a VolumeModifyClaim using kubectl, perform the following steps.

  1. Use a remote access tool, such as PuTTY, to log in to any master node in the Kubernetes cluster through the management IP address.

  2. Run the following command to query a PVC change. In the command, vmc-name indicates the name of the VolumeModifyClaim resource.

    kubectl get volumemodifyclaims <vmc-name> -owide

    The following is an example of the command output.

    NAME    STATUS      READY   SOURCEKIND     SOURCENAME   STARTEDAT              COMPLETEDAT            AGE
myvmc   Completed   1/1     StorageClass   mysc         2024-06-06T03:19:13Z   2024-06-06T03:19:16Z   2m2s

    Table 1 Command output description

    Parameter

    Description

    NAME

    VolumeModifyClaim resource name.

    STATUS

    VolumeModifyClaim resource status. The value can be:

    • Pending: initial status.
    • Creating: The VolumeModifyClaim has completed basic verification and the server has received the change task, but the task has not been completed.
    • Completed: All associated PVCs are changed.
    • Rollback: When associated PVCs are partially changed, a user deletes PVCs.
    • Deleting: When all associated PVCs are changed, a user deletes PVCs.

    READY

    Ratio of the number of changed PVCs to the total number of PVCs that need to be changed.

    SOURCEKIND

    Data source type, for example, StorageClass.

    SOURCENAME

    Data source name, for example, StorageClass name.

    STARTEDAT

    Change start time, that is, the timestamp when the server receives the task and starts to process the task.

    COMPLETEDAT

    Change completion time, that is, the timestamp when the changes of all associated PVCs are complete. This parameter exists only when STATUS is Completed.

    AGE

    Lifetime of a VolumeModifyClaim from the time when it is created to the current time.

You can use kubectl to view the Events information of a VolumeModifyClaim. If a VolumeModifyClaim cannot meet the creation requirements or an error occurs during the creation, the server will record the Events information. The following command is used as an example:

kubectl describe volumemodifyclaims local-to-hypermetro

Querying a VolumeModifyContent

A VolumeModifyContent is created using a VolumeModifyClaim and records the change details of a single PVC. To query a VolumeModifyContent using kubectl, perform the following steps:

  1. Use a remote access tool, such as PuTTY, to log in to any master node in the Kubernetes cluster through the management IP address.

  2. Run the following command to query a PVC change. In the command, myvmc-uid indicates the VolumeModifyContent resource name.

    kubectl get volumemodifycontents myvmc-uid  -owide

    The following is an example of the command output.

    NAME         STATUS      MODIFYCLAIMNAME     SOURCEVOLUME   STARTEDAT              COMPLETEDAT            AGE
myvmc-uid    Completed   myvmc               default/mypvc  2024-06-06T03:19:07Z   2024-06-06T03:19:09Z   36m

    Table 2 Command output description

    Parameter

    Description

    NAME

    VolumeModifyContent resource name. The format is VolumeModifyClaim name-UID of the associated PVC.

    STATUS

    VolumeModifyContent resource status. The value can be:

    • Pending: initial status.
    • Creating: The VolumeModifyContent has completed basic verification and the server has received the change task, but the task has not been completed.
    • Completed: The associated PVC is changed.
    • Rollback: The PVC change is being rolled back.

    MODIFYCLAIMNAME

    Name of the associated VolumeModifyClaim.

    SOURCEVOLUME

    Information about the associated PVC. The format is Namespace name/PVC name.

    STARTEDAT

    PVC change start time, that is, the timestamp when the server receives the task and starts to process the task.

    COMPLETEDAT

    PVC change completion time, that is, the timestamp when the changes of all associated PVCs are complete. This parameter exists only when STATUS is Completed.

    AGE

    Lifetime of a VolumeModifyContent from the time when it is created to the current time.

You can use kubectl to view the Events information of a VolumeModifyContent. If a VolumeModifyContent cannot meet the creation requirements or an error occurs during the PVC change, the server will record the Events information. The following command is used as an example:

kubectl describe volumemodifycontents myvmc-uid

3.2.3 - Deleting a PVC Change

  • If STATUS of a VolumeModifyClaim is Creating, deleting the VolumeModifyClaim resource will delete the created resource on the storage side and then remove the cluster resource. After the deletion, if you continue to use the original StorageClass for PVC management, you need to restore the associated storage backend to a non-HyperMetro storage backend.
  • If STATUS of a VolumeModifyClaim is Pending or Completed, deleting the VolumeModifyClaim resource will only remove the cluster resource and will not delete the created resource on the storage side (that is, there is not interaction with the storage side).
  • VolumeModifyContent resources are managed by VolumeModifyClaim. Do not manually manage VolumeModifyContent resources.
  • If some PVCs among the PVCs to be changed meet the change requirements and the batch change fails, all PVC changes will be removed. As a result, the PVCs that meet the change requirements will not meet the change requirements.
  • If a PVC to be changed has been manually managed on the storage side, the change may fail. Do not manually manage storage volumes when using the change feature.

This section describes how to use kubectl to delete a PVC change. The procedure is as follows.

Procedure

  1. Use a remote access tool, such as PuTTY, to log in to any master node in the Kubernetes cluster through the management IP address.

  2. Run the following command to delete a PVC change. In the command, vmc-name indicates the name of the VolumeModifyClaim resource.

    kubectl delete volumemodifyclaims <vmc-name>

  3. Query the deletion result by following the instructions in Creating a PVC Change Resource.