Extended Storage Backends (ESB)¶

This document introduces ESB in StarlingX OpenStack, describes its capabilities and supported storage protocols, and outlines how to determine whether it is suitable for your deployment.

Earlier, StarlingX OpenStack supported only a predefined set of platform-managed storage backends (Ceph, NetApp NFS, NetApp iSCSI, and NetApp FC), which were automatically detected and configured. ESB extends this support to other storage backends by allowing you to configure any upstream OpenStack Cinder driver as a custom backend.

An extended backend is a storage backend that you define yourself. You declare it once in the Cinder Helm chart overrides, and StarlingX OpenStack handles the pod-level settings for the specified protocol, injects credentials from a Kubernetes Secret, and passes your driver configuration to Cinder unchanged. StarlingX OpenStack does not validate the driver configuration, so you are responsible for ensuring that the configuration is valid.

ESB is integrated into StarlingX OpenStack through the following components:

An upstream OpenStack Cinder volume driver for your storage array
Helm overrides that declare the backend and select the backend per service
A Kubernetes Secret that provides the driver’s credentials when the configuration is applied

This section covers the following topics:

Supported ESB Protocols ¶

An extended backend declares one of the following access protocols. The protocol determines the pod-level settings StarlingX OpenStack applies (host networking, iSCSI, and multipath), and not the specific driver you use.

iscsi: Provides block storage over iSCSI for Cinder volumes attached to instances. StarlingX OpenStack automatically enables iSCSI and multipath.
fcp: Provides block storage over a Fibre Channel fabric for Cinder volumes that use multipath I/O. Use fcp rather than fc.
nfs: Provides file-based storage over NFS for Cinder volumes, backups, Glance images, and Nova ephemeral storage.

Any Cinder driver that supports one of these protocols can be configured as an extended backend, provided all required prerequisites are satisfied.

Define an Extended Backend ¶

Configure an extended backend in the Cinder chart using two entries:

An entry in storage_conf.storage_backends that declares and enables the backend.
A corresponding entry in storage_conf.backends_conf, keyed by name, that specifies the protocol, StorageClass, credentials, and driver options.

To use the backend for a service, add its name to that service’s priority list. The same extended backend can support Cinder volumes and Cinder backup. If it has a valid Kubernetes StorageClass, it can also serve control-plane services (MariaDB and RabbitMQ), Glance, and Nova ephemeral storage.

Note

StarlingX OpenStack resolves backend names in a priority list to their corresponding StorageClass; the names are not direct references to StorageClasses. A strict backend such as ceph maps to its platform-managed StorageClass, while an extended backend maps to the StorageClass specified by its k8s_storage_class.

Note

The backend names ceph, netapp-nfs, netapp-iscsi, and netapp-fc are reserved for platform-managed backends and must not be used for extended backends. In this release, any backends_conf entry that uses a reserved name is silently ignored. Similarly, rbd is reserved for the platform Ceph backend and is not supported as a protocol for extended backends. Use only iscsi, fcp, or nfs as the protocol value.