#PV Name

1 messages · Page 1 of 1 (latest)

lucid light
#

Is it possible to set the FlexVol name from the pv or volume prefix pvc configuration?

I have already set the storage prefix but require at volume level also either name or being able to set prefix for each volumes to identify application type

warm plover
#

https://docs.netapp.com/us-en/trident/trident-reference/objects.html#trident-volume-objects
"Trident generates internalName when creating the volume. This consists of two steps. First, it prepends the storage prefix (either the default trident or the prefix in the backend configuration) to the volume name, resulting in a name of the form <prefix>-<volume-name>. It then proceeds to sanitize the name, replacing characters not permitted in the backend. For ONTAP backends, it replaces hyphens with underscores (thus, the internal name becomes <prefix>_<volume-name>). For Element backends, it replaces underscores with hyphens.
You can use volume configurations to directly provision volumes using the REST API, but in Kubernetes deployments we expect most users to use the standard Kubernetes PersistentVolumeClaim method. Trident creates this volume object automatically as part of the provisioning
process."
Here is example of PV describe from PVC method:
VolumeAttributes: internalName=trident_pvc_74e49cd9_681c_441d_b42e_02347d822b1d

Kubernetes and Trident objects

There are several resource objects that dictate the relationship between Kubernetes and Trident, Trident and storage, and Kubernetes and storage. Some of the...

lucid light
#

I have looked at the documentation and there is no annotation or other property to define the ONTAP volume name.

This is a bit of a challenge as the volumes that appear in the AWS console under FSxN cannot be identified easily. In case there is a need for a snapshot restore or any other operation on the data outside of the k8s cluster.

Additionally we cannot create the volume outside and import using trident as there are hundreds of volumes.

warm plover
#

Trident uses the dynamic (PVC) provisioning method, which requires a unique persistent claim name and is bound to a unique PV name generated by Trident. A possible solution is using different 'storagePrefixes' for different backend configs. (Or virtual storage Pools in different backend.configs.) Then use different storageClasses as needed and config the SC so it picks a specific backend:

Example: The storageClasses would look like this:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: backend-1
provisioner: csi.trident.netapp.io
parameters:
storagePools: "backend1:.*" (or could specify "backend1:aggr1,aggr2" etc..)
backendType: "ontap-nas"

​The 2nd StorageClass will look like this:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: backend-2
provisioner: csi.trident.netapp.io
parameters:
storagePools: "backend2:.*"
backendType: "ontap-nas"

lucid light
#

So if we use this approach and create 50+ matching configuration of Backend, SC and Volumes, what will be the impact on performance?

Additionally, Does each dedicated Backend and Storage Class will have one connection to the filesystem i.e. 50+ connections or more?

soft lichen
#

There is no active/permanent connection between trident & FSxN. More precisely, Trident talks to FSxN through API.
Also, Trident is not the IO path, once the FSxN volume is created, the mount between the WorkerNode/POD & the volume will be direct

warm plover
#

-> Trident cannot control the name ie. (controlling the backend's internal name).
If you need to find the matching volume name, should be able to get that from the 'tridentctl' output as the internal name.
..................
Using ontap-nas-economy as an example, with storagePrefix='rippy'

$ kubectl get -n trident pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
basic Bound pvc-84790356-b62d-46d3-8636-2e2cfe980fb0 1Gi RWO basic 4m40s

$ tridentctl -n trident get volume pvc-84790356-b62d-46d3-8636-2e2cfe980fb0 -o json | jq '.items[0].Config.internalID'
"/svm/nfs_vs/flexvol/trident_qtree_pool_rippy_HKWZLTIOFQ/qtree/rippy_pvc_84790356_b62d_46d3_8636_2e2cfe980fb0"

  • If not using tridentctl, it can be retrieved from Trident's custom resources via
    $ kubectl get -n trident tridentvolume pvc-84790356-b62d-46d3-8636-2e2cfe980fb0 -o json | jq '.config.internalID'
    "/svm/nfs_vs/flexvol/trident_qtree_pool_rippy_HKWZLTIOFQ/qtree/rippy_pvc_84790356_b62d_46d3_8636_2e2cfe980fb0"

cluster-1::> qtree show -vserver nfs_vs -volume trident_qtree_pool_rippy_HKWZLTIOFQ
Vserver Volume Qtree Style Oplocks Status

nfs_vs trident_qtree_pool_rippy_HKWZLTIOFQ
"" unix enable normal
nfs_vs trident_qtree_pool_rippy_HKWZLTIOFQ
rippy_pvc_84790356_b62d_46d3_8636_2e2cfe980fb0
unix enable normal
....................

#

-> Agree with Yvos regarding connections.
Trident is not in the data path, the backends would all be pointing at the same system, so that should not have an effect.

-> Regarding multiple backends:
With more backends, that's more matches to spin through. For provisioning, the impact would be on finding the proper backend to match the request and if the backend is explicitly specified it should be pretty quick. It probably will impact the time it takes to start Trident. As Trident starts, each backend will have to be initialized and that's an API call per backend to validate the API connection/credentials.

Hope this is helpful.