Getting going with OpenEBS installation-whatever flavor-via few clicks

Intro: OpenEBS Installation

OEP, the free-forever OpenEBS Platform (yes, a rename may be in the works…), simplifies the deployment of OpenEBS.

You may say - well, it’s just containers, and you can use Helm, right? And of course, you can, or you can grab the YAML as explained in the OpenEBS docs.

https://docs.openebs.io/v130/docs/next/installation.html

And as the docs explain, pretty quickly, you’ll be up and running with storage classes available to your users - including yourself - whether using dynamic LocalPV, or cStor or other data engines available within OpenEBS. As an aside, in a future post, we’ll talk about matching your workload needs to data engines. OpenEBS is fairly unique in this regard - it does not lock you into a particular engine and ships with a few different batteries included and more on the way.

The OpenEBS docs indirectly make a case for why you might want to use OEP.

OpenEBS configuration sequence

As you can see, the box “Install OpenEBS” is one step. You also will want to actually configure any underlying hardware or cloud volumes used by OpenEBS. And pretty quickly, you’ll want to see how users are consuming and these capabilities via Storage Classes. All of that functionality is easiest via OEP, as is adding back-ups. And checking on operational compliance. And visualizing it all. And logging… But I degrees. This blog is about Day 1 - initial deployment.

So let’s get started - OpenEBS Installation

First - do you want to do a simple OpenEBS installation with all the defaults pre-populated, including the creation and use of an OpenEBS namespace? If so - choose Basic. If you want to get under the hood a little more and choose a custom namespace and so forth, choose advanced. Let’s assume you are a relative newbie and just want the basics - so you click Basic.

Fig 1

Once you review the YAML - which again has standard content for Basic deployments - you click “Deploy OpenEBS.” That’s it.

You’ll see a Happy screen as it completes along these lines:

OpenEBS Installation Completed

You are then good to continue. Try out the other capabilities to your heart’s content. You’re on your way towards trusting Kubernetes as your data layer.

Sometimes, though, things happen. What happens when despite the best effort of you and your Kubernetes cluster, a non-Happy path is followed? Grrr - clean up, right?

Well, there is an easy button for that case as well. Take a look:

OpenEBS Installation failed


Click abort, and the deployment is cleaned up. You are then free to try again… Or get in touch with us, and we’ll see if we can help. As of Q2 2020, we see very few failures at this stage, but it does happen, and we do want to get your feedback.

That’s too easy!

What if the Basic deployment is too basic, and you want to use OEP to deploy AND configure OpenEBS, so it better takes advantage of whatever underlying systems and volumes you have available, then click Advanced.

Under Start Installation, specify the Namespace, Default Directory, and Docker registry for OpenEBS Installation.

Fig 2


Next, Specify your resource limit. You can choose one of these options available based on the size of the application, or you can provide some custom values.

AdvancedInstallation.png


Then, select the nodes where Control Plane components will get scheduled. To be clear, this is NOT the data; this is the intelligence of OpenEBS itself.

OpenEBSControlPlane.png


Keep going! Now you get to select the nodes where the Data Plane components should be scheduled. As the name suggests - these are the pieces of OpenEBS that are in the data path.

OpenEBSDataNodes.png


Lastly - you can segregate the Disk Filters under Include or Exclude. This interface leverages NDM, which is a MayaData originated sub-project that extends Kubernetes to track the inventory of places to store data. By the way, you’ll notice you can use different disks and volumes of various types - sure you can. It turns out that older storage systems and services often don’t allow “heterogeneous” disk, and cloud volume types, and this level of freedom provides you with a lot more flexibility as you and your data grow.

If you want to avoid lock-in, you’ve got to pay attention to the details.

Once everything is done, the customized YAML gets displayed. Click on Deploy OpenEBS for OpenEBS installation.

OpenEBSAdvancedFinalYAML.png


And that’s it. You’re back in the same flow as before. If the non-Happy Path takes you away, you can, again, Abort at failure.

Congratulations!

That’s it! You are done. Please take a look around on this blog and on OEP itself and try out other functions. Keep in mind that OEP is increasingly organized around the workload itself. As you deploy workloads invoking the storage classes you’ve created and are creating, you’ll see they appear in OEP and that from OEP you can do a lot to make them more resilient and efficient in their operations. Feedback welcome and needed.

Don Williams
Don is the CEO of MayaData and leading the company for last one year. He has an exceptional record of accomplishments leading technology teams for organizations ranging from private equity-backed start-ups to large, global corporations. He has deep experience in engineering, operations, and product development in highly technical and competitive marketplaces. His extensive professional network in several industries, large corporations and government agencies is a significant asset to early stage businesses, often essential to achieve product placement, growth and position for potential exit strategies.
Kiran Mova
Kiran evangelizes open culture and open-source execution models and is a lead maintainer and contributor to the OpenEBS project. Passionate about Kubernetes and Storage Orchestration. Contributor and Maintainer OpenEBS projects. Co-founder and Chief Architect at MayaData Inc.
Murat Karslioglu
VP @OpenEBS & @MayaData_Inc. Murat Karslioglu is a serial entrepreneur, technologist, and startup advisor with over 15 years of experience in storage, distributed systems, and enterprise hardware development. Prior to joining MayaData, Murat worked at Hewlett Packard Enterprise / 3PAR Storage in various advanced development projects including storage file stack performance optimization and the storage management stack for HPE’s Hyper-converged solution. Before joining HPE, Murat led virtualization and OpenStack integration projects within the Nexenta CTO Office. Murat holds a Bachelor’s Degree in Industrial Engineering from the Sakarya University, Turkey, as well as a number of IT certifications. When he is not in his lab, he loves to travel, advise startups, and spend time with his family. Lives to innovate! Opinions my own!