Jiva User Guide

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

Monitoring a Jiva Volume

Create a Jiva Pool

Setting up Jiva Storage Policies

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 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/v1beta1
  kind: Deployment
  metadata:
    name: percona
    labels:
      name: percona
  spec:
    replicas: 1
    selector: 
      matchLabels:
        name: percona 
    template: 
      metadata:
        labels: 
          name: percona
      spec:
        securityContext:
          fsGroup: 999
        tolerations:
        - key: "ak"
          value: "av"
          operator: "Equal"
          effect: "NoSchedule"
        containers:
          - resources:
              limits:
                cpu: 0.5
            name: percona
            image: percona
            args:
              - "--ignore-db-dir"
              - "lost+found"
            env:
              - name: MYSQL_ROOT_PASSWORD
                value: k8sDem0
            ports:
              - containerPort: 3306
                name: percona
            volumeMounts:
              - mountPath: /var/lib/mysql
                name: demo-vol1
        volumes:
          - name: demo-vol1
            persistentVolumeClaim:
              claimName: demo-vol1-claim
  ---
  kind: PersistentVolumeClaim
  apiVersion: v1
  metadata:
    name: demo-vol1-claim
  spec:
    storageClassName: openebs-jiva-default
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 5G
  ---
  apiVersion: v1
  kind: Service
  metadata:
    name: percona-mysql
    labels:
      name: percona-mysql
  spec:
    ports:
      - port: 3306
        targetPort: 3306
    selector:
        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.

2.Busybox

Before provisioning the application ensure that all the below mentioned steps are carried out:

1. Ensure that the filesystem is mounted as per requirement. To know more about mount status click here.
2. First, You need to Create a Jiva Pool specifying the filesystem path on each node. To know about the detailed steps
3. Using this storage pool, create a storage class by referring here.

4. 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/v1
   kind: Deployment
   metadata:
    name: busybox
    labels:
      app: busybox
   spec:
    replicas: 1
    strategy:
      type: RollingUpdate
    selector:
      matchLabels:
        app: busybox
    template:
      metadata:
        labels:
          app: busybox
      spec:
        containers:
        - resources:
             limits:
              cpu: 0.5
          name: busybox
          image: busybox
          command: ['sh', '-c', 'echo Container 1 is Running ; sleep 3600']
          imagePullPolicy: IfNotPresent
          ports:
           - containerPort: 3306
             name: busybox
          volumeMounts:
          - mountPath: /var/lib/mysql
            name: demo-vol1
        volumes:
         - name: demo-vol1
           persistentVolumeClaim:
            claimName: demo-vol1-claim
   ---
   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
    name: demo-vol1-claim
   spec:
    storageClassName: openebs-jiva-gpd-3repl
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
   ---
   apiVersion: v1
   kind: Service
   metadata:
    name: busybox-mysql
    labels:
      name: busybox-mysql
   spec:
    ports:
      - port: 3306
        targetPort: 3306
    selector:
        name: busybox

   To deploy busybox, execute

   kubectl apply -f demo-busybox-jiva.yaml

5. To verify whether the application is successfully deployed, execute the following command:

   kubectl get pods

   The application pods should be running as displayed below

   NAME                       READY   STATUS    RESTARTS   AGE
   busybox-66db7d9b88-kkktl   1/1     Running   0          2m16s

Monitoring a Jiva Volume

By default 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.

openebs_actual_used # Actual volume size used
openebs_connection_error_total # Total no of connection errors
openebs_connection_retry_total # Total no of connection retry requests
openebs_degraded_replica_count # Total no of degraded/ro replicas
openebs_healthy_replica_count # Total no of healthy replicas
openebs_logical_size # Logical size of volume
openebs_parse_error_total # Total no of parsing errors
openebs_read_block_count # Read Block count of volume
openebs_read_time # Read time on volume
openebs_reads # Read Input/Outputs on Volume
openebs_sector_size # sector size of volume
openebs_size_of_volume # Size of the volume requested
openebs_total_replica_count # Total no of replicas connected to cas
openebs_volume_uptime # Time since volume has registered
openebs_write_block_count # Write Block count of volume
openebs_write_time # Write time on volume
openebs_writes # Write Input/Outputs on Volume

Grafana charts can be built for the above Prometheus metrics.

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.

Prerequisites

• 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 .
• 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.

Overview

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 .

The following are the step by step procedure for taking backup and restore of application with Jiva.

1. Install Velero
2. Annotate Application Pod
3. Creating and Managing Backups
4. Steps for Restore

Install Velero (Formerly known as ARK)

Follow the instructions at 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.

kubectl get pod -n velero

The following is an example output in a 3 Node cluster.

NAME                    READY   STATUS    RESTARTS   AGE
restic-8hxx8            1/1     Running   0          9s
restic-nd9d9            1/1     Running   0          9s
restic-zfggm            1/1     Running   0          9s
velero-db6459bb-n2rff   1/1     Running   0          9s

Annotate Application Pod

kubectl -n YOUR_POD_NAMESPACE annotate pod/YOUR_POD_NAME backup.velero.io/backup-volumes=YOUR_VOLUME_NAME_1,YOUR_VOLUME_NAME_2,...

In the above example command, where the volume names are the names of the volumes specified in the application pod spec.

Example Spec:

If application spec contains the volume name as mentioned below, then use volume name as demo-vol1 in the below command.

            volumeMounts:
            - mountPath: /var/lib/mysql
              name: demo-vol1
      volumes:
        - name: demo-vol1
          persistentVolumeClaim:
            claimName: demo-vol1-claim

And if the application pod name is percona-7b64956695-dk95r , use the following command to annotate the application.

kubectl -n default annotate pod/percona-7b64956695-dk95r backup.velero.io/backup-volumes=demo-vol1

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.

velero backup create <backup_name> --selector '!openebs.io/controller,!openebs.io/replica'

Example:

velero backup create hostpathbkp2 --selector '!openebs.io/controller,!openebs.io/replica'

After taking backup, verify if backup is taken successfully by using following command.

velero backup get

The following is a sample output.

NAME           STATUS      CREATED                         EXPIRES   STORAGE LOCATION   SELECTOR
hostpathbkp2   Completed   2019-06-19 17:14:43 +0530 IST   29d       default            !openebs.io/controller,!openebs.io/replica

You will get more details about the backup using the following command.

velero backup describe hostpathbkp2 --details

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.

Prerequisites

• 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.

velero restore create --from-backup <backup-name>

Example:

The following can be used to obtain the restore job status.

velero restore get

The following is an example output. Once the restore is completed you should see the status marked as Completed.

NAME                          BACKUP         STATUS       WARNINGS   ERRORS   CREATED                         SELECTOR
hostpathbkp2-20190619171932   hostpathbkp2   Completed    44          0        2019-06-19 17:19:33 +0530 IST   <none>

Verify application status using the following command.

kubectl get pod -n <namespace>

Verify PVC status using the following command.

kubectl get pvc -n <namespace>

Verify PV status using the following command.

kubectl get pv

Create a Jiva Pool

The process of creating a Jiva pool include the following steps.

1. Prepare disks and mount them

2. 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 mounthing to the node.

• Create a GPD

  gcloud compute disks create disk1 --size 100GB --type pd-standard  --zone us-central1-a

• Attach the GPD to a node

  gcloud 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 it

  sudo lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL
  sudo mkfs.ext4 /dev/<device-name>
  sudo mkdir /home/openebs-gpd
  sudo 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 default pool).

• YAML specification to create the Jiva pool is shown below

    apiVersion: openebs.io/v1alpha1
    kind: StoragePool
    metadata:
        name: gpdpool            
        type: hostdir
    spec:
        path: "/home/openebs-gpd"

• Copy the above content to the into a file called jiva-gpd-pool.yaml and create the pool using the following command.

  kubectl apply -f jiva-gpd-pool.yaml

• Verify if the pool is created using the following command

  kubectl 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.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: openebs-jiva-gpd-3repl
  annotations:
    openebs.io/cas-type: jiva
    cas.openebs.io/config: |
      - name: ReplicaCount
        value: "3"
      - name: StoragePool
        value: gpdpool
provisioner: openebs.io/provisioner-iscsi

• kubectl apply -f jiva-gpd-3repl-sc.yaml

• Verify if the StorageClass is created using the following command

  kubectl get sc

Below table lists the storage policies supported by Jiva. These policies can be added into StorageClass and apply them through PersistentVolumeClaim or VolumeClaimTemplates interface.

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.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: openebs-jiva-default
  annotations:
    openebs.io/cas-type: jiva
    cas.openebs.io/config: |
       - name: ReplicaCount
         value: "3"
provisioner: openebs.io/provisioner-iscsi

Replica Image Policy

You can specify the jiva replica image using value for ReplicaImage property.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: openebs-jiva-default
  annotations:
    openebs.io/cas-type: jiva
    cas.openebs.io/config: |
      - name: ReplicaImage
        value: quay.io/openebs/m-apiserver:2.0.0
provisioner: openebs.io/provisioner-iscsi

Controller Image Policy

You can specify the jiva controller image using the value for ControllerImage property.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: openebs-jiva-default
  annotations:
    openebs.io/cas-type: jiva
    cas.openebs.io/config: |
      - name: ControllerImage
        value: quay.io/openebs/jiva:2.0.0
provisioner: openebs.io/provisioner-iscsi

Volume Monitor Policy

You can specify the jiva volume monitor feature which can be set using value for VolumeMonitor property.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: openebs-jiva-default
  annotations:
    openebs.io/cas-type: jiva
    cas.openebs.io/config: |
      - enabled: "true"
        name: VolumeMonitor
provisioner: openebs.io/provisioner-iscsi

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

Note:

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.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: openebs-jiva-default
  annotations:
    openebs.io/cas-type: jiva
    cas.openebs.io/config: |
      - name: StoragePool
        value: default

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.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: openebs-mongodb
   annotations:
    openebs.io/cas-type: jiva
    cas.openebs.io/config: |
      - name: FSType
        value: "xfs"
provisioner: openebs.io/provisioner-iscsi

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.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: openebs-jiva-default
  annotations:
    openebs.io/cas-type: jiva
    cas.openebs.io/config: |
      - name: VolumeMonitorImage
        value: quay.io/openebs/m-exporter:2.0.0
provisioner: openebs.io/provisioner-iscsi

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 RetainReplicaData as 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.

kind: StorageClass
metadata:
  name: openebs-jiva-default
  annotations:
    openebs.io/cas-type: jiva
    cas.openebs.io/config: |
      - name: RetainReplicaData
        enabled: true
provisioner: openebs.io/provisioner-iscsi

Target NodeSelector Policy

You can specify the TargetNodeSelector where Target pod has to be scheduled using the value for TargetNodeSelector. In following example, node: apnodeis the node label.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    cas.openebs.io/config: |
      - name: TargetNodeSelector
        value: |-
            node: appnode
    openebs.io/cas-type: jiva
provisioner: openebs.io/provisioner-iscsi

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.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    cas.openebs.io/config: |
      - name: ReplicaNodeSelector
        value: |-
            node: openebs
    openebs.io/cas-type: jiva
provisioner: openebs.io/provisioner-iscsi

TargetTolerations Policy

You can specify the TargetTolerations to specify the tolerations for Jiva target.

- name: TargetTolerations
  value: |-
     t1:
       key: "key1"
       operator: "Equal"
       value: "value1"
       effect: "NoSchedule"
     t2:
       key: "key1"
       operator: "Equal"
       value: "value1"
       effect: "NoExecute"

ReplicaTolerations Policy

You can specify the ReplicaTolerations to specify the tolerations for Replica.

- name: ReplicaTolerations
  value: |-
     t1:
       key: "key1"
       operator: "Equal"
       value: "value1"
       effect: "NoSchedule"
     t2:
       key: "key1"
       operator: "Equal"
       value: "value1"
       effect: "NoExecute"

TargetResourceRequests Policy

You can specify the TargetResourceRequests to specify resource requests that need to be available before scheduling the containers.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    cas.openebs.io/config: |
      - name: TargetResourceRequests
        value: |-
            memory: 1Gi
            cpu: 200m
            ephemeral-storage: "100Mi"
    openebs.io/cas-type: jiva
provisioner: openebs.io/provisioner-iscsi

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 .

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    cas.openebs.io/config: |
      - name: TargetResourceLimits
        value: |-
            memory: 1Gi
            cpu: 200m          
    openebs.io/cas-type: jiva
provisioner: openebs.io/provisioner-iscsi

AuxResourceLimits Policy

You can specify the AuxResourceLimits which allow you to set limits on side cars.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    cas.openebs.io/config: |
      - name: AuxResourceLimits
        value: |-
            memory: 1Gi
            cpu: 100m
    openebs.io/cas-type: jiva
provisioner: openebs.io/provisioner-iscsi

AuxResourceRequests Policy

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.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    cas.openebs.io/config: |
      - name: AuxResourceRequests
        value: |-
            memory: 0.5Gi
            cpu: 50m
            ephemeral-storage: "50Mi"            
    openebs.io/cas-type: jiva
provisioner: openebs.io/provisioner-iscsi

ReplicaResourceRequests Policy

You can specify the ReplicaResourceRequests to requests the resource requirements of replica pod by specifying memory, CPU and ephemeral-storage values.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    cas.openebs.io/config: |
      - name: ReplicaResourceRequests
        value: |-
            memory: 1Gi
            cpu: 200m
            ephemeral-storage: "100Mi"
    openebs.io/cas-type: jiva
provisioner: openebs.io/provisioner-iscsi

ReplicaResourceLimits Policy

You can specify the ReplicaResourceLimits to restrict the memory usage of replica pod within the given limit using the value for ReplicaResourceLimits.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    cas.openebs.io/config: |
      - name: ReplicaResourceLimits
        value: |-
            memory: 2Gi
    openebs.io/cas-type: jiva
provisioner: openebs.io/provisioner-iscsi

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: v1
  kind: Pod
  metadata:
    name: fio-jiva
    labels:
      name: fio-jiva
      openebs.io/target-affinity: fio-jiva

  For OpenEBS PVC, it will be similar to the following.

  kind: PersistentVolumeClaim
  apiVersion: v1
  metadata:
    name: fio-jiva-claim
    labels:
      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 . 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 astrue , Jiva pods will get additional privileges to access hostpath in OpenEBS namespace.

The following is a snippet of an StorageClass YAML spec for running Jiva pods in openebs namespace.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: jiva-pods-in-openebs-ns
  annotations:
    openebs.io/cas-type: jiva
    cas.openebs.io/config: |
      - name: DeployInOpenEBSNamespace
provisioner: openebs.io/provisioner-iscsi

Understanding Jiva