 Hi everyone. Yeah, I got the post lens slot and the challenge is accepted. I have a Spider-Man slide coming up. So, those who are sleeping will still get up and it is a 15 minute talk. Who am I? I am Raghuntha Thalur as he just said. I work for Redat. I have been working with Gluster. It is a software defined storage for about 4 years now and for the past few months I have been working on containerizing Gluster and also making Gluster the de facto storage system for containers. And the talk today is about this. Basically how not to do this. When I heard the term persistent storage for the first time I was curious and a little confused. Isn't storage always persistent? Why do we need to call it as persistent storage? So in container world in the container platform that is required and the reason is if your ports are your containers then your nodes from Kubernetes or any other container platform are different ships. When you port a container from one ship to another you have to ensure that the storage is also ported otherwise you risk putting it down into the water. So we will tell you how not to do this and what is our solution for it. Why is this an interesting problem to solve? So a survey which was conducted recently we asked admins what is the most challenging aspect of setting up a container platform and 25% of them said that it is persistent storage. We do not know how to get this right in container platform. Another survey said that it is the complexity of setting up persistent storage which is most compared to even the scale or the cost problems of persistent storage. The same survey we also asked okay so it is a problem and so what are you trying to do? How are you trying to solve this problem of persistent storage? They said okay we considered everything but I think we will go with the existing sand or the nasa appliances we have at least 33% said we will try to use some software defense storage but a very low number only 18% replied saying that we will try to have something which is hyper convinced with my container platform something which is embedded into my content platform and this is a very low number in my opinion a good system is a system which is complete by itself. It should be coherent and if you are trying to glue in two different systems to get a solution it is probably not the right way to do it and that is what this solution will try to solve. For those of you okay so persistent storage as you looked at the slides why is it different? Why is storage that much of a problem when it comes to container platform because storage is not a commodity like CPU cycles and memory are when Kubernetes it is already solved you will get the same number of CPU cycles and memory when the pods move from one container one node to another that is not the case with storage and because it is not yet a integral part of container platform you also have the problem that it requires some extra management effort sometimes even a extra storage expertise what happens in this case is that you have two admins one admin who is maintaining the Kubernetes cluster or the container platform cluster and the other admin who is trying to do only the storage part there and as we saw in the previous slide already most of the times storage is kept external to the platform this is again a problem so before I go into the solution I will have to recap through how you do persistent storage in Kubernetes it's a very simple thing when you want persistent storage for your application you claim for it it's called persistent volume claim you write a spec which is I need this much of space with this access mode and it should come from this storage class this is a request that you send to Kubernetes it will satisfy the request based on the inputs that you gave once the request is satisfied it's called that the PV is now bound once the PV is bound you use it in your application part this is a sample application part spec for engine x all we need to do here is mention what is the name of the PV claim that you want to be bound with this and where you want it to be mounted and that's it so this is how persistent volume works in Kubernetes it's similar for other container platforms too once you know how to use it let us go into the solution let's take example of a typical Kubernetes cluster that you have with three nodes I have one master three node setup now depending on whether it's a private setup or a public cloud setup you will surely have some local disks on the nodes or you might have some block instances on each of the nodes so these green shapes circles are the local disks or the EBS instances once you have this you run a cluster pod on each one of them you create a cluster cluster out of it and now the cluster cluster will aggregate all the storage from all these nodes and will make it look like a single storage system we also deploy a hackety pod here which is the intelligent cluster volume manager that can be run on any of these nodes and it is now made aware of the cluster cluster lastly we have a cluster provisioner it comes with Kubernetes it will be running on the master so whenever a PV claim comes in it is given to this provisioner the provisioner knows how to talk to hackety pod and satisfy a PV claim this is all you need to get things working to use it say you deploy engine export somewhere here the engine export will now talk to a cluster volume plug-in that knows how to talk to the cluster cluster and the data is available everywhere if your engine export moves from node 3 to node 1 it will get the same data there too so this is the solution yeah I know it looks a lot many pods with so many connections and we have solved that too so let's recap the components before I show you how to set up so from Kubernetes side we have a cluster provisioner which knows how to satisfy a PV claim we have a mount plugin which knows how to provide that storage to a application pod cluster cluster is the storage component it is the manager for all your storage which can integrate all the disk hackety is that orange pod that we saw that's intelligent enough to translate a PV claim coming with a storage requirement into a cluster volume and lastly we have gk deploy this is the tool which will simplify the process of setting this up you don't need to run so many pods separately all you need to do is run this tool with a proper input and it will do all the setup for those of you who are not aware of cluster cluster is a storage system it is scalable but this is a better definition in my opinion so what we do is we aggregate local file systems from where from multiple machines we aggregate them we call that cluster of machine as cluster storage pool and we let you aggregate in multiple configurations if you have redundancy requirements please satisfy that if you have resource constraints you don't want to waste too much of storage space then you can use erasure coding so the configurations are many and you can use the task per your requirement there are some added features like snapshot you can take snapshot of a volume you can also use encryption on the wire and we have bitrot and protransistor and it's not only our cluster native protocol which you can use to access it the well-known other protocols like NFS and SMBR supported you also support Swift okay so now let us move to how to setup as I told you it's a single command to run you just give a input saying how your cluster is made up of the container platform this setup is similar to what I showed in the diagram there single master three node setup there are no pods running as of now and this is the input file the input file is very simple you just need to tell me which are your Kubernetes nodes what are the IPs and the hostname and what devices on those nodes are free to be used by cluster so in this sample file I have three nodes each of them having three disk devices we also have a concept of zone this is similar to the failure domain of Amazon so if you have VMs running in each zone and this zone then you can specify that here and that will be taken as an input when we create a volume we will try to make sure that the replica starts spread over different zones so that you have better availability you can reuse the same concept for private clouds by mapping your zones to the power racks that you have okay so that's the input file you give that input file to this tool and the option minus d is used to specify whether you want us to deploy cluster pods or not if you have already deployed cluster to some other means you can skip this part you will have to open the right number of ports it varies from each setup so that you will have to do manually before you run this tool okay so we now started deploying cluster pods we labeled the right number of nodes which meant which are meant to be running cluster is here deployed as a demon set because it is using this it cannot migrate from node to node we have to make sure that the pods always start on the same node now we told akt what the devices are akt is deployed and it's now running so you can see three cluster parts up and running you can see one akt board up and running the video was here played at two x speed but it's only 48 seconds so the whole deployment happened in less than two minutes and this is all you need to do to have a hyperconvert storage up and running in your Kubernetes cluster that's it so there is one small task that I admin has to do before he can ask the app developers to start using it which is common to any other storage system in Kubernetes you have to define a storage class so the cluster cluster is up and ready akt is up and ready you have to now tell Kubernetes this is my Kubernetes cluster this is my cluster cluster and you have to connect them as we saw the connector is called provisioner that's done using a storage class we create a new storage class here we name it as clusterfs we use the provisioner clusterfs we name it as myse and we say okay the provisioner needs to talk to akt at this url the url here is the only important thing that you need to make note of when you run the previous tool the tool would have given you a url you have to use this create a storage class that's it so here the admin's work ends completely now he's free to relax he or she is free to relax no more work from the admin you have to just let your app developers know what's the name of the storage class that you have created from an app developer perspective if he or she knows the concept that I explained about PV claim and PV from Kubernetes they will be able to use it they need to know nothing about cluster here so this is my PV claim I name it as my pvc and I refer back to the storage class that the admin has created by mentioning it here I want to use it from myse I want to GB of space and the access mode will be redirect menu do you when a PV claim is satisfied it is said to be bound so now we have it bound here to show you that it really used luster in the back end what we can do is we can use Hector CLI to list the volumes so the volume had come up this is a typical application part that you have here all you need to do is mention the PV claim that you use to create your volume and you say where it should be mounted let us create the application part and see if it really uses luster in the back end so the application part my app is running now and it has no data in index.html because we gave it a empty volume from cluster what we do is we write hello world into it and see if it shows up when we do a curl there it is this still does not prove that it's coming from cluster so let us do all the investigation what's required so what we do is we now look into the mounts of this application part we see that fuse.cluster first mount is here so the cluster of this volume is found inside the application part we can also verify from the Gluster pod here we go into the Gluster pod and look into one of the brick directories a brick is a unit which makes up volumes so we go into one of the bricks and see what it has in index.html it has hello world so this is how it works I have not told you how we did this but this is sufficient for admin or a DevOps guy to set up a Gluster cluster hyperconverse with Kubernetes in less than a few hours with all the investigation you need to do and it should be easy for any application developer to start using it we have many more features coming up we have file support already this is what I showed you as a file support we have block and object store coming in soon in the next release we have more volume management features up we have also reduced memory footprint because obviously if you are running storage ports on the same nodes where you are running application parts you want as much money free for the application parts so we have done a lot of work here to reduce the memory footprint depending on how many bricks you are going to run or how many volumes you have created you can get up to 5x benefit there were suggestions for auto discovery of nodes because many of you might be using the auto scaling feature from AWS so there are plans of using the node labels to automatically take in the nodes for Gluster cluster and we are working with Kubernetes for the API for snapshot once that is ready we will also have it in okay that's all I had from the talk any questions when a new node is added to Kubernetes if application port runs there it can always use cluster automatically we don't need to do anything admin does not need to do anything if you want storage from that new node to be used in the cluster cluster as of today it's one single command that you need to run a kt cli add node and you give the IP of the node and it's inherited with auto discovery it will be made automatic you can pre-define what label we should be looking at and based on that we will automatically take in the node whenever it's joined demon said because cluster ports were running on all the three nodes here so the cluster part which was started on node one even when node one is rebooted should not move over to node two and node three yes the demon set need to be modified now to so the demon set uses labels to identify which nodes the demon set should be running on so all we need to do is when node four is added we have to label it appropriately and Kubernetes does the rest of the work yes it will we won't label it automatically you have to tell us to label it or you have to label it yourself yes once you do that it will automatically start the port there yeah hi so i had a question i have two questions right so one of them is regarding the performance impact of snapshots in relation to Gluster FS because i have i'm coming from a background of ZFS in which snapshots are like instant now in this case since it is spread across the network what is the exact yeah so Gluster uses LVM snapshot in the backend to take a snapshot the barrier is created for a very small amount of time and we take a snapshot in time it has no performance impact after the snapshot is taken when the snapshot is taken it there will be a my point was like for example if i'm running running it in a production environment yes and i have access to data yes i do not want any at any moment in time that my data is not accessible by my application yes so what in terms of snapshot what happens at that moment will i still have access to my data all the time you will have okay the second question was regarding partition tolerance in case of ZFS sorry in Gluster FS yes suppose one of my nodes goes out goes out crashed ebs volume corrupted whatever yes what does what is protected what what protects it you can always configure it in various ways but the demo i did today with the default setting what we do is we create in replica three mode and with the quorum of more than 50 percent so what that means is if i three node cluster if one of the node goes down you can still do read and write using the other two nodes and guys just take this outside yeah everyone our next