Lightbits is now a certified Cinder driver for Red Hat OpenStack Services on OpenShift, tested on release 18.0.22. The certified component is the Lightbits Labs Cinder Driver for OpenStack Services on OpenShift, version 2.3.12. In May, we explained why NVMe/TCP disaggregated storage fits Red Hat OpenStack Services on OpenShift and how Lightbits plugs into both the control plane and the data plane. This post covers what has changed since.
Who is running Red Hat OpenStack Services on OpenShift today?
Telecommunications providers were some of the first large wave of adopters with NFV use cases such as 4G or 5G, and they remain a big part of the base. What has changed is the spread. We now see growing adoption across enterprise and public-sector customers.
Sovereignty is a big part of this shift. Organizations and governments that need control over where their data lives, who control the source code and who operate their infrastructure are building their own clouds; OpenStack allows this with great control, with multi-tenancy and at scale.
These environments differ in scale and workload, but they share one expectation: The storage underneath must be integrated and supported as part of the platform, not next to it. That is where certification comes in.
What certification means for you
Beyond the obvious integration testing coverage, the actual customer value of certification lives on the support side. Red Hat and each partner support their own products, but when an issue crosses that boundary, whether the partner component is certified determines what happens. Our third-party support policy spells it out:
- The partner component is not involved in the issue: Standard Red Hat support and SLA
- The partner component is involved and is certified in the Red Hat Ecosystem Catalog: Standard Red Hat support and SLA, collaborating with the partner as needed
- The partner component is involved and is not certified: The customer is asked to reproduce the issue on a certified product, or is directed to the third-party vendor
In other words, with certification, an issue in a partner's driver is not a reason to bounce a customer back to the storage vendor.
Before we certify a storage partner, we check 4 things:
- The storage operations work: Any operation the driver does not support is explicitly excluded, so customers know exactly what they get. The certified storage protocol is explicitly mentioned.
- The deployment stays within Red Hat support: The way the driver is deployed and configured must not put the customer outside a supported configuration.
- The driver comes from upstream: Red Hat only certifies drivers it distributes. A driver must be accepted in upstream OpenStack, and Red Hat OpenStack Services on OpenShift includes the drivers from the 2023.1 (Antelope) release. Details are in Integrate partner storage solutions.
- The partner is committed to support: The partner has an agreement with Red Hat and named support contacts.
Another value of certification is the ability for Red Hat to backport upstream partner's driver features into OpenStack Services on OpenShift (when possible), improving the customer experience without the need to wait for the next major release.
It is worth noting that certification does not evaluate the performance and scalability of the storage solution. Cloud architects should take extra care in the design, sizing and tuning; we recommend they reach out to their vendor for best practices and guidance.
What it took on the Lightbits side
The Lightbits Cinder driver is part of the upstream OpenStack cinder repository, so it ships as Red Hat builds it. We did not fork or patch it to get certified.
The deployment uses standard OpenStack Services on OpenShift mechanisms. The Cinder backend is defined in the OpenStackControlPlane custom resource, and the Lightbits discovery client deployed on each external data plane management (EDPM) compute node handles the NVMe/TCP connections. Nothing in that setup takes a customer outside Red Hat's supported configuration, which Red Hat enforces.
In this certified release, for some new features, Lightbits also relies on the CSI driver installation. The CSI driver installation also creates a discovery client container (inside the lb-csi pod) that handles all the regular PV/PVC mount and unmount operations. This certified version of the Cinder driver is using the same discovery client container to mount cinder volumes directly to the OpenStack pods. The CSI driver by itself also allows OpenStack control plane services that require persistent volumes to use the existing storage classes for components like Keystone, Glance, Cinder, Neutron, Galera, rabbitmq, and so on. Figure 1 illustrates how the components fit together.
New features available in the new certified Lightbits Cinder driver for Red Hat OpenStack Services on OpenShift
The certification covers the Cinder operations that day-to-day OpenStack work depends on. All of them run through the standard OpenStack APIs and CLI, with no Lightbits-specific tooling.
- Boot from volume: Instance root disks live on Lightbits, not on the compute node's local disk
- Create volume from image: A Glance image becomes a bootable Lightbits volume
- Snapshot: A point-in-time copy kept on the Lightbits cluster, usable as the source for new volumes
- Backup: A copy of the volume's data written by the Cinder backup service to a separate backup target
- Retype: A volume moves to a different volume type, on Lightbits or from another backend onto Lightbits
- Multi-attach: One volume attached to several instances at the same time
Retype: A supported way onto Lightbits
Retype is the operation we expect customers to use most when they adopt Lightbits. Within Lightbits, it changes a volume's type, for example to a type with a different replication or compression policy. Across backends, retype with migration moves a volume from existing storage onto Lightbits using standard Cinder calls (see Migrate a volume between backends). You can move workloads volume by volume, on your own schedule.
Snapshots and backups are different tools
Snapshots stay on the Lightbits cluster and are the fast way to clone or roll back a volume. The Cinder backup service writes backups to a separate target, so they protect data if the primary storage is lost. A sound data protection plan in Red Hat OpenStack Services on OpenShift uses both.
Multi-attach needs a cluster-aware workload
Lightbits lets several instances attach the same volume at once. The instances still need a clustered filesystem or an application that coordinates writes, such as a clustered database. Without that, concurrent writes will corrupt data.
Getting started
Red Hat OpenStack Services on OpenShift customers can now run Lightbits NVMe/TCP storage as a certified Cinder backend, covered by Red Hat's standard support and SLA. The operations covered are the ones teams run every day: booting, imaging, snapshots, backups, retype and multi-attach.
- Find the listing: Lightbits Labs Cinder Driver for Red Hat OpenStack Services on OpenShift in the Red Hat Ecosystem Catalog
- Plan the deployment: The Lightbits Storage Integration with Red Hat OpenStack Services on OpenShift technical reference guide, with the YAML manifests and a verification playbook
- Read the background: Our earlier post, Red Hat OpenStack Services on OpenShift and Lightbits Storage
- Talk to us: Reach out to the Lightbits team, or to your Red Hat account team