Utilizing Local Storage for Sisense Stateful Sets
Utilizing Local Storage for Sisense Stateful Sets
Introduction
When Sisense is deployed, we typically deploy with two types of storage, ReadWriteOnce (RWO), mainly used by stateful sets such as MongoDB, and ReadWriteMany (RWX) supporting by our core application.
Use-Cases for this Configuration
This configuration is typically used either because you need extreme performance for a Stateful Set (due to storage bottlenecks), or because of locking issues on a chosen RWO storage medium-- for example, Trident. In particular, MongoDB has extremely specific user permissions which are incompatible with most CSI providers.
This configuration does have some limitations such as binding each stateful set member to an individual host. Please use this cautiously and ensure regularly scheduled backups are performed and maintained.
How to Apply
Back up and Delete the intended STS from the Kubernetes environment. For this example, we will examine MongoDB.
kubectl get sts -n sisense sisense-mongodb -o yaml > mongodb.backup.yaml
kubectl get sts -n sisense sisense-mongodb -o yaml > ModifiedBackup.yaml
kubectl delete sts -n sisense sisense-mongodb
Next, edit ModifiedBackup.yaml:
Near the bottom, there is a section such as:
volumes:
- configMap:
defaultMode: 493
name: sisense-mongodb-scripts
name: scripts
updateStrategy:
type: RollingUpdate
volumeClaimTemplates:
- apiVersion: v1
kind: PersistentVolumeClaim
metadata:
creationTimestamp: null
name: datadir
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: $MongoDBPVCSize
storageClassName: $RWOstorage
volumeMode: Filesystem
status:
phase: Pending
Add this section under “volumes”, and reference a host-local filepath for all hosts that will be running stateful sets. Kubernetes is capable of creating directories if they did not previously exist. Please make sure any referenced mount points for SSDs are available across all hosts if that is your desired configuration.
- name: datadir
hostPath:
path: /opt/mongo
type: DirectoryOrCreate
Please also delete the “volumeClaimTemplates” section as well, this is now unnecessary
This section should look like this now:
serviceAccount: sisense-mongodb
serviceAccountName: sisense-mongodb
terminationGracePeriodSeconds: 30
volumes:
- configMap:
defaultMode: 493
name: sisense-mongodb-scripts
name: scripts
- name: datadir
hostPath:
path: /opt/mongo
type: DirectoryOrCreate
updateStrategy:
type: RollingUpdate
Run the “kubectl apply -f ModifiedBackup.yaml” command to recreate the deleted STS with the new volumes.
Summary
In summary, there are a few niche scenarios that require more specialized storage configurations. Sisense has an extremely flexible deployment model and is capable of utilizing node-local storage in high-performance or otherwise uncommon storage configurations.