Kickstarting your journey with Red Hat OpenShift Virtualization and Rubrik

Late last year, Rukrik announced a collaboration with Red Hat to support Rubrik Security Cloud on Red Hat OpenShift Virtualization, and we’re excited to share that this is now official. Rubrik Security Cloud paired with Red Hat OpenShift Virtualization helps organizations more easily migrate and protect virtual machines (VMs) and applications running on a consistent, trusted and comprehensive application platform. As enterprise organizations migrate their workloads from VM environments to cloud-native platforms  such as OpenShift, they must understand differences in storage between virtualized environments and Kubernetes. This blog will explore the differences between these storage environments and give you a technical overview of how Rubrik will support and protect your workloads running on OpenShift Virtualization. 

Virtualization vs. Kubernetes

Virtualization environments with mature ecosystems and well understood methodologies offer a robust framework for running applications on virtualized hardware. On the other hand, Kubernetes provides agility and scalability for container-based applications, making it the choice for cloud-native environments.

These two technologies, often in combination, are currently the most popular platforms for deploying and managing applications, but their approaches to storage differ significantly. Any data protection technology that supports both container-based and virtualized workloads must account for these different approaches.

Virtualization

Virtualization uses software to emulate a physical computer system, so it presents storage to its workloads as virtual disks. This has two important implications for storage management in a virtualized environment.

First, the virtualization software is part of the virtualized application’s data path. The software running within the VM reads from and writes to these virtual disks, and the virtualization software handles those requests using whatever backing storage it has been configured to use, which may be anything from a simple “raw” file on a local disk to a LUN on a high-end Fibre Channel storage system.

Second, disk input and output is conceptually simple. It involves reading and writing fixed sized blocks, almost always 512 or 4096 bytes, from or to specified locations on the device. (Compare this to a file system with its directory hierarchy, variably sized files, file attributes, links, etc.) This is known as block I/O, and disks are often referred to as block devices.

This combination of block-based I/O and a virtualized data path can be used to enable a variety of advanced storage features — sparse allocation, deduplication, changed block tracking, snapshots, etc. — independently of the underlying storage technology. Importantly, the software that provides these advanced features does not require any knowledge of the format of the data within these blocks; it can treat them as fixed size “blobs” of data.

Kubernetes

In contrast, Kubernetes does not emulate a physical computer system when running container-based applications. An application running within a container has direct access to a restricted subset of its host systems storage. This storage is ephemeral; it only exists while that particular container exists on that node within the Kubernetes cluster.

Early Kubernetes releases did not provide any facility for persistent storage. It was expected that applications running within Kubernetes were either stateless (with no requirement for persistent storage) or that they used some form of external, networked storage — usually object storage that supported Amazon Web Services’s S3 API.

Eventually, Kubernetes introduced the persistent volume storage API and the Container Storage Interface (CSI) for dynamically provisioning and managing persistent storage. Today, most storage vendors provide a CSI that enables Kubernetes workloads to make use of their storage products.

Kubernetes supports two persistent volume “modes,” file mode and block mode. Just like the virtual disks discussed above, block mode persistent volumes support reading and writing of fixed size blocks at specified locations within the block device. Importantly though, container-based workloads have direct access to their block-mode persistent volumes; there is no virtualization software within the data path. Thus, any advanced features must be provided by the underlying storage technology. (It is worth noting that very few container-based workloads make use of block-mode persistent volumes. The vast majority of applications are written to use file-based storage.)

File mode persistent volumes provide container-based workloads with access to file system based storage, effectively a subdirectory. This can be a network filesystem, using a protocol such as NFS or CIFS, or it can be a local file system (NTFS, XFS, FAT, etc.) on top of a block device. In the latter case, only the workloads running on a single node within the Kubernetes cluster will be able to access the persistent volume concurrently, even if it resides on some form of shared storage.

KubeVirt

The KubeVirt project enables Kubernetes to run VMs, in addition to container-based workloads. In order to provide storage for those VMs, KubeVirt creates a persistent volume for each virtual disk. Because the VM will use the storage for block-mode I/O, block mode persistent volumes are usually recommended for performance reasons, but KubeVirt can use file-mode persistent volumes.

How Rubrik manages and protects your data in Red Hat OpenShift Virtualization

Whether customers are looking to migrate their VMs to consolidate infrastructure platforms or fully migrate their applications into a container-based environment, having a single data protection platform to manage them all helps to ease the journey – whatever path an application will take. Knowing data will not only be protected across time, but also stored in a way to prevent manipulation or destruction allows for one less thing to worry about when change is occurring throughout the environment. This is why the collaboration between Red Hat and Rubrik is so effective for our joint customers.

Rubrik is a platform that protects data across multiple platforms – on-premises, in popular public cloud platforms, and across multiple different SaaS applications. All this data will be encrypted in-flight and at-rest, be stored in one or more air-gapped and immutable storage locations to prevent modification, and protected from unauthorized access with role-based authorization controls and quorum authorization.

Rubrik protects both Kubernetes applications and VMs by taking copies of both the persistent volume(s) (PV) and objects within the pod. This creates consistency of the entire pod on restoration by collecting all the interrelated changes necessary. All the data protection work is done within a Rubrik specific namespace that is created when connecting OpenShift with a Rubrik cluster and includes a controller and an external interface. To ensure minimal impact to the resources in the cluster, Rubrik’s backup agent is only instantiated during the backup and recovery process, and is destroyed as soon as the process is completed.

The backup process is pretty straightforward. SLA policies are used to declaratively define how often backups should occur, how long they should be retained, and where they should be stored throughout that retention period. During the backup process, the Rubrik backup agent is instantiated and connected to a snapshot for each PV. Then, all objects and data are copied to the Rubrik cluster.

The restore process works very similar to the backup process, and can happen to the same or a different namespace. Again, the Rubrik backup agent is instantiated and any PVs created and connected to the agent, followed by a copy of all data from the Rubrik cluster into the new PVs. Once all the PVs are restored, the PV is reconnected to the destination namespace along with restoration of any related objects.

In both processes, the Rubrik agent is destroyed at the completion of the job.

Wrap-up

As organizations decide to migrate their virtual machines and legacy workloads to Red Hat OpenShift Virtualization they need to consider storage implications and how to best protect their data. Check out the hands-on walkthrough of Rubrik Security Cloud to continue learning. Make sure to tune in on Wednesday, March 26th at 10:00am PST to watch a live webinar featuring Rubrik and RH experts on: Building Cyber Resilience for OpenShift VMs, register today.

More Resources

Check out the datasheet

Learn more about Rubrik’s partnership with Red Hat.

Check out the listing on Red Hat Ecosystem Catalog