Volumes and snapshots
The volume is a virtual disk. InfiniBox volumes span across all active drives, allowing for self-healing in case of a drive failure.
The volume capacity is determined by the user and is affected by the settings of the pool that the volume belongs to. Each volume must belong to a pool and can belong to only one pool. The volume can move among pools.
The volume snapshot is a point-in-time representation of the volume’s data. The volume can have up to 999 snapshots. A snapshot can have snapshots, as well. Taking a snapshot of multiple volumes at the same point in time is also supported. In order to do this, the volumes are grouped into consistency groups.
The volume is the basic data container that is presented to the hosts as a logical disk. The term volume is sometimes used for an entity that is either a volume or a snapshot, as hosts view volumes and snapshots through the same protocol.
To distinguish the volume from its snapshots, whenever required, the term "master volume" is used.
Each volume has the following basic configuration attributes: name, size, pool, provisioning type and ssd-enabled. The volume name is an alphanumeric string that is not related to the SCSI protocol. The volume size represents the number of blocks in the volume that the host sees. InfiniBox presents the volume size in bytes and multiplications of bytes (KB, GB, TB).
Available volume operations are (all of the operations are available from the GUI, CLI and API):
- Creating a volume – creates a volume by name, pool and size (mandatory parameters), attributes such as provisioning type, usage of SSD drives and compression. The GUI and CLI also allow to create series of volumes at once
- Querying for volumes – displaying a filterable and sortable list of the system’s volumes
- Displaying the volume tree – displaying the parental relations between the volume and its snapshots in a tree format
- Resizing a volume – increasing the volume size
- Shrinking the volume is not available
- Resizing the volume is not applicable for replicated volumes
- Setting the volume to use the system’s SSD drives – as InfiniBox provides several hardware layers to choose from, it is possible to allow highly active volumes to utilize the system’s SSD drives. This attribute is inherited from the pool, and can be changed individually for each volume
- Renaming the volume – the volume can be renamed (in accordance with InfiniBox naming scheme)
- Write-protection – locking the volume to host writes
- Changing the thin provisioning setting – the volume can be set to be thin-provisioned or thick-provisioned
- Thick-provisioned - the capacity that is allocated to the volume is determined upon the volume creation.
- Thin-provisoned - the capacity that is allocated to the volume is determined upon incoming writes.
- Mapping the volume to a host – InfiniBox exposes the volume to the host in order to allow for reads and writes. To be mapped to a volume, he host has to be connected to InfiniBox.
- Creating a snapshot and restoring from a snapshot
- Deleting a volume
- Setting the volume to be compressed
- Moving the volume between pools
See a broader discussion below for each of the operations.
InfiniBox uses the redirect-on-write approach to snapshots taking, where creating a snapshot means creating a pointer to the existing volume data, rather than copying the volume aside in a mechanism known is copy-on-write. The InfiniBox natively enables the user to take any number of snapshots with no performance penalty whatsoever.
As taking the snapshot does not impact performance, and at the moment of creation the snapshot contains only pointers to the volume, the system can store an unlimited number of snapshots. For functional considerations, the number of snapshots for a volume is limited to 999. All of the snapshots of a volume share a single copy of unmodified data.
The redirect-on-write mechanism creates a volume snapshot as follows:
- All of the data of the volume is not impacted by the snapshot. It remains in place, not moved and not copied.
- Following the creation of the snapshot, as the volume accepts new writes, the new writes are stored on a new storage space.
- The snapshot keeps pointing to the old data (as it represents the volume data on a specific given time) and the volumes points to the new data instead of the old data.
Taking a snapshot of a snapshot is done similarly to taking a snapshot of a volume. The parent snapshot is not impacted by this action, and the child snapshot only points to data.
When a snapshot is created, it is write-protected. This means that the snapshot depicts the volume (or parent snapshot) at a specific point-in-time such that when the volume is restored from the snapshot, it reflects its own content at the point-in-time in which the snapshot was taken.
When a snapshot becomes writable and starts accepting writes, its child snapshots behave similarly to the way a snapshot of a volume behaves. For every write that the snapshot receives, the child snapshot keeps pointing at the old data, with no unecessary writes and no impact on performance.
Refreshing the snapshot means that the snapshot points to the current volume data, but it maintains its metadata (SCSI serial, creation date, location on the volume tree). The refresh mechanism involves changing only the pointers of the snapshot. Storage space that is released by the refreshed snapshot and is not pointed to by any other snapshot is freed, and this operation takes place outside of the scope of the snapshot refresh.
Restoring a volume from a snapshot
When a volume is restored from its snapshot, it points to the blocks of data that the snapshot points to. No actual data copy takes place, and the operation is instantaneous similarly to the operation of taking a snapshot. The volume stops pointing to blocks of data that were not pointed to by the snapshot from which it is restored. In order not to lose this data, it is recommended to create a snapshot prior to the restore operation.