Red Hat アカウントを使用すると、メンバープロファイルや設定、さらにお客様のステータスに応じて以下のサービスにアクセスできます。
Red Hat アカウントを使用すると、メンバープロファイルや設定、さらにお客様のステータスに応じて以下のサービスにアクセスいただけます。
Red Hat’s OpenShift Container Storage 4 delivers a uniform, persistent storage experience for data-intensive applications in hybrid and multicloud environments. Let's take a look at what differentiates Red Hat OpenShift 4 and why businesses and developers might want to pivot to OpenShift Container Storage.
The appeal of OpenShift Container Storage is that you'll have a uniform set of persistence services for OpenShift applications, independent of the infrastructure on which OpenShift is running.
When speaking about OpenShift Container Storage, we use the term ‘persistence services’ instead of storage services, as OpenShift Container Storage almost always sits above the storage services provided by the infrastructure. So now, with persistence services like multicloud object gateway mirroring, deduplication, encryption, combined with traditional Kubernetes storage classes, we're offering a set of persistence services to the applications running on OpenShift. A uniform set of persistence services.
There are people who ask "With the advent of the container storage interface (CSI) API, or the standardized container native storage interface, do I still need OpenShift Container Storage?" The answer is yes. If you want a uniform set of persistence services. And that's the key.
CSI offers an array of services and the CSI driver authors have a choice of what part of that array of services they implement.
However, if you want to provide your customers with a uniform set of persistence services, independent of the infrastructure on which you run, you need to have a CSI driver that offers, within that array of CSI services, the same set of services across all of those infrastructures.
OpenShift Container Storage does this as an operator of OpenShift.
For example, let’s say that you are running OpenShift on top of Amazon Web Services (AWS). There is an AWS EBS CSI driver, there is an AWS EFS CSI driver. And let’s say, you also run OpenShift on premises on top of VMware. There you might be using, for instance, an NFS driver, or the NetApp Trident CSI driver on top of a NetApp NAS.
You might say: "Oh great, they're all CSI, life is good." But they implement different features within the CSI driver family. In a multi-cloud, hybrid cloud world, if you want a common set, a uniform set of persistence services, independent if you're running OpenShift, on AWS, or running Openshift on VMware on premises, if you want your persistence services layer to be consistent, that's why you still need something like OpenShift Container Storage.
The benefit of uniformity?
Well, let's take a practical example. Let's say, for instance, you want to have some of the applications that you're running on OpenShift have multiple instances of that application access the same data at the same time. That's called RWX access inside of Kubernetes parlance.
So, let’s say you have multiple pods who both need access to the same data at the same time. Well, not all CSI drivers implement RWX access. If you're offering OpenShift services on top of multiple platforms, and you need to offer all of your applications, both multi-pod access and single pod access, not all CSI drivers offer both.
Another example: What if you also need to offer your applications automated bucket claim access through object-bucket claims? Well, as far as we’re aware, only OpenShift Container Storage provides this service, and it is uniformly provided on multiple platforms.
If you are providing the OpenShift service to your customers, you can offer them a common set of services so they don't need to re-architect or re-engineer their application code when you switch or introduce new cloud service providers.
You write to OpenShift once and it runs anywhere that OpenShift runs. That uniformity of platform carries throughout, not only from a compute standpoint, but from a storage or persistence standpoint.
And you can reduce your dependencies, which is a huge deal in a competitive and ever-evolving industry. When you need to create a one-of-a-kind or one-off variations, that always equals cost.
Having a dependency on AWS, on Azure, on VMware on premises, that also equals cost, That's OpenShift’s point. It decreases the cost of having a multicloud or a hybrid cloud approach.
OpenShift 4 as a type of CEO
You might make a comparison to a CEO, to the extent that one of the functions of a CEO is to provide a uniform tone for the organization.
In fact, if you further the analogy and say that good CEOs practice servant leadership, that's what OpenShift Container Platform and OpenShift Container Storage do. They provide servant leadership to the applications that are running thereon.
And, at the end of the day, it's all about the applications running thereon, because that's where the business is. It’s in the applications, running on OpenShift, backed by OpenShift Container Storage.
In a hybrid cloud or multicloud framework, you can decide where you want to store sensitive information or where you want to double-dip for backup purposes. When you're making decisions about your storage profile, there's flexibility there. And that's key. That's one of the novel aspects of OpenShift Container Storage 4 with our acquisition of NooBaa, a year ago, which is now the Multi-Cloud Object Gateway inside of OpenShift Container Storage.
Let’s say I’m writing my data on-premises on a VMware infrastructure, but I also want to mirror that data to AWS or Azure. I want to provide a seamless mirroring service. I don't want to have to have each application owner have to figure out how to do that themselves.
So I’m reducing dependencies. And for safekeeping or, possibly for regulatory purposes, I can mirror my data in another cloud environment. That’s one of the things you can simply do with OpenShift Container Storage 4.