 Hi everyone. I hope this is getting recorded right now. Thank you for taking the time to learn about OpenEBS and what's coming, what's come in the 3.0 release. I'm Kiran Mova. I'm one of the maintainers of the OpenEBS project and I'm currently working at Maya Data. Before we get into the details about OpenEBS, just a few coordinates on how to reach us and what's been the journey for OpenEBS like. OpenEBS was created by Maya Data and donated to CNCF in May 2019. It's a sandbox project at the moment and we are on Kubernetes Slack where you can reach out to us on either OpenEBS channel or OpenEBS dev channel. Since donating to this CNCF, we have had a take in the number of community members using the product of contributing to the project. We also have public references of how customers use this project. You can check that out in the links provided in this slide. This one shows the analytics that we have on how many clusters get deployed that run OpenEBS on them and we have seen a tremendous growth. It's a steady growth in terms of the number of clusters having OpenEBS. To quickly recap on what OpenEBS is and what's the problem it really solves for the users, this is a reference architecture for the storage stack for the cloud native workloads that was presented by CNCF tag for storage. OpenEBS sits into the, just above the storage systems, which is basically like hardware devices and it has basically two components called as control plane and data engines, which are responsible for providing volume services. So it could be like anything from aggregating the storage from the devices and presenting it as volumes or like performing like snapshot or like clone kind of capabilities. OpenEBS supports like local and distributed block storage and OpenEBS is tightly integrated into Kubernetes. It is in fact like an Kubernetes add-on. And the control plane of OpenEBS helps you integrate like the operational aspects into the framework or tools that the enterprises already have. If you look at like the technology radar like you know storage typically means like the data platforms are like the products that are used in the data platforms and they those actually need some kind of like an underlying block volumes or like persistent volume claims or persistent volumes if you are like in the Kubernetes world that have certain characteristics that are like around availability, consistency, durability and how easy it is to use them. So I did mention like you know we are like OpenEBS is tightly integrated into Kubernetes and it really works for stateful workloads that are moving towards Kubernetes. And it's a fair question to ask like you know is our stateful workloads really moving into Kubernetes or why they are moving into Kubernetes. This is like a talk that was presented at the last KubeCon and there's actually a follow up talk again that's coming up in the North America KubeCon. The Flipkart here is one of the largest customer or like the user of OpenEBS and the reasons for them to shift stateful workloads to Kubernetes is the same reasons why stateless workloads move as well. It's about like you know trying to have a common abstractions that can enable you to move the workloads across different clouds, even from on-prem to cloud etc. And then also ability to easily automate the process of deploying and maintaining them which comes inherently by using the declarative way of like doing things with Kubernetes. They claim to have an increased developer productivity where you don't have to like wait for like infrastructure to provide the storage rather like you know it's a kind of automated. And there are like enhancements that are planned as we like get into like the OpenEBS 3.1 and ahead you'll notice that we are enhancing the data engines that we have for improved availability and resilience. So the just to recap I think like there has been a shift in terms of like how customers are looking or like users are looking at deploying their stack and in part it's due to the nature of like new processes, new technologies, new hardware tools that are available. And also like the new policies like you know it could be like government policies around data that have come in which require you to redesign the systems as well. Right. So in fact like as part of this redesign like there are like very types of stateful workloads that are emerging, some that could be called a standalone which need a lot of like traditional storage services but also like a cloud native kind of workloads that have a lot of capabilities that typically are done by the underlying storage built into them. So what this means is like you know they really need like fast and local storage and resiliency replication high availability are taken care by those workloads itself. Right. And when we want to design storages for the new kind of applications that have come up, it's inevitable to kind of redesign the data engines but along with the data engines comes the control plane. The control plane has a lot of similarities with the aspects that Kubernetes already provides and Kubernetes has evolved into this universal control plane that doesn't just orchestrate containers anymore. It goes on to like orchestrate virtual machines or anything and in our case we have made Kubernetes orchestrate the volumes. So this is like a typical storage stack with open EBS, which some things which is kind of like analogous to what you have seen with reference architecture that like a control plane and a data engine components and the control plan and the data engine components are all like deployed as containers, there is no dependency on like the platform so you can kind of like declare it really make them run on any kind of platform. So the data engines itself like again like can be divided into two, like I said before around like local and replicated. So the local volumes are for those workloads that just need fast storage and there is no component of open EBS that comes in the data part it just uses like the standard libraries available in the line exit could be like creating a sub directory and using it or it could be like using that odd device to creating volumes on LVM or ZFS and then using them as local volumes. So there is no resiliency that can be put in place by using LVM and ZFS, but the workloads are like directly getting the storage from the local storage. In case of like workloads that need some durable volumes where like you know you need to sustain the failure of a node and like be highly available. So open EBS supports this concept called as replicated volumes, actually, you know, if you kind of the really kind of CMS distributed volumes but I'll get into in a bit on why we call them as replicated. So these distributed block volumes, the applications right to something we call as target or like you know in a master speak it's called as an access that in turn writes the data to the local replica or local storage as well as synchronously replicates to other nodes. So the way this replication is done is different than a typical like distributed system where like you know blocks are typically sharded across multiple nodes in a distributed system but in case of open EBS, the entire volume data is available on a single node and it also gets replicated to the other nodes. So that's why we call them as replicated volumes and there are advantages to doing this which, you know, this like lower metadata overhead that is involved in writing to a particular volume. It's just about like maintaining the replicas and where the replicas are located. It also helps in recovery of like the replicas when a node goes out of the cluster and comes back in. So the rebuilding will only be from the nodes where the complete data is there. So it doesn't really impact all the nodes in the cluster to rebuild the water. Right. So, just in terms of like, you know, to try home that concept local volumes are for pods with the data written to only one node and if that node goes out of the cluster then that part cannot be rescheduled to another nodes. And you basically are stuck with it. So typically like stateful sets that can handle resiliency or like a good case sometimes machine learning jobs are also like a good use cases for using the local volumes especially like you know there is like enough data that's been written into the local volume and you it's better to wait for the node to get restarted and start the job there rather than like kickstarting the job on some of the nodes. Right. So the option is for running a pod with a volume that's local to the storage in case of like distributed the PV in sense the data to a container, which we call as a container that has storage volume or like a target for that's an open EBS container that in turn replicates the data to multiple nodes. So if one of the node fails that can be that pod can run on some of the other nodes here. So this just shows that. So these are like, you know, just getting into like a differences between like these were local volumes and recorded volumes that have just covered. So one thing to call out apart from the benefits that we talked about a limitation is because of the replicated nature of the volumes is volumes can support a capacity that can all be accommodated into a single node. As we don't shut it. Right. And we have so far seen very less use cases in the cloud native space that really need volumes that go beyond like what can be afforded afforded by beyond what's available on a local note. And of course like reiterate the many is supported by NFS natively by open EBS and we think like you know the trend is actually moving towards object storage for any kind of like redirect many use cases going forward. This one actually just tries to capture like you know what's the typical user journey or like you know what are the personas of open EBS the open EBS is targeted like a different types of people like you know it's for the developers who just want to quickly start with running their stateful workloads in a mini cube or like you know in a single cluster that they have with like local storage or like even a three node cluster and it's pretty easy to get started and the, you know, one of the things that we focused on really providing is just 15 minutes experience where you can just install open EBS like any other community application and get started. So we notice that a lot of people come in at this stage and they become like an advocates or contributors to the open EBS project, helping to improve. And then once those users get really comfortable with running then that's when like you know they kind of pull in their sres or database administrators to see if open EBS can be integrated into their internal platforms and this is when like we see a phased approach of deployment for open EBS where it starts with running some kind of a non critical workloads by the database administrators of the sres could be like a CI CD or like a highly resilient workloads. And then once they're comfortable with that they get into a phase two where they provide like databases on top of like open storage, right. We also notice like another category of users that have come in, which are like actually other cloud service providers that tend to provide block services using open EBS technology for their cloud customers. So this is a typical workflow that you know when a fully functional open EBS the platform sres bring up a Kubernetes cluster and they can install open EBS just like any other application not like then cluster component. And then using the standard Kubernetes API, they can configure like you know which of the storage on the nodes of the types of the stories on the nodes should be used for provisioning the pools of the volumes and create the corresponding storage classes from that storage classes like the application systems to create PVCs and then those PVCs interact with the control plane components of the open EBS which are like CSI operators or like data engine operators to provision the volume and make it available for the application. And all of these open EBS components both the volumes and the control plane components expose metrics in an alternative way and that can be integrated into the overall manageability or the observability stack that customers have, right. So one thing that we did touch upon is the difference between the local volumes and the replicated volumes and this is where we are now getting into what's changed. So in fact like with the last two releases like the major releases what we have supported in terms of local volumes is a host path. So in the case of the device and the ZFS local PVS and in case of replicated volumes, it was primarily Giva, CSTOR and Giva is actually like a fork of long horn so it's a stable engine and CSTOR is based out of CFS which is also a stable engine and then we started working on something called as My Store which is which was targeted like providing a high performance distributed volumes for which makes use of SBDK and totally geared towards NVMe devices. So one other aspect in which like replicated volumes get used is like you know maybe using them in a desegregated way where like you know some nodes in the cluster could be treated as a storage nodes or like you know could be designated to run straight full workloads and because you can connect via either NVMe or like I see the application parts could be running anywhere on a fleet of like application nodes and then they can write to the volumes that are on the storage node. With 3.0 there are several engines that we have introduced. I'll get into like some of these things in the slides that are further down. So the OpenEBS has evolved into this collection of like storage engines that are suited for different types of applications. So it's there are like two aspects that determines like what storage engine to use. One is like the needs of the application from the underlying storage and the second one is about like the type of storage that's available to the Kubernetes cluster. So for example if you don't have any disks then it makes sense to use localpv hostpata which run on top of like hostpats as well. If you have like HDDs then cstore could be like a good one or like ZFS volumes could be like a really good option. And if it is NVMe devices that's where like we are talking about using master. In addition to like these data engines we also have made some enhancements to the control plane out like the operational or operators that can make it easy to install and use OpenEBS. Some examples will follow. One thing to call out though here is so we started supporting G1 and cstore you know when CSI wasn't even there using the Kubernetes external storage and Kubernetes external storage is getting slowly phased out. And in line with that like even the external storage provision is for G1 CSI are getting deprecated in OpenEBS. There are an corresponding CSI and G1 CSI and cstore CSI drivers that are available and there are like upgrade operations or like the operators that are available for you to help migrate towards them. So this one lays out the comparison of like you know the different capabilities that each of the data engines have. Again like I think at a high level you need to decide whether it's local or replicated that you need. And then within the local depending on the type of the storage you can pick up like the different flavors that are available. Similar with respect to like the replicated G1 cstore or my store. So while there are differences in how we support all of them support like of course like dynamic provisioning and some of them are really good for performance. And some shine in terms of like the capabilities like CFS based ones are like really rich in the capabilities that they provide and we are trying to like build all those kind of functionality into my store as well. So in terms of like the operations or ease of use almost all the engines support them or like are in the process of supporting them the star here indicates like you know those are the plant additions that are going to come up in the future releases. So we already spoke a little bit about this I'm going to skip this one. This gives you a overview of like how open this local previous are like typically used. So what we do is on the Kubernetes nodes, we install open US along with open US components. There's a component called notice manager that gets installed that has the capability to discover what stories are available. Now, depending on the type of the local PV either we can like mount that particular storage into a path and use this as a host path or like you know we can tag some of the devices and say that these should be given as ease either as like Roblox devices or like a partition on that device to the workloads. And a popular option is also like creating a pool and in this case pool is like I did the episode and VM and creating a storage class that specifies which of these types of storage should be used. And depending on the type of the storage class selected the volumes are provisioned accordingly. So a few things have we have enhanced almost like all of these engines in 3.0 and key things that need to highlight with respect to the host path local PV, especially if the host path is coming from an XFS based mount, there is an option now to enforce the quota. So prior to this, there would be a sub directory or a volume created and the users can write up to the capacity of the mount point that's available. But now the capacity will be limited by the PVC request size that's available. With respect to ZFS as it's rich in its storage capabilities we also supported like a well or plugin that can actually help with providing incremental backups and restores. We also enhanced as these ZFS local PV and LVM local PV or CSI we have the capacity based scheduling feature that's available in the CSI integrated as well. With respect to LVM like you know we are also experimenting with a way of how to set the QoS on the containers that uses LVM volumes and this is done in a generic way that can be extended to the other volumes as well. So this one just shows a quick example on how to use the new XFS quota feature that we have. So typically we create a storage class for the host path and if the mount point is one of the prerequisites for using this feature is that the XFS project quota should be set on the mount point. And then like in the storage class, we have to set the XFS quota flag as true and that will automatically the provisioners will make sure like the quota is set on the PV volumes. So in terms of replicated PV I think like the key difference compared to like the other cases when the PV writes into something called as a target. In case of C store the target is like another pod that you can actually like use QCTL to check it out. And then the data that's coming to the target is like synchronously replicated to the C store pools that are running on the storage nodes. So the major changes have been in terms of like supporting the CSI driver for both Jiva and C store. And as we did that we also enhanced a lot of capabilities in terms of like data operations. You know, for example, like one of the things like you know whenever there are network failures are not shut downs there are possibilities that the volumes will be mounted as read only especially if you're using a quick stick profile system. So there is a feature that we have enabled which can auto remount and there are also cases where like if you're running on Prem, the applications that are running on the node that went down get stuck and start throwing multi attach error. Those things have been handled with the CSI driver with the C store, which is basically like you know, which has like a little bit more of higher functionality. So you have to create something called as a pools and these pools are now capable of like declaratively kind of replacing a disk or like you know, moving the pool to a new node if the node moves at the node course and the disks are attached to the new node. All these things were supported manually but right now we are changing the YAML for the sister pool, those are automated by the C store operators. With respect to Jiva also I think like one of the change is that it uses the instead of using the host path volumes entry it uses actually the local volumes, which helps to avoid cases where like nodes get rebooted and the storage is not it mounted which causes like the additional new host path to be created and then the data starts getting written to that one that can be avoided by using like the host path volumes like the local volumes which will make sure like the replica starts only after the storage is mounted. It's again like important to call out that the older external provision as are getting deprecated and we want like users to move as soon as possible. As we get to Kubernetes 1.25 some of the objects used by the older provision as will not be supported anymore. So it's important to kind of move to the CSI drivers. So I think like a test upon C store, I mean, C store and Jiva and with respect to my store, we are still in beta and we are still actively developing and working through the feedback that we are getting from the community on how to make my store better. So the key difference between like C store and my store. In terms of like the way the volumes are structured is that there's no target pod. In fact, like the target is embedded into the core my store engine itself, and that will help in like replicating to the other nodes, or like other things that the master pool is running. So these are like some things that we are like currently working on and hoping to complete the beta very soon for this project. So there are like a whole bunch of other things that we've worked on other than like you know enhancing like the engines, a few things to call out or the NFS provisioner. So we have like a couple of NFS provisioners in the Kubernetes that we actually closely work with. But there's a new NFS provision that we support in open EBS, which is slightly different from the ones that are available. I'll just speak to that in a minute and we also have a QCPL plugin now for open EBS, and, and Prometheus stack that can be set up out of the box and that allows you like the default dashboards that you can probably take and like you know customize for your environment. So this is about the NFS provisioner. So what we have here is like you know we have made it easy to launch an NFS server or any block volume. Especially you know if you are, if you need to create like an NFS server that's per volume. This is like a really good option. So the configuration can be controlled to through a storage class where you specify actually we support only kernel as part of this beta release that we have released for this provisioner. And you can specify what's the storage class to use for saving the data and that data could be like you know any kind of a PVC. So the NFS provisioner when the request for RWX volume in this case comes in will launch a new NFS server and that NFS server will include a packet PVC PV. That's created and you can, and it also creates a PV object that is pointing to this NFS server that can be mounted from multiple parts running on multiple nodes. All right. So these are like some examples. I mean, some some really cool things that are there in the CLI example like there are multiple engines. So the OpenEBS command has been enhanced to show what engines are really installed in the cluster and we are kind of increasing them to include other engine support as well. So if you have used CSTOR, I think like one of the painful processes is to create the CSTOR pool config. We are hoping that that we get improved with this CLI as a first stage like you know, for example, like the we need to identify the nodes and the devices which needs to be used and this is the first command that we have which is we use block devices or a BD that shows what are all the devices that are available and in the cluster, you know, it's a tree of like node to the devices that are there. And it shows like, you know, whether it's already mounted or not mounted. And for CSTOR, we need to take those devices that are like mounted or like, you know, without any file system. So this helps in getting that very easily instead of like using a CSTOR command with a lot of creps and all that. So there are like multiple commands that this CLI provides. I highly recommend to check it out. Like, you know, this is an example of how we displace the status of the health of CSTOR volumes. It's pretty cool to kind of get the consolidated output of the various objects that are involved in the CSTOR really helps in troubleshooting and like knowing the status. Talking about status like, you know, this is another way. So we can set up like a monitoring dashboard is delivered as a health chart and it's also available as a permittance mix in. And it has like some set of default charts that have been loaded as well. This one shows like an example. This one shows more overview chart that shows like you know what the consumptions of the various pools, the status of them and the volumes that are provisioned on top of that. All right. So, that's what we have in 3.0. And these are some of the things that we are working as I said earlier like master beta is something that we are actually working towards in the 3.0 timeline. There are a few features that have come in from the community, you know, we are engaging like the CNC of mentees as well to work on some of these features. And yes, so the XFS quota and like the part that we have about the transports, even the CLI, and there is also a feature on the governor policies, all of these have been made possible, working with like the mentees that students from the CNC of mentee mentorship program. It's a huge call out and thanks to the people that participated part, Rahul, and Almas and really great to work with like the new set of mentees right now on some of the projects that I'm listing here. So just to pick on like one of the features that we are adding, and we really look forward to contributions and feedback on these features. So what we have learned from the community is that the storage can be connected to the nodes via some kind of SAS interconnects, which makes it possible for the devices to be visible on multiple nodes. So in this case, even though it's a local storage that storage is visible on like all the nodes that are in that cohort if you will not like a storage pack or a set or a domain. So now when we use like a shared device we can create a volume on one of those devices, specifically in this case we are looking at like shared volume groups that have that capability. And if that node feels so the application part can move to any one of the nodes that's there in the storage pack or the storage cohort if you will, and that can connect to the same block device that sees for that's connected to the other nodes, just extending that, and also like you know trying to come to a solution between like my store and the local volumes is this solution where we want to put an target, which is what we already have in the my store on top of these local devices, we could actually run those targets on multiple nodes so makes it possible to create a volume that could be running on a remote node, which is not connected to the storage pack. And then when the node goes down the client side initiators can make sure like you know they connect to the active part. And when it comes back up, there is no need for rebuilding kind of technology because it's all on the same device. And the path becomes available. So these are just like you know few of the different volume types that we are trying to support, we started with local PV and we had like replicated volumes at the extreme and snow we are like trying to create like two more types of volumes, depending on the new topology that we have discovered which is about like the shared devices that can work. So this is, I hope you learned something and we are really look forward to you trying it out and shouting at us with your feedback. We are available on the open EBS Slack and there are like Contributor meetings that you can join, you can also participate in the mentorship programs that we conduct and we really look forward to talking to you. Thank you everyone for taking time today and learning about open EBS.