Jiffin Tony Thottan

Scaling your object store is complex and payloads vary in size - objects can be as large as virtual machine images or as small as emails. In behaviour - some are mostly reading, writing, and listing objects. Other payloads delete objects, and some keep them forever. Using CPU and RAM to autoscale the pods horizontally or vertically is limited and may adversely affect the system. Treating our object store as a queueing system: converting HTTP requests to actions on disks may be the solution! Please note that this session was originally scheduled for 18:30.

In this talk, we would show how we use KEDA and Prometheus to track the backlog of work in an object store system orchestrated by Rook and to autoscale the object store pods based on different metrics. We show how autoscaling is impacting the performance and resource utilization in the environment by taking Ceph’s object store frontend (the RADOS Gateway daemon) as a use case. We will demonstrate how to use KEDA and Prometheus to solve a scaling problem that cannot be quickly resolved by the traditional HPA (horizontal pod autoscaling). We will show how the Rook operator orchestrates the different parts of the system. Attendees will learn how to use cloud-native tools to perform autoscaling, better utilize resources like CPU and I/O and increase the performance of their solutions.

For applications in Kubernetes, CSI provides a way to consume file/block storage for their workloads. The main motivation behind the Container Object Storage Interface is to provide a similar experience for Object Store. Basic idea is to provide a generic, dynamic provisioning API to consume the object store and the app pods can access the bucket in the underlying object-store like a PVC. The major challenge for this implementation there is no standard protocol defined for object and the COSI project need to be vendor agonistic. For example, in the case of RGW, the application can request for S3 bucket and Swift bucket from the same ceph-cosi driver. Ideally, the Kubernetes resource for the bucket can be migrated to the different cloud if the drivers support it and the application can seamlessly continue with the same k8s object. It won't handle the orchestration/management of object store, rather it will be another client and provide bucket access on behalf of applications running in Kubernetes. A similar session was given in last FOSDEM'21, but the whole project went through design changes and will share that information.

Kubernetes graduated Container Storage Interface (CSI) to GA status in v1.13. Since CSI’s origin, it has evolved to support a large number of vendors and storage formats. It has brought the industry together in consensus about the best practices in storage. However, CSI’s major limitation is that it only supports Block and File storage. The rapid growth of Object storage means that a growing share of the ecosystem is currently using ad-hoc solutions to leverage this new technology. Object storage is a fundamentally different paradigm where data is accessed over the network rather than locally. It allows applications to remain stateless while offloading state into a black box over the network. Object storage is the key enabler for cloud migration. This paradigm, however, does not have a standard mechanism for consumption in Kubernetes. COSI fundamentally exists to enable the natural consumption of object storage with Kubernetes.

In this talk, we discuss our efforts in bringing object storage into the forefront of Kubernetes and introduce the Container Object Storage Interface (COSI) and cover: - Why COSI is needed for Kubernetes - Best practices for using COSI - Designing apps to leverage COSI - The COSI architecture, and how to contribute to the project.

The NFS is old but simple protocol existed from long back and it is one of most widely accepted protocol in linux systems. NFS-Ganesha is user space nfs server. This talk will helpful to anyone who wants to run their day today application on nfs. NFS-Ganesha has plug-able architecture in which any file systems can easily added, currently it supports Gluster, Ceph(FS/RGW), GPFS etc. There are a lot of features and discussions happening on the community. This talk will help to provide update whats happening on the community

NFS-Ganesha is a user-mode file server for NFS (v3, 4.0, 4.1, 4.1 pNFS, 4.2) and for 9P from the Plan9 operating system. It can support all these protocols concurrently. The project was started around 2009 and it got well matured over past few years and includes participation including CEA, IBM, Red Hat. There are a lot protocol specific features added including LABELED NFS, Delegations to nfs-ganesha layer. The is workload specific changes made to nganesha layer which includes async op and non blocking io's. There are other projects like storhaug which integrates the nfs-ganesha to ctdb and so on. The session will touch up briefly on all the new improvements happening in nfs-ganesha and how it can be consumed in different scenarios.

GlusterFS is an open source, software defined scale out distributed filesystem which resides in user-space and typical runs on any commodity hardware. It has a stackable architecture so that it is very easy to introduce a new feature. When storage (in any sort) comes into picture, security and privacy are two important features which are of concern to everyone. SELinux is one among the trending facilities which provides both. From the server-side view GlusterFS works well in SELinux environments, but this does not address SELinux support for the contents stored on Gluster volumes. This presentation will cover one step further; how an end user can use SELinux context over Gluster volumes. In the world of Storage As a Service this is a feature that everyone will love to have.

This talk will cover two open source technologies SELinux and GlusterFS. GlusterFS is software defined storage. SELinux otherwise known as Security Enhanced Linux is security module available in linux kernel through which security policies can be defined. Although it is widely used in linux world , no one has tried it with a distributed file system.So why it is important for software defined storage or in distribute storage ? The user specific security options available for end user is always limited(one of them is acl). First of all it is an additional security flavor for the end user. From a point of storage as a service, it is one of the key security feature which an end user can directly use. There are different clients which tries to provide this facility. In case of NFS, Labeled NFS is effort put on nfsv4 protocol which avails the same.

The entire talk covers how SELinux feature can be implemented in a distributed file system, taking GlusterFS as an example. GlusterFS has a stackable architecture so that we can easily plug this feature. Each layer in this stack is known as translator. In case of SELinux a new translator will introduced at server side. The SELinux context are stored at backend as extended attributes named as "security.selinux". So this translator will handle all the getxattr/setxattr calls from the clien. Another important point to be noted is there will SELinux context for gluster process in Linux environments. So this contexts should be mess up with files stored in gluster volumes.

This project is planned for gluster 3.10 release. So it will be a good platform to get early feedback/suggestion/contribution for this feature.