Feature Request: Enable LINSTOR Storage Pools Using Kubernetes PersistentVolumeClaims as Backing Storage

[stevefan1999-personal]

Overview

This feature request proposes extending the LinstorSatelliteConfiguration CRD to support using Kubernetes PersistentVolumeClaims (PVCs) as backing storage for LINSTOR storage pools. This would enable LINSTOR to leverage cloud provider storage through standard Kubernetes abstractions.

Use Case

Organizations want to combine LINSTOR/DRBD's advanced features with cloud provider managed storage. By using PVCs as backing storage, users can:

• Leverage existing cloud provider storage classes (OCI Block Volumes, AWS EBS, Azure Disks, GCP Persistent Disks)
• Maintain a clean separation between infrastructure provisioning and storage management
• Use Kubernetes-native constructs for the entire storage stack

Proposed Architecture

Application Pod
    ↓
[DRBD Volume via LINSTOR CSI]
    ↓
[LINSTOR Storage Pool]
    ↓
[Mounted PVC path on node]
    ↓
[PersistentVolumeClaim]
    ↓
[PersistentVolume (e.g., iSCSI from cloud provider)]
    ↓
[Cloud Provider Storage Service]

Proposed Configuration Enhancement

Extend the LinstorSatelliteConfiguration to support PVC-backed pools:

apiVersion: piraeus.io/v1
kind: LinstorSatelliteConfiguration
metadata:
  name: storage-satellites
spec:
  storagePools:
    # Existing pool types remain unchanged
    - name: vg1
      lvmPool: {}
    
    # New: LVM pool backed by PVCs
    - name: cloud-backed-lvm
      lvmPool:
        volumeGroup: vg-cloud
      source:
        persistentVolumeClaims:
          - name: backing-pvc-1
            namespace: linstor-system
            mountPath: /mnt/cloud-storage-1
          - name: backing-pvc-2
            namespace: linstor-system
            mountPath: /mnt/cloud-storage-2
    
    # New: File pool backed by PVC
    - name: cloud-backed-file
      filePool:
        directory: /mnt/cloud-file-storage
      source:
        persistentVolumeClaim:
          name: file-backing-pvc
          namespace: linstor-system
          mountPath: /mnt/cloud-file-storage
    
    # New: ZFS pool backed by PVCs
    - name: cloud-backed-zfs
      zfsPool:
        zPool: cloud-zfs
      source:
        persistentVolumeClaims:
          - name: zfs-backing-pvc-1
            namespace: linstor-system
            devicePath: /dev/disk/by-id/cloud-pvc-1

Supporting Kubernetes Resources

Users would create PVCs using their cloud provider's storage class:

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: backing-pvc-1
  namespace: linstor-system
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: oci-bv-standard  # Or any cloud provider storage class
  resources:
    requests:
      storage: 100Gi
  volumeMode: Block  # For LVM/ZFS pools
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: file-backing-pvc
  namespace: linstor-system
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: oci-bv-standard
  resources:
    requests:
      storage: 200Gi
  volumeMode: Filesystem  # For file-based pools

Implementation Requirements

1. PVC Management:

   • LINSTOR operator should manage the lifecycle of PVCs used as backing storage
   • Ensure PVCs are bound and available before creating storage pools
   • Handle PVC mounting on appropriate satellite nodes

2. Node Affinity:

   • Respect PVC node affinity constraints
   • Ensure LINSTOR satellites run on nodes where PVCs can be attached

3. Device Discovery:

   • Automatically discover block devices for volumeMode: Block PVCs
   • Handle device path mapping for cloud provider volumes

4. Dynamic Provisioning:

   • Support automatic PVC creation based on pool requirements
   • Allow scaling by adding new PVCs to existing pools

Benefits

1. Cloud-Native Integration: Uses standard Kubernetes abstractions
2. Flexibility: Mix local and cloud storage in the same cluster
3. Portability: Works across any cloud provider with CSI support
4. Management: Leverage existing Kubernetes tooling for storage management
5. Cost Control: Use different storage tiers for different pools

Example Use Cases

1. Hybrid Storage:

   • Performance-critical data on local NVMe (existing pools)
   • Less frequently accessed data on cloud-backed pools

2. Disaster Recovery:

   • Primary pools on local storage
   • DR pools backed by cloud storage with provider-level replication

3. Development/Testing:

   • Dynamically provision ephemeral environments using cloud storage
   • Easy cleanup by deleting PVCs

This enhancement would make LINSTOR more versatile in cloud-native environments while maintaining its powerful feature set for distributed storage management.

[WanzenBug]

This is related to piraeusdatastore/piraeus-operator#356

One change to the proposal I would suggest is that the SatelliteConfiguration would contain the "PVC" template, like volume templates in a STS. Otherwise, how would multiple satellites trying to access the same volume work?

If that is even supported by the storage provider, you would need to set up some "shared storage pool" in LINSTOR. While that is possible, its not something that would be generally recommended.

The updated spec would look something like:

    # New: LVM pool backed by PVCs
    - name: cloud-backed-lvm
      lvmPool:
        volumeGroup: vg-cloud
      source:
        persistentVolumeClaims:
          - metadata:
              name: backing-pvc-1 # may be implied by storage pool name?
            spec:
                accessModes:
                - ReadWriteOnce
                storageClassName: oci-bv-standard  # Or any cloud provider storage class
                resources:
                  requests:
                    storage: 100Gi
                # volume mode is implied to be block
                # the operator can also set up "allowed topology" and so on, to ensure locality of data on the node....