Clustering applications, such as MySQL and Cassandra, typically require persistent storage to maintain the integrity of the data and files that the application uses. When many applications require persistent storage at the same time, multi-disk provisioning might not be possible due to the limited amount of available resources.

Shared storage solves this problem by allocating the same resources from a single device to multiple services.

File storage solutions provide the directory structure that is found in many environments. Using file storage is ideal when applications generate or consume reasonable volumes of organized data. Applications that use file-based implementations are prevalent, easy to manage, and provide an affordable storage solution.

File-based solutions are a good fit for data backup and archiving, due to their reliability, as are also file sharing and collaboration services. Most data centers provide file storage solutions, such as a network-attached storage (NAS) cluster, for these scenarios.

Network-attached storage (NAS) is a file-based storage architecture that makes stored data accessible to networked devices. NAS gives networks a single access point for storage with built-in security, management, and fault-tolerant capabilities. Out of the multiple data transfer protocols that networks can run, two protocols are fundamental to most networks: internet protocol (IP) and transmission control protocol (TCP).

The files that are transferred across these protocols can be formatted as one of the following protocols:

NAS solutions can provide file-based storage to applications within the same data center. This approach is common to many application architectures, including the following architectures:

These applications take advantage of data reliability and the ease of file sharing that is available by using file storage. Additionally, for file storage data, the OS and file system handle the locking and caching of the files.

Although familiar and prevalent, file storage solutions are not ideal for all application scenarios. One particular pitfall of file storage is poor handling of large data sets or unstructured data.

Block storage solutions, such as Storage Area Network (SAN) and iSCSI technologies, provide access to raw block devices for application storage. These block devices function as independent storage volumes, such as the physical drives in servers, and typically require formatting and mounting for application access.

Using block storage is ideal when applications require faster access for optimizing computationally heavy data workloads. Applications that use block-level storage implementations gain efficiencies by communicating at the raw device level, instead of relying on operating system layer access.

Block-level approaches enable data distribution on blocks across the storage volume. Blocks also use basic metadata, including a unique identification number for each block of data, for quick retrieval and reassembly of blocks for reading.

SAN and iSCSI technologies provide applications with block-level volumes from network-based storage pools. Using block-level access to storage volumes is common for application architectures, including the following architectures:

Application storage that uses several block devices in a RAID configuration benefits from the data integrity and performance that the various arrays provide.

With Red Hat OpenShift Container Platform (RHOCP), you can create customized storage classes for your applications. With the NAS and the SAN storage technologies, RHOCP applications can use either the NFS protocol for file-based storage, or the block-level protocol for block storage.

A stateful application is characterized by acting according to past states or transactions, which affect the current state and future ones of the application. Using a stateful application simplifies recovery from failures by starting from a certain point in time.

A stateful set is the representation of a set of pods with consistent identities. These identities are defined as a network with a single stable DNS, hostname, and storage from as many volume claims as the stateful set specifies. A stateful set guarantees that a given network identity maps to the same storage identity.

Deployments represent a set of containers within a pod. Each deployment can have many active replicas, depending on the user specification. These replicas can be scaled up or down, as needed. A replica set is a native Kubernetes API object that ensures that the specified number of pod replicas are running. Deployments are used for stateless applications by default, and they can be used for stateful application by attaching a persistent volume. All pods in a deployment share a volume and PVC.

In contrast with deployments, stateful set pods do not share a persistent volume. Instead, stateful set pods each have their own unique persistent volumes. Pods are created without a replica set, and each replica records its own transactions. Each replica has its own identifier, which is maintained in any rescheduling. You must configure application-level clustering so that stateful set pods have the same data.

Stateful sets are the best option for applications, such as databases, that require consistent identities and non-shared persistent storage.

With Kubernetes, you can use manifest files to specify the intended configuration of a stateful set. You can define the name of the application, labels, the image source, storage, environment variables, and more.

The following snippet shows an example of a YAML manifest file for a stateful set:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: dbserver 
spec:
  selector:
    matchLabels:
      app: database 
  replicas: 3 
  template:
    metadata:
      labels:
        app: database 
    spec:
      containers:
      - env: 
        - name: MYSQL_USER
          valueFrom:
            secretKeyRef:
              key: user
              name: sakila-cred
        image: registry.ocp4.example.com:8443/redhattraining/mysql-app:v1 
        name: database 
        ports: 
        - containerPort: 3306
          name: database
        volumeMounts: 
        - mountPath: /var/lib/mysql
          name: data
      terminationGracePeriodSeconds: 10
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ] 
      storageClassName: "lvms-vg1" 
      resources:
        requests:
          storage: 1Gi 

Create the stateful set by using the create command:

[user@host ~]$ oc create -f statefulset-dbserver.yml

Verify the creation of the stateful set named dbserver:

[user@host ~]$ kubectl get statefulset
NAME       READY   AGE
dbserver   3/3     6s

Verify the status of the instances:

[user@host ~]$ oc get pods
NAME         READY   STATUS    RESTARTS   AGE
dbserver-0   1/1     Running   0          85s
dbserver-1   1/1     Running   0          82s
dbserver-2   1/1     Running   0          79s

Verify the status of the persistent volumes:

[user@host ~]$ kubectl get pvc
NAME              STATUS   VOLUME             CAPACITY   ACCESS MODES   STORAGECLASS ...
data-dbserver-0   Bound    pvc-c28f61ee-...   1Gi        RWO            nfs-storage  ...
data-dbserver-1   Bound    pvc-ddbe6af1-...   1Gi        RWO            nfs-storage  ...
data-dbserver-2   Bound    pvc-8302924a-...   1Gi        RWO            nfs-storage  ...

Notice that three PVCs were created. Confirm that persistent volumes are attached to each instance:

[user@host ~]$ oc describe pod dbserver-0
...output omitted...
Volumes:
  data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  data-dbserver-0
...output omitted...

[user@host ~]$ oc describe pod dbserver-1
...output omitted...
Volumes:
  data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  data-dbserver-1
...output omitted...

[user@host ~]$ oc describe pod dbserver-2
...output omitted...
Volumes:
  data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  data-dbserver-2
...output omitted...

You can update the number of replicas of the stateful set by using the scale command:

[user@host ~]$ oc scale statefulset/dbserver --replicas 1
NAME         READY   STATUS    RESTARTS  ...
dbserver-0   1/1     Running   0         ...

To delete the stateful set, use the delete statefulset command:

[user@host ~]$ kubectl delete statefulset dbserver
statefulset.apps "dbserver" deleted

Notice that the PVCs are not deleted after the execution of the oc delete statefulset command:

[user@host ~]$ oc get pvc
NAME              STATUS   VOLUME             CAPACITY   ACCESS MODES   STORAGECLASS ...
data-dbserver-0   Bound    pvc-c28f61ee-...   1Gi        RWO            nfs-storage  ...
data-dbserver-1   Bound    pvc-ddbe6af1-...   1Gi        RWO            nfs-storage  ...
data-dbserver-2   Bound    pvc-8302924a-...   1Gi        RWO            nfs-storage  ...

You can create a stateful set from the web console by clicking the Workloads → StatefulSets menu. Click Create StatefulSet and customize the YAML manifest.