Skip to main content

Longhorn

Longhorn is one of our supported storage providers that can be installed into a cluster that has no access to other storage classes in order to allow for persistence within the platform cluster. Learn more about Longhorn in the official documentation. A storage provider like Longhorn is needed when bootstrapping our Rocket Pad Platform outside a managed Kubernetes or cloud provider. Cloud provider will normally have some sort of Cloud Storage solution and a Kubernetes Storage Classes available to request such storage within Kubernetes without configuring anything.

Longhorn is great for smaller setups or when your platform setup will be mainly used for compute workloads or uses external datastores like cloud managed Databases external Cloud storage and so on.

note

Longhorn is a great tool, reliable and production ready. But for High Availability platform installations with data read and write heavy applications we recommend using Ceph or an external high availability Storage Cluster to allow for faster read and write access and faster self healing

What does the Module provide​

The Longhorn Module provided for the Rocket Pad Platform is used to bootstrap the platform with a pre configured Longhorn installation that is already interwoven with all other platform tools and features like Metrics, Logging, SSO and others.

What you will get with Longhorn is distributed storage within the cluster using the build in storage of the cluster nodes. When installed Longhorn will provide a Kubernetes StorageClass that can be used to create persistent volumes, create volume backups and snapshots, move volumes between nodes and so on.

You will get an UI Interface to manage Longhorn with build in SSO Support out of the box. Additionally the logs and metrics of Longhorn will automatically be collected and stored with the build in Rocket Pad Platform Observability Base Module. The module also provides you an already pre configured monitoring dashboard for Longhorn in order to see the health of your Storage Layer, Storage Usage and so on.

Installation​

In order to see how modules are installed take a look into the Installation instructions for an example module. The installation process is the same but there are some important differences to other Modules due to Installation being a Storage provider and therefore a stateful and critical component of the platform.

warning

Storage Modules need proper migration procedures if they are uninstalled changed or replaced.

The module configuration can be done the same way as our basic tutorial. Add the module to the bootstrap/main.jsonnet and configure it trough the bootstrap/config.libsonnet file under the longhorn key. The configuration options can be seen in the modules repository. An example configuration to set a Longhorn namespace as well as well as a storage class with volumes replicated 3 times can be found below:

config.libsonnet
{
... 
  longhorn: {
    namespace: 'longhorn-system',

    storageClasses: {
      replicated: {
        replicas: 3,
      },
      retained: {
        enabled: true,
      },
    },
  },
...
}

The module can mostly used as is with the default config. If you want to change something refer to the longhorn documentation and adjust the needed configuration within the bootstrap/config.libsonnet file afterwards to achieve your goal.

warning

Longhorn uses the storage provided on your nodes. We recommend to always use volume replicas across different nodes and setup automatic backups uploaded to S3 or other cluster external Storage to prevent data loss due to corrupted nodes or uncontrolled cluster downsizing.

Usage​

Longhorn itself will provide you with a StorageClass to use for Persistent Volume Claims. In most cases that will be everything needed to use Longhorn within your cluster.

But there are additional features like snapshots, backups and more functionality that can be used to make the storage layer Longhorn provides more usable and secure. The Longhorn UI makes managing snapshots, backups and volumes easy and intuitive if needed. But we recommend sticking to the GitOps principles and IaC based infrastructure thinking and try to define as much as possible with Longhorns Kubernetes CRDs.

Core Concepts​

  • Persistent Volume (PV): An abstract representation of a piece of storage in the cluster.
  • Persistent Volume Claim (PVC): A request for storage within the cluster.
  • Storage Class: Defines the parameters for creating PVs.
  • Replica: A copy of the volume data stored on a different node for redundancy.
  • Longhorn Manager: Manages the creation and lifecycle of PVCs and Longhorn Engines (Kube API based)
  • Longhorn Engine: Will be created by the Longhorn Manager on each node to manage storage volumes
  • Snapshots: Incremental backups of volumes that can be restored from within the cluster
  • Backups: Full volume backups saved on external storage that can be used for full disaster recovery on cluster failure (Preferably S3 Storage externally from the cluster itself)

Creating a Persistent Volume Claim​

A Persistent Volume Claim (PVC) is a request for storage and can be attached to a pod. You specify the required storage size and Storage Class in the PVC. In case of using Longhorn the Storage Class has to be Longhorn.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: longhorn

Longhorn UI​

The module creates creates not only a fully pre configured Longhorn installation but also exposes the Longhorn UI via an Ingress. The UI will be secured by a OAuth2 Proxy and use the Rocket Pad Platform Base IAM Module to provide SSO capability and limit access to the Longhorn UI.

The UI will be available after install at https://longhorn.example.com. The Longhorn UI will look like this:

Longhorn UI Image