 Hello, welcome So my name is Alex Kirkop. I'm an architect at Akamai and co-chair of the storage tag for the CNCF And I'm here with my two co-chairs Xing and Rafaela. Do you want to quickly introduce yourself? Hello everyone, Xing Yang. I work at a BMRO in the Clown Edition 3 team was our co-chair of tech storage And my name is Rafaela Spassoli. I am an architect at Red Hat So we're here today to talk about the storage tag, but also a little bit about the storage landscape in the CNCF About 350 people signed up for this, but there's obviously not 350 people here So we're gonna tell you how exciting storage is and hopefully you can tell everybody else too So just a little bit about what we're covering today We're gonna talk a little bit about the tag, how you can help and join in the community What is cloud native storage and some of the documents? And point you to some links that provide additional information about the work that we've been doing So first off the CNCF has been expanding The roles effectively to allow it to scale to the large number of projects that have been Coming in and joining the CNCF and so the tags or the technical advisory groups Are here to help provide Subject matter expertise in this case for the storage space To the CNCF's talk. We have meetings every second and fourth Wednesday of the month all the meetings are open And on every slide where we have some links, please Take a quick pick up the QR code and that will take you to the repo that we're talking about So who are we? Well, you've met the co-chairs. We're up here on stage. We also have a number of Tech leads that help with that that that work with with us and with the rest of the community as well as Some talk liaisons who's for storage is Nikita and Matt Farina in our case So what do we do the the main idea for creating the tags was to be able to to scale what the CNCF is capable of as we increase the large number of projects within the environment so what we're what we're what we're here to do is effectively create content and White papers etc to help Provide guidance to the community as to the ecosystem and how to best use storage We also have a very important role where we review projects within the CNCF and guide them through the sandbox incubation and graduation stages you'll have seen some of the graduated projects in the keynote this morning And of course we we we work with the user community and provide that subject matter expertise so Wanted to quickly touch on some of the CNCF projects which we've been working with and which have been going through the process so starting with within Cubation we have Dragonfly which is which is a peer-to-peer registry cube of s a Large-scale shared file system and Longhorn that provides a distributed block and file system capability to running in Kubernetes and we also have a large number of graduated projects that that's fit under the storage umbrella of course you'll have heard of xcd Which is the strong consistency key value store which most which which all Kubernetes Clusters depend on but we also have really interesting scale out key value stores and databases like TIKV and test as well as Rook Which falls into the operator umbrella and and Jing is going to be talking a little bit more about operators in a minute And Rook acts as an operator for Ceph so providing file system block and object store And we also have Harbor which is which is a container registry project For for deploying your own private container registries So a little bit about the different categorizations of the projects and and how you need to think about these So there are a large number of projects that come in as sandbox Sandbox projects have a fairly low bar to entry and and the idea is for them to join the CNCF so that we can Help grow them help evaluate experiments help build a community and also, you know figure out their IP policies within within the community and As we progress as the project get gain traction they go to incubation stage So incubation is actually Despite the name. It's it's where a lot of the due diligence happens. So I think Cubation stage we Figure out real-life use cases the tag and the TOC interview Real-life end users that are using the project And we and we therefore get you know a healthy level of validation that the project is Doing what it's doing is actually being used in production and is and is a certain level of maturity and stability And then finally we have graduation and graduation is up is is like a final step where we have Additional governance controls in terms of the maintainers and the number of maintainers from different organizations, but we also but the CNCF also pays for independent security audits and and gets those and any security issues that are identified fixed Before before it gets a graduation stage. So graduation means it's being Verified and validated in use in production in a number of large organizations and has a nice Solid roadmap with with a with a healthy maintainer based in a healthy governance So we're here to talk about cloud native storage and why we should think about this so I'll go out there and maybe Step on the landmine and say there is no such thing as a status architecture, right? at the end of the day every application is going to store states somewhere and whether it's Services within Kubernetes where you're storing states or Services outside of Kubernetes those need to be managed and orchestrated in in our environment and and the and the reason that this is important is because all of the Benefits as as as enterprises and organizations go through their cloud native Roadmap in their cloud native journey where they adopt Containers and they adopt Orchestrators like Kubernetes the next step is obviously to take advantage of all of those benefits like the Automatic healing and automatic failover and and and the performance and scaling capabilities and apply that to stateful workloads, too And at this stage we have a very broad ecosystem that supports cloud native storage CSI support and cozy support in in in Kubernetes and We have a lot of operators for databases message queues and almost every other thing you can think of and it's important to Recognize that when we talk about cloud native storage We're not just talking about, you know volumes and file systems and block and and objects But we're also talking about key value stores and and databases and that sort of thing, too So in order to kind of demystify and detangle this this environment We put together the CNCF storage white paper again as a QR code there that will take you to the link and in the white paper we try to go about things by by by Explaining the the attributes of a storage system and the various layers that that form the topology of that system, but also Defining how the data access parts and the control plane work in the Kubernetes environment So some of the storage attributes that we focus on or the key ones that we focus on in the white paper are These five years of availability scalability performance consistency and durability almost every Storage system aspect can be linked into one of these attributes And it's important to understand these attributes in terms of how it relates to your application Because each of those attributes can be measured across a number of different criteria So for example when we talk about performance some applications need to do lots of operations per second some applications need to do Some applications are more throughput focused and other applications might be very latency focused for example And the same goes for things like availability where the ability to fail over and moving Data between nodes and the amount of redundancy and data protection is also critical to your application But of course each of these things are compromises against each other, right? So the higher Consistency commitments or higher consistency guarantees will affect performance and Scalability concerns may also affect aspects of availability or performance or consistency So these these things kind of all interrelate and they also interrelate with with all of the layers And I'm not going to sort of read through every single one of these layers mostly because I just want you to focus on the fact that Most storage systems today Are actually built using a number of different layers and that is also key to understanding the attributes of the storage So for example, you might have a file system that is built on top of an object store So for example, we now have a system that has the shared attributes and the scaling attributes of a shared file system But it also has the scaling and the latency and the other attributes of an object store that that underpin that system And why this matter is is kind of evident if you look at a couple of sort of use cases or examples Out of the many that that we see in in the storage world so just pick on a couple of these to give you those examples like in a case of hyper converged for example We look at the availability attributes and we see that we're merging the fault domains and change management domains between compute and storage so now compute failures can relate to storage failures and vice versa, but obviously we also see An impact on the performance attributes in terms of the shared network between the between the storage and the compute and When we look at block volumes, so you know think about things like EBS for example, which is an obvious use case Here that everybody will be familiar with The main idea here is to disaggregate the storage from the compute And therefore when we look at this we need to see how easy is it to connect those volumes to To the compute nodes and move them around when we look at availability concerns But also, you know, we look at this from a performance point of view So typically these sort of volumes might have the lowest latency, but they also need good connectivity between the storage nodes and the compute nodes similarly shared file systems can now be used by Multiple nodes at the same time but using a shared file system across multiple nodes at the same time leads to Challenges with consistency and how you deal with cash coherency and distributed locks for example And obviously we also talked about those layers and and and the fact that that's you know The underlying layers for these file systems can also depend can also affect the attributes and Finally something like object stores, which are very appealing from a scale point of view almost infinite for capacity and and throughput But typically, you know suffering from higher latency than than say a file system or a block store And and in this environment Request per second is often the the bottleneck that you kind of needs to to determine So I'll pause here and hand over to Jing who's going to talk a little bit about the data on Kubernetes my paper Thanks, Alex according to the 2022 survey by data on Kubernetes community more and more data workloads are moving to Kubernetes as Shown here. There are different types of workloads Database workloads have the highest of percentage Followed by analytics and machine learning. We also have streaming messaging and CSED and the underlying storage used by this data workloads could be blog file or object storage Stable workloads move to Kubernetes to take the advantage of Kubernetes self-healing ability agile deployment portability and scalability we are collaborating with a Data on Kubernetes community on a white paper to describe the patterns of running data on Kubernetes The paper is complete and it has been in review in the paper we are Describing the attributes of our storage system and how they affect running data on Kubernetes We compared running data inside versus outside of Kubernetes and We describe the common Kubernetes features and patterns being used when running data on Kubernetes and In the first version of the paper we are focusing on databases Although the things we talk about will apply to other type of workloads as well storage system has attributes as described in our landscape by paper and For a cloud native databases the type of a back in store used the number of replicas All will have an impact on the attributes such as availability and durability a Clown native database typically uses a sharding to facilitate horizontal scaling for example Vitas is a graduated CNCF project It has a built-in sharding feature to facilitate horizontal scaling of the mySQL databases and Here we also have observability and elasticity In a cloud native environment typically there are lots of microservices running in a distributed fashion So if something happened, it is hard to find out exactly which component is causing the problem so it is even more important to have a comprehensive observability system built in so that we can detect problem early and prevent failure from happening and Elasticity refers to the ability to scale up and down quickly This is the on-demand infrastructure Well, you can release resources when they are no longer needed This also refers to the tiering Story tiering where you can move your data across different tiers depending on how often they are accessed and For DR Rafael will talk about that in detail later There are options to run data inside versus outside of Kubernetes Managing databases without proper automation is not a pattern that is recommended So that means we have mainly two alternatives We can use managing database services provided by most cloud providers or we can run data inside Kubernetes and that is typically facilitated by an operator and operator uses the declarative API of Kubernetes and reconciles the desired state versus the actual state and Operator can automate the two operations such as a backup and restore upgrade migration an operator can also leverage third-party tools like Prometheus and Grafana for monitoring and so on so here we have a Kubernetes operator that deploys and manages a database cluster and the database cluster is typically Defined in a customer resource a CR that describes what type of a cluster user wants that's the desired state and Operator reconciles the desired state defined in the CR spec Against the actual state of the cluster So here the database cluster is running as a steeper set with three replicas Each replica has a pod that uses the persistent volume to store data The persistent volume is provisioned by using a CSI driver CSI container storage interface that defines common interfaces For a storage vendor to write a plugin so that the underlying storage can be consumed by containers running in Kubernetes and the right other container orchestration systems According to the do case survey And organization typically uses a more than one operator As showing in the operator hub. I have a screenshot here. There are more than 300 operators among them more than 40 are database operators and There are two CNCF graduated the project listed there the EDCD and Vitas There are nine postgres SQL operators including cloud native PG Clown native PG is an open source operator that manages a postgres SQL Database running a primary standby architecture in Kubernetes Although operators are widely used when running data on Kubernetes There are a lot of challenges including lack of standard That's why the do k community is working on a operator feature metrics trying to define standardized and vendor neutral feature metrics for the operators so that it will be easier for user to choose an operator When running data in Kubernetes, there are lots of common patterns and features used We already talked about the operator and CSI And topology while scheduling is also a common used feature You can define node labels where the key is the topology key and the Kubernetes scheduler can use that to spread the parts across different failure domains and Together with the topology where dynamic provisioning your persistent volumes can be provisioned to the failure domains Where your parts are scheduled to? So that's all I want to cover for the Okay, white paper. Let me hand it over to Alex It's not like we didn't rehearse this. Okay, so I'm just going to spend a couple of minutes to focus on One of the white papers that we've been working on which we're hoping to finalize. It's been It's had an extended review period one of the things we looked at when we were looking at the different attributes in our original storage white paper was lots of questions came up around performance performance seemed to be one of the one of those things that that people find difficult to understand and actually When we started putting this white paper together to to define some of the concepts for how you measure Performance and how you benchmark things like volumes and databases The common recurring team was actually it's it's so easy to you to get things wrong and so easy to To to to be challenged when you when you're doing these sort of benchmarking said that a large part of the document is is trying to determine is trying to define those best practices that that are used during performance and and what we look at is Trying to trying to match some of the some of the things that that actually matter when when we're looking at this so differentiating for example between the operations per second versus the throughput which which Different storage systems are often optimized differently for those for those two specific Criteria so for example if you want to do lots of transactions in your app, then you might want To have lots of operations per second But if you want to do say, you know analytics or machine learning for example, you probably need to focus on on throughput type options And of course as we talked about with the layers things like the topology in the way that Data protection like replicas or erasure coding is implemented the data reduction like like compression and encryption that matters But ultimately in most of the discussions People need to see the need to measure the latency more than almost anything else like that is often the biggest determinant between Between the the performance benchmarking and this kind of leads to how you build out and scale out the concurrency in these systems Both in terms of you know the queues to individual APIs or or volumes, etc. But also like how many clients and how many backends that the systems can scale to and of course One of the biggest gotchas is that in systems with lots of different layers caching happens everywhere all the way from, you know, the physical media to the the operating system to the file systems and and everything in between And and therefore always be very very critical when you're looking at the numbers and make sure you we understand What we're actually measuring because the number of times we've seen, you know benchmark results being Being published in blogs and things like that which which are obviously incorrect because they're they're talking about Crazy levels of performance that's the hardware that they're running the performance test on can't actually deliver So it's so they're obviously testing the cash or the speed of memory in those cases And this is really important to to understand but the biggest single most important takeaway is Almost all of the published results are very hard to make use of for your own levels of applications, especially with microservices where we have a Large number of dependencies within a system where everything needs to work together. So The the best way that the best single takeaway here is to run your own test in your own environments with your own Applications and if you're trying to do apples apples comparisons between different providers run those apples apples comparisons in those same environments because Network computes and everything else kind of factors in on those tests So I'll pause over there and hand over to Raphael who's going to dazzle you with cloud native disaster recovery Thank you, Alex Okay disaster recovery my favorite topic Before we delve into the white paper. I wanted to show you these slides which represents the four archetypes that you can organize your disaster recovery strategies around The reality is much more complex than these four diagrams Obviously because in your data centers you have multiple applications They can be using different disaster recovery strategies. They can be dependent on each other So the reality is much more complex. But if we want to reduce it to a tractable, you know Level of complexity. These are the four things These are the four patterns that you can use for disaster recovery and from left to right. They yields they yield better and better Performance in terms of the two key metrics for disaster recovery, which are recovery time objective and recovery point objective so we have The copper store we have volume replication that could be synchronous and the synchronous. We have transaction level replication where the software that the stateful software is organized with a master and Slave or primary and secondary and then finally we have Fully distributed workloads. And so if you look at the line at the top the first three Methodologies are active passive. The last one is active active. It's it's the only active active one and this is what we focus on in the white paper this this last one is what we call clown native disaster recovery approach and The other thing I try to represent in this slide is the capabilities that you need to Have available if you want to enable these Strategies so if you think about Yourself as a platform engineering that engineer that is trying to decide which capability to have in the platform In order to let the developers or wherever your customers Build their application and run their application depending which of these strategies you want to support I try to Show the main capabilities that you need It's interesting that the first two require storage They're very storage focus requires storage capabilities like volume replication and backup restore But then as we move to the right we need the more networking capabilities And we need some capabilities also in the software in this in the state for workload as opposed to just relying on this on the volumes And everywhere we need a global of bouncer So I try to Looking to find Software and open source project but also Project that you have to pay for commercial commercial Products that you could use in your platform to build those capabilities. So I'm not gonna go over all of them but I just wanted to point out here that there is this one called Yuga bite if you were yesterday at the distributed sequel So distributed sequel Meeting I think it was There at the Mario to just across the street They were there the one organizing it and they were Showing exactly this type of architecture and we're showing demos with this type of active active architecture Okay So what do we have in the white paper? Well, first we define this concept of a clownative disaster recovery Which is essentially this their active active diagram that we just saw So I'm not gonna go over the slide all of these light because we don't have a lot of time But let's focus on just the last two lines Who who is the the disaster recovery owner? Process owner in traditional DR In theory, it's the business Unit of the business application team But because they own the business continuity plan But normally they turn to the storage team and they ask what what level of this DR Can you give me and then they adopt whatever is available? But in this new clownative DR They pick the middleware software. So they are the owner of the disaster recovery Strategy and the last Line is is more about noticing that as we move toward active active We need to focus more on the networking capability to enable this east-west communication between between the instances of our state for workload and Then the global of Banser if and then the other thing that we do in these white paper is that we look at the Cap theorem this theorem, you know, there aren't many theorems in IT So it's important to know the few the few that exist and the this theorem is about Describing the how distributed workloads Can work it's about organizing Organizing how the possible behavior of distributed workload is and in particular It says that if if we want to have distributed workloads so workloads that is Tolerant to network partitioning you can only have it to be either consistent or available But it cannot be both. So you have to make a choice when you design your software and then if we look at These out this new generation of software that was built on top of the or that was built with the knowledge of the kept here They they look all similar. They are organized with replicas for a high availability and organizing partitions and and the partition data for this for having the ability of scaling almost indefinitely and so they need a coordination layer to organize to coordinate the replicas and the partitions and You can you can learn a lot about the behavior of this kind of software just by studying how the coordination layer works And what are the protocols that are used? Took to do this coordination and so we did some research We took a bunch of this new generation middleware that was that are built with the cap theory in mind and we looked at the Coordination protocol for replicas and for shards or for partitions. So you can you can take a look at this There are probably new ones here that now are not in the table and then we have some reference architecture for how to build this kind of This kind of disaster recovery strategies with strongly consistent workloads So these are the one that pick a consistency in the cap theorem and then also with eventually consistent workloads These are the one that pick availability. So here I have an I have a diagram of the Strongly consistent one. Okay, and in this when you do this deployment for which you need three failure domain Because of the quorum. So at least you must be up so and this is Anyway, when you do this kind of deployments if you lose one data center or one cloud region Everything will keep working. Okay You know, the global balancer need to redirect the connections, but beyond that Everything keeps keeps working. You have zero at the or very very close to zero at you and you have exactly zero RPO Yesterday by the way, they gave some examples some real use case with very large deployment Across in North America, you know different region in North America. It was it was very interesting So these are the things that we have in the white paper I'm gonna stop here to leave some time for questions So With that we finish our talk, I'm just gonna put out a final call out. We'd really love to Have you help us review the documents work with us help work with the tag it's also a great way to find out about projects and projects often present at our attack sessions, so it's a great way to Find out about some of the latest things which are happening not just in in this in you know The plain storage space, but also for things like databases operators key value stores, etc And we're also always on the lookout for people who want to actually contribute in a more formal manner and And either become a tech lead or work with the with the tag to help with The papers that we're working on or or reviewing projects, etc. Going forward. So please do reach out we're available on on the CNCF slack and with that I will pause for a couple of minutes where we have some time for questions Okay, then so thank you all for coming and I hope to see you soon