My Storage has CSI drivers, why do I need IBM Fusion?

View Only

My Storage has CSI drivers, why do I need IBM Fusion?

By Greg Deffenbaugh posted Wed January 10, 2024 03:00 PM

Like

I often get the question, “My storage has CSI drivers, why do I need Fusion?”. Unfortunately, the answer is not short. My standard Fusion Technical Value presentation takes about 40 minutes to go through without questions and I always get questions. A conversation with experienced Kubernetes architects and admins often lasts an hour and a half. I am going to try to answer in 800 – 1000 words.

Background

First, let’s start with what is the Container Storage Interface (CSI). Here is a quote from a blog by Saad Ali, one of the upstream developers.

“CSI was developed as a standard for exposing arbitrary block and file storage systems to containerized workloads on Container Orchestration Systems (COs) like Kubernetes. With the adoption of the Container Storage Interface, the Kubernetes volume layer becomes truly extensible. Using CSI, third-party storage providers can write and deploy plugins exposing new storage systems in Kubernetes without ever having to touch the core Kubernetes code. This gives Kubernetes users more options for storage and makes the system more secure and reliable.”

In other words, it is an API to enable storage vendors to expose their products to Kubernetes. If you want to know more about the details you can read the CSI Specification.

If you don’t find the spec very helpful, you are not alone.

The Basics

A vendor providing CSI drivers for their storage offering is like providing an automobile chassis. You can store and snap (point-in-time-copy) your container persistent data, but that is all you know for sure. If you want a dashboard, a comfortable cockpit, or basic safety features like seatbelts or airbags, you will need to determine what your vendor has added to the base CSI feature set. In the automobile industry, there are governing bodies to define minimum safety standards and a common feature set for operations that make it easy to move from one vendor’s automobile to another. For Kubernetes storage, you are going to have to do your own safety and operational evaluation.

A Complete Solution

I grew up on a farm and drove vehicles that weren’t much more than the one above. But today I want a much better transportation experience. I don’t want to have to manually adjust the carburetor or worry about brake pad wear. I just want to get in and drive. The same can be said for storage infrastructure for Kubernetes. You want to focus on building cloud-native applications or porting applications from your virtualization environment.

So what makes Fusion different?:

OpenShift Integrated Console – Fusion is Cloud Native Storage (CNS), it runs within OpenShift, all management is performed within OpenShift, including a full feature dashboard. Many “CSI solutions" still require separate system management by a storage admin, even some “HCI solutions”.

- Managing all OpenShift resources from within OpenShift simplifies operations, reduced risks, and decreases application time-to-market.

Integrated Application Protection – A CSI snap captures the persistent data. Fusion Backup captures the state and the components of the application, plus the persistent data, to create a “backup object” that provides everything needed to restart the application at a point in time.

- Fusion Backup can protect applications that don’t have persistent data, providing a one-stop solution to protect all of your applications.

Automated Disaster Recovery – external storage systems may be able to replicate your data to another system, but that is not a DR solution. Yes, your data is your most important asset, but just having your data is a long way from getting your business up and running again. Fusion replicates your data (synchronously or asynchronously) and integrates with Red Hat Advanced Cluster Manager (ACM) to automate the failover and failback of your application to another OpenShift cluster.

- The OpenShift admin has a “Red Button” to push when you have decided to declare a “disaster” has occurred.

File, Block and Object Storage – CSI only defines interfaces for block and file storage – object storage has its own set of APIs – COSI – that is under development. The being said, external storage CSI solutions usually only support block or file natively. Some file-based solutions offer block on file, where a file is provisioned to look like a block device to the application. Block on file has been around for a long time, if met all needs, why is SAN still so popular? Block SAN systems address the performance challenges of block on file, but leave you to share files at the application, not storage infrastructure level.

- Fusion offers native, file, block, and object storage, without compromise, to meet all of your application requirements.

Object Storage Gateway – While having local S3-compatible storage is valuable for new cloud native applications, the big push of AI and deep analytic projects is to make use of the vast amounts of data that already exists in your company. The Multi-Cloud Gateway provides programmatic access to existing S3 data stores whether on-prem or in the cloud. Further, it provides local caching to address latency challenges of active S3 data processes.

- Managing S3 access at the infrastructure, not application layer, improves security and application portability.

Fusion is designed to be Managed by Kubernetes Admins and Consumed by Application Developers – Fusion hides the complexity of managing storage freeing up resources to focus on building and managing cloud native applications. Fusion is based on the Rook/Ceph project to provide robust storage management and data protection but was designed and built specifically for Kubernetes. It is not just an old storage system with some new API calls, it is purpose built to provide the most complete data management and application protection solution available.

Conclusion

The answer to “My storage has CSI drivers, why do I need Fusion?” is not short, but it is straightforward. Fusion provides a complete storage and application protection solution for OpenShift. Oh, by the way – Fusion can use the CSI drivers provided by your block SAN vendor. If you have un-depreciated SAN storage assets that you want to use for your OpenShift environment, Fusion can use block devices presented to the OpenShift cluster for physical storage extending the useful life of your SAN asset. When you are ready to retire your SAN infrastructure, you can move to solid state devices in your servers and eliminate the Opex and Capex of external SAN storage.