It is October and you know what that means: spooky season, yellow and orange leaves, and an Astra Trident release! We are excited to announce that Astra Trident v22.10 is now available for download. This release is packed with functionality and innovation, delivering the features that you have been asking for, including support for stateful Windows workloads, cross-namespace volume access, and more. Let’s dive in.
Stateful Windows workloads with Trident and Azure NetApp Files
Trident’s list of supported protocol grows to include SMB with v22.10. Stateful Windows workloads can now use Trident to provision Azure NetApp Files (ANF) volumes using SMB. Azure NetApp Files supports SMB 2.1 and SMB 3.1. The version of SMB used will be the highest dialect support by the client. Users can now install Trident in Kubernetes clusters that contain both Linux and Windows nodes (Trident’s controller requires that it run on a Linux node). Support for FSx for NetApp ONTAP, Cloud Volumes ONTAP, Cloud Volumes Service Google Cloud Platform, and ONTAP is planned to be delivered in upcoming releases.
SMB is presently qualified with self-managed Azure Directory and community Kubernetes running on Azure VMs, with qualification on AKS planned and underway.
Here is how it works:
- A Kubernetes secret that contains the username (in the format
<DOMAIN-NAME.COM>\\<username>) and password must be created.
kubectl create secret generic smb-ad-credential --from-literal username="Mycompany.com\\trident" --from-literal password="sdjwengbyvyonbyh" – namespace=app
nasTypeis provided in the associated Trident backend definition and is set to
smb. An example ANF backend would look like this:
- A storageClass is created. It contains the name of the secret and the namespace the secret is created in.
PVCs can then be created using the storageClass.
LUKS encryption for ONTAP block devices
Support for client-side LUKS encryption in this release provides an additional layer of security so that a server-side breakout won’t fully compromise your environment.
Persistent volumes created on ONTAP SAN backends [that use the
ontap-san-economy storage drivers] can now be encrypted with Linux Unified Key Setup-on-disk-format (LUKS). LUKS encryption is performed on the block device that is attached to Kubernetes nodes, thus providing client-side encryption. Worker nodes are required to have
cryptsetup installed, running version 2.1 or newer.
luksEncryption can be set to true in Trident backend definitions to encrypt disks with LUKS. Refer to the documentation for example storageClasses and backends.
Note that ONTAP’s storage efficiency features (deduplication and compression) are rendered ineffective if you use client-side encryption.
Cross Namespace Volume Access
Volumes provisioned by Trident can be shared across namespaces. Trident achieves this by using annotations provided in primary and secondary PVC definitions. This demo walks you through the feature and how it works. In addition, the documentation explains the components in play. Take a look at this blog to understand how you can share volumes today!
Custom Role for Azure NetApp Files backends
To tighten Trident’s access to Azure resources, Trident now provides a custom role definition. When contrasted with pre-defined Azure “Owner” and/or “Contributor” roles, the custom role is more fine-grained and restrictive. It is built on the principle of least privilege and contains the smallest set of capabilities needed by Trident to function.
iSCSI and Multipath enhancements
This release provides multiple enhancements for better handling of iSCSI connections with ONTAP SAN. These include:
- Updated retries during volume attachment to fail fast and improve performance.
- Deprecating non-multipathed iSCSI configurations. Trident will now strictly enforce the use of multipathing configuration in SAN environments, with a recommended value of
multipath.conffile. Use of non-multipathing configuration or use of
find_multipaths: smartvalue in
multipath.conffile will result in mount failures.
- Reduced the number of iSCSI LUN scans when attaching a volume for improved performance.
Seamless NetApp MetroCluster volume failover
Astra Trident v22.10 allows for seamless MetroCluster switchover. Previous versions (v22.01 and before) required Trident administrators to update backends when a switchover was initiated. This is replaced by an automatic switchover detection in Trident, allowing it to read data from the respective site. Users are required to provide the SVM management LIF in MetroCluster backend definitions.
Encrypting ONTAP volumes: NVE and NAE explained
Volumes provisioned on ONTAP clusters can be encrypted in more than one way. NetApp Volume Encryption and NetApp Aggregate Encryption are two versatile options. This FAQ explains the major differences. Astra Trident can be used to create NAE and NVE volumes. The documentation highlights how the
encryption flag can be used in conjunction with NAE. It is important to note that if NAE is enabled on an ONTAP cluster, all Trident volumes created on the cluster will be NAE enabled.