This chapter describes some of the advanced storage functionality provided by KumoScale software, such as online pool expansion, volume expansion, and snapshots. These features are available by using KumoScale interfaces such as the KumoScale REST API or CSI Driver for Kubernetes orchestration. See the appropriate interface guide for your environment for the commands to implement these features.
Deleting a Volume
The REST API supports the command Delete Volume.
This command will work only on volumes that are not in use. That is, only volumes not added as namespaces to a target can be removed.
Data lost through this action cannot be recovered.
Deleting a volume is irreversible and deletes all its data.
Modifying a Volume
Some of a volume’s properties may be modified after creation using the REST API command Modify Volume:
- Span flag for a volume allocated over a pool: a volume can be made to span more than one SSD sometime after its original creation. The flag will be modified if currently set to false.
If the flag is set to true, it will be modified only if the volume does not already span more than one SSD.
- Volume capacity: a volume may be expanded (see next section, Expanding a Volume).
Expanding a Volume
A volume may be expanded as long as there is free capacity on its underlying SSD. If the volume is allowed to span more than one SSD, it can be expanded to the maximum available capacity of its underlying group.
The expansion may be performed online non-disruptively, even while initiators are connected and using it.
Adding and Removing a Replica
KumoScale software allows adding or removing a replica to a resilient volume. This may be useful in the event a replica is permanently down, or when preparing for a planned maintenance operation, where a rack will be shut down or disconnected.
A resilient volume may temporarily contain up to four (4) replicas.
At least one replica should be available when adding a new replica. The KumoScale Provisioner service will use the capacity and QoS requirements from the existing replica(s), and the
Span Allowed field (if not specified). Other parameters, such as topology, will be read from the add-replica parameter (or ignored, if not specified).
When calling directly to the KumoScale Provisioner service, the administrator must add or remove the new replication to the host agent.
The caveat above is not required when working with the CSI driver. Similarly, the Ansible playbooks contain an example (self-healing) which implements this mechanism (refer to the relevant manual).
The following sections provide examples of how to manage target volumes.
When attaching a volume to multiple hosts, it is expected by the underlying application to maintain data integrity.
A volume may be attached to more than one initiator, thus enabling faster recovery in use cases such as failover or support of the OpenStack live migration feature.
When a volume is attached to multiple targets, it must be removed from all targets (initiators), via the unpublish command before it can be deleted.
Removing Namespaces from a Target (Unpublish)
Once you remove a namespace from a target, all initiators (hosts) connected to the target will lose access to their data on that namespace.
Removing a namespace from a target does not delete the data from the volume. In order to delete the data, delete the volume after removing it from the target.
Administrators can remove namespaces from targets and add the volume as a namespace to another target or delete the volumes after they are removed.
The KumoScale Provisioner service deletes the target if it has no namespaces to save resources.
Removing a Target
Removing a target does not delete its volumes but will delete the target with its namespaces. To ensure data is deleted, administrators must delete the volumes after deleting the target.
If calling directly to a KumoScale storage node, administrators can delete a target from storage so that it is no longer accessible.
To maintain data coherency, the application layer should quiesce its volume activity when creating the snapshot.
Snapshots may be used for backup and restore, or for test and development purposes, when required to use real data without harming the production environment.
A snapshot is a ‘point in time’ representation of the volume, but it cannot be exposed or used. In order to use it, administrators must create a snapshot volume over the snapshot.
Creating a Snapshot and Snapshot Volumes
Administrators can take up to eight snapshots over a volume using the Create Snapshot function.
Once a snapshot is created, administrators can create up to 512 snapshot volumes over the snapshot. Each snapshot volume may be either Read Write or Read Only.
See the Create Snapshot Volume command in the relevant interface document for a list of its input parameters.
1) There must be at least 1GB free capacity on an SSD hosting the source volume to take a snapshot over it.
2) The snapshot and writable snapshot volume require a small amount of space for metadata handling. This capacity shall be subtracted from the SSDs total available space.
3) Administrators can set this value when creating the snapshot or the writeable snapshot volume, as a percentage of the original volume capacity. The default value is 10%.
4) If the reserved space is completely utilized, KumoScale software will attempt to auto-expand space. If this is not possible, the snapshot or the snapshot volume may become invalid.
5) A snapshot volume does not inherit the QoS properties of its source volume. Administrators can specify different QoS requirements when creating a new snapshot volume.
Viewing a Snapshot and its Snapshot Volumes
Administrators can view the list of snapshots in a cluster using the get-snapshots command. Snapshot volumes appear along with non-snapshot volumes in the reply to the get-volumes inquiry. The snapshot volumes may be distinguished from non-snapshot volumes by their snapshotID – only snapshot volumes will return this field – or according to their volumeType.
The result for each of these commands includes the snapshot data state. The various states, when they appear in volume, snapshots or snapshot volumes, include the following (Table 2):
Table 2. Data States in Various Volume Types
The data is valid
There was not enough space, the snapshot is invalid (failed to save a change).
Occurs when the origin snapshot is invalid.
KumoScale software detected a corruption in the underlying volume’s data.
Deleting a Snapshot and its Snapshot Volumes
Snapshots can be deleted at any time.
The OpenStack interface for KumoScale supports cloning volumes, creating a volume with the starting image of an existing volume. The total number of clones and snapshots created from the same source volume must be no more than eight (8).
See the Clone Volume command in the OpenStack guide or the REST API for information on how to clone a volume.
Thin-provisioned volumes are created by defining the provisioningType as ‘thin’ in the storageclass. The default provisioningType value is ‘thick.’
When a thin-provisioned volume reaches its reserved space minus a 10GB margin, the actual allocated space is expanded in the maximum between 20GB and 2% of the volume’s reserved space. If required, the input/output (I/O) will be throttled during the expansion to ensure no write errors are received.
Limitations and Constraints
- The minimum size for a thin-provisioned volume is 40GB.
- The maximum size for a thin-provisioned volume is 512 terabytes (TB).
- A minimal assured space may be specified as well using the reservedSpacePercentage field (the default is 10%).
- The block size must be set to 4KB, in order to reduce metadata.
- KumoScale software requires a small amount of capacity for metadata management (<100MB) when creating a thin-provisioned volume. This is subtracted from the group’s overall capacity.
 Definition of capacity - KIOXIA Corporation defines a megabyte (MB) as 1,000,000 bytes, a gigabyte (GB) as 1,000,000,000 bytes and a terabyte (TB) as 1,000,000,000,000 bytes. A computer operating system, however, reports storage capacity using powers of 2 for the definition of 1Gbit = 230 bits = 1,073,741,824 bits, 1GB = 230 bytes = 1,073,741,824 bytes and 1TB = 240 bytes = 1,099,511,627,776 bytes and therefore shows less storage capacity. Available storage capacity (including examples of various media files) will vary based on file size, formatting, settings, software and operating system, and/or pre-installed software applications, or media content. Actual formatted capacity may vary.