When striving to push the boundaries of the Sisense application's performance, it becomes imperative to possess an underlying infrastructure that can seamlessly deliver cutting-edge capabilities. In this regard, the collaborative efforts of Azure and NetApp have yielded the pinnacle of performance solutions – the Astra-Trident Container Storage Interface.
Official whitepapers for Azure storage solutions are available here:
https://bluexp.netapp.com/blog/astra-blg-comparing-and-contrasting-the-aks-anf-nfs-subdir-external
https://learn.microsoft.com/en-us/azure/storage/files/storage-files-netapp-comparison
It is important to acknowledge that despite its exceptional attributes, this storage solution may not be ideally suited for every facet of our product due to certain limitations. Consequently, it stands as a fitting choice exclusively for the Shared Storage (RWX) module within our product's architecture. For optimum outcomes, we strongly recommend choosing this solution alongside the managed-csi-premium default AKS storage class for RWO operations during the Sisense deployment process.
Deploying the Trident Interface can be summarized in three simple tasks:
- Deploy the Trident Operator: This is a prerequisite to enable dynamic volume provisioning for Sisense or any other Kubernetes application using Trident. Detailed guidance can be found at:
https://docs.netapp.com/us-en/trident/trident-get-started/kubernetes-deploy-operator.html#critical-i...
- Configure the NetappFiles Backend: This pivotal configuration bestows Trident with the necessary privileges to communicate seamlessly with the underlying storage. The process is outlined comprehensively at:
https://docs.netapp.com/us-en/trident/trident-use/anf-prep.html#prerequisites-for-nfs-and-smb-volume...
- Create a Kubernetes Storage Class: By setting up a dedicated storage class within Kubernetes, applications like Sisense can effortlessly access the underlying storage infrastructure. Detailed steps are provided at:
https://docs.netapp.com/us-en/trident/trident-use/create-stor-class.html#configure-a-kubernetes-stor...
This configuration harmoniously aligns with the Sisense Helm with Provisioner installation package, facilitating seamless reference to the newly established storage class and default storage class through the persistence.rwxScName and persistence.rwoScName parameters, respectively. When using this configuration, you can leave the persistence.storageType parameter as a set of empty quotes, and ensure sure persistence.enabled is set to true.
It is worth noting that this configuration can also be seamlessly extended to cater to customers opting for FSX ONTAP within the AWS ecosystem or Cloud Volume Services within Google Cloud, simply by selecting the appropriate backend configuration under the second step. While deploying Sisense using Helm with Provisioner, under the persistence.rwoScName parameter, you’ll need to use the ebs-csi in modern Kubernetes clusters within AWS environments and in Google Cloud, you can use the standard storage class for the persistence.rwoScName parameter.
In summary, NetApp has created a CSI which is highly adaptable and efficient. For Azure customers seeking the best performance possible, review the Trident CSI solution and determine it is best for your environment.
