 Good morning. Good afternoon or good evening. Welcome to this session where we're going to talk about some of the work that we're doing in the CNCF storage SIG, covering a view of the landscape, the projects of technology that we're working on and some of the interesting things that are happening in the CNCF relating to storage. My name is Alex Kirkup, CEO of StorageOS and one of the co-chairs of the storage SIG and I'm here with Xin Yang and I'll let Xin make a quick intro. Thanks, Alex. Hello everyone. My name is Xin Yang. I work at VMware in the cloud native storage team. I'm a co-chair of Kubernetes SIG storage and also working with Alex in the CNCF storage SIG. Brilliant. Thanks, Xin. So today we're going to cover a little bit about how the SIG works, how you can join in and help. We're going to cover off some of the projects that are part of the storage landscape in the CNCF and some of the projects that are going through review. And we'll also talk about some of the documents and other contents that we're working on, like the storage landscape documents and the performance and disaster recovery documents, which hopefully will spark some involvement and questions. I would love to hear back from you. So the storage SIG works with the CNCF TOC. We hold meetings every second and fourth Wednesday of the month. All of our calls and membership are open. We share our agenda, our recordings for all the sessions. And we have an open mailing list and we'd really like you to join and share some information on how to do that in a second. So who are we? There's a diverse group of people who form the SIG. Some are independent contributors, some are working for different vendors or organizations. But in general, we're all leaders and early adopters in the storage space. At the moment, our co-chairs are myself, Princeton and Shing. We have Raphael Eloise and Shing as tech leads and Saad and they're in work as talk liaisons. And together, we cover a range of important functions for the storage space and the TOC. The important thing here is we provide that storage experience and advisory services to the TOC, as well as providing a number of documents and other educational materials to the end user community. At the end of the day, we want our mission is to be able to improve the number of projects in the storage space and improve the adoption of cloud native storage in environments for the CNCF. So a large part of the work we do is to provide easy to read documentation and materials that help end users understand all the different technologies. The landscape is a vast varied projects and technologies. And so it's really important to try and document that and cover all of the different products and practices and trends and technologies, etc. That we have in the environment. Two of the important documents that we have provided are the CNCF storage white paper and Shing will go through that in a shortly. As well as some new documents like the performance and benchmarking white paper, which are developments and following feedback from our original storage white paper. As much as possible the information that we're providing is based on research and the collective experience of the tech leads and the community within the SIG. Another important role that the SIG is responsible for is the helping the TOC evaluate projects in the CNCF. We have three classes of projects. There are sandbox projects there are incubation projects and graduation projects. Sandbox projects are there to provide an experimental zone within the CNCF to allow collaboration and allow projects to build their community. The idea is that Sandbox projects have a low barrier to entry and they help and they help the projects build and perhaps ratify things like their licensing and IP policies to be compatible with the CNCF. Incubation projects are where we do a lot of due diligence incubation projects are projects that need to be successfully used in production by a number of organizations. And we also evaluate the technology and some of the the project metrics in terms of you know things like the committers and the health of the project in terms of having regular regular updates. Once a project has been in incubation for a while it can graduate. Graduation means a graduated project means that the project is in mainstream production use and it's recommended for production use. Graduated projects for example include Kubernetes and graduation also means that the CNCF is is confident about the security where they provide security orders for the project and also with the governance of the project to ensure that there are multiple committers. So as a SIG we help the TOC review and document the different projects as they go through this life cycle within the environment. When a project goes through incubation for example we usually have the project present to the SIG and following that presentation and a review with the SIG will provide a recommendation to the TOC to move forward with due diligence. The due diligence involves both technology and governance reviews as well as interviews with production users and then ultimately the TOC will vote to enable projects to go into incubation. One important point to note here is that the SIG is also very keen to learn about new projects and new open source projects in the storage space. So we often have presentations from projects who are interested in joining the CNCF either at incubation or at sandbox. And those presentations provide valuable material and valuable input to the TOC in their decision making process. Another thing that we do is we run surveys and we work with the end user community in the CNCF to understand what's important to them, where we can help and that can be in terms of creating white papers or other documentation it could also be in terms of seeking out projects to present to the CNCF. And we do all of this in a very open way where all of our meetings, our agendas, mailing lists etc are all done in the open and we publish all of those links in the CNCF storage SIG repo on GitHub. One thing to bear in mind is that whilst we're considered advisors to the TOC and we help with the technical due diligence as well as in project reviews during their life cycle within the CNCF. We are advisors and that is the key point here so ultimately in all cases the TOC are responsible for making the final decisions in any project adoption or project review process. So how can you get involved? Well, we have a fantastic community. We cover a huge range of different topics, everything from management frameworks and tooling, block stores, file systems, subject stores, key value stores, databases, storage and cloud native storage covers a wide variety of topics and would be very interested to hear from you. Please do consider joining our meeting and signing up to our mailing list. If for nothing else you'll probably find it extremely valuable to see some of the project presentations that have presented to the SIG in the past which have covered a lot of these different technology areas. With this I'll hand over to Shane who's going to cover off some of the CNCF storage projects that we've been talking about. Thanks, Alex. I'm going to talk about graduated and incubating storage projects. RUG is a graduated project. It provides storage operators for Kubernetes. RUG turns distributed storage systems into self-managing, self-scaling and self-healing storage services. RUG orchestrates multiple storage solutions each with a specialized Kubernetes operator to automate management. It currently supports CIF, Cassandra and FS. Vitas is a graduated project. It is a cloud native database system for deploying, scaling and manage large clusters of database instances. It supports MySQL and MariaDB. It combines and extends many important SQL features with the scalability of a no SQL database. EDCD is a graduated project. It is a distributed key that you store that provides a reliable way to store data across a cluster of machines. All Kubernetes clusters use EDCD as their primary data store. It handles storing and replicating data for Kubernetes cluster state and uses the raft consensus algorithm to recover from hardware failure and network petitions. TechKV is a graduated project. TechKV is an open source distributed transactional key value database built in Rust. It provides transactional key value APIs with asset guarantees. The project provides a unified distributed storage layer for cloud native applications. It can also be deployed on top of Kubernetes with an upward operator. Dragonfly is an incubating project. It is also a project under SIG runtime. Dragonfly is an open source cloud native image and file distribution system. It was originally created to improve the user experience of image and file distribution in Kubernetes. We also have a few sandbox storage projects. TroubleFS is a cloud native storage platform that provides both POSIX compliant and S3 compatible interfaces. Project Langhorn implements distributed block storage using containers and microservices. Langhorn creates a dedicated storage controller for each block device volume and synchronously replicated the volume across multiple replicas stored on multiple nodes. Project OpenEPS builds on Kubernetes to enable safer applications to easily access dynamic local PVs or replicated PVs using the container attached storage pattern. Project Prius is the cloud native storage system that enables Kubernetes local persistent volumes with dynamic provisioning resource management and high availability. And Project Pravega is an open source distributed storage service implementing streams. It offers stream as the main primitive for the foundation of storage systems. Next, please. We have several sandbox projects that are applying for incubation status. They are currently being reviewed. Next, please. Now I'm going to talk about the CNCF storage white paper. In this white paper, we described storage system attributes, different layers in the storage solution and how they affect the storage attributes. We talked about the definition of data access interfaces and management interfaces. Next, please. Storage systems have several storage attributes, availability, scalability, performance, consistency, and durability. Availability of a storage system defines the ability to access the data during failure conditions. Scalability of a storage system can be measured by a number of criteria, the ability to scale the number of clients, the ability to scale throughput or number of operations, the ability to scale the capacity in terms of data stored, of a single deployment, or the ability to scale the number of components. Similarly, the performance of a storage system can be measured against different criteria, latency to perform a storage operation, the number of storage operations that are possible per second, and the throughput of data that can be stored or retrieved per second. Consistency attributes of a storage system refer to the ability to access newly created data or updates to the same after it has been committed. This applies to both read operations and any delays that occur between performing the data storage operation and the data getting committed. Systems that have delays are defined as being eventual consistent. If there are no delays, the system is defined as being strongly consistent. Durability is affected by the data protection layers, level of redundancy, the endurance characteristics of the storage media storing the data and ability to detect corruption of data and ability to rebuild or recover the data. Next, please. There are several storage layers that can impact the storage attributes. For example, rather than directly access resources, a hypervisor can provide access to resources, which could add access overhead. Storage topology describes the arrangement of storage and compute resources and the data link between them. This includes centralized, distributed, shorted, or hyperconverged topologies. Storage systems usually have data protection layer, which adds redundancy. This refers to RAID, erasure coding, or replicas. Storage systems usually provide data services, in addition to the core storage functions, including replication, snapshots, clones, and so on. Storage systems automatically process data on physical storage layer, which is usually non-volatile. It has impact on overall performance and the long-term durability. Next, please. In this diagram, we can see that workloads consume storage through different data access interfaces. There are two categories of data access interfaces here. We call them volumes and API. CO has interfaces for volumes, which supports both block and file system. In Kubernetes, there are two volume modes, file system and block. File system mode allows workloads to consume file system directly. Underneath, it can be either file system or block. Block mode allows raw block device to be consumed directly by the workload. Under API, we have object store API that stores or retrieves objects or blocks. It is usually a HTTP interface. It has distributed architecture. It is optimized for capacity, durability, and scalability. It would also have a high latency and high throughput. Note that there is a Kubernetes Sieg storage subproject called COSY, which introduces Kubernetes APIs to support orchestration of object store operations for Kubernetes workloads. Therefore, bring in object storage as the first class citizen in Kubernetes, just like file and block storage. It also introduces container object storage interface or COSY as a set of GRPC interfaces for provisioning object stores. It is targeting AFAR in Kubernetes when the R22 release. Under API, we also have key value stores, which use an API to store retrieval values from stores based on a key. It supports strong consistency. It is typically used to store state or configuration for distributed systems. On the API, we have databases. Databases are typically accessed through an API. In the past, the term database used to be synonymous to a relational database. However, there are now many new SQL systems as well as specialized ones like corrupt databases that get categorized as databases. In the meantime, existing relational databases such as Postgres SQL and MySQL have been going in the opposite direction, allowing storing data without a fixed schema. Not all databases are cloud native. Some databases may not be inherently built to run in cloud native environment like Kubernetes. This can typically be addressed with additional tooling like the use of proxies and orchestration systems that allow them to better suited to run in a cloud native environment. Next list. Now let's take a look of the orchestration and management interfaces. This diagram shows workloads consume storage through data access interfaces. There are two ways for storage system to interact with container orchestration systems. The darker green box here control plain interfaces refers to storage interface directly supported by seals, including container storage interface CSI, Docker volume driver interface and so on. Note that Kubernetes in the Kubernetes entry volume plugins and the flux volumes are deprecated Kubernetes six storage is working on migrating entry volume plugins to CSI drivers. CSI is an industry standard to define a set of storage interfaces so that a sort of vendor can write one plugin and have it work across a range of container orchestration systems, such as Kubernetes. CSI has three GRPC services, controller node and identity services. Identity service provides info and capabilities for plugin. Controller service supports create and delete volume create and delete snapshot and attach and detach volume and so on. Note service supports one and amount volume. Expand volume and volume house support are in both controller and node services. The orange box here is called frameworks and tools. This is an extension of control plain interfaces. In addition to provisioning, this interfaces could provide functionalities such as discovery, automation, data services such as data protection, disaster recovery, data migration and data lifecycle management and so on. For application API, including key value store and databases, CEOs currently don't have direct interfaces for it yet, but some frameworks and tools have support for them. For example, Rook supports Cassandra. Vitas has an operator to manage my SQL clusters. Now I'm going to hand it over to Alex to talk about the performance white paper. Great, thanks, Ling. Once the SIG had put together the white paper, the storage white paper that Ling has just summarized, we decided to look at some of the attributes and dive into a bit more depth for some of the detail relating to the attributes. One of those attributes of course is performance, which actually of course does tie in in many ways to things like consistency and availability and scalability too. We realized that the performance was one of those hard things to understand and benchmarking and understanding the performance of the system was fairly complex. So what we decided to do was to dive in and write the documents that covered some of the common concepts for measuring the performance and benchmarking for both volumes and databases and we focused on those to start with and we will probably add other types of storage in the future. One of the things that we realized as we were talking about the different options and tools that could be used to measure performance and benchmarking within cloud-native environments was that there actually is a number of problematic common pitfalls that a lot of people fall into. So we decided to spend quite a bit of time documenting some of these potential issues and some of the things that it's useful to be aware of when you're measuring performance of different systems, especially when you're comparing the performance of different systems. Of course, it's important to understand some of the basics. When Jing was describing those attributes, we could see that the attributes can be measured across multiple accesses, perhaps operations per second and also throughput. And it's probably fair to say that you need to have an understanding of your use case to be able to understand which of operations and throughputs are more important to your environment. So for example, analytics might be very focused on throughput in terms of megabytes or gigabytes per second, whereas databases or message queues, for example, might be much more heavily dependent on being able to implement a large number of operations per second. And of course, you know, we saw the different attributes and the different layers in the storage paper and that of course translates to different challenges in performance too. So understanding the topology, like for example, is the data local or remote can affect performance quite dramatically. The different topologies in terms of sharding or hyper converged as well have similar sort of impacts. Data protection, having commonality on data protection is another key aspect. So whether the storage system is implementing some sort of replication or perhaps erasure coding has a big factor in the performance data reduction can also impact performance in many different ways. So for example, if a storage system is implementing data reduction in terms of compression or deduplication, it's important to understand the type of data that you're using to store that system because if your benchmark is storing all zeroes for the sake of argument, you know, that compresses particularly well and gives you a false reading in terms of the performance. And of course, if you're running in the cloud and you're implementing services like encryption, that's also a factor to be aware of. Another big factor which is poorly understood is the concept of latency. So how you access the data and how the data is protected all impacts latency in terms of how long it takes to implement a specific operation. That can be measured in microseconds or milliseconds typically. And that gives you an idea of the number of operations per second. But very often, if you're thinking about operations on a website or the number of database transactions that can be run through a system, latency is often the key measurements that you'll want to focus on is that the low latency has a direct relation to the number of transactions per second that the system can implement. Of course, the performance is also dependent on the concurrency of the environment. So understanding things like the queue depth sort of volume and how many clients are issuing requests in parallel and how many and how many back ends the the storage is sharded or replicates the cross makes makes a huge difference. So if the application is able to utilize the concurrency within the storage environment, then you can maximize the number of operations or throughput. But if the application is very serialized, for example, then then it can't make use of that concurrency. One other big factor is is caching. This can happen at multiple layers within the storage within the storage topology, starting from, you know, the operating system layer and file system caches all the way down to, you know, different storage layers and different storage subsystem layers. And caching is one of those things that often catches people out when they're doing when they're doing benchmarks. And that's because for practicality reasons, they might be testing volumes or databases of a small size to allow to allow the benchmark to happen easily. But of course, if the data set that you're testing is significantly smaller than the memory of the nodes that you're that you're running that load on, then the reality is you're probably making a lot of benefit. You're getting a lot of benefit from the cash and you're probably testing the speed of the cash as opposed to the speed of the storage system. So that's, that's, that's a key factor. And of course, when you're trying to do apples for apples and comparisons, being able to manage the environment and get dedicated. Compute and rhyme and storage QoS for for your environment is obviously going to be key, but also don't forget, you know, that often storage systems nowadays, especially with extremely fast SSDs and then VME disks can run at hundreds of thousands of of operations per second. And often the client executing the tests might also be the bottleneck in your in your in measuring performance or or the environment and not the overall storage system. So the important takeaway out of all of this is run your own tests and your own environments with your with your own applications and try not to use published results. Because unless you actually understand all of those test conditions and all of the potential grotches you might have, you might not be comparing apples to apples. The white paper that we're developing is is open for comments. We really, really appreciate any contributions or comments to to the document. We're also working on another document relating to availability and disaster recovery. This is this is a document that's very close to one of our techniques hearts Raphael who's who's been focusing on this for us. We talk about we talk about availability and consistency for example in in the storage white paper but but this document aims to go down a bit further and look at some of the architecture considerations for implementing disaster recovery in cloud native environments. So when we talk about high availability, we're often asking the question, you know what happens when a component in in a failure to aim is is lost so so perhaps you know a server or a network connection or or or something like that. So the high availability is a property that allows the system to continue to work in the presence of of some of these failures. When we talk about failure domain, it's, you know, we're looking at more than one individual components, you know, so we're looking at multiple nodes or cluster or perhaps an entire data center. And so when we talk about disaster recovery we're now we're now elevating availability to the failure of or the loss of an entire failure domain. So what happens if you lose an entire cluster what happens if you lose a data center or or an availability zone say within within a cloud provider. And the document talks about some of the considerations around availability versus consistency with a discussion about the the cap theorem and the different consensus product protocols like raft and taxes. And we and we summarize you know how different solutions and different databases and different platforms optimize for implementing consistency guarantees or availability guarantees because you can't obviously with with the cap theorem. You get you get two out of three effectively. And we talk about the anatomy of a stateful application and how this translates to some of the some of the DR architectures so so you know starting with the API layer coordination layer on the back end and a storage layer that may implement additional replicas for availability and charts for for scaling. But the idea here is, and this is just, you know, a sample reference architect. The idea here is that some sort of load balancing capability will will give you access to to to multiple ingresses and front ends that will be able to see a stateful. That will be able to implement a stateful workload and persist the data in a consistent way across, you know, multiple failure domains in this diagram. It's different data centers with the aim being that we're trying to provide an architecture that allows for automated failovers between between the different failure domains. So we have, you know, we're looking to move away from the traditional view of disaster recovery where it's, it's implemented generally by human intervention, where we have recovery point objectives and recovery time objectives, which are often measured in two hours. And where all of the technical capabilities just happen in the storage layer to a more, a more autonomous view, where in a cloud native discovery, sorry, a cloud native disaster recovery process. So we have autonomous processes to fail over across those different failure domains, and if stateful synchronization is happening correctly and implemented correctly with that coordination storage layer, you often you will often be able to reduce the recovery time and recovery point objectives. And, but of course that depends on the entire architecture from top to bottom being implemented to facilitate this disaster recovery. So it's not just the storage layer, but also the networking and the east west communication and load balancing capabilities for that ingress. So again, this document is we're currently in the process of discussing this document in the sick calls. And we have, we have some additional information in presentations that are that can be seen in the sick minutes. And we definitely love to hear from you and love to hear, have your feedback and any comments to the documents would be extremely helpful. And with that, we'd like to thank you for for your time. I think in myself will be online to take some questions. And we'd love to to further on this discussion.