Jiva User Guide
The recommended approach to provision Jiva volumes is via CSI Driver. For detailed instructions on how to get started with new Jiva CSI Driver please refer to the Quickstart guide on Github.
For details of how Jiva works, see Jiva overview page
Jiva is a light weight storage engine that is recommended to use for low capacity workloads. The snapshot and storage management features of the other cStor engine are more advanced and is recommended when snapshots are a need.
Provisioning with Local or Cloud Disks
Provision Sample Application with Jiva Volume
Setting up Jiva Storage Policies
#Simple Provisioning of Jiva
To quickly provision a Jiva volume using the default pool and StorageClass, use the following command
In this mode, OpenEBS provisions a Jiva volume with three replicas on three different nodes. Ensure that there are 3 Nodes in the cluster. The data in each replica is stored in the local container storage of that replica itself. The data is replicated and highly available and is suitable for quick testing of OpenEBS and simple application PoCs. If it is single node cluster, then download the above YAML spec and change the replica count accordingly and apply the modified YAML spec.
#Provisioning with Local or Cloud Disks
In this mode, local disks on each node has to be formatted and mounted at a directory path. The steps for mounting a disk into a node and creating a Jiva storage pool is provided here. Then, storage class has to be created by specifying this StoragePool name. You can use this StorageClass in PVC configuration.
#Provision Sample Applications with Jiva Volume
Here we illustrate the usage of default Jiva storage class. In the following example manifest, the default storage class
openebs-jiva-default is specified in
PersistentVolumeClaim specification. So, the Jiva volume will be created with 3 replicas adhering to the default configuration. The manifest for deploying Percona can be downloaded from here or use the following spec.
Percona spec---apiVersion: apps/v1beta1kind: Deploymentmetadata:name: perconalabels:name: perconaspec:replicas: 1selector:matchLabels:name: perconatemplate:metadata:labels:name: perconaspec:securityContext:fsGroup: 999tolerations:- key: "ak"value: "av"operator: "Equal"effect: "NoSchedule"containers:- resources:limits:cpu: 0.5name: perconaimage: perconaargs:- "--ignore-db-dir"- "lost+found"env:- name: MYSQL_ROOT_PASSWORDvalue: k8sDem0ports:- containerPort: 3306name: perconavolumeMounts:- mountPath: /var/lib/mysqlname: demo-vol1volumes:- name: demo-vol1persistentVolumeClaim:claimName: demo-vol1-claim---kind: PersistentVolumeClaimapiVersion: v1metadata:name: demo-vol1-claimspec:storageClassName: openebs-jiva-defaultaccessModes:- ReadWriteOnceresources:requests:storage: 5G---apiVersion: v1kind: Servicemetadata:name: percona-mysqllabels:name: percona-mysqlspec:ports:- port: 3306targetPort: 3306selector:name: percona
Run the application using following command.kubectl apply -f demo-percona-mysql-pvc.yaml
Now, Percona application runs inside jiva default storage pool.
Before provisioning the application ensure that all the below mentioned steps are carried out:
Ensure that the filesystem is mounted as per requirement. To know more about mount status click here.
First, You need to Create a Jiva Pool specifying the filesystem path on each node. To know about the detailed steps click here.
Using this storage pool, create a storage class by referring here.
Once all the above actions have been successfully executed, You can deploy Busybox with Jiva volume as follows Copy the below spec into a file, say demo-busybox-jiva.yaml and update storageClassName to openebs-jiva-gpd-3repl.apiVersion: apps/v1kind: Deploymentmetadata:name: busyboxlabels:app: busyboxspec:replicas: 1strategy:type: RollingUpdateselector:matchLabels:app: busyboxtemplate:metadata:labels:app: busyboxspec:containers:- resources:limits:cpu: 0.5name: busyboximage: busyboxcommand: ['sh', '-c', 'echo Container 1 is Running ; sleep 3600']imagePullPolicy: IfNotPresentports:- containerPort: 3306name: busyboxvolumeMounts:- mountPath: /var/lib/mysqlname: demo-vol1volumes:- name: demo-vol1persistentVolumeClaim:claimName: demo-vol1-claim---kind: PersistentVolumeClaimapiVersion: v1metadata:name: demo-vol1-claimspec:storageClassName: openebs-jiva-gpd-3replaccessModes:- ReadWriteOnceresources:requests:storage: 5G---apiVersion: v1kind: Servicemetadata:name: busybox-mysqllabels:name: busybox-mysqlspec:ports:- port: 3306targetPort: 3306selector:name: busybox```To deploy busybox, execut```kubectl apply -f demo-busybox-jiva.yaml```
To verify whether the application is successfully deployed, execute the following commandkubectl get pods
The application pods should be running as displayed belowNAME READY STATUS RESTARTS AGEbusybox-66db7d9b88-pod01 1/1 Running 0 2m16s
#Monitoring a Jiva Volume
VolumeMonitor is set to ON in the JIva StorageClass. Volume metrics are exported when this parameter is set to ON. Following metrics are supported by Jiva as of the current release.
Grafana charts can be built for the above Prometheus metrics.
#Backup and Restore
OpenEBS volume can be backed up and restore along with application using velero plugin. It helps the user for taking backup of OpenEBS volumes to a third party storage location and then restoration of the data whenever it needed. The steps for taking backup and restore are following.
- Mount propagation feature has to be enabled on Kubernetes, otherwise the data written from the pods will not visible in the restic daemonset pod on the same node. It is enabled by default on Kubernetes version 1.12. More details can be get from here.
- Latest tested Velero version is 1.4.0.
- Create required storage provider configuration to store the backup data.
- Create required storage class on destination cluster.
- Annotate required application pod that contains a volume to back up.
Velero is a utility to back up and restore your Kubernetes resource and persistent volumes.
To take backup and restore of Jiva volume, configure Velero with restic and use
velero backup command to take the backup of application with OpenEBS Jiva volume which invokes restic internally and copies the data from the given application including the entire data from the associated persistent volumes in that application and backs it up to the configured storage location such as S3 or Minio.
The following are the step by step procedure for taking backup and restore of application with Jiva.
- Install Velero
- Annotate Application Pod
- Creating and Managing Backups
- Steps for Restore
#Install Velero (Formerly known as ARK)
Follow the instructions at Velero documentation to install and configure Velero and follow restic integration documentation for setting up and usage of restic support.
While installing Velero plugin in your cluster, specify
--use-restic to enable restic support.
Verify using the following command if restic pod and Velero pod are running after installing velero with restic support.
The following is an example output in a 3 Node cluster.
#Annotate Application Pod
Run the following to annotate each application pod that contains a volume to back up.
In the above example command, where the volume names are the names of the volumes specified in the application pod spec.
If application spec contains the volume name as mentioned below, then use volume name as
demo-vol1 in the below command.
And if the application pod name is
percona-7b64956695-dk95r , use the following command to annotate the application.
#Creating and Managing Backups
Take the backup using the below command. Here you should add the selector for avoiding Jiva controller and replica deployment from taking backup.
After taking backup, verify if backup is taken successfully by using following command.
The following is a sample output.
You will get more details about the backup using the following command.
Once the backup is completed you should see the
Phase marked as
Completed in the output of above command.
#Steps for Restore
Velero backup can be restored onto a new cluster or to the same cluster. An OpenEBS PVC with the same name as the original PVC will be created and application will run using the restored OpenEBS volume.
- Create the same namespace and StorageClass configuration of the source PVC in your destination cluster.
- If the restoration is happens on same cluster where Source PVC was created, then ensure that application and its corresponding components such as Service, PVC and PV are deleted successfully.
On the target cluster, restore the application using the below command.
The following can be used to obtain the restore job status.
The following is an example output. Once the restore is completed you should see the status marked as
Verify application status using the following command.
Verify PVC status using the following command.
Verify PV status using the following command.
#Create a Jiva Pool
The process of creating a Jiva pool include the following steps.
Prepare disks and mount them
Create a Jiva pool using the above mounted disk.
#Prepare disks and mount them
If it is a cloud disk provision and mount on the node. If three replicas of Jiva volume are needed, provision three cloud disks and mount them on each node. The mount path needs to be same on all three nodes. The following is the steps for creating a GPD disk on Google cloud and mounting to the node.
Create a GPDgcloud compute disks create disk1 --size 100GB --type pd-standard --zone us-central1-a
Attach the GPD to a nodegcloud compute instances attach-disk <Node Name> --disk disk1 --zone us-central1-a
If the disk attached is mapped to /dev/sdb, verify the size, mount the disk and format itsudo lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABELsudo mkfs.ext4 /dev/<device-name>sudo mkdir /home/openebs-gpdsudo mount /dev/sdb /home/openebs-gpd
Repeat the above steps on other two nodes if this is a three replica case.
#Create a Jiva Pool using the mounted disk
Jiva pool requires mount path to be prepared and available on the Node. Note that if the mount path is not pointing a real disk, then a local directory is created with this mount path and the replica data goes to the container image disk (similar to the case of
YAML specification to create the Jiva pool is shown belowapiVersion: openebs.io/v1alpha1kind: StoragePoolmetadata:name: gpdpooltype: hostdirspec:path: "/home/openebs-gpd"
Copy the above content to the into a file called
jiva-gpd-pool.yamland create the pool using the following command.kubectl apply -f jiva-gpd-pool.yaml
Verify if the pool is created using the following commandkubectl get storagepool
#Create a StorageClass
This StorageClass is mainly for using the Jiva Storagepool created with a mounted disk. Jiva volume can be provision using default Jiva StorageClass named
openebs-jiva-default in the corresponding PVC spec. The default StorageClass has replica count as 3.
The steps for creating Jiva Storage pool is mentioned in the above section. Specify the Jiva pool in the
StoragePool annotation of StorageClass. Example StorageClass specification is given below.
Copy the above content to the into a file called jiva-gpd-3repl-sc.yaml and create the pool using the following commandkubectl apply -f jiva-gpd-3repl-sc.yaml
Verify if the StorageClass is created using the following commandkubectl get sc
#Setting up Jiva Storage Policies
Below table lists the storage policies supported by Jiva. These policies can be added into StorageClass and apply them through PersistentVolumeClaim or VolumeClaimTemplates interface.
|JIVA STORAGE POLICY||MANDATORY||DEFAULT||PURPOSE|
|ReplicaCount||No||3||Defines the number of Jiva volume replicas|
|Replica Image||openebs/m-apiserver:2.11.0||To use particular Jiva replica image|
|ControllerImage||openebs/jiva:2.11.0||To use particular Jiva Controller Image|
|StoragePool||Yes||default||A storage pool provides a persistent path for an OpenEBS volume. It can be a directory on host OS or externally mounted disk.|
|VolumeMonitor||ON||When ON, a volume exporter sidecar is launched to export Prometheus metrics.|
|VolumeMonitorImage||openebs/m-exporter:2.11.0||Used when VolumeMonitor is ON. A dedicated metrics exporter to the workload. Can be used to apply a specific issue or feature for the workload|
|Volume FSType||ext4||Specifies the filesystem that the volume should be formatted with. Other values are |
|Volume Space Reclaim||false||It will specify whether data need to be retained post PVC deletion.|
|TargetNodeSelector||Decided by Kubernetes scheduler||Specify the label in |
|Replica NodeSelector||Decided by Kubernetes scheduler||Specify the label in |
|TargetTolerations||Decided by Kubernetes scheduler||Configuring the tolerations for Jiva Target pod.|
|ReplicaTolerations||Decided by Kubernetes scheduler||Configuring the tolerations for Jiva Replica pods.|
|TargetResourceLimits||Decided by Kubernetes scheduler||CPU and Memory limits to Jiva Target pod|
|TargetResourceRequests||Decided by Kubernetes scheduler||Configuring resource requests that need to be available before scheduling the containers.|
|AuxResourceLimits||Decided by Kubernetes scheduler||configuring resource limits on the target pod.|
|AuxResourceRequests||Decided by Kubernetes scheduler||Configure minimum requests like ephemeral storage to avoid erroneous eviction by K8s.|
|ReplicaResourceRequests||Decided by Kubernetes scheduler||Configuring resource requests that need to be available to the Replica.|
|ReplicaResourceLimits||Decided by Kubernetes scheduler||Allow you to specify resource limits for the Replica.|
|Target Affinity||Decided by Kubernetes scheduler||The policy specifies the label |
|OpenEBS Namespace Policy for Jiva Pods||false||Jiva Pod will be deployed in PVC name space by default. With the value as |
#Replica Count Policy
You can specify the Jiva replica count using the value for ReplicaCount property. In the following example, the jiva-replica-count is specified as 3. Hence, three replicas are created.
#Replica Image Policy
You can specify the jiva replica image using value for ReplicaImage property.
#Controller Image Policy
You can specify the jiva controller image using the value for ControllerImage property.
#Volume Monitor Policy
You can specify the jiva volume monitor feature which can be set using value for VolumeMonitor property.
#Storage Pool Policy
A storage pool provides a persistent path for an OpenEBS volume. It can be a directory on any of the following.
- host-os or
- mounted disk
You must define the storage pool as a Kubernetes Custom Resource (CR) before using it as a Storage Pool policy. Following is a sample Kubernetes custom resource definition for a storage pool.
This storage pool custom resource can now be used as follows in the storage class.
#Volume File System Type Policy
You can specify a storage class policy where you can specify the file system type. By default, OpenEBS comes with ext4 file system. However, you can also use the xfs file system.
Following is a sample setting.
#Volume Monitoring Image Policy
You can specify the monitoring image policy for a particular volume using value for VolumeMonitorImageproperty. The following Kubernetes storage class sample uses the Volume Monitoring policy. By default, volume monitor is enabled.
#Volume Space Reclaim Policy
Support for a storage policy that can disable the Jiva Volume Space reclaim. You can specify the jiva volume space reclaim feature setting using the value for RetainReplicaData property. If User would like to disable Jiva Volume Space reclaim (or in other words - retain the volume data post PVC deletion), set
true. RetainReplicaData specifies whether Jiva replica data folder should be cleared or retained. In the following example, the Jiva volume space reclaim feature is disabled. Hence, volume data will be retained post PVC deletion.
#Target NodeSelector Policy
You can specify the TargetNodeSelector where Target pod has to be scheduled using the value for TargetNodeSelector. In following example,
node: appnode is the node label.
#Replica NodeSelector Policy
You can specify the ReplicaNodeSelector where replica pods has to be scheduled using the value for ReplicaNodeSelector . In following sample storage class yaml,
node: openebs is the node label.
You can specify the TargetTolerations to specify the tolerations for Jiva target.
You can specify the ReplicaTolerations to specify the tolerations for Replica.
You can specify the TargetResourceRequests to specify resource requests that need to be available before scheduling the containers.
#Target ResourceLimits Policy
You can specify the TargetResourceLimits to restrict the memory and cpu usage of Jiva target pod within the given limit using the value for TargetResourceLimits .
You can specify the AuxResourceLimits which allow you to set limits on side cars.
This feature is useful in cases where user has to specify minimum requests like ephemeral storage etc. to avoid erroneous eviction by K8s.
AuxResourceRequests allow you to set requests on side cars. Requests have to be specified in the format expected by Kubernetes.
You can specify the ReplicaResourceRequests to requests the resource requirements of replica pod by specifying memory, CPU and ephemeral-storage values.
You can specify the ReplicaResourceLimits to restrict the memory usage of replica pod within the given limit using the value for ReplicaResourceLimits.
#Target Affinity Policy
The Stateful workloads access the OpenEBS storage volume by connecting to the Volume Target Pod. This policy can be used to co-locate volume target pod on the same node as workload.
This feature makes use of the Kubernetes Pod Affinity feature that is dependent on the Pod labels. User will need to add the following label to both Application and PVC.labels:openebs.io/target-affinity: <application-unique-label>
You can specify the Target Affinity in both application and OpenEBS PVC using the following way.
The following is a snippet of an application deployment YAML spec for implementing target affinity.apiVersion: v1kind: Podmetadata:name: fio-jivalabels:name: fio-jivaopenebs.io/target-affinity: fio-jiva
For OpenEBS PVC, it will be similar to the following.kind: PersistentVolumeClaimapiVersion: v1metadata:name: fio-jiva-claimlabels:openebs.io/target-affinity: fio-jiva
Note: This feature works only for cases where there is a single application pod instance associated to a PVC. Example YAML spec for application deployment can be get from here. In the case of STS, this feature is supported only for single replica StatefulSet.
#OpenEBS Namespace Policy for Jiva Pods
This StorageClass Policy is for deploying the Jiva pods in OpenEBS Namespace. By default, the value is
false, so Jiva Pods will deploy in PVC namespace. The following are the main requirement of running Jiva pods in OpenEBS namespace.
With default value, granting additional privileges to Jiva pods to access hostpath might involve granting privileges to the entire namespace of PVC. With enabling this value as
true, Jiva pods will get additional privileges to access hostpath in OpenEBS namespace.
To avoid duplicate Jiva Pod creation during the restoration using Velero.
The following is a snippet of an StorageClass YAML spec for running Jiva pods in
openebsnamespace.apiVersion: storage.k8s.io/v1kind: StorageClassmetadata:name: jiva-pods-in-openebs-nsannotations:openebs.io/cas-type: jivacas.openebs.io/config: |- name: DeployInOpenEBSNamespaceenabled: "true"provisioner: openebs.io/provisioner-iscsi