StorPool advantages

Here you can find how using CloudStack and StorPool together brings several advantages, like bypassing secondary storage, using hyper-converged infrastructure setup, having storage tiers, and so on.

Bypassing secondary storage

Using StorPool as a primary storage provider offers the ability to bypass the secondary storage for virtual machine and snapshot creation by handling those actions with features of the primary storage solution. When configuring the StorPool plugin you can use this feature by enabling the sp.bypass.secondary.storage option (see Plugin settings) to obtain the following advantages:

  • Accelerate the VM and snapshot creation operations.

  • Get instantaneous reverts to snapshots.

  • Offload the snapshots functions from the hypervisors.

  • Decrease the load and the used capacity on the secondary storage.

  • Decrease the load on the storage network.

Reducing the demand on the secondary storage allows using simpler configurations (like NFS server) on the controller nodes.

Using hyper-converged setup

CloudStack’s documentation about Choosing a Deployment Architecture describes how you can choose a CloudStack setup that suit your needs. There are several options, ranging from small-scale to multi-site deployment.

In addition to the architectures listed there, you can also consider using a hyper-converged infrastructure (HCI) setup. Whit HCI you can have the same servers run as compute and storage nodes. You can achieve this with StorPool as a primary storage combined with the KVM hypervisor.

In such deployments, the CloudStack management server (or servers) can run on dedicated physical servers, or in virtual machines on the same HCI infrastructure. HCI deployments can be combined with secondary storage bypass (where supported) to eliminate the need for a dedicated secondary storage appliance. This simplifies the deployment to just a pair of layer-two switches for redundancy and a set of servers of the same type.

Also, when installing a Management Server you might want to set up an NFS server as described in CloudStack’s documentation at Prepare NFS Shares. Consider that when using StorPool as storage provider you can utilize its ability to run HCI workloads along with the storage services. This means you could deploy a highly available virtual machine for the secondary NFS storage on the same nodes where the storage services are running, thus simplifying your cloud architecture.

Tiers and availability

CloudStack’s documentation about Storage Architecture describes how you can choose between local storage, node-based shared storage, and clustered shared storage. Using StorPool you can enhance the storage architecture in the following ways:

  • Some storage solutions offer quality of service ‘tiers’ based on the underlying media. StorPool can also offer different tiers using the same set of storage devices.

  • StorPool enables all data to continue to be accessible in the event of the loss of an entire node, simultaneous failure of two nodes, or even whole racks when the right cloud architecture is in place.

Built-in functionality vs. additional packages

CloudStack’s documentation about Additional Packages Required for Features describes that you might need to install some third-party packages. When using StorPool there is no need to do this:

  • Secondary Storage Bypass

    Templates stored in secondary storage can also be downloaded to the primary storage system, so that future virtual machines created from these templates are created quickly using features of the primary storage system.

  • Volume Snapshots

    StorPool supports the creation of snapshots directly in the primary storage system. This means you can create storage-based snapshots of individual virtual disks or virtual machines running on KVM (group snapshot of all virtual disks associated with a VM) to offload the qemu process and accelerate snapshot creation.

Volume and snapshot deletion

CloudStack’s documentation about Volume Deletion and Garbage Collection describes how in some managed storage systems the volume snapshots are linked entities in the volumes wherein deletion of the volume would delete those snapshots.

Consider that this does not apply to storage systems such as StorPool Storage, where snapshots are handled independently of the volumes. This enables deleting a volume while keeping the snapshots of that volume.

Temporarily backing up volumes before deletion

Sometimes a user could delete a volume by mistake. CloudStack’s documentation about Instance delete protection describes how you can use the deleteprotection flag as a protection mechanism.

Starting with CloudStack version 4.19.1.0, the StorPool plugin provides an additional mechanism for preventing data loss in such a situation. When the storpool.delete.after.interval and storpool.list.snapshots.delete.after.interval global settings are set (see Plugin settings), the plugin would create a backup of the volume before it’s deleted. This way, the user will be able to see the snapshot in CloudStack’s UI/CLI, and to create a volume from it.

Note that this mechanism doesn’t support encrypted volumes, and also doesn’t support the option to create a template from the snapshot. You can only restore the volume from the snapshot via the createVolume API call.