A Comprehensive Guide to OpenShift Storage, Volumes, and Claims

Containerization and Kubernetes in particular have changed how enterprise applications are delivered. With Red Hat OpenShift, you gain an enterprise-level platform to automate deployment, scaling, and operation of applications. However, it is easy to see that statless microservices are easily managed in ephemeral containers; enterprise workloads need stable persistent state to carry out transactions using relational databases, handle distributed analytics, and move messages effectively by using message brokers or other tools.

To put it differently, navigational tasks in the continuously shifting container ecosystem imply possessing an extensive knowledge of some essential platform elements. Taking a properly organized openshift course will assist programmers and platform experts in learning the essential abstractions necessary for isolating containerized runs from permanent enterprise storages.

The Issue of State in Container-based Architectures

Created to be temporary, containers erase their writable layer when they crash, shut down, or when they are scheduled to another node. In the early days of containers, state preservation was achieved by developers binding the directories of the host OS directly to the containers. This approach worked for single-node architectures only, as binding at the level of the host OS does not prove to be useful when dealing with clustered environments.

Another problem arises when the compute node fails since the workloads that were tied to that local disk cannot migrate without human involvement and complex data replication process. It’s also important to note that giving containers direct access to the host’s filesystem creates huge security risks and imposes a strict restriction on the design of the architecture.

Kubernetes/OpenShift is a solution to this problem. Both tools help in abstracting storage and make it independent of the individual pod or node in the cluster and provide the opportunity of seamless storage volume migration in case of pod failure or rescheduling. Successful execution of all this requires separation of the operational functions.

Decoupling architecture with regard to administration and developer consumption

OpenShift’s storage design takes a clear position that the duties of infrastructure administrators and application developers should be separated.

Cluster administrators deal with the physical infrastructure, storage capacity planning, resilience of storage fabric, performance tiers of storage, networking options, and the implementation of various access control mechanisms. Their main aim is to provide storage capacities in a way that is reliable, safe, and economically efficient without the need for control over all daily processes of application development.

Application developers, on the other hand, are concentrated on the functional aspects of applications being developed. In particular, the application developer who launches a database application does not need to think about the configuration of storage area networks, fiber channel switches, and block storage devices. Instead, he/she requires a clear list of operational characteristics, such as storage capacity, speed, latency, and read-write processes.

OpenShift achieves this separation by creating two separate APIs.

Persistent Volumes: The Backbone of Infrastructure

A Persistent Volume is identified as a major asset of a cluster. Pods and deployments can be associated with specific namespaces in the project. Still, Persistent Volumes have a cluster-wide scope, which allows them to be perceived as a physical or logical asset of the cluster.

Static and Dynamic Provisioning

In the past, the process of provisioning storage took place in a static manner. The administrator created some storage volumes of certain sizes in an external storage device such as a network file system, enterprise SAN, or the cloud and registered it as a Persistent Volume in OpenShift. The developer applied for the persistent volume claims, and the cluster matched it with one of the existing volumes.

Today's OpenShift environments utilize dynamic provisioning as the core technology. In this process, an abstract definition called a StorageClass is prepared by an administrator. As soon as an application needs storage through a StorageClass, it will automatically provision the storage equipment itself and register it as Persistent Volume in real-time. Dynamic provisioning increases delivery speeds and reduces manual administration costs. By acquiring practical knowledge through enterprise-level redhat openshift training, the administrators of clusters will be prepared to create effective StorageClasses and automate tiered storage solutions.

Attributes of Persistent Volume

There are specific structural properties of Persistent Volumes that determine their operational parameters in the cluster.

Capacity: The size of the storage allocation of the resource that can be either a physical or logical size, given in binary units like GB and TB.
Access Modes: The operational model of concurrency used by the storage volume. This implies whether it can be mounted by one or several nodes and if the write access is available.
Reclaim Policy: The behavior of the cluster after the deletion of the bound claim. The volume can be either retained for investigation purposes, recycled using basic filesystem sanitization, or deleted together with the backend asset.
Mount Options: The parameters of the low-level filesystem and the protocol that are provided directly to the kernel of the operating system when the storage device is being mounted to the compute node.
Volume Mode: The format in which the storage volume is available to the container, meaning whether it is seen as a formatted filesystem or as a raw block device.

The developer agreement for persistent volume claims

In the world of persistent volumes, persistent volume claims represent demand for storage. Strictly appearing inside the OpenShift project namespace, the claim acts as a boundary between authorized applications ensuring that different projects cannot access the storage of one another.

When creating claims, developers indicate their requirements in terms of workload.

Requested capacity: the smallest possible storage space. The system will be unwilling to bind the claim to the volume smaller than that indicated, yet may do the binding to a larger volume if required parameters cannot be matched.
Access mode requirements: specifics about the concurrency model.
Storage class selection: intended operational performance or replication level of the volume enabling to choose fast SSDs, inexpensive HDDs, or geographically distributed cloud storage available.

Application manifests remain completely portable in any environment because they specify claims rather than explicitly the volume. A deployment manifest can run either in a local test cluster with direct-attached disks or in a production enterprise cluster based on software-defined production storage without changing any detail in the definition of the application workload.

Binding and lifecycle mechanics

The interaction between volumes, claims, and pods occurs in a succession of certain lifecycle phases: provisioning, binding, using, reclaiming, and deleting.

Phase 1: Provisioning

In a static scenario, the administrator would interact with an external storage and obtain a logical unit number, export, or block allocation, which would lead to the creating of the persistent volume resource in OpenShift. In a dynamic scenario, the provisioning phase starts automatically when an application creates a claim related to the working StorageClass.

Phase 2: Binding

The OpenShift master controller manager contains a control loop that regularly reconciles claims against the volumes by checking unbound volumes based on unbound claim criteria.

Is the volume capacity sufficient?
Is the access mode supported by the volume?
Is the volume compatible with the storage class requested?
Is the mode configuration of the volume correct?

If there is a matching volume, then the volume and the claim are bound together through an exclusive mutual reference. The claim points to the volume, and vice versa. This referral is one-to-one - only one volume can be bound to a claim, and only one claim can be bound to one volume at a given moment.

When there are no matching volumes available, and dynamic provisioning is not turned on or fails, then the claim stays in the unbound state indefinitely. The control plane will log the failure, and then you will not be able to start dependent pods until the binding criteria are met.

Phase 3: Usage

After the claim enters the bound state, the claim can be consumed by the pods within the same namespace. Whenever a pod is created using the volume mount, OpenShift carries out a number of underlying activities.

Connecting: The storage layout connects the designated disk space to a particular logical or physical processing unit where the pod is scheduled for execution.
Setup: The computer node’s operating system sees the connected block storage or network, initializes it if it is new, and installs it to a local directory associated with the container.
Namespace Mapping: The container technology puts the mounted host directory into the container boundary at the location where the developer indicated.

The pod continues its operation, using simple IO calls to read from and write to the disk space.

Phase 4: Recovery

When a program is taken out of service, the programmer removes the privilege. This process leads to the end of the exclusive right to the used volume while the Persistent Volume takes up the released status. Next, the specific reclaim policy for the used volume is applied:

Retain: The volume stays in the cluster while also remaining in the underlying storage. It cannot be claimed by anyone else, as it is still filled with sensitive application information. The intervention of the administrator is required, who should recover (or archive) the information, sanitize the volume, and delete or register this resource. The majority of known cases concern efficient databases used in production, where the loss of data must be prevented by all means.
Delete: The volume is simply destroyed by the cluster and the storage provider is informed that the particular storage agent is to be destroyed. This is applied mainly in clouds, where data is ephemeral.
Recycle: The method is old and is of basic nature – simply burns the current file system to return the volume to available capacity.

Modes of Access and Concurrency of Workload

Different types of storage workloads vary significantly in their modes of data access across computing boundaries. OpenShift classifies volume access into different types which should be supported by both storage drivers as well as application architecture.

ReadWriteOnce

In this access mode, the volume can be mounted as read-write by only one compute node at a time. To clarify, multiple pods can perform operations on the volume, however, they need to be scheduled onto the same physical or virtual node. This is the most widely used access mode in traditional block storage, including devices working in the cloud as well as enterprise SAN volumes. This is the best access type for transactional stateful applications such as relational databases, where exclusive access to the storage device via one engine process is crucial.

ReadOnlyMany

In this access type, a volume can be mounted as read-only by many compute nodes at once. The mode is appropriate for workloads that involve access to static reference data, for instance geospatial databases, static asset delivery pods, composition bundles, or machine learning inference models executed across distributed nodes.

ReadWriteMany

With this approach, multiple computing nodes can use the volume ReadWrite mode. It involves integrating some special networks such as the clustered or online ones. ReadWriteMany is important for horizontally scalable enterprise systems in which several pod examples need simultaneous read and write access.

ReadWriteOncePod

This access mode is enforced to provide some additional isolation features in comparison with the traditional ReadWriteOnce. The use of this approach means that only a single pod could use the volume. While standard ReadWriteOnce allows several nodes to be connected to the disk, it has allowed the simultaneous connection of other pods present on the same node. ReadWriteOncePod enforces the principle of access of one pod for the entire cluster.

The Storage Classes and their Provisioning

In dynamic provisioning, the storage changes from being a strict and upscale barrier to an adaptive approach with an unprecedented set of possibilities. This transformation takes place via the mechanism known as StorageClass resource.

StorageClass has the following administrative functions:

Provisioner: It refers to a storage plug-in or the specific driver in charge of provisioning storage volume used for provisioning the lower level.
Parameters: specific vendor configurations transferred directly to storage devices, such as RAID levels, encryption keys, replication factors, geographical zones, or disk performance levels.
Reclaim Policy: the appropriate recovery policy that is used for the volumes created under that class.
Volume Binding Mode: the most significant directive indicating precisely when storage provisioning is to be done.
Volume Binding Modes: Immediate vs. WaitForFirstConsumer

The timing of volume creation has direct implications on how the OpenShift scheduler distributes pods throughout the cluster:

Immediate binding: With this approach, as soon as a claim is made, the storage driver communicates with the underlying storage system to create the volume, and generates the Persistent Volume resource as well. But here is the problem: If volumes are created in a specific availability zone or a rack before the scheduling of the pods, the scheduler has to create pods only in nodes that belong to that zone, which are often undersized in terms of CPU and memory.

WaitForFirstConsumer: This option provides for the delay of the provisioning of the volume until the pod that is going to consume the claim is being processed by the scheduler. The scheduler finds a node with sufficient compute and memory resources, takes into consideration the constraints on topology of the cluster, and then gives the driver an instruction to provision the volume in the necessary topological location, thus eliminating deadlocks in the provisioning process and achieving the optimal use of the cluster resources in terms of time and cost.

Filesystem vs. Block Volume Modes

Most container-based applications utilize storage using a conventional mounted directory structure, however, OpenShift is capable of using raw block storage.

Filesystem Mode

Filesystem is the most common volume method used in OpenShift. When a raw block volume is created from a cloud provider or a storage array, OpenShift mounts the storage device into the hosting node, formats it using a specific filesystem such as xfs and ext4, then exposes the directory path inside the container. This scheme is user-friendly, industry-standard and can be used with a big share of existing applications.

Raw Block Mode

In this case, OpenShift connects the storage device to the hosting compute node but does create and mount a file system. The raw block device becomes part of the container as a raw block device file.

This type of approach gives some substantial benefits, particularly for certain workloads:

Fast Databases: Modern advanced databases are specially designed in such a way that they use certain self-optimizing techniques for caching, disk-layout algorithms, and logging. The effective use of customized code means that the burden on CPU is significantly reduced along with latency.
Utilization of OpenShift Virtualization for managing traditional virtual machines in conjunction with containers: The application of OpenShift Virtualization allows for the running of existing virtual machines in conjunction with the virtualization of containers. Implementation of thorough and complete open shift training enables teams to master the process of configuring raw block storage and optimizing the performance of directly attached virtual machines.

The Container Storage Interface (CSI)

Development in Kubernetes and OpenShift storage technologies gave rise to the Container Storage Interface (CSI). For example, Kubernetes's early versions had all storage drivers integrated into the Kubernetes codebase. The down side of this so-called in-tree architecture was as follows:

Problems with third parties' storage drivers would lead to malfunctioning of vital Kubernetes components.
The storage vendors couldn't deliver any updates, patches, or fixes outside the regular scope of Kubernetes releases.
The proprietary third-party technologies had to be present in the open-source code.

CSI has eliminated these structural shortcomings by introducing the industry-wide standard specification that is external to Kubernetes. The storage providers can now create unified plugins that work with Kubernetes using the universal remote procedure calls.

Innovative Features Provided by CSI

Shifting from in-tree to out-of-tree microservices-based architecture made it possible to provide numerous advanced features in OpenShift.

Volume Snapshots: OpenShift API allows users to generate snapshots of claims at defined date and time. Snapshots are useful for archiving purposes in the event of disaster recovery or for creating new instances of the same claims for testing and development.
Volume Cloning: Developers instantly create a duplicate of already available volume and do not affect the original data. This advanced feature is possible due to the CSI drivers, which produce copies through pointers in the storage system, thereby achieving fast creation of realistic testing environments.
Volume Expansion: Often the amount of resources allocated for enterprise applications is not enough to cover the organization's needs. Thanks to modern CSI drivers, it has become possible to resize the claim just by changing the value in the request field.

Summary: Modern OpenShift Storage Mastery

The container-centric architecture of OpenShift's Persistent Volumes and Persistent Volume Claims obtains the best of both worlds by unifying dynamic cloud-native application deployments and robust storage. With OpenShift's approach of separating the management of the infrastructure layer from the developer consumption side, it establishes the framework suitable for running stateful applications in production environments.

Features of modern storage technologies including dynamic provisioning through Storage Classes, standardized CSI, and consolidated platforms such as OpenShift Data Foundation make data storage a manageable utility tool.

Possessing practical expertise in volume lifecycles, access modes, security contexts, and corporate data protection enables companies to successfully move their mission critical workloads when required. To gain career-ready capabilities in managing production containers infrastructure, one must undergo openshift training provided by the industry because OnlineITGuru offers hands-on project experience in mastering cloud storage management.