Appendix

1: Example ALUA Configuration Policy of OceanStor V5 and OceanStor Dorado V3
2: Example ALUA Configuration Policy of OceanStor Dorado
3: Example ALUA Configuration Policy of Distributed Storage
4: Communication Matrix
5: Configuring Custom Permissions
6: Huawei CSI Resource Management

1 - Example ALUA Configuration Policy of OceanStor V5 and OceanStor Dorado V3

Example 1: The configuration file content is as follows:

parameters:
  ALUA:
    "*":
      MULTIPATHTYPE: 1
      FAILOVERMODE: 3
      SPECIALMODETYPE: 0
      PATHTYPE: 0
    node1:
      MULTIPATHTYPE: 1
      FAILOVERMODE: 3
      SPECIALMODETYPE: 0
      PATHTYPE: 1

If the host name is node1, both of the preceding ALUA configuration sections can be used to configure initiators. According to the configuration policy rules in Configuring ALUA Parameters for a Huawei Enterprise Storage Backend, the priority of the second configuration section (where HostName is node1) is higher than that of the first configuration section (where HostName is *).

Example 2: The configuration file content is as follows:

parameters:
  ALUA:
    node[0-9]:
      MULTIPATHTYPE: 1
      FAILOVERMODE: 3
      SPECIALMODETYPE: 0
      PATHTYPE: 0
    node[5-7]:
      MULTIPATHTYPE: 1
      FAILOVERMODE: 3
      SPECIALMODETYPE: 0
      PATHTYPE: 1

If the host name is node6, both of the preceding ALUA configuration sections can be used to configure initiators. According to the configuration policy rules in Configuring ALUA Parameters for a Huawei Enterprise Storage Backend, select the first ALUA configuration section to configure initiators.

Example 3: The configuration file content is as follows:

parameters:
  ALUA:
   node$:
      MULTIPATHTYPE: 1
      FAILOVERMODE: 3
      SPECIALMODETYPE: 0
      PATHTYPE: 0
   node10$:
      MULTIPATHTYPE: 1
      FAILOVERMODE: 3
      SPECIALMODETYPE: 0
      PATHTYPE: 1

According to the configuration policy rules in Configuring ALUA Parameters for a Huawei Enterprise Storage Backend: For host node1, select the first ALUA configuration section to configure initiators. For host node10, select the second ALUA configuration section to configure initiators. ^ matches the beginning of a character string, and $ matches the end of a character string.

2 - Example ALUA Configuration Policy of OceanStor Dorado

Example 1: The configuration file content is as follows:

parameters:
  ALUA:
    "*":
     accessMode: 1
     hyperMetroPathOptimized: 1
   node1:
      accessMode: 1
      hyperMetroPathOptimized: 0

Example 2: The configuration file content is as follows:

parameters:
  ALUA:
   node[0-9]:
     accessMode: 1
     hyperMetroPathOptimized: 1
   node[5-7]:
     accessMode: 1
     hyperMetroPathOptimized: 0

Example 3: The configuration file content is as follows:

parameters:
  node1$:
    node[0-9]:
    accessMode: 1
    hyperMetroPathOptimized: 1
  node10$:
    accessMode: 1
    hyperMetroPathOptimized: 0

3 - Example ALUA Configuration Policy of Distributed Storage

Example 1: The configuration file content is as follows:

parameters:
  ALUA:
    "*":
      switchoverMode: Enable_alua
      pathType: optimal_path
    node1:
      switchoverMode: Enable_alua
      pathType: non_optimal_path

If the host name is node1, both of the preceding ALUA configuration sections can be used to configure initiators. According to the configuration policy rules in Configuring ALUA Parameters for a Distributed Storage Backend, the priority of the second configuration section (where HostName is node1) is higher than that of the first configuration section (where HostName is *).

Example 2: The configuration file content is as follows:

parameters:
  ALUA:
    node[0-9]:
      switchoverMode: Enable_alua
      pathType: optimal_path
    node[5-7]:
      switchoverMode: Enable_alua
      pathType: non_optimal_path

If the host name is node6, both of the preceding ALUA configuration sections can be used to configure initiators. According to the configuration policy rules in Configuring ALUA Parameters for a Distributed Storage Backend, select the first ALUA configuration section to configure initiators.

Example 3: The configuration file content is as follows:

parameters:
  ALUA:
    node1$:
      switchoverMode: Enable_alua
      pathType: optimal_path
    node10$:
      switchoverMode: Enable_alua
      pathType: non_optimal_path

According to the configuration policy rules in Configuring ALUA Parameters for a Distributed Storage Backend: For host node1, select the first ALUA configuration section to configure initiators. For host node10, select the second ALUA configuration section to configure initiators. ^ matches the beginning of a character string, and $ matches the end of a character string.

4 - Communication Matrix

Source Device	Host where CSI controller is located	Host where CSI controller is located	Host where CSI node is located	Kubernetes master node
Source IP Address	IP address of the source device	IP address of the source device	IP address of the source device	IP address of the source device
Source Port	1024 to 65536	1024 to 65536	1024 to 65536	1024 to 65536
Destination Device	Storage device	Host where CSI controller is located	Host where CSI node is located	Host where CSI controller is located
Destination IP Address	Management IP address of the storage device	IP address of the destination device	IP address of the destination device	IP address of the destination device
Destination Port (for Listening)	8088	9808	9800	4433
Protocol	TCP	TCP	TCP	TCP
Port Description	Used to create, manage, and delete volumes	Used by Kubernetes to check the health status of CSI controller	Used by Kubernetes to check the health status of CSI node	Used to invoke webhook verification
Listening Port Configurable	No	No	No	Yes
Authentication Mode	User name and password	Certificate	Certificate	Certificate
Encryption Mode	TLS 1.3/TLS 1.2	TLS 1.3/TLS 1.2	TLS 1.3/TLS 1.2	TLS 1.3/TLS 1.2
Plane	OM	O&M plane	O&M plane	O&M plane
Special Scenario	None	None	None	None
Remarks	Enable some source ports.			For details about how to change the webhook port, see the CSI user guide.

5 - Configuring Custom Permissions

User-defined Role Configurations

For different storage resources, refer to the following configurations:

For NAS resources, configure the minimum permissions by referring to Table 1.
For SAN resources, configure the minimum permissions by referring to Table 2.

For details about how to configure permissions for user-defined roles, see OceanStor Dorado 6000, Dorado 18000 Series Product Documentation.

Table 1 Minimum permissions for NAS resources

Permission Object	Parent Object	Read/Write Permission	Function
workload_type	file_storage_service	Read-only	Queries the workload type.
file_system	file_storage_service	Read and write	Manages file systems.
fs_snapshot	file_storage_service	Read and write	Manages file system snapshots.
quota	file_storage_service	Read and write	Manages file system quotas.
nfs_service	file_storage_service	Read-only	Queries NFS services.
share	file_storage_service	Read and write	Manages NFS shares.
dtree	file_storage_service	Read and write	Manages dtrees.
hyper_metro_pair	hyper_metro	Read and write	Creates file system HyperMetro pairs.
hyper_metro_domain	hyper_metro	Read-only	Queries information about file system HyperMetro domains.
remote_device	local_data_protection	Read-only	Queries remote device information.
storage_pool	pool	Read-only	Queries storage pool information.
smart_qos	resource_performance_tuning	Read and write	Manages SmartQoS policies.
system	system	Read-only	Queries storage device information (this object needs to be configured only when the owning group is the system group).
vstore	vstore	Read-only	Queries vStore information.
port	network	Read-only	Queries logical port information.

Table 2 Minimum permissions for SAN resources

Permission Object	Parent Object	Read/Write Permission	Function
remote_device	local_data_protection	Read-only	Queries remote device information.
hyper_clone	local_data_protection	Read and write	Manages clone pairs.
lun_snapshot	local_data_protection	Read and write	Manages LUN snapshots.
workload_type	lun	Read-only	Queries the workload type.
lun	lun	Read and write	Manages LUNs.
host	mapping_view	Read and write	Manages hosts.
host_group	mapping_view	Read and write	Manages host groups.
initiator	mapping_view	Read and write	Manages initiators.
lun_group	mapping_view	Read and write	Manages LUN groups.
mapping_view	mapping_view	Read and write	Manages mapping views.
target	mapping_view	Read-only	Queries iSCSI initiators.
port	network	Read-only	Queries logical ports.
storage_pool	pool	Read-only	Queries storage pool information.
smart_qos	resource_performance_tuning	Read and write	Manages SmartQoS policies.
system	system	Read-only	Queries storage device information (this object needs to be configured only when the owning group is the system group).
vstore	vstore	Read-only	Queries vStore information.

6 - Huawei CSI Resource Management

This section lists the resource requests and limits used by each container of the Huawei CSI plug-in. For details about the unit, see Resource units in Kubernetes.

Table 1 Container resource requests and limits

Pod Name	Container Name	CPU Request	CPU Limit	Memory Request	Memory Limit
huawei-csi-controller	huawei-csi-driver	50m	500m	128Mi	1Gi
	storage-backend-sidecar	50m	300m	128Mi	512Mi
	storage-backend-controller	50m	300m	128Mi	512Mi
	huawei-csi-extender	50m	300m	128Mi	512Mi
	csi-attacher	50m	300m	128Mi	512Mi
	csi-provisioner	50m	300m	128Mi	512Mi
	csi-resize	50m	300m	128Mi	512Mi
	csi-snapshotter	50m	300m	128Mi	512Mi
	snapshot-controller	50m	300m	128Mi	512Mi
	liveness-probe	10m	100m	128Mi	128Mi
huawei-csi-node	huawei-csi-driver	50m	500m	128Mi	1Gi
	csi-node-driver-registrar	50m	300m	128Mi	128Mi
	liveness-probe	10m	100m	128Mi	128Mi

Modifying Resource Requests and Limits

If you need to modify the resource requests and limits of a container, perform the following steps (in the following example, Helm is used to install Huawei CSI):

If Helm is used for installation, go to the /helm/esdk/templates directory. For manual deployment, the file to be modified is in the /manual/esdk/deploy directory. For details about the component package path, see Table 1.
Modify the deployment template file.
- If the Pod name is huawei-csi-controller, modify the huawei-csi-controller.yaml file.
- If the Pod name is huawei-csi-node, modify the huawei-csi-node.yaml file.
For details about Pod names, see Table 1.
For example, to modify the resource request of the huawei-csi-driver container in the Pod named huawei-csi-node, run the following command to edit the configuration file and find the container whose spec.template.spec.containes.name is huawei-csi-driver. Modify resource requests and limits as required.
```
vi huawei-csi-node.yaml
```
Edit the following content.
```
containers
 - name: huawei-csi-driver
   ...
   resources:
     limits:
       cpu: 500m
       memory: 1Gi
     requests:
       cpu: 50m
       memory: 128Mi
```
If Huawei CSI is not installed, the modification of resource requests and limits takes effect after Huawei CSI is installed by referring to Installing Huawei CSI on Kubernetes, OpenShift, and Tanzu.
If Huawei CSI has been installed, the modification of resource requests and limits takes effect after Huawei CSI is updated by referring to Upgrading Huawei CSI.