SolidFire Storage Now Available with Platform9 OpenStack
One of the primary benefits of an open platform such as OpenStack is its ability to be an integration engine for various cloud technologies. This gives users the flexibility to choose best of breed compute, networks, and storage technologies to build out their private cloud while retaining the benefits of a common management framework for operators and a set of consistent APIs for developers. It is one of the reasons that we at Platform9 decided to build our cloud management as a service solution using the OpenStack project. As a result, we are able to provide managed services for the management layer while allowing users to choose both KVM and vSphere as hypervisors and any number of networking solutions for their private cloud infrastructure.
And today, we announced general availability of Platform9 Managed OpenStack Cinder integration to enable customers to leverage the storage subsystem of their choice to provide persistent block storage in their KVM or vSphere powered private cloud. Additionally, we are excited that the first storage partner to be certified with Platform9 is SolidFire, the leading all-flash storage company.
Now that we are making Cinder available with Platform9, customers can use storage from partners, such as SolidFire, and know that Platform9 will take responsibility for deploying, hosting, and managing the OpenStack services required to transform that storage into cloud storage. In upcoming weeks, we will be providing more technical detail on how Cinder works, how we architected this joint solution, and the capabilities that we are providing. In this post however, we want to address the following questions:
- Why use Cinder?
- Why use Cinder with an enterprise storage array?
- Why did Platform9 choose to work first with SolidFire?
Why Use OpenStack Cinder Block Storage?
OpenStack cloud instances/virtual machines are typically created with at least one ephemeral disk which is used to run the VM guest operating system and boot partition; an ephemeral disk is purged and deleted when an instance is terminated. Initially, block storage wasn’t an independent project but created as a component of Nova Compute, called Nova Volumes; that has since been broken out as its own project called Cinder.
So what are the characteristics of Cinder and what are some its benefits? Cinder provides instances with block storage volumes that persist even when the instances they are attached to are terminated. A single block volume can only be attached to a single instance at any one time but provides the flexibility to be detached from one instance and attached to another instance. The best analogy to this is of a USB drive which can be attached to one machine and moved to a second machine with any data on that drive staying intact across multiple machines. An instance can attach multiple block volumes.
In a Cloud platform such as OpenStack, persistent block storage has several potential use cases:
- If for some reason you need to terminate and relaunch an instance, you can keep any “non-disposable” data on Cinder volumes and re-attached them to the new instance.
- If an instance misbehaves or “crashes” unexpectedly, you can launch a new instance and attach Cinder volumes to that new instance with the data intact.
- If a compute node crashes, you can launch new instances on surviving compute nodes and attach Cinder volumes to those new instances with the data intact.
- Using a dedicated storage node or storage subsystem to host Cinder volumes, capacity can be provided that is greater than what is available via the direct-attached storage in the compute nodes (Note that is also true if using NFS with shared storage but without data persistence).
- Using an enterprise storage solution to host Cinder volumes so specific vendor features such as thin-provisioning, tiering, Quality of Service, etc. can be leveraged.
- A Cinder volume can be used as the boot disk for a Cloud instance; in that scenario, an ephemeral disk is not required.
Although all of the above use cases can be found across various OpenStack deployments, customers typically design their Cinder environment to support the “compute node crash, greater capacity, and enterprise storage” use cases.
Why Use Cinder with an Enterprise Storage Array?
Some OpenStack deployments use commodity servers as dedicated Cinder volume nodes, as depicted below. In this configuration, the Cinder volume node functions as low cost, no-frills storage array that serves simple block volumes to cloud instances, using the Logical Volume Manager (LVM) included in all Linux distributions to manage locally attached storage.
While this will work for some use cases, it has limitations that make it less than desirable in many enterprise use cases:
- While deploying a commodity Cinder solution is likely the cheaper option when capacity requirements are low, it becomes less cost effective in large capacity use cases. For example, a typical Cinder volume node in an OpenStack deployment might be a Dell R720 server with 8 internal drives.Using 600 GB 15K SAS drives would yield ~2.3 TBs with RAID 10 and ~5.4 TBs with RAID 5 and less, obviously, with SSD. I’ve talked to users that required 12 TBs of Cinder storage and needed it to be on 600 GB SAS drives in a RAID 10 configuration; using just commodity servers would mean implementing a solution with 5 Cinder volume nodes.
Enterprise storage solutions provide greater capacity than a commodity Cinder volume node solution without creating silos of independent nodes.
- Another limitation in a commodity Cinder solution is the lack of redundancy. While both nodes can be managed by the same Cloud controllers, the volume nodes are in fact independent “storage arrays” that do not share data between each other. Effectively, this means that if a Cinder volume node fails, all volumes exported by that node, as well as the data on it, become unavailable.
An enterprise storage solution provides more redundancy than is available with a commodity Cinder server. For example, many modern storage arrays have redundant controllers with mirrored write cache. In the case of SolidFire, metadata are distributed across multiple nodes as well.
- Cinder with LVM lacks much of the advanced functionality that is found in most enterprise storage solutions, such as compression, de-duplication, thin-provisioning, and QoS. There are enterprise applications, such as database, where these capabilities are important.
For these reasons, most users are looking to enterprise storage vendors to provide Cinder storage solutions that are suitable for their growing production cloud workloads.
Why Did Platform9 Choose to Work First with SolidFire?
When we made the decision to roll out Cinder with our Platform9 solution, SolidFire was an easy choice for our first storage partner.
- SolidFire has been involved with the Cinder project from its inception, with John Griffith serving as the first Cinder Project Technical Lead. John’s continued involvement with the project and the fact that SolidFire was among the first storage solutions to integrate with Cinder make them a clear OpenStack storage leader.
- SolidFire exposes all the functionalities in its solutions through RESTful APIs which makes it an ideal cloud storage platform and aligns with Platform9’s commitment to Open APIs.
- SolidFire exposes not only basic Cinder functions, but advanced capabilities such as its volume-level QoS through the OpenStack APIs. This made it much easier for our engineering team to integrate the SolidFire platform with our solution and in our dashboard, providing ease of use for our joint customers.
- SolidFire’s scale-out architecture and QoS-per-volume capabilities make it an ideal storage platform for cloud workloads where high performance and guaranteed performance are critical.
- While focusing early on OpenStack with KVM, SolidFire is also a great storage solution for VMware vSphere. This clearly aligns with Platform9’s commitment to provide a cloud solution which supports multiple hypervisors. Users can deploy SolidFire with Platform9 and know that they have full support of and ability to run KVM and/or vSphere in their private clouds.
As you can tell, we are excited about the benefits we can jointly provide to customers as we help them to build out their private clouds and enable business success through technical innovation. Look for more to come as Platform9 and SolidFire continue to partner together.
Learn more
- Beyond Kubernetes Operations: Discover Platform9’s Always-On Assurance™ - November 29, 2023
- Platform9 Introduces Elastic Machine Pool (EMP) at KubeCon 2023 to Optimize Costs on AWS EKS - November 15, 2023
- KubeCon 2023 Through Platform9’s Lens: Key Takeaways and Innovative Demos - November 14, 2023