Configure a NetApp HCI or SolidFire backend
Suggest changes
PDFs
Learn how to create and use an Element backend with your Trident installation.
Element driver details
Trident provides the solidfire-san storage driver to communicate with the cluster. Supported access modes are: ReadWriteOnce (RWO), ReadOnlyMany (ROX), ReadWriteMany (RWX), ReadWriteOncePod (RWOP).
The solidfire-san storage driver supports file and block volume modes. For the Filesystem volumeMode, Trident creates a volume and creates a filesystem. The filesystem type is specified by the StorageClass.
| Driver | Protocol | VolumeMode | Access modes supported | File systems supported |
|---|---|---|---|---|
|
iSCSI |
Block |
RWO, ROX, RWX, RWOP |
No Filesystem. Raw block device. |
|
iSCSI |
Filesystem |
RWO, RWOP |
|
Before you begin
You'll need the following before creating an Element backend.
-
A supported storage system that runs Element software.
-
Credentials to a NetApp HCI/SolidFire cluster admin or tenant user that can manage volumes.
-
All of your Kubernetes worker nodes should have the appropriate iSCSI tools installed. Refer to worker node preparation information.
Backend configuration options
See the following table for the backend configuration options:
| Parameter | Description | Default |
|---|---|---|
|
Always 1 |
|
|
Name of the storage driver |
Always “solidfire-san” |
|
Custom name or the storage backend |
“solidfire_” + storage (iSCSI) IP address |
|
MVIP for the SolidFire cluster with tenant credentials |
|
|
Storage (iSCSI) IP address and port |
|
|
Set of arbitrary JSON-formatted labels to apply on volumes. |
“” |
|
Tenant name to use (created if not found) |
|
|
Restrict iSCSI traffic to a specific host interface |
“default” |
|
Use CHAP to authenticate iSCSI. Trident uses CHAP. |
true |
|
List of Access Group IDs to use |
Finds the ID of an access group named “trident” |
|
QoS specifications |
|
|
Fail provisioning if requested volume size is above this value |
“” (not enforced by default) |
|
Debug flags to use when troubleshooting. Example, {“api”:false, “method”:true} |
null |
|
Do not use debugTraceFlags unless you are troubleshooting and require a detailed log dump.
|
Example 1: Backend configuration for solidfire-san driver with three volume types
This example shows a backend file using CHAP authentication and modeling three volume types with specific QoS guarantees. Most likely you would then define storage classes to consume each of these using the IOPS storage class parameter.
---
version: 1
storageDriverName: solidfire-san
Endpoint: https://<user>:<password>@<mvip>/json-rpc/8.0
SVIP: "<svip>:3260"
TenantName: "<tenant>"
labels:
k8scluster: dev1
backend: dev1-element-cluster
UseCHAP: true
Types:
- Type: Bronze
Qos:
minIOPS: 1000
maxIOPS: 2000
burstIOPS: 4000
- Type: Silver
Qos:
minIOPS: 4000
maxIOPS: 6000
burstIOPS: 8000
- Type: Gold
Qos:
minIOPS: 6000
maxIOPS: 8000
burstIOPS: 10000
Example 2: Backend and storage class configuration for solidfire-san driver with virtual pools
This example shows the backend definition file configured with virtual pools along with StorageClasses that refer back to them.
Trident copies labels present on a storage pool to the backend storage LUN at provisioning. For convenience, storage administrators can define labels per virtual pool and group volumes by label.
In the sample backend definition file shown below, specific defaults are set for all storage pools, which set the type at Silver. The virtual pools are defined in the storage section. In this example, some of the storage pools set their own type, and some pools override the default values set above.
---
version: 1
storageDriverName: solidfire-san
Endpoint: https://<user>:<password>@<mvip>/json-rpc/8.0
SVIP: "<svip>:3260"
TenantName: "<tenant>"
UseCHAP: true
Types:
- Type: Bronze
Qos:
minIOPS: 1000
maxIOPS: 2000
burstIOPS: 4000
- Type: Silver
Qos:
minIOPS: 4000
maxIOPS: 6000
burstIOPS: 8000
- Type: Gold
Qos:
minIOPS: 6000
maxIOPS: 8000
burstIOPS: 10000
type: Silver
labels:
store: solidfire
k8scluster: dev-1-cluster
region: us-east-1
storage:
- labels:
performance: gold
cost: '4'
zone: us-east-1a
type: Gold
- labels:
performance: silver
cost: '3'
zone: us-east-1b
type: Silver
- labels:
performance: bronze
cost: '2'
zone: us-east-1c
type: Bronze
- labels:
performance: silver
cost: '1'
zone: us-east-1d
The following StorageClass definitions refer to the above virtual pools. Using the parameters.selector field, each StorageClass calls out which virtual pool(s) can be used to host a volume. The volume will have the aspects defined in the chosen virtual pool.
The first StorageClass (solidfire-gold-four) will map to the first virtual pool. This is the only pool offering gold performance with a Volume Type QoS of Gold. The last StorageClass (solidfire-silver) calls out any storage pool which offers a silver performance. Trident will decide which virtual pool is selected and ensures the storage requirement is met.
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: solidfire-gold-four provisioner: csi.trident.netapp.io parameters: selector: "performance=gold; cost=4" fsType: "ext4" --- apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: solidfire-silver-three provisioner: csi.trident.netapp.io parameters: selector: "performance=silver; cost=3" fsType: "ext4" --- apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: solidfire-bronze-two provisioner: csi.trident.netapp.io parameters: selector: "performance=bronze; cost=2" fsType: "ext4" --- apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: solidfire-silver-one provisioner: csi.trident.netapp.io parameters: selector: "performance=silver; cost=1" fsType: "ext4" --- apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: solidfire-silver provisioner: csi.trident.netapp.io parameters: selector: "performance=silver" fsType: "ext4"