Configuring DiskPools

About DiskPools

When a node allocates storage capacity for a replica of a persistent volume (PV) it does so from a DiskPool. Each node may create and manage zero, one, or more such pools. The ownership of a pool by a node is exclusive. A pool can manage only one block device, which constitutes the entire data persistence layer for that pool and thus defines its maximum storage capacity.

To get started, it is necessary to create and host at least one pool on one of the nodes in the cluster. The number of pools available limits the extent to which the synchronous n-way mirroring feature (replication) of PVs can be configured; the number of pools configured should be equal to or greater than the desired maximum replication factor of the PVs to be created. Also, while placing data replicas ensure that appropriate redundancy is provided. DataCore Bolt's control plane will avoid placing more than one replica of a volume on the same node. For example, the minimum viable configuration for a DataCore Bolt deployment, which is intended to implement 3-way mirrored PVs must have three nodes, each having one DiskPool, with each of those pools having one unique block device allocated to it.

The current version of DiskPools only supports thick provisioning.

A pool is defined declaratively, through the creation of a corresponding DiskPool custom resource on the cluster. The DiskPool must be created in the same namespace where DataCore Bolt has been deployed. The following parameters of the pool custom resource are user configurable:

• metadata.name:

  This specifies a name for the pool. This field must be unique within the namespace where DataCore Bolt is deployed.

• spec.node:

  This specifies the name of the node on which the DiskPool will be hosted.

• spec.disk:

  This specifies the disk device which is accessible from the node.

The pool definition requires reference to its member block device to adhere to a discrete range of schemas, each associated with a specific access mechanism/transport/device type. The table below lists the permissible schemas for the parameter spec.disks under DiskPool custom resource YAML.

DataCore advises usage of by-uuid form of reference for block devices. This prevents loss of access to pools in the case of node reboots, which may lead to changes in the disk path.

After creating a pool, ensure that the associated block device is used only by the node that hosts the pool. The block device should not be partitioned, formatted, or shared with another application or process. Any pre-existing data on the device will be destroyed.

Minimum and Maximum configurations for pools:

• Disk devices per pool:

  A pool can only have one disk.

• Pool disk device size:

  The minimum size of block device that can be used to create a DiskPool is 1GiB. There are no upper limits imposed on pool size.

• Maximum number of pools:

  There is no maximum limit to the number of pools that can be provisioned per node or cluster.

Create Disk Pool(s)

Using the following examples as templates, pool(s) with required configuration can be created.

apiVersion: datacore.com/v1alpha1
kind: DiskPool
metadata:
  name: INSERT_POOL_NAME_HERE
  namespace: datacore
spec:
  disks: 
  - INSERT_DEVICE_URI_HERE
  node: INSERT_WORKERNODE_HOSTNAME_HERE
  

Ensure that the fields metadata.name, spec.node and spec.disks are updated based on the cluster's intended configuration. Note that while the disks parameter accepts an array of values, the current version of DataCore Bolt supports only one disk device per pool.

Verify Pool Creation and Status

The status of DiskPools can be determined by reference to their cluster custom resources (CRs). Available, healthy pools should report their state as online. Verify that the expected number of pools have been created and are online.

kubectl get diskpool -n datacore

NAME                  NODE          STATUS   CAPACITY      USED   AVAILABLE
pool-on-node-0-1611   node-0-1611   Online   10724835328   0      10724835328
pool-on-node-1-1611   node-1-1611   Online   10724835328   0      10724835328
pool-on-node-2-1611   node-2-1611   Online   10724835328   0      10724835328

Create StorageClass

DataCore Bolt dynamically provisions PersistentVolumes (PVs) based on StorageClass definitions created by the user. Parameters of the definition are used to set the characteristics and behavior of its associated PVs. Most importantly, StorageClass definition is used to control the level of data protection afforded to it (that is, the number of synchronous data replicas which are maintained, for purposes of redundancy). It is possible to create any number of StorageClass definitions, spanning all permitted parameter permutations.

In this user guide we will illustrate the creation of StorageClass with examples of two possible use cases:

• Single data replica (i.e. No data redundancy)

• Three data replicas.

These can be modified to match the desired use case.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: INSERT_STORAGE_CLASS_NAME
parameters:
  ioTimeout: "30"
  protocol: nvmf
  repl: "1"
provisioner: com.datacore.bolt
reclaimPolicy: Delete
volumeBindingMode: Immediate

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: INSERT_STORAGE_CLASS_NAME
parameters:
  ioTimeout: "30"
  protocol: nvmf
  repl: "3"
provisioner: com.datacore.bolt
reclaimPolicy: Delete
volumeBindingMode: Immediate

The default installation of DataCore Bolt includes the deployment of a StorageClass with the name bolt-1. The replication factor is set to 1. The users can either use this default StorageClass or create one themselves.