This is the functional specification for the supporting LINSTOR SDS as primary storage.
CloudStack currently supports Ceph/RBD storage which is a distributed block storage. Linstor also provides distributed block storage through DRBD.
This proposed feature will add support for Linstor storage as a primary storage (new Storage Plugin) in CloudStack.
|Added feature specification and design||11 May 2021|
This feature should able to:
LINSTOR is a configuration management system for storage on Linux systems. It manages LVM logical volumes and/or ZFS ZVOLs on a cluster of nodes. It leverages DRBD for replication between different nodes and to provide block storage devices to users and applications.
Linstor itself has 3 software components: Linstor-Controller, Linstor-Satellite and Linstor-Client.
More about Linstor objects can be taken from the Linstor user-guide: https://linbit.com/drbd-user-guide/linstor-guide-1_0-en/#s-concepts_and_terms
The Linstor counterparts above can be mapped and used with CloudStack and KVM as follows:
A Cloudstack PS should be associated with a Linstor resource group, a resource group is a meta object in linstor which controls things like replica-count and options for all created resources/volumes from this resource group.
Templates can be of QCOW2 or RAW type, no changes in secondary storage or template/iso lifecycle are necessary.
At the time of root-disk/VM provisioning, the KVM host agent can convert a template from secondary storage or direct-download into a RAW disk and write it to a mounted block-storage device, which is the spooled template on the primary pool.
Root disk resize will cause resize of the related Linstor volume, similarly deletion of the root disk will cause deletion of the Linstor volume after unmapping it across all KVM hosts.
On provisioning data-disks can be simply volumes that are created in Linstor that can be mapped on a KVM host and attached as “raw” disk(s) to a VM. Detach operation would be to detach the raw block-storage device from the VM and un-mapping the volume from a KVM host. Data disk resize will cause resize of the Linstor volume, similarly deletion of the data disk will cause deletion of the disk on Linstor after unmapping it on all KVM hosts.
Implement a new CloudStack storage plugin for Linstor storage. This will follow the design principles abstracted by CloudStack API for implementing a pluggable storage plugin.
Introduce a new storage pool type “Linstor” that associates with a Linstor resource group and allows for shared storage and over-provisioning. This type is used across various operations for handling a storage pool specific handling of operations especially on the hypervisor (KVM agent) side. Implement a new storage volume/datastore plugin with the following:
i. Linstor Datastore Driver: a primary datastore driver class that is responsible for lifecycle operations of a volume and snapshot resource such as to grant/revoke access, create/copy/delete data object, create/revert snapshot and return usage data.
ii. Linstor Datastore Lifecycle: a class that is responsible for managing lifecycle of a storage pool for example to create/initialise/update/delete a datastore, attach to a zone/cluster and handle maintenance of the storage pool.
iii. Linstor Datastore Provider: a class that is responsible for exporting the implementation as a datastore provider plugin for CloudStack storage sub-system to pick it up and use for the resource groups of type “Linstor”.
iv. Introducing a dependency to java-linstor, a API wrapper library for the Linstor-REST-API
2. Hypervisor layer (KVM): The hypervisor layer would have the following design aspects:
Linstor StorageAdaptor and StoragePool: For handling of Linstor volumes and snapshots.These classes will be responsible for managing storage operations and pool related tasks and metadata.
All storage related operations need to be handled by various Command handlers and hypervisor/storage processors (KVMStorageProcessor) as orchestrated by the KVM server resource class (LibvirtComputingResource) such as CopyCommand, AttachCommand, DetachCommand, CreateObjectCommand, DeleteCommand, SnapshotAndCopyCommand, DirectDownloadCommand, etc...
The following naming conventions are used for CloudStack resources in Linstor.
Linstor does not have a global capacity, rather every Linstor storage-pool has its individual capacity.
So either the Linstor driver reports back a average of all used nodes, or we always use the value from the node with the least available free capacity.
The Allocated size (TotalCapacity - FreeCapacity) of the Linstor volume is considered as the used / physical size of the volume in CloudStack.
What actions should be tested?