 Hello everyone, my name is Duncan Hardy, I'm a product manager in OpenShift and today I'm joined by Aran. Hello everybody, my name is Aran Tamir and I'm the OpenShift container storage product manager. Excellent, thanks Aran. So today we're going to talk to you about the state of OpenShift container storage but while that's going to be your main meal today and you're at the meat in our sandwich I thought I'd start with a nice little mousse bouche or maybe an aperitif and I'll just give you all an update on OpenShift storage itself. Just a quick view of what we're up to, the main things that have happened in the product recently and where we're going to go to. So I thought I'd start with just a quick refresher. I know Diane's really good at getting excellent varied audiences here and some of you are very familiar with OpenShift already and some maybe not so much. So let me start by giving you an idea of where we're going with OpenShift storage. There's four themes, these have been pretty standard. Through my time with OpenShift storage and we haven't moved from them I guess what's changed is where we maybe focus what areas we're playing with particularly. So let me go into each one as you read through the slide itself. The first area is feature expansion. So there's a little thing called the container storage interface that has come to Kubernetes. I'm going to talk a lot more about that in a moment. But that has been an area that we have looked at as far as our feature side. We want to make sure and work upstream with the community to make sure that we have a complete spec in CSI and enable all the required features that we need. It's pretty comprehensive already but certain things like resize or clone or still in beta. So we want to take forward and make sure that keeps moving on and meets the expectations of an enterprise product like OpenShift. Second, flexibility. So obviously we want you to be able to use your storage flexibly. Particularly in the switchover that's coming from what we'll learn about entry drivers to CSI drivers we want to make sure that we minimize any outages that you experience, any lengthy operations that is just a simple clean process. So that's another area that we're looking at. The third theme for today is about enable and choice. So OpenShift and its ecosystem is excellent and we want to continue to do that on the storage side. We've got partner certification programs going for CSI and we want to continue to grow these options that are available on OpenShift. And of course what we're here to learn about today we also want to make sure that you have the best experience possible and you go straight to using OCS as your storage of choice. And then the final thing on our themes is just around observability. So we've had some time now to kind of look at what storage matrix or what storage telemetry you want to pull out of your operators and that's an area that is a group that we're looking at. How are we aligning with this? If you talked to me three months ago we'd be very much in the first quadrant, the feature expansion area focusing on doing things there. But that's kind of studied down now. There are a few key things still to come but that's kind of in a good state. So we're now moving into the middle to looking at the flexibility looking at enabling our partners on the infrastructure. So I mentioned CSI, Container Storage Interface. There'll be some of you listening in today that will be able to teach me a lot more about it than I know and some of you may be a new thing for you. So a quick kind of lesson. What is CSI and why do we do it? If you go back to Kubernetes before CSI you had the idea of in-tree drivers for storage. So those were storage drivers that were part of the Kubernetes core code they were embedded into there. And while there was kind of some volume plug-in systems because these things were in-tree this meant that vendors wanting to add support for their storage systems or even just fix a bug. They were forced to align with the Kubernetes and hence the OpenShift release. In addition to that some of the third-party storage code that went into that core Kubernetes binaries could be problematic. There might be some security issues there or maybe reliability issues. And it was really hard for the maintainers not only just even to maintain but also test they might not have access to that storage that they need to. So the storage takes thought long and hard and the result was CSI. And that's essentially a standard for exposing arbitrary block and file storage systems into Kubernetes. Well it's a little bit more than just Kubernetes the CSI goal is to aim for any container orchestration system but we're here to talk about OpenShift so let's focus on Kubernetes today. With CSI you have a truly extensible volume layer now and the third-party storage providers can write their plugins, they can update them when they want they kind of get out of that being part of the Kubernetes release system and the plus side just for Kubernetes core is it takes some of that risk out and makes Kubernetes core much more secure and reliable. So what does that specifically mean for OpenShift? And we've been doing CSI since the 4.2 release so back in August last year it's been around for a while, the API's been in there and our focus up until now is it kind of said on the previous slide has been around enabling partners so we've been working closely with the OCS team who have their CSI driver already available and we've been working with our partners to educate them and make them available to do that. And we decided to do that rather than move our current entry drivers across to CSI because the mandatory switch over from CSI over to CSI from entry drivers is still a few releases out so we had some time to get the base level, the architecture light, right? And we also kind of wanted to make sure that we were able to do this smoothly so the migration piece before we kind of enforced that. So what does that mean? Let's have a look at some dynamic provisioning with the CSI driver itself. So this diagram's pretty cipher explanatory but let me go through it anyway it's just to give you an illustration. So what do you do? You've got your CSI driver written, you've installed it, everything's good to go, what actually happens behind the scenes. So your user will create a PVC or persistent volume plane on the API server. A thing called the external provisioner will get an event that this PVC had been created and then what that external provisioner will do is it initiates a create volume call into the CSI driver itself. Then the nice bit happens, the CSI driver talks to the storage back end and the volume's created. And then once that's happened, the CSI driver returns a volume to the external provisioner. He then passes the PV or the persistent volume back up to the API server that's bound and you're all done and that's how this new CSI API and through the Kubernetes now it allows you to do this plug-in and allows you to do dynamic provision and as it says there. So it's a really nice solution and we've seen some success with it already. So you're still done there. How do you get it from OpenShift or how do you work with a CSI driver in OpenShift? Well there's three options here. You can go straight upstream and you can have a look. There's quite a lot of CSI drivers up there. There's definitely 30 plus last time I looked for various different vendors. You can go and download those just like you would with any other upstream thing and then layer those on top of OpenShift. The only downside there is this is something you've taken from upstream so it's between you and the maintainer's upstream to look after and maintain and take responsibility for that piece. The nice thing about OpenShift now is that we've re-engineered it to be based on operators and a discussion on operators itself would take of all of Diane's session and layer at me and I'm very scared of Diane's glares. So safe to say that operators, this fantastic revolutionally move forward for us as far as OpenShift is concerned and we're leveraging them with CSI drivers. So any CSI driver that wants to install on OpenShift more officially then we're mandating that they go inside an operator. And there's a great operator hub community up there where you can go and do your GitHub request and commit your operator in there and it has great benefits. I always badly describe them as operators like groupings of containers with operational intelligence built in so you can do that with your CSI driver and it's a really nice way and as you can see on this diagram our customers can just search for the storage piece and you'll see the CSI drivers and it makes provisioning really easy. There is a third option here and this is to certify your CSI driver pilot program that we're coming out of currently. In fact we've just had HPE to be your first partner vendor to certify the CSI driver with us and essentially this just takes the operator certification that we have today which does some security checks and looks at the images and adds in a simple CSI test that's based on the upstream one that's already available and we just check that the API is working and what does it mean to get a certified operator? Well that means Red Hat will fully support it you know that we've tested it and also it will pay it on what we sometimes call our embedded operator hub that you get with OpenShift itself. So I'll stop going on about CSI now and move on. OpenShift 4.4 that depending on when you're listening to this is just around the corner or just come out and what have we done in storage. So you can see on the right hand side I think we've got excellent coverage now of all the main storage offerings that we need to have. This has been bolstered massively by OCS coming along with their storage offerings again you're going to hear a lot more about that in a moment. On our side it's just between the leap between 4.3 and 4.4 we've been looking at bringing snapshot restore and clone to tech preview so you can have a play with that. We also did a sidecar rebase for those of you not aware when you're developing a CSI driver there are a whole bunch of sidecars that make some of the more common tasks much easier to do that you can just reuse so we kind of just rebase the upstream what was there. The CSI test suite that I alluded to is now included in 4.4 so if you were developing a drive and you wanted to use it it's just there and easy to use and as always with Red Heart we've continued our focus on upstream work but the team's certainly done a lot more in this place and then finally from my side and we'll get on to the main course what about our roadmap well we've talked about 4.4 already but in the medium term CSI CSI CSI really to be honest there's a few things that 1.18 has moved into GA so we'll pick those up resize cloning and row block we start our own work now on the CSI drivers so the AWS EBS driver we'll have a tech preview of that and we're going to do ephemeral or inline volumes as a tech preview as well those of you not used to ephemeral volumes this is for volumes that don't persist after the pod ceases to exist so these are volumes that are useful for storing configuration information or a scratch space for location so there's a good community upstream about it go and have a look at it and then there's a couple of enhancements that we're going to do so local storage discovery was something that came from the OCS team actually so that's to look at a node and see what storage is available on there and then recursive permissions that's around making sure that with things for recursive permission changes for FS Group and SE Linux it has taken a long time in the past so we're looking at how we can speed that up longer term and the further out we go the more this can change so please take this with a grain of salt we're looking at migration so that's that clean switch over from Intree to CSI that I talked about snapshot restore everyone's looking for that we're working upstream with Kubernetes because both in the CSI API and Kubernetes API objects themselves both in beta so we're working to move them forward more cloud providers ephemeral storage ok working more with third party vendors and now the good thing is we've kind of had our heads down to try and get CSI going and working in a good state so that's giving us a chance now to look at more ROFEs and that's it from the OpenShift side and what I want to do now is hand you over to Aran who will take you through the OCS pieces over to you Aran so hi everybody as I said before my name is Aran Tamia I'm the product manager for OpenShift container storage and I'll try to give you an up-to-date state of OpenShift container storage so just to recap for those who don't know what is OpenShift container storage so the OpenShift container storage is another product that releases and what we are doing is providing a highly scalable and production grade persistent storage which means that we want to be the layer that supports your applications in OpenShift and provide them scalable solution and also deploy sorry and also provide you a very easy way to deploy it and maintain it so both onboarding and day-to-day maintenance were made very easy with OpenShift container storage we integrated the product into OpenShift dashboards and I will show you in a second all the benefits of having a well integrated product in terms of alignment with the releases and leveraging features like Duncan just mentioned features like snapshot scrolling and so on so what we are looking at what we were looking at when we designed and developed OpenShift container storage is that we want to provide the same agnostic level that OpenShift is trying to provide for the application and providing for the data so we want to make sure that customer can run in any infrastructure that is available for OpenShift to ensure that there is no vendor locking so you have the freedom to choose you can start on-prem you can have your dev and test running in various environments either in the cloud or on-prem and then decide where you are actually going to use the production and again OpenShift container storage provides the same API, the same behavior across these environments the second important part is the efficiency we want to make sure that you get the most efficient storage that you can give you the flexibility that you are looking for either with block storage, file storage or object storage so and again it will all work exactly in the same way regardless of where you are working the third part which is very important is the scalability whenever you have a new project you know where you start, you don't know if it will succeed or not so you always want to start small and then have the opportunity to scale and that's also linked to the idea of where do I run so maybe I will start on-prem I will start very small and then the project is successful I will scale I need more storage for that I need more instances of my application sorry, instances of my application running so we support all that we can let you start small we can let you scale in a very optimized way from terabytes to petabytes and I will talk about it when I talk about the future in a high level the way that we look at it whenever you have OpenShift and regardless of the environment we will provide the box storage, the file storage and object service across these environments so let's take for example regardless let's take for example the AWS so the OpenShift container storage will actually use the EBS for example or any other storage if it's local drives we can use that as well it's all about cost management and performance that you need so regardless of what you're using underneath from the application point of view it's transparent and you will always get the same experience so we actually provide the ability to divide between the concerns that OpenShift cluster manager has and the developer or the DevOps point of view, same goes for file and object regardless of what is your current data layer either AWS S3 or Azure from the development point of view the API is always AWS S3 compatible and it means that regardless of where you're running your application it will behave the same you don't need to change your code and you will get the same experience I talked about simplicity and ease of use as Duncan mentioned the idea of having the operators and the operators have really makes everything much easier you can install OpenShift container storage directly from the operators app simply click here and it will get installed once you install it and I'm linking it to the integrated behavior that I mentioned before you get all the information that you need from the storage layer directly to OpenShift dashboard so in this case you can see that the persistent storage dashboard everything is well integrated you can see the status you don't need to be a storage expert in order to understand what's going on here it's very easy to understand what application is consuming data how much data how frequently specific storage is been used in what namespace and so on and same goes for the objects service as well as for second day operation also very easy to scale simply decide how what is the increment that you want to scale with and it's that easy I want to elaborate a bit about the S3 service which introduce new capabilities of hybrid and data management in general and this service is provided by a component we call multi-cloud object gateway and the idea again is to startling it's a very lightweight pod that you have whenever you deploy OCS you don't need to change anything you don't need to configure anything you get this service out of the box and you can scale locally by using local storage that you have on-prem or in the cloud and later on you can start with mirroring data to enjoy better portability for the applications you can use it for backup and you can use it of course for high availability and in short that's the way that it looks like on the left side we have the applications S3 compatible API provided by OpenShift content storage on the right side as I mentioned before for the block and file we have also here the separation so admin can decide where is the actual data the data can be on-prem the data can be in cloud native storage wherever you are working in to save egress cost and once you have this configuration you can of course change it and add more layers for that add tiering, add mirroring between these locations and have hybrid buckets part of the data all the data is can be placed in both on-prem or the cloud or you can have even multi-cloud buckets that you have all the data across multiple cloud providers and again this decision can be made for every bucket that you have so you can have multiple policies within the same solution and it means that you have all the flexibility in short that's the way that the multi-cloud object gateway provides or digest the data and it's important to talk about it because it introduces also a security advantage whenever an application is writing data there is a fragmentation process in-application compression and encryption at the end we have multiple chunks, small chunks, encrypted chunks that are spread across the underlying storage whenever we are talking about cloud it's another advantage where we keep directly the keys and the data which is encrypted and that's important added value that we bring to such environments workload and technologies that's just to explain how do we look at this various services that OpenShift Container Storage provides so we have the block and in a high level everything which is transactional databases messaging and so on will go with a persistent volume which is based on the block offering here if we need more than one application consuming the same data set we'll use the shared file system again from the application point of view it's a simple PV claim from the OpenShift Container Storage but different type of that persistent volume claim the object service is mainly targeting media, large object in high level backup, archiving anything that you need when you start developing usually new application and you want to start with a cloud like approach or you will probably start using that object service and again one of the main advantages is that it's abstracting the underlying storage regardless of the actual environment the first two the services, the persistent volume services provided by Rooksef and I explain what is it in the second and the last one provided by the multi-cloud object gateway and that's the time where we want to expand a bit under the hood what do we have so the persistent volume storage provided by Rooksef storage and people usually ask okay so I heard about Rooksef storage I know that it's highly available there is a lot of features around resiliency and scalability and its petabyte scale storage how different it is in OpenShift storage and the short answer is that it's the same pet storage same capabilities but a very opinionated deployment meaning that we wanted to keep it very very simple for customers so we took a very opinionated approach and provided all the benefits in a very accessible and consumable way into the OpenShift product the way that we did it is by using Rook which is another open source project that helps us to do exactly that I'm taking the Duncan's world about what is operator and the fact that it's a bunch of intelligent containers that's exactly that that's what Rook brings to the game and it helps us to magically deploy itself monitor it correctly and make sure that we keep on track in terms of the self-healing and other features that we have intact the third component is Nuba part of Reddit acquisition happened at the end of 2018 and it's an open source as well and it provides a construction layer for all the data services I want to jump to this diagram not specifically to deep dive on what we have here in terms of the components but mainly look at the components that we have on the top so for those who already played with persist the volume and persistent storage in the open shift so there is something called volume claim and the volume claim as I mentioned before can be for block and file what we also added to this is something new called object bucket claim the idea is very similar to volume claim but for objects meaning that by adding several lines to the application YAML the developer can easily get endpoint access scan secretly to his application and read it dynamically and start using it dynamically meaning that we wrapped all the interaction between the application and the object service and we took the connectivity part and provided it in a dynamic way to the application and that's the way that it's working so the application has a bucket claim to the OCS operator it creates a new bucket it creates a new account which is important because you get an isolation in that way so every application can get its own account and the data is dedicated only for this application and we bring this information back to the application and from that point the application can start writing and reading from the bucket underneath the administrator can decide what type of bucket do we use do we use the default backing store which is the local storage or we use something more complex to ensure mirroring and so on data protection data protection is one of the most I think challenges that we currently see in the market like any relatively new platform we need to tackle all these challenges as well the way that we divide it is that we see that we look at the market and we look at the data protection segment and we want to deliver backup solution, want to deliver one DR solution and metro AJDR solution and let's talk about it for two minutes when we're talking about backup solution we're talking about I would say the most easy way to protect ourselves against logical failures users things that happen due to application bugs malicious software and so on so we want to backup our storage and we want in case of a failure we want to move back in time lose part of the data maybe but move back in time to a normal situation and we want to base that solution on snapshots we look at two options one is local snapshot to our current store another one is snapshot to a remote location we are talking about one DR solution we're talking about multi-cluster at the end of the day we want to make sure that we can have a solution for disaster recovery across clusters which means that usually we'll put it in separate locations in order to protect ourselves from geographical concerns flooding, earthquakes or just power supply failure that takes too long and of course have an automatic failover to a remote site by a hot site that we keep replicating the data all the time to this location so that's another solution that we are working on and the last one is the metro HA disaster recovery solution which is mainly targeting or leveraging I would say availability zones that's something that we already have as part of our support in availability zones today here we actually want to also support smaller capacity smaller data centers and we want to also improve the cost model so we have new features around that just a quick recap on what do we need in order to have this when we are looking at this challenge so we have data mirroring and that's what we need to support from the storage point of view we want to be able to synchronously mirror data across locations between locations we need the snapshot which is upcoming soon from OpenShift and Kubernetes of course we have the backup that is a component that take advantage of the snapshots and we have the data replication that is using asynchronous replication to make sure that we have all the information but in asynchronous way as opposed to the synchronous data mirroring that I mentioned before so what do we have next next we have multiple areas of I would say interest that we want to tackle first one is platforms it's a long side effort we want to make sure that in addition to our bare metal support AWS and VMware support we can also support OpenStack, Azure, Google, IBM Cloud, Alibaba, Rev and so on we have a dedicated team in order to make it this delivery faster we want to improve our security solution for customers so currently we have encryption at rest for AWS customers and cloud customers in general but we want to make sure that we can provide it on bare metal and VMware so we want to add encryption and trust in transit which is unrelated to the underlying infrastructure once OpenShift provides a KMS integration we will also integrate it into the storage to leverage centralized key management systems on the multi-cloud object gateway aspect we want to move to the next phase which is multi-cluster as you can see multi-cluster is repeating them for the next versions that we have both in data protection and in the multi-cloud object gateway so we want to have a good solution for that as well for the multi-cloud object gateway so we are going to introduce the caching mode mainly for AIML with a huge data set in centralized location an ability to bring closely to the digested area to the computer area and the relevant data another step is integration with multi-cluster dashboards that we have and also improve something that we call namespaces which is a proxy for multiple cloud providers and again we will elaborate that in the next session scalability is another step that we have we want to introduce independent mode soon means that we have a huge centralized storage which is scalable and serves multiple open-shift clusters it's managed a bit differently it is very powerful in terms of all the knobs that you can have but it allows open-shift administrator to ignore the challenge of storage management and provide the data in a simple way as I mentioned before for every cluster so we kind of separating the scale concerns from the open-shift administration we also want to improve our efficiency and improve the ratio of amount of PVs per node and the last one is the data protection that I mentioned before all these features that I mentioned we have it in various I would say progress in our engineering NQA and we hope to start delivering it in the next versions sooner better with that I finished