Utilizing Local Storage for Sisense Stateful Sets

[Wyatt]

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.

[stevediaz]

Hello

Great guide on utilizing local storage for Sisense Stateful Sets! This detailed walkthrough is helpful for addressing specific scenarios where specialized storage configurations are necessary. Thanks for sharing these steps and considerations.